Pourquoi le ZOO Project ?
Par René-Luc D'Hont le lundi 12 avril 2010, 23:07 - Système d'Information Géographique (SIG) - Lien permanent
Le Projet ZOO a pour objectif de fournir un serveur de Web Processing Services (WPS) respectant la norme définie par l'Open Geospatial Consortium (OGC). Les Web Processing Services permettent de réaliser des opérations sur des données en mode distribué comme par exemple la reprojection, la modification de format, différents traitements avancés, etc...
La force du ZOO est de pouvoir charger dynamiquement des Process, analyses et traitements de données, codés dans différents langages C/C++, Python et JavaScript. C'est donc un serveur WPS extensible et personnalisable à souhaits.
Mais la démarche n'a pas été de créer un nouveau projet de serveur WPS pour créer un nouveau projet. Nous, 3Liz et Geolabs, sommes partis du constat que l'environnement des Système d'Information Géographiques Open Source (OpenGIS) était riche de nombreuses solutions chacune avec leurs avantages mais nous ne disposions pas d'un environnement permettant de facilement les exploiter de façon distribuées. Nous souhaitions pouvoir exploiter les capacités de lecture de format de GDAL/OGR, réutiliser les solutions proposer par l'environnement Python et profiter de la flexibilité du langage JavaScript. Tout cela en gardant à l'esprit qu'il existait déjà des solutions.
A partir de là 2 points nous semblait essentiel, notre projet doit permettre à l'utilisateur de :
- définir facilement ses Process
- choisir les solutions les plus pertinentes pour ses Process
En fait, nous souhaitons que le Projet ZOO permette à celui qui met en place un service de traitements et d'analyses de données géographiques de pouvoir le faire facilement et avec les Process qu'il souhaite. Donc celui qui souhaite utiliser le Projet ZOO ne sera pas limité aux Process fournis avec le coeur du ZOO.
Donc pour pouvoir permettre à quelqu'un de facilement mettre en œuvre des Process, il nous a paru pertinent de proposer les solutions suivantes :
- un Process est un couple métadonnées/script
- un Process doit pouvoir s'appuyer sur l'existant
Nous avons donc traduit cela par les réalisations suivantes :
- les métadonnées d'un Process sont contenu dans un fichier texte et pointe vers le fichier contenant le code du Process
- les Process peuvent être réalisés dans un des langages supportés par le noyau du ZOO (C/C++, Python, Fortran, JavaScript)
Ce qui nous a paru le plus intéressant était de pouvoir réaliser son Process dans le langage que l'on souhaite.
En Permettant de coder en C/C++, il est possible de créer des Process à partir de bibliothèques de fonctions déjà très répandu comme GDAL/OGR, GEOS et Proj4, mais aussi à partir de bibliothèques émergentes comme GGL et Orfeo Toolbox ou plus ancienne comme CGAL. Cela signifie que la conception des Process n'est pas limité à une solution et qu'il est possible d'utiliser celles qui sont la mieux adapter aux besoins.
En permettant de coder en Python, il est possible de créer des Process à partir des nombreux modules disponibles. Il est ainsi possible d'utiliser les projets du Laboratoire de logiciels SIG et Python (The GIS and Python Software Laboratory), ou la bibliothèques de fonctions Python GRASS (GRASS Python library), ou réaliser des analyses statistiques via le Projet R, ou encore exploiter OpenOffice pour générer des documents Office.
En permettant de coder en Fortran, il est possible d'exploiter des algorithmes Mathématique complexes issues de laboratoires de recherche. Cette possibilité permet de diminuer le coût de mise en œuvre de service Web basé sur des résultats de recherches et de partager facilement des algorithmes entre laboratoires.
Enfin en permettant de coder en JavaScript, il est possible de concevoir rapidement des traitements et analyses de données géographiques vectorielles mais aussi des enchaînements logiques de Process. Une autre possibilité offerte par le JavaScript est celle de pouvoir évaluer dynamiquement du code. Cette capacité permet de rédiger et tester de nouveaux process et/ou enchaînements sans modifier aucun fichier côté serveur, un client Web suffi.
En s'imposant la ré-utilisabilité de l'existant nous estimons nous intégrer pleinement dans une démarche OpenSource. Nous ne souhaitions pas réécrire l'existant pour l'adapter à la problématique WPS mais fournir un outil facilitant l'exploitation de sa solution préféré dans un contexte Web standardisé par l'OGC.
En faisant ce choix, nous pensons accroître le degré de liberté offert aux concepteurs de services Web SIG. Il est libre de concevoir les traitements et analyses de données qu'ils souhaitent mettre à disposition sans se soucier de la solution technique puisqu'il pourra choisir celle qui conviendra le mieux.