Les membres du consortium Open Geospatial (OGC) se sont réunis à Orléans du 19 au 23 mars. Depuis peu, ces réunions expérimentent une nouvelle formule pour la séance plénière de clôture. Durant la semaine, les membres votent pour un sujet qui sera présenté et débattu en séance. À Orléans, le sujet discuté à la clôture était latent depuis plusieurs mois. Il avait été soulevé plus explicitement, sous différentes formes, à au moins deux reprises au cours de la semaine.
Depuis une ou deux années, les agences spatiales – notamment la NASA et l’ESA – expriment à l’OGC un besoin d’inverser la logique actuelle dans la façon de manipuler les données. Au lieu d’amener les données aux algorithmes (c’est-à-dire de télécharger des données à partir de serveurs vers le poste du scientifique qui effectuera les calculs), on souhaite amener les algorithmes vers les données. La raison est que les données d’observation de la Terre occupent un volume tel que leur téléchargement peut devenir impraticable. On souhaite plutôt exécuter les algorithmes là où se trouvent les données.
Ce souhait est déjà partiellement réalisé par certains acteurs. Par exemple Google Earth Engine (GEE) permet d’exécuter des algorithmes définis par l’utilisateur sur les serveurs de Google. Le guide du développeur contient un exemple d’algorithme (un calcul d’indice de végétation) exécuté localement, puis exécuté plus efficacement sur les serveurs où se trouvent les données. Mais cet exemple utilise une interface de programmation (API) propre à Google ; aucun standard géospatial n’y est appliqué. Cette conception expose les utilisateurs au risque de verrouillage du fournisseur. Une situation où les algorithmes écrits pour GEE peuvent être difficiles à porter vers une autre source de données.
L’initiative openEO part de ces constatations (besoin d’exécuter des algorithmes là où se trouve la donnée ; les solutions existantes utilisent des API propriétaires) pour proposer une API neutre en Python. Leur prototype permet déjà de définir des algorithmes pour GEE en utilisant une API qu’ils veulent transposable à d’autres fournisseurs. Toutefois, bien que openEO ait été présenté à la réunion OGC à Orléans, l’API montrée semble leur être propre. Il utilise assez peu les modèles conceptuels de l’OGC.
Les standards définis par l’OGC s’articulent autour du transfert de données. Soit en définissant des formats de fichiers (par exemple netCDF) ; soit en définissant des services web permettant de télécharger ces fichiers. La principale exception est le standard Web Processing Service (WPS) qui permet d’exécuter des algorithmes à distance. Cependant, ses possibilités sont limitées aux algorithmes pré-définis sur le serveur (auquel cas on ne fait que transmettre des paramètres) ou aux algorithmes exprimables dans un langage proche du SQL (beaucoup plus limité que Python, Java ou autres langages de programmation). Cette situation a amené la NOAA à poser trois questions à Orléans :
- Quels standards OGC restent pertinents lorsque les données sont à la fois hébergées et traitées par l’informatique en nuage ?
- Quels standards OGC deviennent non-pertinents lorsque l’utilisateur final (sous forme d’algorithme) est aussi dans le nuage ?
- Quels nouveaux standards OGC ou quelles révisions de standards existants sont nécessaires ?
La réponse à la question 2 pourrait être « tous les standards web et formats de fichiers ». Ce qui englobe beaucoup des standards les plus populaires de l’OGC ! Notons toutefois que même si ces standards peuvent devenir inutiles pendant la phase d’exécution d’un algorithme par l’informatique en nuage, ils restent pertinents pour récupérer le résultat du calcul.
Une réponse à la question 3 pourrait être GeoAPI, un standard OGC qui définit des interfaces de programmation depuis plus de 15 ans. GeoAPI poursuit les mêmes objectifs que openEO, mais en prenant le problème par le bout opposé. OpenEO part du haut (« fournir une image à l’utilisateur »), et descend dans les détails au fur et à mesure des besoins. Ils peuvent se permettre cette approche car ils définissent leur propre API, qu’ils complètent à leur rythme. De l’autre côté, GeoAPI s’est donné comme mission d’implémenter les modèles conceptuels standards de l’OGC et de l’ISO. GeoAPI évite de créer son propre modèle, excepté pour des besoins d’intégration avec le langage de programmation ciblé. Par exemple, pour représenter une image, GeoAPI s’appuiera sur le modèle conceptuel définit par ISO 19123 (schema for coverage geometry and functions), qui lui-même dépend de ISO 19107 (spatial schema), qui dépend de ISO 19111 (spatial referencing by coordinates), qui dépend de ISO 19115 (metadata), qui dépend de ISO 19103 (conceptual schema language)… GeoAPI part donc du bas et monte vers les besoins des utilisateurs en suivant le fil des dépendances entre les standards ISO. C’est un processus plus long que l’approche prise par openEO, mais qui tend vers une solution collant mieux aux standards internationaux.
Paradoxalement, l’informatique en nuage remet d’actualité une approche qui était en vogue il y a une vingtaine d’années, avant d’être (temporairement?) éclipsée par la vague des protocoles web. Le mode de fonctionnement de Google Earth Engine ressemble au mécanisme derrière les Remote Method Invocations (RMI) du Java, publié en 1997. D’ailleurs, le slogan de Sun Microsystems (le créateur du langage Java à cette époque) était « The network is the computer ». Les API définis par des interfaces Java – comme GeoAPI – se prêtent naturellement à une utilisation par l’informatique en nuage. Étendre cette approche à des langages autres que Java – à commencer par Python – est en cours sur le dépôt de code de GeoAPI.