neogeo

L’intérêt de tuiler un jeu de données raster, c’est-à-dire de préparer des imagettes multi-échelles qui seront exploitées nativement dans une application de webmapping n’est plus à démontrer. Dans le cadre du Google Summer of Code 2008, Klokan Petr Pridal vient d’ajouter un nouveau module de ce type aux outils GDAL : gdal2tiles.

Son intérêt principal est de pouvoir exploiter directement une image existante (ECW, TIFF, MrSid, JPEG, JPEG2000 et PNG) sans passer par le relai d’un serveur WMS par exemple comme TileCache. Une arborescence est alors créée répondant aux principes du TMS (Tile Mapping Service). Publiée dans un répertoire web, elle est alors directement exploitable par les client TMS tels qu’OpenLayers.

Mais ce n’est pas tout. Klokan a également inclus des options spécifiques à la création de tuiles pour GoogleMaps (en projection sphérique Mercator donc) ou GoogleEarth (en WGS 84). Qui plus est, l’application génère automatiquement, pour peu qu’on lui demande, des fichiers html pour une mise en ligne immédiate. Simple mais efficace, même dans GoogleEarth qui exploite les SuperOverlays déjà disponible avec TileCache !

Mais ce n’est pas tout ! Klokan a également pensé à ceux d’entre nous qui ne sont jamais arrivés à faire une simple conversion ogr2ogr de Shapefile en MapInfo… Il prépare MapTiler, une interface  graphique pilotant gdal2tiles pour générer ses tuiles en faisant clic clic clic ! Si c’est pas gentil ça !

Pour les autres, voici les quelques options glanées dans la documentation :

gdal2tiles.py [-title "Title"] [-publishurl http://yourserver/dir/]
              [-nogooglemaps] [-noopenlayers] [-nokml]
              [-googlemapskey KEY] [-forcekml] [-v]
               input_file [output_dir]
-title : le titre pour les metadata xml, les pages web et le KML
-publishurl : URL de publication du répertoire contenant les tuiles
-nogooglemaps : pas de génération de page GoogleMaps
-noopenlayers : pas de génération de page OpenLayers
-nokml : pas de génération de KML
-googlemapskey : votre clé GM pour l’utilisation de la page html GoogleMaps
-forcekml : forcer la génération du KML
-v : mode verbeux.
input_file : fichier à traiter
output_dir : répertoire de création des tuiles

Il faut bien noter que gdal2tiles.py est un module Python, et que GDAL doit donc avoir été compilé avec l’option –enable-python.

Source : gdal-dev mailing list

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.

Phénomène assez inhabituel pour un projet quasi-institutionnel puisque sous couvert de l’OSGeo, le développement de  MapBuilder vient d’être arrêté par son comité de pilotage. Les raisons invoquées sont d’une part l’aboutissement technique de la solution, désormais stable, complet et conforme aux standards; d’autre part la concurrence féroce livrée, bien involontairement, par OpenLayers, tant au niveau des utilisateurs que des développeurs. De ce que j’en constate, c’est aussi la fin d’un modèle de produit de webmapping, associant étroitement les environnements client et serveur. Comme Cartoweb, remplacé par le plus flexible MapFish (qui utilise également OpenLayers), MapBuilder était un produit tout en un, où un client spécifique communiquait avec un serveur idoine. Or, la diffusion des standards (WMS, WFS, mais aussi GeoRSS ou GeoJSON) exige du client que celui-ci soit indépendant d’une quelconque configuration serveur, pour peu que celui-ci puisse lui communiquer des flux répondant aux normes. MapFish client et MapFish serveur sont ainsi deux environnements complètement indépendants, même s’ils sont associés sous une même appellation.

De même, dans mes récents développements pour le Grand Toulouse, j’ai utilisé un framework Python (Django) sur le serveur (mais ça aurait pu être Symfony, enfin, presque…), et le même client que tout le monde, OpenLayers. L’intérêt d’OpenLayers, et la principale raison de son succès (voir aussi l’API du Géoportail…), est qu’il sait se faire oublier tout en pouvant intégrer une quantité de types de données impressionnante.

De ce fait, la récente intégration de GeoDjango dans la version principale de Django ouvre des perspectives plus qu’intéressantes. Outre le fait de pouvoir disposer du meilleur framework actuel (sans exagérer bien sûr, cf le lien plus haut), la possibilité ainsi offerte de manipuler (lire, interroger, croiser…) les données géographiques à partir d’un ORM est très séduisante car elle répond aux besoins du moment : stocker la donnée au meilleur format possible (PostGIS, what else ?) pour la diffuser sous quelque format que ce soit (XML, GML, GeoJSON, KML…) pour s’adapter à son contexte d’utilisation.

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