Aujourd’hui, le format par défaut de WFS est le GML. Le standard laisse néanmoins la porte ouverte à d’autres formats. Voici un exemple de requête GetFeature tiré de la version 2.0 des spécifications de WFS et qui demande une réponse en KML :

http://www.someserver.com/wfs.cgi?
SERVICE=WFS&
VERSION=2.0.0&
REQUEST=GetFeature&
TYPENAMES=PLACES&
BBOX=18.54,-72.3544,18.62,-72.2564&
OUTPUTFORMAT=KML

J’ai effectué une petite recherche pour essayer de déterminer si le format GeoJSON est une alternative répandue au format GML du côté des serveurs. Voici quelques exemples de listes de formats issues de services qui indiquent le support de JSON :

text/xml;subtype=gml/3.1.1
application/csv
application/javascript
application/shape
application/serialized.feature

text/xml; subtype=gml/3.1.1
text/xml; subtype=gml/2.1.2
application/json

text/xml; subtype=gml/3.1.1
GML2
GML2-GZIP
SHAPE-ZIP
csv
gml3
json
text/xml; subtype=gml/2.1.2

Plusieurs constats :

• le support de JSON et GeoJSON par les services WFS n’est pas rare mais est loin d’être supporté par toutes les implémentations ;
• certains de ces services supportent JSON mais pas GeoJSON ;
• la distinction entre les deux formats est impossible à faire en lisant les « capabilities » du service ;
• l’utilisation des types MIME n’est pas homogène d’une implémentation à une autre. Pour information, une discussion est en cours à l’OGC pour essayer de l’homogénéiser l’usage des types MIME ;
• les implémentations supportent souvent d’autres formats que GML pour l’opération GetFeature mais pas pour les autres opérations (DescribeFeatureType et Transaction notamment).

En conclusion, oui vous pouvez utiliser du GeoJSON en sortie d’un service WFS. Il y a un « mais » : la déclaration de ce format dans les capabilities des services WFS reste imparfaite ce qui peut entrainer des problèmes d’interopérabilité entre clients et services. Par ailleurs, son usage semble se limiter à l’opération GetFeature. On peut également noter que des initiatives au sein de l’OGC visent à définir des interfaces de services web respectant les principes de REST. Les travaux (propositions faites par ESRI et CubeWerx) allant dans ce sens font figurer JSON et GeoJSON en bonne place.

Note pour ceux qui utilisent MapServer : le support de JSON peut être ajouté en sortie d’un service WFS à l’aide de templates (cf. ici).

Qu’est-ce que GeoDjango ?

C’est une extension de Django (ça existe même en français) destinée à gérer les données géographique. OK, mais on n’avance pas là. Qu’est-ce que Django ? Un framework web en Python sous licence OpenSource BSD qui permet de structurer un site web au travers d’une structure Modele – Vue – Template très rapidement. Les modèles sont les tables de votre BD, mais en mode objet; les vues sont les actions et les manipulations diverses que vous voulez effectuer, et les templates sont des modèles de mise en page HTML destinés à présenter les résultats des vues. De plus, Django génère automatiquement un module d’administration des Modèles (des tables donc), qui permet facilement de CRUDer (lire, retrouver, mettre à jour, supprimer) le contenu de votre SI. Un peu comme PhpMyAdmin, mais en mieux !

A ceci, GeoDjango ajoute donc la dimension spatiale, tout comme PostGIS ajoute la dimension spatiale à PostgreSQL. Cela peut fonctionner avec PostgreSQL, MySQL ou Oracle, mais pour ces deux derniers toutes les fonctions ne sont pas encore intégrées (voir la table de compatibilité). Vous obtenez alors des tables spatiales référencées en tant que modèles, et manipuler les objets géométriques (intersection, union, extent, aire…). Ceci grâce au portage dans le code de GeoDjango des librairies bien connues GDAL et GEOS.

Depuis août 2008, GeoDjango fait partie intégrante de Django, tout en gardant sa propre doc et son wiki.

KiCéKiLaFé ?

Justin Bronn, qui va bientôt passer ses examens pour devenir District Attorney (procureur…). A l’occasion de la mise en place de son application Houston Crime Maps, il a choisi Django et y a progressivement intégré la dimension spatiale dont il avait besoin.

Et on peut voir ça où ?

Une petite application de démonstration est accessible ici. Elle a été construite par Dane Springmeyer, Josh Livni et  Christopher Schmidt. Vous pouvez utiliser le login/passwd geo/geo pour vous connecter au module d’administration. Surprise, les données géographiques sont éditables grâce à l’intégration d’OpenLayers dans la page et de votre objet en mode vectoriel !

Sinon la présentation faite par Justin Bronn au Forum Texas GIS en octobre 2008 donne aussi quelques liens.

Ok, c’est beau, mais il y a de la doc ?

Oui, aussi. D’abord un tutoriel : http://geodjango.org/docs/tutorial.html#geographic-data

Un kit d’installation : http://geodjango.org/docs/install.html

Les spécificités des modèles GeoDjango (qui surclassent les modèles standard Django)

