Le logo du ZOO Project

Mais vous aussi vous demandez peut-être ce qu’est le ZOO Project ? Originellement conçu par GeoLabs, cette petite merveille est un serveur de services WPS (les Web Processing Services, qui vous ingèrent de la donnée et la recrachent transformée selon votre souhait), qui peut charger dynamiquement des modules externes donc (GDAL par exemple) et être manipulé directement en C++ mais aussi en Perl ou en Python. Le WebSIG de demain donc, ou pour faire plus simple, la version web de FME ! Oui, il faut faire un client, et une bonne démo, car dit comme ça, ça reste un peu obscur.

L’équipe s’est étoffée en regroupant des compétences diverses, de Venkatesh Raghavan de l’Université d’Osaka en passant par moi-même. Je ne connais pas encore tout le monde, mais je viens de tenir un premier Zoo Meeting avec Gérald Fenoy, avant un ZooDay début novembre en terre languedocienne.  Ca va faire mal. Mais après, il y aura la demo et le client !

Certes, mais il y a un hic. Le code de ladite projection est le 3857 (voir les détails sur http://www.epsg-registry.org/ et notamment cette remarque : « It is not a recognised geodetic system »…Tout est dit !). Or toutes les applications web ont pris l’habitude de traiter cette projection sous le pseudo-code 900913 qui est ainsi répandu dans tout ce qui fait le geoweb d’aujourd’hui. On rentre donc dans une phase de turbulences qui va voir les deux codes coexister, ou pas, dans les différents composants. Avec les blocages associés. Si Openlayers se met à appeler les WMS en 3857 lorsque la carte est en Spherical Mercator, que vont dire les serveurs configurés pour servir du 900913 ? Aïe.

D’où l’importance d’une rapide prise en compte de cet aspects de la part des différents responsables de projets Open Source Géographiques. Au final, tout sera quand-même bien plus clair, même si incorporer l’EPSG donne à cette projection des lettres de noblesse qu’elle ne mérite pas de par ses qualités intrinsèques.

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

Premièrement, concernant les langages de développement, Python fait réellement l’événement puisque c’est le langage utilisé dans les applications les plus pointues et récentes présentées au FOSS. Citons TileCache, FeatureServer, Cartoweb 4, Shapely, GeoDjango, tous ces projets ont privilégié le python en raison de sa stabilité et de son extraordinaire versatilité (au sens anglo-saxon du terme). Java est toujours là, structurant des projets déjà reconnus (uDIG) ou en devenir (un ETL OpenSource présenté par Talend et CampToCamp). Par contre le PHP ne fait plus partie des langages en vue. Encore utilisé largement, s’il apparaît notamment dans des retours d’expérience il n’est plus le fer de lance du développement en WebMapping, dont l’architecture s’oriente vers des bibliothèques puissantes écrites en C, intégrées dans des wrappers python. Cela a été rendu possible par l’intégration de Ctypes dans python 2.5 qui permet l’appel direct de bibliothèques C sans passer par une fastidieuse interface SWIG.
Du côté des geeks, Charlie Savage met désormais en oeuvre du GeoRuby pour faire tourner son MapBuzz, et à créé une liste dédiée au webmapping dans RubyOnRails, que rien ne semble arrêter !

Tout ceci produit des applications plus puissantes, plus stables et plus robustes, notamment dans la gestion de la mémoire et de la montée en charge. Des bibliothèques aussi cruciales que Geos, Gdal, Ogr, Proj peuvent ainsi être utilisées au coeur même d’une application web dont les scripts python constituent une double interface entre les requêtes utilisateurs d’un côté et la manipulation des données à un bas niveau de l’autre. Ceci devrait faire émerger des frameworks cartographiques avec de véritables fonctions d’administration des données, qui sont encore des aspects trop négligés par le monde OpenSource.

GeoDjango devrait montrer la voie puisque ses concepteurs ont montré un vif intérêt à l’idée d’intégrer des notions de règles de topologies à la gestion des tables.