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 Groupe sur l'observation de la Terre (GEO) a invité des experts mondiaux du cube de données à discuter de « l'état de l'art » et à trouver une voie à suivre Atelier Vers l'interopérabilité du Data CubeL'atelier de deux jours, organisé fin avril 2021, a débuté par une série de déclarations de position préenregistrées de fournisseurs et d'utilisateurs de cubes de données. Ces vidéos ont servi de point d'entrée à des discussions intenses qui ont non seulement produit une nouvelle définition du terme « cube de données », mais ont également souligné la nécessité d'une approche basée sur une API « centrée sur l'utilisateur » qui expose non seulement les données disponibles pour l'utilisateur, mais aussi les algorithmes de traitement qui peuvent être exécutés dessus - et permettent à l'utilisateur d'ajouter les siens. Les résultats de l'atelier ont été publiés sur le site Page Web de l'atelier OGC & GEO sur l'interopérabilité des cubes de données.
Cubes de données du point de vue des utilisateurs
Les définitions existantes des cubes de données se concentrent souvent sur l'aspect structure des données tel qu'il est utilisé en informatique. En revanche, Atelier Vers l'interopérabilité du Data Cube L'accent a été mis sur la nécessité de laisser ces définitions de côté et de se concentrer sur le point de vue de l'utilisateur. Les utilisateurs ne se soucient pas de savoir si les données sont stockées dans une base de données relationnelle, dans un magasin d'objets basé sur le cloud ou sur un serveur de fichiers. Ce qui les intéresse, c'est la manière dont ils peuvent accéder aux données et les algorithmes de traitement qu'ils peuvent y appliquer. Toute norme d'accès de ce type devrait refléter cela.
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 pour apprendre et/ou coder, quel que soit l'endroit où se trouvent les données, signifie qu'une sélection accrue de logiciels disponibles (y compris des plateformes low-code ou no-code) prendra en charge un plus grand choix de fournisseurs de cubes de données et un plus grand nombre d'algorithmes de traitement. D'un point de vue scientifique, cela signifie que le scientifique atmosphérique n'a pas besoin d'être également un expert Python, utilisant potentiellement une interface graphique de plateforme low-code ou no-code pour créer un algorithme qui traite les données pour son étude sur les vagues de chaleur en Allemagne. Un autre scientifique atmosphérique pourrait alors prendre ce même algorithme de traitement et l'appliquer au Royaume-Uni avec des modifications minimes - même si les données requises sont détenues par un autre fournisseur de données conforme aux normes. Cette approche augmente considérablement la transparence et la répétabilité des études scientifiques et d'autres tâches d'analyse précieuses.
Pour les développeurs de logiciels : Une API HTTP unique, simple et standardisée signifie que les développeurs de logiciels n'ont pas besoin de concevoir leurs propres méthodes spécifiques au fournisseur pour fournir l'accès aux cubes de données dans leur logiciel. Au lieu de cela, ils interagissent avec les cubes de données via des appels HTTP, bénéficiant ainsi d'une communication Web standard simple, plutôt que d'interactions au niveau programmatique. En codant selon une norme convenue, les développeurs peuvent travailler avec n'importe quel cube de données conforme tout en minimisant les adaptations spécifiques au cube. Cela augmente la convivialité du logiciel, tout en réduisant les coûts de développement et de maintenance.
Pour les opérateurs de cube 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 base de clientèle. La conformité aux normes permet aux fournisseurs d'accéder aux clients qui utilisent n'importe quel progiciel conforme, plutôt qu'à ceux qui utilisent uniquement une liste restreinte de logiciels codés pour fonctionner avec votre instance spécifique. Cela signifie que davantage de personnes coderont pour votre cube de données, même si elles ne savent pas que votre service existe.
Quelle est la prochaine étape pour l'OGC ?
Il est encore tôt pour le dire, mais vous pouvez vous attendre à voir une API liée au cube de données faire partie de notre famille de Normes API OGCLes travaux visant à créer une telle API de cube de données s'appuient sur les travaux de notre plateforme d'exploitation de l'observation de la Terre (voir Un App Store pour le Big Data, dans GeoConnexion International, juillet/août 2020), et est actuellement en cours dans le cadre de 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 leur développement précoce en tant que Observateurs dans le banc d'essai 17 de l'OGC. Alternativement, les membres de l'OGC peuvent rejoindre le Groupe de travail sur le domaine de la plateforme d'exploitation de l'observation de la TerreLes résultats détaillés de l'atelier sont disponibles sur le site Page Web de l'atelier OGC & GEO sur l'interopérabilité des cubes de données.
Une version de cet article a été initialement publiée dans le Édition juillet/août 2021 du magazine international GeoConnexion.
