neogeo

Le groupe de recherche GeoSOA, mené par l’éminent Thierry Badard, nous signale la sortie de GeoKettle, que tout estivant ayant traversé le Lot pourra facilement traduire par GeoBouilloire, qui n’est pas destinée à éliminer les impuretés de vos données cartos, mais à réaliser du data-mining en 3 mn chrono !

C’est, pour reprendre les termes du communiqué, une version “spatialisée” de Pentaho Data Integration, outil ETL (Extract, Transform, Load) dédié à l’agrégation de sources de données différentes dans des entrepôts de données. GeoKettle intègre ainsi l’ensemble de la suite décisionnelle Pentaho, afin de donner une dimension géographique tant à la présentation du résultat des analyses (ça c’est facile) qu’à leur exploration elle-même. Pour faire court, la dimension géographique devient une des composantes analytiques, permettant par exemple de consolider les indicateurs en fonction d’entités administratives, ou d’énoncer des contraintes d’ordre spatial (distance par exemple) à leur composition.

Il semblerait donc qu’après le rapprochement entre CampToCamp et Talend, autre éditeur d’ETL OpenSource, le GéoDécisionnel ait le vent en poupe et constitue le nouveau territoire de la géomatique.

Via un message sur plusieurs listes et son blog personnel, Christopher Schmidt vient d’annoncer la publication de la version finale de la spécification GeoJSON, la version 1.0 donc.

Le GeoJSON est un format cartographique un peu particulier puisqu’il n’est pas destiné au stockage mais plutôt au transfert des données cartographiques entre un serveur et un client web exécutant du javascript. Car dans GeoJSON il y a JSON (JavaScript Object Notation) ! Hors de ce contexte donc, point de GeoJSON. L’un des principaux intérêts de ce format est de structurer naturellement son contenu en objets javascript un fois interprété par celui-ci. Par exemple :

{”type”: “FeatureCollection”, “features”: [{"type": "Feature","geometry": {"type" : "Point","coordinates" : [527904.26, 1844683.7]},”properties”: {”nom”:”PLACE ESQUIROL”,”adresse”:”15 PL ETIENNE ESQUIROL”,”numero”:”0102″,”bornes”:”18″}}]}

génère un objet fait de features, features dont les éléments ont une propriété nom, à laquelle on accède par features[i].properties["nom"], mais aussi une propriété geometry caractérisée par un type et un tableau de coordonnées.

Surtout, les protagonistes à l’oeuvre dans ces specifications ont tenu à l’enrichir suffisamment pour couvrir de très larges contextes d’utilisation. On retrouve donc des objets tels que les multi-lignes, multi-polygones, bounding boxes, ou même des systèmes de référence spatiaux qui peuvent être faits de liens http vers une définition externe (sur http://www.spatialreference.org par exemple).

Enfin, ce format a connu un succès rapide, dès avant sa formalisation complète. OGR l’intègre depuis quelques mois, OpenLayers et FeatureServer également, ça va de soi, mais on le retrouve aussi dans des logiciels propriétaires tels que FME de Safe Software. En tout, plus de vingt logiciels l’utilisent déjà sous une forme ou une autre.

Rien ne synthétise sans doute mieux les récentes évolutions de la néocartographie qui s’affranchit des frontières classiques du SIG que ce format, destiné à faire le lien entre la données carto “classique” et des contextes d’utilisation web de plus en plus diversifiés.

De la 3D dans un navigateur web sous Linux ? Non, ce n’est ni Google (dont l’Api GoogleEarth n’est pas encore compatible), ni VirtualEarth (allez savoir pourquoi…), mais notre champion national l’IGN qui innove en proposant désormais la visualisation 3D sous Windows, MacOS ET Linux donc. L’installation du plugin TerraExplorer se fait facilement, même s’il n’est pas encore compatible avec Firefox 3, pourtant désormais distribué en standard dans Ubuntu, distribution phare du monde Linux, mais cependant encore à l’état de bêta release.

Cette évolution a été possible grâce au développement d’un nouveau plug-in au sein de TerraExplorer, capable de télécharger les tuiles raster en WGS84 et de les reprojeter à la volée en Lambert 93 (mais aussi tout autre système de projection géré par Proj). Réalisé par GeoLabs (qui préfère faire des plug-ins que finir son site web…) et notamment Gérald Fenoy, célèbre spécialiste de Gentoo, associé au non moins célèbre Frank Warmerdam, architecte en chef de GDAL-OGR, cette réalisation est une belle illustration de l’apport des logiciels OpenSource à l’information géographique grand public.

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 !

L’intérêt des cartes par anamorphose, ou cartogrammes, ces cartes dont les contours des polygones sont déformés en fonction de la valeur d’un attribut, n’est plus à démontrer (voir par exemple les réalisation de l’IRD, ou l’excellente collection de Worldmapper). Néanmoins, leur constitution et leur mise en oeuvre était jusqu’alors réservées aux spécialistes.

Désormais, tout un chacun peut se lancer dans ce type de réalisation grâce à ScapeToad, petit logiciel OpenSource (GPL) basé sur OpenJump, en java donc, qui propose un assistant intégré. ScapeToad utilise des ShapeFiles comme format d’entrée, mais surtout permet d’exporter son résultat au format SVG mais surtout de tout simplement le sauvegarder en Shapefile. Le résultat peut ainsi être facilement publié sur Internet, de manière dynamique qui plus est, à la différence des exemples présentés plus haut.

Via MapRoom