Le Zoo-Project est constitué de 3 éléments distincts :

• Le zoo-kernel, écrit en C
• Le zoo-server, ensemble de services pouvant être écrits en C, python (pour le moment) ou autres (un jour…) et proposant un fichier texte de configuration (description des format, entrées/sorties, mapping vers les processus du noyau).
• Le zoo-client, qui est plus un support de démonstration, puisque en inter-opérabilité le serveur se veut indépendant du client qui l’interroge.

L’originalité principale vient de la facilité d’intégration des librairies externes, celles qui réaliseront les tâches exposées par les services. On peut soit les compiler directement dans le noyau, pour obtenir un maximum de performance. C’est déjà le cas pour GDAL/OGR et CGAL. Mais on peut aussi les charger dynamiquement à l’exécution, pour privilégier la souplesse. Il faut aussi noter que le champ d’application ne se limite pas aux librairies de traitement géométrique ou de traitement d’image. On peut ainsi imaginer des services de publication PDF, de calcul statistique, d’intégration de données, et bien entendu les chaîner puisque l’input d’une requête WPS peut être un résultat de requête WPS.

En l’état actuel, le Zoo-Project n’implémente pas complètement l’ensemble de la spécification WPS, et cette dernière est elle-même encore susceptible d’être amendée par l’OGC. Il faudra par exemple tenir compte des « profils » WPS, destinés à exposer un ensemble de services autour de problématiques précises. Néanmoins, le Zoo-Project est une implémentation intéressante du concept WPS et permet de mettre à l’épreuve sa plus-value par rapport à des traitements exécutés en local.

Les prochains chantiers du projet sont la finalisation du kernel, l’intégration d’une gamme étendu de services, et la constitution d’un client riche « générique » capable de proposer les formulaires correspondant aux entrées attendues par chacun des services.

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 !

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 !