Notons, qu’une demande de modification (change request) a déjà été émise par Panagiotis A. Vretanos (éditeur de la standard WFS 2) en vue d’intégrer une interface REST à WFS. Cette demande est même très complète puisqu’elle comprend le projet de spécification. Par ailleurs, ESRI a déjà proposé que ses spécifications de GeoServices REST (que vous trouverez ici) soient promues au rang de standard de l’OGC.

Ce groupe de travail, avant même d’être officiellement formé, a déjà du pain sur la planche !

Dans ce document de plus de 200 pages, ESRI nous présente une variété intéressante de services web :

• Map Services : il s’agit à la fois d’un équivalent de WMS et TMS avec des capacités complémentaires pour exécuter des requêtes sur les objets composant les couches de données diffusées. Ce type de service peut à la fois produire une carte dont l’emprise et le contenu sont libres et des tuiles dont le découpage est pré-établi ;
• GeoProcessing Services : services dont l’interface est calquée sur les capacités des GeoProcessing d’ArcGIS. Ces traitements peuvent être exécutés de manière synchrone ou asynchrone ;
• Geometry Services : services destinés à réaliser des opérations sur des géométries. Ils peuvent être vus comme des GeoProcessing Services avec des capacités restreintes (les spécifications présentent ce type de service de cette manière) : une vingtaine d’opérations telles que la reprojection, la simplification, la généralisation, le calcul de l’enveloppe convexe sont disponibles ;
• Image Services : services publiant une image ou une mosaïque d’images avec des capacités calquées sur les fonctions de rendu et d’export des données raster d’ArcGIS Desktop. Par exemple : sélection des canaux, identification de la couleur de padding, choix de la méthode d’interpolation, méthode de rendu des canaux. Typiquement, ce type de service peut produire une image d’un MNT combinant ombrage et couleurs hypsométriques ;
• Feature Services : services se rapprochant de WFS-T ou du FeatureServer de Christopher Schmidt par leur aptitude à manipuler (sélection, création, modification et suppression) les objets d’une couche ;
• Geocode Services : services de géocodage et géocodage inverse.

Force est de constater que les démarches de l’OGC et de l’ISO ne sont pas les seules possibles pour élaborer des standards. Il est également intéressant de noter que des spécifications de services web peuvent être concises.

Ce document montre également que les principes de REST peuvent être appliqués à un grand nombre de services web géospatiaux (j’entends régulièrement que l’information géographique ne serait pas adaptée à REST et réciproquement).

Il est trop tôt pour savoir si ces spécifications seront implémentées par d’autres acteurs. Personnellement, je trouverais dommage que ce ne soit pas le cas, même si je ne me fais guère d’illusions. Elles devraient au moins alimenter les réflexions de l’OGC sur REST.

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.

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…

Histoire de finir l’année sur de bonnes résolutions pour celle à venir, quelques principes de base de la « Budgetecture » pour partir du bon pied donc.

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

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.