Deux événements majeurs aujourd’hui : la sortie de Chrome, navigateur créé par Google; mais aussi de la version finale de Django 1.0, dont David explique les nouveautés. Mais un peu de patience, l’un comme l’autre ne seront vraiment disponible que dans la soirée…
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.
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.
Après une semaine fort excitante passée à suivre les conférences et ateliers du FOSS4G2007, je profite du temps épouvantable qui m’oblige à rester cloîtré dans la salle commune du Whalers on the Point Guesthouse de Tofino et m’empêche de sortir ma planche de surf pour livrer quelques réflexions sur ce que j’ai pu apprendre ces derniers jours.
Premièrement, concernant les langages de développement, Python fait réellement l’événement puisque c’est le langage utilisé dans les applications les plus pointues et récentes présentées au FOSS. Citons TileCache, FeatureServer, Cartoweb 4, Shapely, GeoDjango, tous ces projets ont privilégié le python en raison de sa stabilité et de son extraordinaire versatilité (au sens anglo-saxon du terme). Java est toujours là, structurant des projets déjà reconnus (uDIG) ou en devenir (un ETL OpenSource présenté par Talend et CampToCamp). Par contre le PHP ne fait plus partie des langages en vue. Encore utilisé largement, s’il apparaît notamment dans des retours d’expérience il n’est plus le fer de lance du développement en WebMapping, dont l’architecture s’oriente vers des bibliothèques puissantes écrites en C, intégrées dans des wrappers python. Cela a été rendu possible par l’intégration de Ctypes dans python 2.5 qui permet l’appel direct de bibliothèques C sans passer par une fastidieuse interface SWIG.
Du côté des geeks, Charlie Savage met désormais en oeuvre du GeoRuby pour faire tourner son MapBuzz, et à créé une liste dédiée au webmapping dans RubyOnRails, que rien ne semble arrêter !
Tout ceci produit des applications plus puissantes, plus stables et plus robustes, notamment dans la gestion de la mémoire et de la montée en charge. Des bibliothèques aussi cruciales que Geos, Gdal, Ogr, Proj peuvent ainsi être utilisées au coeur même d’une application web dont les scripts python constituent une double interface entre les requêtes utilisateurs d’un côté et la manipulation des données à un bas niveau de l’autre. Ceci devrait faire émerger des frameworks cartographiques avec de véritables fonctions d’administration des données, qui sont encore des aspects trop négligés par le monde OpenSource.
GeoDjango devrait montrer la voie puisque ses concepteurs ont montré un vif intérêt à l’idée d’intégrer des notions de règles de topologies à la gestion des tables.
Chris Schmidt et Howard Butler viennent de mettre en ligne un petit site web qui référence les projections EPSG et des projections personnelles, chargées par les utilisateurs du site. Rien de bien excitant ? Et bien si, car ils mettent aussi à disposition des webservices de publication des définitions des projections, aux formats GML, Proj4, EsriWKT, OGC WKT, USGS et JSON. Grâce à une architecture RESTFull, les définitions (ou les ressources, pour utiliser la terminologie REST) sont accessibles par un simple appel d’URL :
http://spatialreference.org/ref/epsg/27572/Proj4 renvoie ainsi un flux texte correspondant au Lambert II structuré selon la norme Proj4.
L’intérêt ? Pouvoir à terme intégrer ces URL en lieu et place des définitions elles-mêmes dans l’utilisation de GDAL ou de MapServer par exemple. Donc un moyen simple d’accéder à des définitions maintenues à jour, sans avoir à mettre les mains dans les fichiers EPSG de la librairie proj, ainsi que de créer ou d’utiliser des projections non définies par l’EPSG.
Autre intérêt du site : bâti autour du framework Django, donc écrit en Python, avec une architecture REST, il montre ce que ces technologies peuvent apporter en termes de simplicité et de flexibilité dans la mise en oeuvre de webservices cartographiques.