Pour ceux qui ne sauraient pas quoi faire pendant les fêtes et que la lecture de 268 pages de spécifications techniques ne rebute pas, l’OGC diffuse depuis hier un RFC (Request For Comments) sur les spécifications du format KML 2.2. Il y a aussi de belles illustrations dedans, genre “la carto pour les nuls” :
Mateusz Loskot vient de publier un nouveau driver pour OGR, la célèbre bibliothèque d’abstraction/conversion de formats SIG, qui va donc désormais pouvoir accéder en lecture seule à des flux GeoJSON. On en a déjà parlé, le GeoJSON est la version Geo (malin non ?) de la notation JSON (Javascript Simple Object Notation) qui permet d’échanger facilement des objets structurés entre un serveur et un client. Un tableau associatif PHP se converti ainsi directement en un objet javascript.
La particularité du driver de Mateusz est de pouvoir accéder directement à un flux http renvoyant du GeoJSON, car ce “format” n’est pas à proprement parler un format de stockage comme le Shapefile ou le GML, mais bien un format d’échange. Avoir un fichier .gjson serait par là même une aberration ! Le driver ouvre donc une connexion vers un service web délivrant du GeoJSON, et permet alors toutes les opérations habituelles des modules OGR : info sur le fichier et conversion :
ogr2ogr -f “ESRI Shapefile” cities.shp http://featureserver/cities/.geojson OGRGeoJSON transforme en shapefile le flux GeoJson des villes issu du serveur de données.
L’intérêt de cette implémentation est tout naturellement son utilisation dans un contexte mobile, où la limitation de bande passante empêche l’exploitation de “gros” formats tels que le WFS-GML, un petit client pouvant ainsi récupérer les données vectorielles dynamiquement pour une exploitation locale.
Notez bien que ce driver n’est pas encore disponible dans la version officielle de GDAL-OGR, mais uniquement à partir du svn osgeo . Le portage dans la version officielle devrait être faite sous peu.
En complément à un précédent post, le FOSS m’a permis d’y voir un peu plus clair sur les différents formats “interropérables” pour les données géographiques et surtout de percevoir un distinction majeure entre ceux-ci : il y a d’un côté les formats issus du monde géographique et créés pour diffuser l’information géographiques sous la formes de services web : WMS, WFS et donc GML sont de ceux-là.
D’un autre côté, on trouve les formats du Web 2.0 qui intègrent peu à peu la dimension géographique : AtomPub, GeoRSS en font partie. Le KML/Z quant à lui se situant entre ces deux approches : imaginé pour diffuser de l’information géographique (et rien de plus, comme le rappelle Raj Singh), il intègre aussi étroitement la notion d’interropérabilité totale.
Car c’est bien en termes d’interropérabilité que les formats se distinguent. Là où les premiers ont été faits pour permettre à des systèmes géographiques d’interropérer (afficher dans MapInfo une carte issue d’un serveur WMS, crééer un application web à partir de multiples serveurs WMS-WFS différents), le deuxième groupe est fait pour permettre à des applications web d’interropérer, nonobstant leur capacité à analyser ou traiter la donnée géographique. Ce point est central pour la compréhension des avantages et inconvénients de chacuns. Là où un flux AtomPub intégrant des balises de géolocalisation en GeoRSS pourra être interprété par n’importe quel client Atom, qu’il exploite les données géographiques ou pas, le flux GML d’un serveur WFS ne sera correctement affiché sous forme de carte que par des clients dédiés à l’affichage cartographique. Cependant, pour des raisons d’homogénéité et de standardisation, l’AtomPub, tout comme le KML, ne diffuse qu’un contenu attributaire restreint (nom - description de l’objet, même si celle-ci peut-être complexe, de la forme d’un bloc HTML complet), tandis que le GML transporte toute la richesse attributaire nécessaire à une réelle exploitation des données. Les usages sont donc forcément différents. Là où le GeoRSS répond au besoin de “Affiche mes posts dans GoogleMaps”, le GML est porteur d’une réelle richesse attributaire et d’une plus value qualitative évidente, qui se paye par une plus grande complexité.
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.
On pouvait pressentir que l’OGC se prenne d’intérêt pour les petits formats agiles du web 2.0 appliqués aux données géographiques. C’est chose faite puisque l’OGC vient d’ajouter un addendum (sic) au programme de discussions en cours (OGC WebServices Phase 5, OWS5 pour les intimes) sous le nom de “Federated Geo-Synchronisation Services” qui fait tout de suite sérieux. Citation : “In the Federated Geo-synchronization work, participants will help develop standard approaches to using GML application schemas such as GeoRSS GML and GML Simple Features Level 0 with Atom and the Atom Publishing Protocol.” Donc faire du GML simple au format Atom, permettant une syndication facile de contenus géographiques. Youpi.
Via import cartography.