neogeo

Ca semble un peu inouï dit comme ça, mais un brevet a été déposé par A9.com, une société du groupe Amazon.com, concernant un “Search engine system supporting inclusion of unformatted search string after domain name portion of URL”, soit en bon français : “Moteur de recherche acceptant l’inclusion d’une chaine de recherche non formatée après le nom de domaine dans l’URL”, donc quelque chose du genre : http://www.recherche.com/spaghetti bolognaise (les espaces sont acceptés). Voir ici pour les détails. Il y est précisé que le principe breveté concerne la soumission d’une chaîne de caractères à un moteur de recherche si cette chaîne ne correspond pas à une ressource existante.
Est-ce que cela signifie que toute structuration un rien RESTFul tombe dans le champ d’application de ce brevet pour peu que l’URL corresponde au modèle breveté ? Si http://www.communes.com/31555 pointe sur une ressource, ça semble bon, mais si http://www.communes.com/Toulouse passe au travers d’un mod_rewrite qui appelle http://www.communes.com/search.php?q=Toulouse pour renvoyer ensuite la ressource http://www.communes.com/31555, on est bien dans le champ d’application du brevet.

Je ne suis pas spécialiste des brevets, mais je frissonne déjà à l’idée de devoir vérifier si ma structuration d’URL, et donc l’architecture de mon application web, ne tombe pas sous une telle protection. Car si A9.com a pu le faire pour quelque chose d’aussi simple et basique, qui va se gêner ? Wikipedia pourrait deposer les URL en http://xxxx/wiki/chaine_de_recherche par exemple. Enorme bourde de l’USPTO ou nouvel eldorado des verrouilleurs de tout poil ?

Via slashdot

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

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.

GML, KML-KMZ, GeoJSON, GeoRSS, GeoAtom, … stop, n’en jetez plus ! Les formats géographiques vectoriels utilisés par les web services sont foisons. Leur point commun est d’être des formats textuels et non binaires. On perd en compacité ce que l’on gagne en interropérabilité puisque, plus “lisibles” ils sont plus facilement implémentables dans des applications web. Tous sont dérivés du XML.
Le premier, le GML, est le plus ancien. Il est l’oeuvre de l’OGC qui en diffuse les specifications (595 pages quand-même…), et est notamment utilisé dans le procole WebFeatureService qui permet la mise en oeuvre de services web en données vectorielles.

Le KML (Keyhole Markup Language, et sa version Z pour la gestion de la 3D) est utilisé par Google, notamment dans GoogleEarth (c’est KeyHole qui l’a créé, mais c’est Google qui l’a racheté).

Le GeoJSON est à destination des programmeurs. Il s’agit d’un moyen de transférer facilement des “objets” d’un language de script vers le javascript (d’où le nom : Javascript Simple Object Notation), tel quel, avec attributs et propriétés. On le croise moins souvent, c’est vrai, mais c’est parce qu’il se cache.

Les deux derniers sont presques des microformats, issus de la volonté de donner autant de souplesse à l’information géographique qu’à l’information tout court, au travers de la syndication de contenu.

Bon, mais on en fait quoi exactement ? Pour la plupart, ils ne sont que des formats d’échange, les MIF/MID du web en quelque sorte. Seul le KML se distingue par son utilisation native dans GoogleEarth. On peut presque en dire autant du GML, que QGis ou Jump sont capable d’afficher directement. Mais malgré ce, ces formats n’ont pas encore pris la place de “standard” que peut avoir le shapefile d’Esri par exemple. Donc on regarde des KML, on affiche des GML, mais quand-même, on travaille avec des formats classiques du SIG bureautique.

Pourtant ces formats ont d’autres atouts que les fichiers binaires habituels. Pour peu qu’une architecture web adaptée leur soit associée, ils peuvent permettre d’accéder à la donnée géographique d’une manière beaucoup plus souple. Prenons un exemple. Vous avez besoin des contours des départements de la Bretagne. Avec une approche SIG classique, vous ouvrez votre Geofla® avec votre logiciel SIG préféré, faites votre sélection, et réexportez le résultat dans une couche toute neuve (lisez quand-même les conditions d’utilisation du GeoFla® avant ;-)) Pour peu qu’il vous faille ainsi des extrations sur toutes les régions françaises, vous êtes bon pour prendre un stagiaire.

