neogeo

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.

Mapstraction intègre désormais un 9ème provider cartographique qui n’est autre qu’… OpenLayers ! Bizarre quand on sait qu’OpenLayers n’est pas un producteur de données mais un client multi-sources, comme Mapstraction justement. Reprenons…

Mapstraction est une classe javascript d’abstraction (d’où le nom, les plus perspicaces l’auront remarqué) des principales API cartos, permettant à partir d’un code unique de manipuler les contenus Google, Yahoo, Microsoft, Map24 etc. Par exemple, pour cadrer la vue sur un endroit particulier, Mapstraction utilise la fonction setCenterAndZoom quelque soit l’API utilisée. C’est la librairie d’abstraction qui traduit en commandes spécifiques à l’API pour vous. Pratique, même si ça réduit forcément l’utilisation de la librairie au dénominateur commun des APIs prises en charge.

OpenLayers, bien connu des lecteurs de ce blog, est une API javascript de cartographie disposant de nombreux types de connexions vers des sources de données (GoogleMaps, YahooMaps, mais aussi des flux GeoRSS, GML, GeoJSON). OpenLayers n’utilise pas les fonctionnalités des API externes, mais au contraire dispose de ses propres contrôles et commandes, ainsi que de couches personnalisées (VectorLayer par exemple).

Mapstraction avait déjà intégré OpenStreetMap, qui n’a pas d’API propre, et devait donc être chargée via l’API Google…

Au final, l’intégration d’OL (qui n’est pas un fournisseur de données) dans Mapstraction se résume à l’utilisation des controles OL dans l’interface Mapstraction, tout en permettant de ne plus passer par l’API Google pour visualiser les données OSM qui sont la couche par défaut chargée avec OL.

Donc, une API qui se sert des contrôles d’une autre API pour manipuler les données d’une troisième, ça donne quand-même un peu le vertige.

via HighEarthOrbit

Il faut bien que je révise complètement mon jugement précédent concernant OpenLayers. Je lui reprochais son approche essentiellement mash-up, d’agrégateur de multiples formats de données (WKT, GML, KML, GeoRSS, GeoJSON) dans une interface certes très ergonomique mais relativement pauvre fonctionnellement, tout en souhaitant voir plus de réelles fonctionnalités SIG se traduire concrètement en webmapping…

Pendant que j’écrivais ces lignes donc, Christopher Schmidt était en train de mettre la touche finale à du WebProcessingService (WPS) intégré à OpenLayers. Ce qui donne  exactement le genre de résultat que j’appelais de mes voeux ! Voilà qui permettra mieux aux “Grey suit guys” de démontrer la qualité de cet environnement et d’en généraliser l’utilisation.

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

En complément du précédent article, j’ai trouvé deux applications cartographiques utilisant le format AtomPub dans un contexte géographique (avec des balises georss décrivant les géométries) :

Le déjà célèbre MapBuzz, dans lequel les objets créés par les utilisateurs et affichés en mode vectoriel sont issus d’un flux AtomPub. Il a l’avantage d’illustrer mon précédent propos sur l’architecture REST : les trois modes d’affichages différents des objets saisis par les utilisateurs (géométries sur les cartes, info-bulle au survol, fichier complète au clic) sont trois représentations différentes (chacune avec plus ou moins d’attributs) d’une même ressource.

Et un prototype fait par Metacarta intégrant la prise en charge de AtomPub dans OpenLayers et s’appuyant sur FeatureServer, sorte de serveur WFS en Python à la différence que les formats de sortie sont variés (JSON, GeoRSS, KML, GML, HTML ou OSM, le format OpenStreetMap). C’est à l’heure actuelle ce que j’ai pu trouver de plus avancé sur la question.