Archive pour le mot-clef ‘AGG’

Fresh meat

Samedi 25 avril 2009

Deux sorties dignes d’intérêt ces derniers jours : OpenJump 1.3 et MapServer 5.4.

Concernant le premier, on note l’arrivée de nouvelles méthodes de discrétisation (moyenne, seuils naturels et Jenks notamment) et d’informations statistiques sur les couches (min, max, moyenne…), ainsi que de nouvelles fonctions d’édition des géométries (auto-complétion des polygones sur tracé existant, simplification de polygones sans incohérence, double fenêtrage synchrone…) qui en font un outil de choix pour tout ce qui touche à la manipulation des données.

MapServer voit quant à lui intégrées les améliorations promises par le Toronto Code Sprint. J’ai fait quelques tests habituels sur des extraits de larges couches PostGIS et Shapefile, et les résultats sont assez troublants. Voici un comparatif avec la version 5.2 pour la génération d’une image de 600 x 600 pixels comprenant deux couches, communes et ROUTE250 sur une zone couvrant à peu près la Gironde :

image générée avec le driver AGG

5.2 5.4
Postgis GIF 0.142 0.159
PNG 0.388 0.386
AGG 0.920 0.707
Shapefile GIF 0.101 0.101
PNG 0.297 0.318
AGG 0.920 0.842
SHP + QIX GIF 0.058 0.060
PNG 0.315 0.284
AGG 0.834 0.606

Il y a à mon avis quelques informations utiles à tirer de ces résultats, qui n’ont pas vocation à présenter des index de performance pure, mais bien à comparer les deux versions dans des situations analogues. Considérons le format GIF comme celui de référence car impactant le moins de temps final de création de l’image.

Premièrement, on note une perte de performances légère (moins de 10 %) entre la version 5.2 et la nouvelle version 5.4 en GIF. Paul Ramsey m’a expliqué que c’est dû au passage à un curseur texte pour parcourir la base de données en lieu et place du précédent curseur binaire, plus performant certes, mais beaucoup plus difficile à maintenir et à utiliser dans le code car devant être manipulé au sein de transactions (et je veux bien le croire…).

Deuxièmement, on note toujours l’avantage significatif du shapefile, a fortiori quand il est indexé. Les modifications indiquées ci-dessus portent le ratio à 1.5 avec un Shapefile standard et à plus de 2 avec un fichier .qix. On peut en conclure que pour obtenir les meilleures performances, c’est cette association SHP + QIX + GIF qu’il faut choisir.

Cependant le rapport s’inverse avec les autres formats, comme si le nouvel handicap de l’accès à Postgis était compensé par une meilleure prise en charge du PNG et de l’AGG/PNG. C’est avec ce dernier choix, l’anticrénelage AGG, que l’amélioration est la plus significative, preuve s’il en fallait que Thomas Bonfort (créateur et mainteneur de l’intégration AGG dans MapServer) n’aura pas fait le déplacement à Toronto pour rien. Mais ce que je ne comprends pas, c’est qu’une image PNG ou AGG semble mieux bénéficier des données indexées (Postgis ou qix) que d’un simple shapefile. Thomas, si tu lis ces lignes…
In fine, 20 % de mieux pour le couple le plus sexy (PostGIS + AGG), c’est une vraie bonne nouvelle.

MapServer, toujours plus vite…

Vendredi 23 mai 2008

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 !

Mapserver vs Mapnik, Round 2

Lundi 10 mars 2008

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.

MapServer vs Mapnik

Dimanche 9 mars 2008

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.

Image MapServer avec rendu AGG

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.

MapServer 5

Mardi 18 septembre 2007

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 standardPNG 8 bits, sans AGG 7 Ko

AGG en mode RGBAGG en mode RGB, 71 Ko

AGG optimisé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.

Petit exemple

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 :
h
ttp://mapserver.gis.umn.edu/docs/howto/agg-rendering-specifics

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