neogeo

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

Depuis ce matin sur les étals du geoweb frétille un nouveau specimen dénommé MapFish. Avec pour emblème une magnifique croquette de poisson pané (!) c’est sous ce nom que CartoWeb4, présenté en septembre au FOSS4G, se présente désormais, Cartoweb restant le nom de la branche 3, toujours maintenue depuis la sortie de la version 3.4 fin septembre.

Egalement sponsorisé par CampToCamp, il est vrai que MapFish n’a pas grand’chose à voir technologiquement avec Cartoweb, même si la finalité reste la mise en oeuvre rapide d’applications cartographiques. De fait, MapFish se veut être le chaînon manquant entre la qualité d’un client carto comme OpenLayers et la puissance de traitement qui fait une vraie application de cartographie en ligne. Ceci se fait en deux temps :

- d’une part un client web qui s’appuie sur OpenLayers tout en y juxtaposant des widgets graphiques issus du fascinant framework javascript extjs. On peut ainsi avoir une légende un peu plus raffinée que la simple liste des couches d’OpenLayers, même si le composant à encore des progrès à réaliser (distinction des types de géométries dans les cartouches par exemple). Parmi les widgets on trouve encore un controle de zooms prédéfinis, ou un outil de recherche. Plus complexe, un composant geostatistique permet de réaliser des discrétisations à la volée à partir d’un flux GeoJSON. Ou encore de réaliser des calculs d’itinéraires en se basant sur les fonctions PgRouting de PostGIS développée conjointement par CampToCamp et Orkney. Voilà pour la partie cliente.

- d’autre part, une architecture serveur basée sur le framework python Pylons qui implémente des modules nécessaires au bon fonctionnement des widgets clients, ainsi que le reste de l’application web si nécessaire.

La version présentée aujourd’hui, et annoncée sur la liste openlayers-dev, est une alpha-release. Certes cela se voit, et le récent remplacement du framework js Dojo par Extjs a laissé quelques traces. Mais comment ne pas saluer une initiative qui :

- rappelle qu’une application cartographique sur le web ce n’est pas qu’un tuilage rapide, c’est aussi des données, l’accès à leurs attributs et à la modification de leur représentation.
- s’appuie sur des bibliothèques existantes qui ont fait leurs preuves dans leur domaine (OL, extJs, Pylons), sans chercher à réinventer la roue. C’est du KISS très DRY !
- s’ingénie à fédérer les énergies, non pas en proposant un environnement complet et fermé, mais plutôt une démarche, une dynamique et une boîte à outils.

Voici donc un petit poisson qui a toutes ses chances de devenir grand.