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 !

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

Les nouvelles qui tombent de la conférence WHERE2.0 2008 sont assez réjouissantes : une nouvelle API GoogleMaps dédiée au Flash d’un côté, et l’intégration de nouvelles fonctionnalités dans le GoogleMaps “traditionnel” de l’autre. Merci à RenaLId, présent sur place, de nous en avoir fait profité aussi vite.  Mais je ne peux non plus m’empêcher d’y voir une tendance envahissante de la maison de Moutain View. Toutes ces “nouvelles” fonctionnalités existaient déjà ailleurs. Pour du GoogleMaps en Flash, voir par exemple ici et bien sûr là. Et côté intégration des articles de Wikipedia dans GoogleMaps, il y avait déjà aussi quelques essais ici et là. C’est donc un peu comme si GoogleMaps reprenait à son compte les idées à succès nées de la diffusion de son API. C’est bien dans un sens, dans la mesure où ça donnera une audience bien plus large à ces fonctionnalités. Mais c’est dommage aussi pour la créativité des mash-ups initiales, qui perdent désormais tout intérêt. Google ne risque-t-il pas d’assécher les sources qui ont fait la formidable popularité de ses applications cartographiques ?

Benjamin me l’apprend au retour du week-end : O’Reilly France vient de fermer définitivement ses portes. Cet article en dit un peu plus sur les conditions de cette triste disparition. Certes on pourra toujours se fournir auprès de l’éditeur américain, mais avoir ces ouvrages de référence en version française permettait de s’immerger plus facilement dans des concepts parfois ardus. Il est donc plus que temps de profiter des derniers stocks disponibles dans les bonnes librairies, même si à l’avenir les titres les plus porteurs se verront sans doute traduits par d’autres éditeurs français.

L’API du GéoPortail est disponible depuis la semaine dernière dans sa version Bêta. Généralement, une version Bêta sert à tester un produit pour déterminer sa capacité à répondre aux besoins des développeurs et des utilisateurs. Sauf que les conditions générales d’utilisation introduisent les restrictions suivantes :

• la taille de la fenêtre cartographique ne doit pas dépasser 400 x 400 pixels (autant dire du webmapping du siècle dernier). C’est tellement petit que même dans les pages d’exemple ils n’ont pas osé respecter cette clause, la carte y est en 900 x 500. Même la mini-carte est en 500 x 400 !
• le nombre de pages vues ne doit pas dépasser 100 / jour ou le nombre de tuiles chargées ne doit pas dépasser 10000/j. Rien qu’avec les fautes de frappe et les petites optimisations liées à la conception d’une page carto, il va me falloir 1 semaine pour faire quelquechose de potable.

Ensuite, l’API est en fait une surcharge d’OpenLayers. Comme ses collègues britanniques de l’Ordnance Survey, l’IGN a donc choisi cette API OpenSource (licence BSD) à la communauté dynamique pour créer un produit complètement propriétaire. La documentation pointe d’ailleurs directement vers les pages d’OpenLayers pour les composants “standard”. Sauf que sans mention de la version d’OL utilisée, on risque rapidement de se retrouver avec une documentation déconnectée de la version utilisée (une “fork” comme on dit dans le Lot).

Plus rigolo encore sont les “Obligations des Bêta-Testeurs”. On a déjà vu qu’ils avaient juste le droit de montrer une fenêtre de 400 x 400 à quelques membres de leur famille, mais pour pouvoir bénéficier de ce privilège, il faut quand-même respecter quelques règles de bonne conduite (c’est moi qui souligne le plus beau passage) : “A aucun moment vous ne devez effectuer (ou sciemment laisser faire) une utilisation illégale, trompeuse ou mensongère de l’API bêta ou de données du Géoportail, y compris, mais sans exhaustivité, le dénigrement de l’IGN ou du Géoportail ou d’autres pratiques qui peuvent être préjudiciables à l’IGN ou au Géoportail.” Donc pas de banderole genre “Riquiqui, limité, fermé - Bienvenue à l’API Géoportail !” au prochain géo-événement ok ?