Les cubes de données géospatiales sont aujourd’hui fréquemment utilisés pour permettre un accès et une analyse performants et compatibles avec le cloud des données géospatiales. Mais les différences dans leur conception, leurs interfaces et leur gestion des caractéristiques temporelles posent des problèmes d’interopérabilité pour quiconque interagit avec plusieurs solutions. De tels défis représentent une perte de temps et d’argent inutile et, d’un point de vue scientifique, affectent la reproductibilité.
Pour relever ces défis, l'Open Geospatial Consortium (OGC) et le Group on Earth Observation (GEO) ont invité des experts internationaux des cubes de données à débattre des dernières avancées et à définir des pistes d'avenir lors de l' atelier « Vers l'interopérabilité des cubes de données » . Cet atelier de deux jours, qui s'est tenu fin avril 2021, a débuté par une série de prises de position préenregistrées de fournisseurs et d'utilisateurs de cubes de données. Ces vidéos ont servi de point de départ à des discussions approfondies qui ont non seulement permis de redéfinir le terme « cube de données », mais aussi de souligner la nécessité d'une approche centrée sur l'utilisateur, basée sur une API, qui expose non seulement les données disponibles, mais aussi les algorithmes de traitement applicables, et permet à l'utilisateur d'en ajouter. Les conclusions de l'atelier sont publiées sur la page web dédiée à l'atelier OGC & GEO « Vers l'interopérabilité des cubes de données ».
Cubes de données du point de vue des utilisateurs
Les définitions actuelles des cubes de données se concentrent souvent sur la structure des données, telle qu'elle est utilisée en informatique. À l'inverse, l' atelier « Vers l'interopérabilité des cubes de données » a souligné la nécessité de dépasser ces définitions et de privilégier le point de vue de l'utilisateur. Ce dernier se soucie peu de savoir si les données sont stockées dans une base de données relationnelle, un système de stockage objet dans le cloud ou un serveur de fichiers. Ce qui l'intéresse, c'est la manière d'accéder aux données et les algorithmes de traitement qu'il peut leur appliquer. Toute norme d'accès doit refléter cette réalité.
Cela a conduit à une réflexion intéressante sur ce qu'est et peut être un cube de données. Bien qu'il n'y ait pas eu de consensus formel sur ce point, les participants à l'atelier ont généralement adopté une définition centrée sur l'utilisateur d'un cube de données géographiques comme suit :
« Un cube de données géographiques est un modèle discrétisé de la Terre qui fournit les valeurs estimées de certaines variables pour chaque cellule. Idéalement, un cube de données est dense (c'est-à-dire qu'il n'inclut pas de cellules vides) avec une distance de cellule constante pour ses dimensions spatiales et temporelles. Un cube de données décrit sa structure de base, c'est-à-dire ses caractéristiques spatiales et temporelles et ses variables prises en charge (alias propriétés), sous forme de métadonnées. Il est en outre défini par un ensemble de fonctions. Ces fonctions décrivent les méthodes de découverte, d'accès, de visualisation, d'analyse et de traitement disponibles par lesquelles l'utilisateur peut interagir avec le cube de données. »
Comme nous le voyons, le cube de données est décrit pour l'utilisateur, pas pour les données. Peu importe que le cube de données contienne une, deux ou trois dimensions spatiales, que le temps ait sa ou ses propres dimensions ou qu'il fasse simplement partie des métadonnées d'une observation, ou qu'il ne soit pas du tout pertinent pour les données. De même, la manière dont les données sont stockées n'a pas d'importance. Ce qui unifiera ces cubes de données hétérogènes, c'est leur utilisation d'une API standardisée basée sur HTTP comme méthode d'accès et d'interaction.
La principale préoccupation de l'utilisateur est de savoir quelles fonctions l'instance de cube de données propose d'appliquer aux données. Ces fonctions sont ce qui différencie principalement la définition du cube de données centré sur l'utilisateur des autres définitions. Un utilisateur doit comprendre quelles questions peuvent être posées pour accéder aux données qui répondent à des critères de filtrage spécifiques, comment visualiser des (sous-)ensembles de données spécifiques ou comment exécuter des fonctions analytiques et d'autres processus sur le cube de données. Si cela est pris en charge, l'utilisateur doit également comprendre comment ajouter ses propres processus au cube de données afin qu'ils puissent être exécutés directement sur le cube de données sans avoir à transférer de grandes quantités de données hors du cloud.
Cela ne signifie pas que toutes les autres caractéristiques – telles que les détails spatiaux et temporels (par exemple, la densité ou la dispersion, le chevauchement ou l'alignement parfait, les distances constantes ou inconstantes) et les détails de propriété (échelles de mesure, données incomplètes, méthodes d'interpolation, valeurs d'erreur, etc.) – ne concernent pas l'utilisateur : elles doivent néanmoins être connues. À ce titre, elles seront fournies via l'API du cube de données sous forme de métadonnées, afin que l'utilisateur puisse les prendre en compte lors de l'évaluation de la meilleure façon de traiter les données.
Interopérabilité via une API Data Cube
Où en est l'OGC dans tout cela ? Nous pensons qu'une approche flexible des normes basée sur les API offrira aux utilisateurs finaux, aux développeurs de logiciels et aux opérateurs de cubes de données la meilleure expérience possible.
Pour les utilisateurs finaux : une API HTTP unique, simple et standardisée, facile à apprendre et/ou à programmer, quel que soit l’emplacement des données, permettra d’élargir le choix de logiciels disponibles (y compris les plateformes low-code ou no-code), de prendre en charge un plus grand nombre de fournisseurs de cubes de données et d’algorithmes de traitement. D’un point de vue scientifique, cela signifie qu’un chercheur en sciences de l’atmosphère n’aura plus besoin d’être un expert en Python ; il pourra utiliser l’interface graphique d’une plateforme low-code ou no-code pour créer un algorithme de traitement des données de son étude sur les vagues de chaleur en Allemagne. Un autre chercheur pourra ensuite appliquer ce même algorithme au Royaume-Uni avec des modifications minimes, même si les données nécessaires proviennent d’un fournisseur de données conforme aux normes différent. Cette approche accroît considérablement la transparence et la reproductibilité des études scientifiques et autres analyses importantes.
Pour les développeurs : une API HTTP unique, simple et standardisée leur évite de concevoir leurs propres méthodes spécifiques à un fournisseur pour accéder aux cubes de données. Ils interagissent avec ces cubes via des requêtes HTTP, bénéficiant ainsi d'une communication Web standard et simplifiée, plutôt que d'interactions au niveau de la programmation. En codant selon une norme convenue, les développeurs peuvent utiliser n'importe quel cube de données compatible tout en minimisant les adaptations spécifiques. Cela améliore l'ergonomie du logiciel et réduit les coûts de développement et de maintenance.
Pour les opérateurs de cubes de données : l’utilisation d’une API HTTP unique, simple et standardisée réduit les coûts de développement et de maintenance tout en élargissant la clientèle. La conformité aux normes permet aux fournisseurs d’atteindre des clients utilisant n’importe quel logiciel compatible, et non plus seulement ceux utilisant une liste restreinte de logiciels conçus pour fonctionner avec votre instance spécifique. Ainsi, davantage de développeurs contribueront au développement de votre cube de données, même sans connaître l’existence de votre service.
Quelle est la prochaine étape pour l'OGC ?
Il est encore trop tôt pour tirer des conclusions définitives, mais vous pouvez vous attendre à ce qu'une API relative aux cubes de données vienne s'ajouter à notre famille de normes d'API OGC . Le développement d'une telle API s'appuie sur les travaux menés sur notre plateforme d'exploitation des données d'observation de la Terre (voir « Une boutique d'applications pour le Big Data » , dans GeoConnexion International, juillet/août 2020) et est actuellement en cours dans le cadre du banc d'essai OGC-17.
Si vous souhaitez en savoir plus sur l'approche de l'OGC en matière de normalisation de l'accès aux cubes de données, les membres de l'OGC peuvent suivre son développement initial en tant qu'observateurs au sein du banc d'essai OGC-17 . Ils peuvent également rejoindre le groupe de travail du domaine « Plateforme d'exploitation des données d'observation de la Terre » . Les résultats détaillés de l'atelier sont disponibles sur la page web de l'atelier OGC & GEO sur l'interopérabilité des cubes de données.
Une version de cet article a initialement paru dans le numéro de juillet/août 2021 du magazine GeoConnexion International.
