Archive pour le mot-clef ‘GeoJSON’

Ô mon Vélô

Lundi 26 novembre 2007

C’est bien connu, à Toulouse nous ne sommes jamais en retard d’une mode parisienne. Le Vélô, version locale du Vélib’ a donc fait son apparition mi-novembre dans les rues de la Ville Rose, le ô étant là pour rappeler l’inoubliable Ô Toulouse du regretté Claude Nougaro.

Pour permettre aux toulousains de repérer facilement la station la plus proche de chez eux, j’ai réalisé une petite application avec OpenLayers. Les fonds de plan sont issus du service WMS de Geosignal. Les emplacements des stations de Vélô sont issus de la mairie de Toulouse. Pour les exploiter sur le serveur de ce site, dépourvu de serveur cartographique, je les ai transformées au format GeoJSON (au passage, merci à Pierre Giraud pour ses lumières), dans un fichier texte donc, qu’OpenLayers exploite directement depuis une requête XMLHttpRequest. Il y a aussi un fichier KML pour visualiser tout ça dans vous savez quoi.

Du GeoJSON dans OGR

Mercredi 7 novembre 2007

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.

Mise en abyme

Mardi 30 octobre 2007

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

Online Web Processing

Samedi 6 octobre 2007

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.

Du neuf dans les GeoFormats ?

Dimanche 30 septembre 2007

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