neogeo

La future version 5.2 de MapServer contient bien des améliorations. Outre l’optimisation du rendu AGG dont j’ai déjà eu l’occasion de parler, elle recèle également un patch de Paul Ramsey qui a repris la procédure de lecture d’un shapefile. Jusqu’à présent, celle-ci chargeait l’intégralité du fichier SHX en mémoire, quelque soit le nombre d’objets à dessiner réellement. Sur de gros fichiers, ce défaut avait une incidence réelle lors du rendu de petites portions. Voyez plutôt :

ShapeFile de 1 208 668 objets, 160 Mo pour le .shp et 5.2 Mo pour le .shx :

Carte de 5×5 km, en 600 x 600, PNG 8bits:
Sans fichier QIX :
mapserv 5.0.2 : 0.680 s
mapserv SVN : 0.699 s

Avec fichier QIX :
mapserv 5.0.2 : 0.124 s
mapserv SVN : 0.027 s

Ceci met en avant deux éléments à prendre en considération :

• Il faut toujours utiliser un fichier .qix lors de l’utilisation d’un ShapeFile dans Mapserver. Le fichier .qix est un fichier d’index spatial, comme le GiST de postGIS, qui est construit à l’aide de l’utilisation shptree distribué avec MapServer. Il suffit d’invoquer shptree nom_du_shape.shp pour générer le fichier. Notez qu’il faut reconstruire cet index lors de toute mise à jour du fichier .shp (et non du .dbf).
• La version en cours de développement de MapServer est alors 5 fois plus rapide que la précédente.

Pour aller un peu plus loin, voici les résultats d’un nouveau test, réalisé sur un jeu de données en MapInfo .TAB et en ShapeFile. qui contient 184000 polygones :

Carte Full extent, en 600 x 600, PNG :

MapInfo :
real 0m3.566s
user 0m3.320s
sys 0m0.250s

Shape :
real 0m0.854s
user 0m0.760s
sys 0m0.100s

Shape-qix :
real 0m0.848s
user 0m0.760s
sys 0m0.090s
Extrait de 1 x 1 km :

MapInfo :
real 0m0.064s
user 0m0.060s
sys 0m0.000s

Shape :
real 0m0.170s
user 0m0.060s
sys 0m0.110s

Shape-qix :
real 0m0.058s
user 0m0.050s
sys 0m0.010s

Un des points intéressants est de voir que pour de petits extraits, le driver MapInfo fait aussi bien qu’un Shapefile indexé. Mais sur le jeu complet, le format .TAB est 4 fois plus lent. Aussi que le .qix ne sert à rien lors de l’extraction de toutes les données, ce qui est logique, mais ne ralentit pas le processus non plus.

Donc, s’il fallait faire une conclusion à ces petits tests, ce serait : utilisez la version 5.2 dès sa sortie, mais surtout, utilisez des fichiers .qix dès maintenant !

P.S. : j’ai aussi testé les performances relatives en reprojection selon le format utilisé pour décrire la projection (code EPSG ou chaîne Proj4) : il y a un léger avantage pour le Proj4 (autour de 0.1 s), mais à mon avis pas assez significatif pour abandonner la facilité de manipulation des codes EPSG !

Suite au commentaire de l’article précédent par Thomas Bonfort , principal maître d’oeuvre de l’intégration d’AGG dans MapServer, j’ai refait les tests avec la version trunk de MapServer, future version 5.1…

Ce qui nous donne (accrochez-vous…):

• Sur le Finistère, communes BDCarto(c), AGG :
  real 0m0.271s
  user 0m0.200s
  sys 0m0.080s
• Sur la France entière, communes BDCarto(c), AGG :
  real 0m1.962s
  user 0m1.880s
  sys 0m0.090s

Les performances ont donc été multipliées par 12 (!!!), et sont désormais nettement supérieures à celles de Mapnik pour les gros jeux de données (mais très comparables sur les petits volumes).

Thomas indique également la prochaine possibilité de tracer des traits plus fins dans le rendu AGG, comme c’est déjà le cas pour Mapnik.

Toutes nos félicitations à l’équipe de développement de MapServer et particulièrement à Thomas Bonfort donc, pour cette significative amélioration des performances.

La récente adoption du format AGG par MapServer (depuis la version 5) l’a doté d’une qualité de rendu qui lui a longtemps fait défaut.

Côté rendu, MapServer a ainsi rejoint une solution plus récente, encore mal documentée, mais prometteuse : Mapnik. Bibliothèque C++ avec une API en python, celle-ci a fait de la qualité graphique une de ses priorités. Elle intègre donc également la bibliothèque AGG (AntiGrainGraphics) permettant de lisser les PNG.

Autant le dire tout de suite, les images produites sont strictement identiques, au pixel près ! Cependant, côté performances, Mapnik est un peu plus intéressant, comme en témoigne ce petit test réalisé sur une machine tout ce qu’il y a de standard pour générer l’image des communes de la pointe du Finistère ci-dessus :

