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.

On l’apprend sur la liste de diffusion de l’OSGeo, via un communiqué de son président Tyler Mitchell, l’IGN devient un sponsor associé de l’OSGeo. Même si c’est le niveau le plus bas, à 3000 $, il convient de saluer cette initiative qui apparaît comme une réelle reconnaissance envers la communauté OpenSource dans laquelle l’IGN a su puiser et participer : proj, gdal/ogr dans un premier temps, OpenLayers pour l’API du Géoportail plus récemment.

C’est précisément l’API du Géoportail qui a incité l’IGN a franchir ce pas. Pour la future version, prévue sous peu, il a été décidé qu’elle deviendrait un type de couche d’OpenLayers, à la manière de ce qui existe pour GoogleMaps. Cette décision renforce le niveau d’intégration de l’API dans OpenLayers, et ce faisant le niveau d’implication de l’IGN dans le projet global (résolution de bugs, patches, nouvelles fonctionnalités…). Mais il était difficile à l’IGN de se soumettre aux Conditions de licence de Metacarta, qui, même si elles sont protectrices pour le projet lui-même, en reviennent à soumettre une institution publique française au droit de regard d’une entité privée américaine, damned ! Le passage par l’OSGeo, fondation à but non lucratif, permettrait de contourner cet obstacle, même si Metacarta reste le détenteur final du copyright.

Toujours est-il que les buts des développeurs de l’IGN est clairement de contribuer régulièrement à la solution OpenLayers, afin d’en faire le standard européen pour les Géoportails. A la différence de l’Ordnance Survey britannique, et à ce que la bêta avait pu faire croire, l’IGN se place donc résolument dans le camp de la généricité et de la mise en commun de ses efforts, ce qui mérite un grand respect et de chaleureux remerciements. Que l’été va sembler long, à attendre la nouvelle version de l’API Geoportail…

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.

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 ?

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.