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

Grâce à un joli mash-up d’une foultitude de sources différentes (MODIS, EO1 mais aussi OSM et Filckr) une application OpenLayers permet de suivre le front des incendies en Californie et de constater l’ampleur des destructions. Un résultat séduisant, qui démontre l’intérêt de la syndication de données géographiques mais dans lequel une bonne légende ne serait cependant pas superflue.

Comme le remarque justement Peter Batty Google vient de changer les règles d’utilisation de son service de géocodage. On passe d’un mode de fonctionnement basé sur un nombre de requêtes journalières par clé à un nombre de requêtes journalières par IP, le nombre limite tombant de 50000 à 15000. Ca change tout, et chacun y trouvera avantage ou inconvénient selon son utilisation du service :

- vous proposez un service de géocodage en ligne ? Chacun de vos clients (au sens informatique, et, peut-être, commercial ;-)) pourra effectuer 15000 opérations par jour. MAIS le traitement devra être effectué par son navigateur, et non plus par votre serveur, car sinon vous n’auriez plus que 15000 opérations à partager entre tous vos clients. Donc les scripts doivent être éventuellement adaptés, de manière à tourner sur le navigateur, en utilisant l’API javascript du Geocoder. Ce qui ne va pas faciliter l’ergonomie, car concrètement cela se traduit par : upload d’un fichier d’adresses sur le serveur, renvoi du contenu du fichier au client (en XML par exemple, ou en JSON), traitement par javascript des adresses, renvoi des résultats au serveur, mise en forme et enfin renvoi au client du fichier d’adresses initial augmenté des coordonnées. Ces multiples allers-retours ne vont pas faciliter la manoeuvre. L’utilisateur quant à lui va devoir laisser ouvert son navigateur pendant tout le traitement, quand l’exécution côté serveur pouvait simplement lui renvoyer par mail un lien de téléchargement quand toutes le adresses avaient été traitées (ce qui donnait une raison très légitime à la demande d’identification de l’utilisateur).

- vous géocodez vous-même beaucoup d’adresses ? Sous réserve de recomposer vos scripts s’ils s’effectuaient sur un serveur (ce qui semble logique pour des traitements de masse), vous allez pouvoir mettre tout le monde au travail, chacun des postes de vos collègues pouvant traiter 15000 adresses par jour. En plus, ils auront même l’impression de travailler en regardant Firefox tourner tout seul ! SAUF QUE… vous avez un proxy ! Pas de chance, vous avez tous la même IP publique, donc c’est en fait 15000 pour toute la boîte. Ce n’est pas demain que vous terminerez de géocoder les Pages Jaunes (quoiqu’avec quelques stagiaires travaillant à domicile…)

Donc l’un dans l’autre, Google nous donne plus de souci que de liberté avec ses nouvelles règles (qui peuvent changer à tout moment, sans préavis, parce que Google c’est gratuit, mais ce n’est ni OpenSource ni Free Software). D’autant que la clé est toujours nécessaire et que le nouveau mode de fonctionnement donne à Google moyen de savoir plus précisément ce que vous faites avec son géocodeur puisque les cas d’utilisation ci-dessus sont facilement identifiables : beaucoup d’IP avec votre clé pour le premier, très peu mais flirtant quotidiennement avec la limite autorisée pour le second. Donc Google sait ce que vous faites, qui sont vos clients et quel est votre volume d’activité. Ne l’oubliez pas !

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.