• MapServer :
  real 0m0.382s
  user 0m0.310s
  sys 0m0.070s
• Mapnik :
  real 0m0.244s
  user 0m0.200s
  sys 0m0.050s

Mapnik s’acquitte donc de la tâche en 1/3 de temps en moins, pour un résultat, rappelons-le, strictement identique. On retrouve un écart d’autant plus significatif que le jeu de données est important. Sur la France entière, communes BDCarto(c) :

• Mapserver :
  real 0m25.415s
  user 0m25.330s
  sys 0m0.080s
• Mapnik :
  real 0m13.673s
  user 0m13.630s
  sys 0m0.040s

C’est preque un facteur 2 qui sépare les deux applications. Alors, MapServer K.O. debout ? Pas si sûr, car le rendu AGG étant souvent utilisé dans un contexte de tuilage et de cache disque (voir par exemple OpenStreetMap) le temps de génération a certes une importance mais pas de manière aussi critique que sur du rendu “live”. L’AGG est un peu trop lent pour être utilisé dans un tel contexte, et il faut souvent se contenter dans ce cas d’une simple rendu PNG standard. Mais les performances sont alors exceptionnelles :

• MapServer, format PNG 256, communes BDCarto(c) France entière :
  real 0m0.638s
  user 0m0.560s
  sys 0m0.070s

6 dixièmes de seconde pour dessiner les 36500+ communes de France en 600 x 600, c’est remarquable, et peut tenir la dragée haute à bien des SIG desktop (faites vos tests…). Mapnik ne fonctionnant qu’en mode AGG, il ne peut atteindre de tels résultats. De sorte que son rayon d’action se trouve fortement réduit, à la différence d’un MapServer avec lequel on peut jouer avec les différents formats de sortie pour optimiser le rendu ou la rapidité selon les besoins, l’échelle, la couche, le contexte (visualisation / impression) etc.

La version 5.0 de MapServer vient d’être publiée. Elle intègre de nombreuses modifications, même si elle traîne toujours le rustique fichier .map. Un des apport les plus intéressants à mon sens concerne le rendu des vecteurs. Grâce à la bibliothèque AGG (Anti-Grain Graphics), les rendus sont spectaculaires, courbures et contours sont lissés. Mais chaque médaille ayant son revers, les fichiers PNG générés avec AGG sont beaucoup plus lourds, de 3 à 12 fois environ. Voici quelques exemples :

PNG 8 bits, sans AGG 7 Ko

AGG en mode RGB, 71 Ko

AGG optimisé (palette adaptative), RGB, 20 Ko

Ce dernier mode est donc relativement performant, générant de belles images sans faire des fichiers trop volumineux.

De plus, la gestion de la transparence pose quelques problèmes. Seul le mode RGBA permet de disposer d’un fond transparent, alors qu’en PNG standard 8 bits cela est possible. Dans une application OpenLayers, où les fonds doivent être transparents pour que chaque couche soit visible, ça devient gênant car ça oblige à l’utilisation du mode RGBA non optimisé, et donc la manipulation de fichiers beaucoup trop gros. C’est un défaut qui a déjà été constaté par les utilisateurs et qui sera donc vraisemblablement corrigé dans les mois à venir.

Reste qu’en utilisation “classique” de MapServer, le mode optimisé fonctionne très bien et permet de très belles réalisations. C’est aussi un rendu qui sera très appréciable pour les exports PDF.

Côté compatibilité, rien de bien compliqué. Les attributs LABELANGLEITEM et LABELSIZEITEM, ainsi que ANGLEITEM et SIZEITEM disparaissent au profit de simples ANGLE et SIZE placés dans les contextes du label ou du symbole.
Le mot-clé SYMBOL du fichier de symboles est remplacé par PATTERN pour ne plus créer de confusion avec le contenu du fichier .map. Enfin, TRANSPARENCY est enfin remplacé par ce qu’il signifiait vraiment, à savoir OPACITY !

La compilation ne pose pas de problème nouveau. Pour le support d’AGG, il suffit de récupérer cette bibliothèque, puis de faire un simple make, rien de plus. Le configure de mapserver comportera alors une option de plus : –with-agg=/chemin_vers_le_rep_de_compilation. Je vais ajouter ce point à ma documentation au plus vite.

Pour de plus amples informations, voir :

La description des nouveautés et améliorations :
http://mapserver.gis.umn.edu/development/rfc et http://trac.osgeo.org/mapserver/browser/tags/rel-5-0-0/mapserver/HISTORY.TXT
Le guide de migration 4.x -> 5.0 :
http://mapserver.gis.umn.edu/download/current/MIGRATION_GUIDE.TXT/

Quelques tuyaux pour optimiser le driver AGG :
http://mapserver.gis.umn.edu/docs/howto/agg-rendering-specifics

et enfin les sources :
http://download.osgeo.org/mapserver/mapserver-5.0.0.tar.gz