Toutes nos félicitations à nos deux représentants nationaux, et n’hésitez pas à retrouver leurs prestations dans la rubrique webcasts du site de l’OSGIS 2010.

8:30 – 9:30 : ZOO project presentation to LIRMM’s researchers
9:30 – 10:15 : Business meeting 3LIZ / GeoLabs / Neogeo Technologies
10:15 – 10:30 : Everybody should be there for coffee
10:30 – 11:30 : Intro / Meeting scheduling
ZOO Kernel presentation (ZOOKernelInternal)
ZOO Services demos (OGR, GDAL, GCAL, QRCode…)
Discussions
11:30 – 12:30 : ZOO Project orgnanization (PSC (ZOO Tribal Council), Tribe, Sponsors, Knowledge partners)
ZOO Project objectives (community, buisness, licensing, marketing)
ZOO Development plans (ZOO Server, ZOO Web Client, ZOO Desktop Client)
Discussions

12:30 – 14:00 : Lunch (restaurant to be booked)

14:00 – 15:00 : ZOO Kernel and ZOO Services session
(Brain storming on Kernel Limitations/Enhancements, Services implementation, ZOO Server and REST API)
15:00 – 16:00 : ZOO Web Client session
(Brainstorming on Client architecture, interactions with OpenLayers and other libs, GUI…)

Je sens que je vais passer mon tour sur le Kernel Limitations/Enhancements…

Depuis mon dernier post, ReLuc a mis au point une petite démo, mettant en oeuvre quelques-uns des services actuellement implémentés. Mais la finalité d’un WPS est-elle d’afficher un résultat dans un navigateur web ? Pas que. De mon point de vue, le WPS permet au geoweb d’effectuer un changement de paradigme, au sens où de cartographie SUR le web il devient cartographie VIA le web. La finalité ultime est de pouvoir enchaîner des traitements prédéfinis sur les données distantes (de type WFS), pour récupérer une donnée adaptée à l’usage que l’on souhaite en faire localement, sans avoir à télécharger/manipuler la donnée source. Ceci sans pré-supposé quant au client utilisé. Mais vu l’immaturité des principaux logiciels SIG en termes d’implémentation de client WPS (déjà qu’avec le WMS/WFS il y a des progrès à faire), il sera nécessaire de prévoir un Zoo Client (web ou pas) générique, capable de conserver références des serveurs et des process, de les assembler, et d’en rediriger la sortie vers ce qui convient le mieux à l’utilisateur (affichage, fichier à enregistrer…) De quoi faire sortir le GeoWeb de la « Naïve Geography« .

A la semaine prochaine pour un compte-rendu !

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.

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

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

Via import cartography.

Le KML (Keyhole Markup Language, et sa version Z pour la gestion de la 3D version zippée) 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/

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.

Une solution facile permet de résoudre ces difficultés : la virtualisation. Il s’agit de faire tourner le Linux (ou le Windows) sur une machine virtuelle hébergée sur l’autre système d’exploitation. VMWare propose son VMWare serveur gratuitement, ce qui permet de faire face à des besoins d’utilisation personnelle ou de pré-production. L’intérêt est que la machine virtuelle se comporte exactement comme une seconde machine, avec sa propre adresse IP, ses ressources dédiées, et ses services accessibles. Ainsi, votre PostGIS peut tranquillement tourner sous Debian tandis que vous exploitez les données qui y sont stockés dans votre logiciel SIG préféré sous Windows.

On peut créer autant de machines virtuelles que nécessaires, et ainsi tester différentes configurations et environnements de production pour les valider. Surtout, une fonction Snapshot permet de prendre une image de la machine virtuelle à un instant t et d’y revenir par simple clic. Vous venez de tout casser après une compilation un peu sauvage, ou de perdre votre base de données suite à une mauvaise manipulation ? Pas de panique, le bouton « Revert to Snapshot » rétablit la situation en un clic.

La machine hôte doit certes disposer de suffisamment de ressources pour pouvoir les partager efficacement, mais un DualCore et 2 Go de RAM sont déjà suffisants pour entreprendre l’opération. C’est donc à moindre coût une excellente solution de production légère.