Un service web bien conçu peut faciliter les choses. Imaginez une architecture REST (Representational State transfert, ça fait un peu peur dit comme ça. Voir “Comment j’ai expliqué REST à ma femme” pour en savoir plus, ou l’excellent blog de David Larlet BioloGeek). Elle permet d’accéder à une liste des départements en appelant l’URL http://www.ign-online.fr/france/departements/. La page contient la liste des départements, ainsi que des liens permettant d’accéder à d’autres “représentations” de ceux-ci, en GML par exemple (la notion de ressource et de représentation est fondamentale dans une architecture REST. Ici les départements sont des ressources, proposées sous diverses représentations, textuelle ou géographique).

On a donc :

01 AIN Bourg-en-Bresse
02 AISNE Laon
.
.
.
voir les données en GML, KML, GeoAtom

en cliquant sur GML, on appelle en fait l’URL http://www.ign-online.fr/france/departements/GML/
Mais jusqu’ici rien de bien bouleversant. On récupère un fichier, on l’enregistre, on l’ouvre avec uDig, et on rappelle le stagiaire. Seulement l’application web susdite à d’autres tours dans son sac. A l’URL http://www.ign-online.fr/france/regions/53/departements correspond la liste des départements de la région dont le code INSEE est le 53, soit la Bretagne. Et http://www.ign-online.fr/france/regions/53/departements/GML renvoie directement un flux GML correspondant aux seuls départements bretons.
Ainsi à partir d’une seule couche de données (qui peut être au format shape, TAB, postgis, le tout étant que le langage dans lequel les services web sont écrits permette de les lire. En optant pour Python associé à GDAL on ouvre déjà d’intéressantes perspectives), on démultiplie les usages possibles par la construction de services web spécifiques. Ceux-ci sont faciles à construire, et peuvent même automatiquement exploiter les champs de chaque couche selon un principe clé/valeur (http://www.ign-online.fr/france/regions/53/departements/GML/?dept=finistere renvoyant le contour du seul Finistère). Pour peu que de bonnes métadonnées accompagnent la description de la couche, chacun peut alors bâtir sa propre requête en composant une URL.

Appelée depuis un logiciel SIG bureautique, cette URL devient une ressource géographique, au même titre qu’un fichier shape. Sans compter que des manipulations spatiales sont également implémentables en web services. Les zones inondables à Toulouse ? Facile : http://www.spatialservices.net/intersection/?url1=http://www.prim.net/cartorisque/AZI/&url2=http://www.ign-online.fr/france/communes/31555/ ! Que va faire ce web service ? d’abord récupérer chacune des URLs, puis les charger dans PostGIS par exemple, réaliser l’intersection, et renvoyer ce seul résultat. Qui sera accessible en GML, KML ou autre.

La multitude de formats n’est donc pas un frein au développement de webservices cartographiques réellement utiles. Ils ne sont que des moyens de représenter la même chose. La diffusion de la donnée doit se faire sans a priori sur l’utilisation qui en sera faite (alors que si je mets un shape à disposition, j’impose à l’utilisateur un logiciel particulier, ou la conversion du fichier avant exploitation).

La technologie existe. Manquent seulement des données de référence, un peu de temps, et beaucoup d’idées. C’est celui qui dit qui y est ? Bon, dans quelques temps, vous trouverez sur neogeo-online.net une première ébauche de ces quelques réflexions…

P.S. : le tendance actuelle est quand même au regroupement de ces formats. La participation de Google à l’OGC devrait faire du KML un nouveau standard de fait, laissant au GML les contenus très complèxes, non gérés par le KML. Dans le même temps, Atom semble s’imposer sur le RSS et ses multiples spécifications.

P.S.S. : Peu de liens dans cet article. En fait, je commence à me demander si ces articles où on trouve presque un lien par mot sont vraiment lisibles… Donc pour faire plus clair, voici juste quelques références :

http://zcologia.com/news/
http://blog.mapufacture.com/
http://cfis.savagexi.com
http://cholmes.wordpress.com/

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.