neogeo

Le blog dédié à GeoServer publie les éléments de son comparatif annuel GeoServer / MapServer présenté à l’occasion du FOSS4G au Cap. Ce qu’on peut en retenir, c’est que MapServer a repris l’avantage sur la traitement des shapefiles (entre 1.5 et 2 x plus rapide que GeoServer), tandis qu’il reste un peu à la traîne sur l’accès à PostGIS (dans la même proportion). Etonnamment, alors que GeoServer va plus vite avec du PostGIS qu’avec du Shapefile, c’est le contraire pour MapServer. Le travail accompli des derniers mois sur la lecture des Shapefiles a donc payé, et Paul prévoit déjà de s’atteler à l’amélioration de la lecture de PostGIS.

J’aborde souvent dans ces pages des problèmes d’optimisation et de recherche de performances dans l’utilisation de nos logiciels OpenSource favoris. Notre éléphant favori (qui n’a pas très bonne mine sur sa nouvelle photo…) nous rappelle que le choix du compilateur lui-même est source de gain de vitesse. En utilisant ICC, le compilateur C/C++ d’Intel pour les processeurs du même nom, ainsi que quelques routines optimisées pour les traitements scientifiques, les temps de traitement ont été diminués de 40 % sur le traitement de rasters en JPG par MapServer. C’est beaucoup, et ça justifie pleinement les 600 et 200 $ que facture Intel. Des versions d’évaluation sont disponibles. Dès que j’aurai eu quelque temps pour jouer avec, je vous livrerai mes impressions.

Fidèle à ses habitudes en matière de communication efficace, CampToCamp a choisi les derniers jours de juillet pour dévoiler GAS, espérant sans doute que les aoûtiens en prendraient un exemplaire à consulter sur la plage. GAS pour GeoAdminSuite, un ensemble de 4 modules intégrés permettant définition de sources de données, consultation de leur contenu, composition de cartes et publication avec intégration d’éléments d’interface et de contrôle.

Le but de cette application est de permettre la constitution facile d’une application OpenLayers ou Cartoweb par tout un chacun, sans avoir à écrire une ligne de code. Le “composer” livre ainsi le contenu des fichiers de paramétrage pour CartoWeb, ou le fichier .map pour MapServer par exemple. Sauf qu’en l’absence d’éditeur de légende, pour modifier la représentation des données, il faut toujours réaliser cette opération dans le fichier .map, manuellement.

Plus qu’une Release Candidate, la version proposée est donc plutôt une ébauche de ce qui pourrait constituer, un jour, une bonne illustration de l’Arlésienne de la cartographie en ligne : le cliquodrome ultime qui génère mon application carto en 5 mn café en main et mon logo en prime (important le logo) ! Mais le sujet est d’autant plus périlleux qu’il est ingrat, chaque avancée suscitant des attentes de plus en plus difficiles à combler. Inutilisable par un néophyte tant qu’il reste du paramétrage manuel à effectuer, snobé par les utilisateurs avertis qui prétendent aller plus vite à la main, c’est le type même d’application qui demande une gouvernance de fer et une vision claire des objectifs à atteindre. Raison de plus pour saluer une initiative qui n’a vraiment pas choisi la voie de la facilité.

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 !

Entre le 22 et le 25 avril, à l’occasion de la “Semaine Internationale des Applications Spatiales“, ou Toulouse Space Show pour les intimes, une application réalisée par Neogeo pour le compte du Grand Toulouse va être présentée au public sur le stand du Grand Toulouse. Cette application est une maquette opérationnelle de ce qui deviendra la plate-forme Toulouse Open de mutualisation et de partage de données.

Pour la réaliser, dans un délai très serré, j’ai mis en oeuvre ce que j’estime être le meilleur des technologies OpenSource : un back-office en python, s’appuyant sur le framework Django couplé à une (petite) base de données PostgreSQL, un serveur WMS/WFS avec MapServer, une pincée de GDAL/OGR pour la manipulation des données, un serveur de cache avec TileCache, et bien sûr côté client la dernière version d’OpenLayers et quelques composants MooTools pour les menus. L’intérêt principal de cette architecture est le faible couplage des éléments entre eux. En utilisant des standard d’échange (WMS, XML, JSON…) chaque élément peut être remplacé facilement par un équivalent pour peu qu’il propose les mêmes entrées et sorties. Les données cartographiques sont directement exploitées dans leur format originel, en MapInfo .TAB ou en ECW, afin de faciliter les tâches de mise à jour, qui se font ainsi par simple remplacement des fichiers.

Au niveau fonctionnel, l’application propose visualisation, téléchargement, reprojection, changement de format sur une cinquantaine de couches de données différentes, dont une orthophotographie à 12.5 cm, le parcellaire cadastral, un Modèle Numérique d’Elévation (avec export 3D vers GoogleEarth !) le tout filtré selon le profil de l’utilisateur et les territoires qui lui sont ouverts. Quelqu’un peut ainsi avoir le droit de “voir” une couche sur l’ensemble de l’agglomération, mais ne pouvoir en télécharger qu’une partie. Les utilisateurs peuvent aussi intégrer des ressources WMS externes, ou uploader leurs propres données vers la plateforme. Après validation par l’administrateur, celles-ci deviennent alors visibles par tous.

Le principal défi a été de proposer quelque chose de parfaitement opérationnel en un délai très bref (moins de 30 jours). Pour le relever, le recours à Django s’est révélé être un choix particulièrement judicieux tant la rapidité de développement dans cet environnement et la stabilité du résultat sont impressionnantes. J’en ai par contre peu utilisé les templates, afin de privilégier l’évolutivité et l’autonomie du client. Ainsi la plupart des échanges se font en JSON, notamment l’initialisation de la liste des couches à intégrer dans OpenLayer.
Autre gros avantages de l’utilisation de Django, c’est la constitution quasi-automatique d’un module d’administration très complet. A partir de quelques formulaires, l’administrateur peut ajouter des couches, tout en spécifiant leurs conditions d’accès (droits utilisateurs en visualisation/export), d’affichage (AGG ou PNG, tuilage ou pas, niveau de transparence par défaut…) ou encore le contenu des métadonnées (qui se basent sur template ISO-19139 minimaliste).

Le but à moyen terme, après avoir décontextualisé certains aspects liés aux demandes spécifiques du Grand Toulouse, est aussi de placer cette solution en OpenSource, afin de pouvoir en faire profiter le plus grand nombre. A suivre donc. Si vous passez par Toulouse cette semaine, venez faire un tour du côté du centre des congrès Pierre Baudis, ou n’hésitez pas à me contacter directement pour toute information complémentaire.