Archive pour novembre 2009

Après le Zoo-Day

Mardi 24 novembre 2009

Avec une petite journée de retard, voici le compte-rendu du premier Zoo Day tenu vendredi dernier à Montpellier qui m’a permis d’y voir un peu plus clair dans l’architecture mise en oeuvre.

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.

Le soleil se lève sur le ZOO Project

Mercredi 18 novembre 2009

Ce vendredi 20 novembre se tiendra à Montpellier le premier ZooDay réunissant autour des concepteurs initiaux du projet, et au premier rang desquels Gérald Fenoy de Geolabs, les amateurs éclairés désireux de se plonger dans cet environnement WPS (Web Processing Service). Nicolas Bozon vient d’en publier le programme sur la ZooDiscuss-List :

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 !