La DB-API, qui intègre les opérateurs spatiaux.

et plein d’autres trucs (sur GDAL, GEOS…)

et enfin, un groupe de discussion !

et sinon, tu en penses quoi ?

Je ne suis pas forcément très objectif, mais je suis un inconditionnel de Django en général et de GeoDjango en particulier. Ce que j’apprécie le plus est de pouvoir stocker les données géographiques sous PostGIS et de les manipuler ensuite pour les envoyer vers le client en GeoJSON par exemple après les avoir reprojetées ou simplifiées. Le GeoAdmin, et la capacité d’édition de la donnée qu’il apporte, même si elle est imparfaite, est aussi très agréable.

La prise en main n’est pas très difficile. Les tutoriels de Django et GeoDjango sont très accessibles, et la vitesse à laquelle on arrive à des résultats concrets donne vite envie d’aller plus loin.

De même, dans mes récents développements pour le Grand Toulouse, j’ai utilisé un framework Python (Django) sur le serveur (mais ça aurait pu être Symfony, enfin, presque…), et le même client que tout le monde, OpenLayers. L’intérêt d’OpenLayers, et la principale raison de son succès (voir aussi l’API du Géoportail…), est qu’il sait se faire oublier tout en pouvant intégrer une quantité de types de données impressionnante.

De ce fait, la récente intégration de GeoDjango dans la version principale de Django ouvre des perspectives plus qu’intéressantes. Outre le fait de pouvoir disposer du meilleur framework actuel (sans exagérer bien sûr, cf le lien plus haut), la possibilité ainsi offerte de manipuler (lire, interroger, croiser…) les données géographiques à partir d’un ORM est très séduisante car elle répond aux besoins du moment : stocker la donnée au meilleur format possible (PostGIS, what else ?) pour la diffuser sous quelque format que ce soit (XML, GML, GeoJSON, KML…) pour s’adapter à son contexte d’utilisation.

Le GeoJSON est un format cartographique un peu particulier puisqu’il n’est pas destiné au stockage mais plutôt au transfert des données cartographiques entre un serveur et un client web exécutant du javascript. Car dans GeoJSON il y a JSON (JavaScript Object Notation) ! Hors de ce contexte donc, point de GeoJSON. L’un des principaux intérêts de ce format est de structurer naturellement son contenu en objets javascript un fois interprété par celui-ci. Par exemple :

{« type »: « FeatureCollection », « features »: [{"type": "Feature","geometry": {"type" : "Point","coordinates" : [527904.26, 1844683.7]}, »properties »: {« nom »: »PLACE ESQUIROL », »adresse »: »15 PL ETIENNE ESQUIROL », »numero »: »0102″, »bornes »: »18″}}]}

génère un objet fait de features, features dont les éléments ont une propriété nom, à laquelle on accède par features[i].properties["nom"], mais aussi une propriété geometry caractérisée par un type et un tableau de coordonnées.

Surtout, les protagonistes à l’oeuvre dans ces specifications ont tenu à l’enrichir suffisamment pour couvrir de très larges contextes d’utilisation. On retrouve donc des objets tels que les multi-lignes, multi-polygones, bounding boxes, ou même des systèmes de référence spatiaux qui peuvent être faits de liens http vers une définition externe (sur http://www.spatialreference.org par exemple).

Enfin, ce format a connu un succès rapide, dès avant sa formalisation complète. OGR l’intègre depuis quelques mois, OpenLayers et FeatureServer également, ça va de soi, mais on le retrouve aussi dans des logiciels propriétaires tels que FME de Safe Software. En tout, plus de vingt logiciels l’utilisent déjà sous une forme ou une autre.

Rien ne synthétise sans doute mieux les récentes évolutions de la néocartographie qui s’affranchit des frontières classiques du SIG que ce format, destiné à faire le lien entre la données carto « classique » et des contextes d’utilisation web de plus en plus diversifiés.

P.S. : même Microsoft s’intéresse à REST, le framework .NET 3.5 intègre une classe .NET d’URI templating, pour interpréter directement les URLs Restful selon des modèles prédéfinis…

• utilisation de tilecache pour les rasters
• récupération des données de disponibilité des vélos en temps réel depuis le webservice de l’application de la ville

Et après ? au programme une version dédiée téléphone mobile. Parce que c’est bien de connaître la disponibilité depuis chez soi sur internet, mais c’est mieux de pouvoir la consulter quand on cherche un vélo dans la rue ! Les beta-testeurs sont les bienvenus.

Au chapître des nouveautés webmapping, PortailSIG nous fait découvrir aujourd’hui deux superbes applications :

• Le PLU du Grand Lyon, sous OpenLayers, fluide et esthétique
• Le nouveau portail INSEE des statistiques locales, avec une partie cartographique en Flash(Géoclip). Excellent outil de géostatistiques, d’une grande rigueur et d’une grande richesse fonctionnelle et surtout impressionnante liste de données consultables ET téléchargeables. Dommage que le plugin Flash ne puisse afficher une France communale en entier, car ce niveau d’analyse garde toute sa pertinence à petite échelle.

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.

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

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.