Article rédigé par Chris Holmes, chercheur invité à l'OGC –
Dans mon précédent article, j'ai présenté la vision du géospatial natif du cloud , mais dans celui-ci, je souhaite aborder plus en détail les besoins. Je présenterai les principaux domaines où des normes fondamentales sont nécessaires, puis j'examinerai l'état actuel de chacun. Ces domaines varient de très bien établis à plus spéculatifs, mais tous sont parfaitement réalisables. Enfin, j'approfondirai le domaine sur lequel je me suis le plus concentré ces derniers mois en tant que chercheur invité à l'OGC.
Composants nécessaires
Il existe quelques composants clés nécessaires pour représenter diverses informations de localisation sur le cloud. Ceux-ci se trouvent « en dessous » d'une API : ce sont simplement des ressources et des formats. Ensemble, ces composants fournissent une base solide pour représenter la plupart des informations géospatiales sur le cloud. Ils doivent être compatibles avec les API ; ils peuvent servir de réponses aux requêtes, en tant que ressources JSON ou formats de streaming. Mais il doit également être tout à fait possible de les stocker simplement sur un magasin d'objets de stockage cloud (S3, GCP, etc.). Ceux-ci seront à leur tour souvent lus par des API plus performantes pour effectuer des opérations intéressantes, mais ce n'est pas nécessaire.
Le noyau que je vois est :
- Format raster de base : Un format cloud natif solide pour gérer l'imagerie satellite, les DEM, les produits de données dérivés principalement de l'imagerie satellite, etc.
- Format raster multidimensionnel : Un format cloud capable de gérer des cubes de données massifs, comme les résultats de prévisions météorologiques, la température au fil du temps et de l'altitude, la modélisation climatique, etc. C'est l'espace traditionnel de NetCDF / HDF.
- Formats vectoriels de base : Un équivalent de données vectorielles au format Cloud Optimized GeoTIFF serait idéal, mais les diverses exigences d'affichage rapide et d'analyse approfondie à la volée peuvent ne pas être facilement combinables, nous pourrions donc nous retrouver avec plus d'un format ici.
- Format du nuage de points : Un format cloud qui fonctionne comme COG, mais permet l'affichage en continu et l'analyse à la volée des nuages de points.
- Métadonnées de la collection et de l'ensemble de données : Le titre, la description, la licence, les limites spatiales et temporelles, les mots-clés, etc. qui permettent la recherche. Pour la base de référence géospatiale native du cloud, cela devrait se concentrer sur la « navigabilité » et sur les liens vers les formats réels. Il devrait prendre en charge divers types de données (données vectorielles, données raster, nuages de points, cubes de données multidimensionnels, vidéos géolocalisées, représentations 3D, etc.) et devrait être suffisamment flexible pour fonctionner avec n'importe quelle donnée. Il devrait être fondamentalement axé sur la géospatiale et ne pas essayer de décrire de manière générique des données.
- Métadonnées Granule / Niveau de scène / « ressource » : Un objet de métadonnées flexible avec des champs communs pour décrire des domaines de capture de données particuliers et établir un lien vers les fichiers de données réels.
La plupart d’entre elles ont au moins un début de réponse dans notre communauté géospatiale mondiale, voire une solution robuste :
- Format raster de base : Aujourd'hui c'est GeoTIFF optimisé pour le cloud (COG). Il est en passe de devenir une norme officielle de l'OGC et a déjà connu une adoption incroyable dans une grande variété d'endroits. C'est vraiment le format géographique natif du cloud qui a prouvé ce qui est possible. Il convient de noter qu'il ne s'agit peut-être pas de la solution ultime pour les formats raster cloud, car on pourrait voir un format d'image plus optimisé, plus petit et plus rapide. Mais il s'agirait probablement d'un format d'image plus général auquel notre communauté ajouterait « geo », comme nous l'avons fait avec TIFF. Les COG domineront pendant un certain temps, car la compatibilité ascendante avec les outils existants est difficile à battre tant que nous sommes encore au début de la transition vers une infrastructure géospatiale axée sur le cloud.
- Format raster multidimensionnel : Il y a déjà une excellente réponse ici avec zarr. C'est en train de en cours d'adoption comme norme communautaire OGC, avec le vote d'adoption qui commence bientôt. Il est également en cours adopté par NetCDF, et a connu une adoption significative au sein de la communauté climatique.
- Formats vectoriels de base : Il n'y a pas encore de réponse définitive à cette question. Je discuterai du paysage et des différentes possibilités dans un prochain article de blog.
- Format du nuage de points : Le nouveau film de Howard Butler Format COPC est une « spécification LASzip lisible par plage, compressée et organisée » qui répond aux mêmes critères que GeoTIFF optimisé pour le cloud et qui connaîtra probablement une adoption rapide.
- Métadonnées de la collection et de l'ensemble de données : possède un noyau solide avec la construction OGC API – Features 'Collection'. Collection STAC puis étend cela, et l'API OGC - Record fournit un équivalent GeoJSON qui peut être utilisé comme retour dans les requêtes de recherche. Mais ces parties ne sont pas toutes connectées de manière cohérente, et l'utilisation complète « statique » (il suffit de télécharger sur S3) n'a pas été entièrement développée. C'était l'objectif principal de mon travail au cours des derniers mois, je vais donc approfondir le sujet ci-dessous.
- Métadonnées Granule / Niveau de scène / « ressource » : est où le Catalogue d'actifs spatio-temporels (STAC) La spécification qui a été mon objectif principal au cours des dernières années a joué un rôle et connaît une adoption très positive après avoir récemment atteint la version 1.0.0.
Qu'en est-il des tuiles ?
Pour moi, la question de la pertinence d'une spécification de tuiles web dans une véritable infrastructure géospatiale native du cloud reste ouverte. Je pense que pour les tuiles raster (PNG, JPEG, etc.), cela n'a pas de sens, car un GeoTIFF optimisé pour le cloud peut être facilement transformé à la volée en tuiles web grâce à des outils de traitement de tuiles sans serveur comme Titiler . L'idéal serait donc d'utiliser un format natif du cloud performant permettant un rendu et un traitement à la volée, dans le format requis par les clients. Les tuiles sont essentielles pour les navigateurs web, mais d'autres outils tirent davantage profit d'un accès direct aux données. Une fois la norme OGC API – Tiles finalisée, il sera probablement judicieux de créer un « bloc de métadonnées de tuiles » pouvant servir de format natif du cloud pour orienter les clients vers les tuiles.
Pour les tuiles vectorielles, je considère les formats MVT et PBF comme des formats géospatiaux natifs du cloud, car ils peuvent être stockés dans un espace de stockage cloud et utilisés par diverses applications. Cependant, je pense qu'un bon format vectoriel natif du cloud pourrait fonctionner comme COGs, avec un serveur de tuiles sans serveur capable de générer les tuiles vectorielles à la volée. J'approfondirai cette idée dans un prochain article consacré aux formats vectoriels.
Comment s'intègrent les API OGC ?
L' initiative OGC API est une refonte de la plateforme OGC W*S en API JSON/REST plus modernes. Elle se situe généralement à un niveau supérieur aux constructions géospatiales natives du cloud présentées ici, définissant des interfaces API pour les services utilisant les formats natifs du cloud (mais pouvant également utiliser des formats et bases de données spatiales plus traditionnels). Ces API offrent davantage de possibilités, comme la recherche dynamique ou le traitement des données à la volée, mais nécessitent également plus de ressources. La plupart des constructions de métadonnées natives du cloud ont été extraites des API ; les variantes natives du cloud devraient donc être compatibles avec les API OGC, bien que beaucoup moins performantes (mais aussi beaucoup plus faciles à implémenter).
Un écosystème idéal devrait contenir la plupart des données stockées dans des formats géospatiaux natifs du cloud, puis un large éventail de services par-dessus ceux-ci, la plupart d'entre eux implémentant des interfaces API OGC. À l'avenir, il sera, espérons-le, facile d'installer un serveur ou même une fonction sans serveur qui fournit des requêtes API OGC plus riches en plus des métadonnées et des formats natifs du cloud.
Vers des métadonnées de collecte géospatiales natives du cloud
Comme mentionné ci-dessus, la majeure partie de mon temps en tant que chercheur invité de l'OGC au cours des derniers mois a été consacrée à la mise au point d'une « collection géospatiale cloud native ». Cela comporte plusieurs aspects différents.
Une collection OGC statique
L'une des constructions les plus puissantes apparues dans l'évolution de STAC est le « STAC statique ». Consultez l' article « Catalogues d'actifs spatio-temporels statiques en détail » pour un excellent résumé de leur nature et de leur fonctionnement. Voici les « bonnes pratiques » de la version 1.0.0 de la spécification :
Un catalogue statique est une implémentation de la spécification STAC qui ne répond pas dynamiquement aux requêtes. Il s'agit simplement d'un ensemble de fichiers sur un serveur web, liés entre eux de manière à pouvoir être indexés par les moteurs de recherche. Ces fichiers sont souvent stockés dans un service de stockage cloud comme Amazon S3 , Azure Storage ou Google Cloud Storage . Un catalogue statique ne peut être indexé que par les moteurs de recherche et les catalogues actifs ; il ne peut pas répondre aux requêtes. En revanche, il est extrêmement fiable, car il ne comporte aucun élément mobile, ni cluster ou base de données à gérer.
Il s'est avéré qu'il s'agit d'un moyen très populaire de publier des données STAC, concrétisant ainsi la vision de mon précédent article de blog consistant à pouvoir télécharger des données sur le cloud et à les faire « simplement fonctionner ».
Bien que STAC ait été pionnier en proposant des options statiques claires pour les éléments d'imagerie individuels et autres ressources spatio-temporelles, ainsi que pour les collections de ce type de données, il manquait jusqu'alors une « collection statique » équivalente pour les données vectorielles. L'API OGC – Feature Collection (que STAC étend pour sa Collection ) ne constitue, telle que spécifiée, qu'une partie d'une réponse d'API et non une ressource JSON indépendante utilisable seule. Cependant, il s'agissait d'un composant modulaire bien conçu, et Clemens Portele et Peter Vretanos, les rédacteurs de la spécification Features, ont toujours été favorables à son extraction.
J'ai fait une tentative grossière dans un dépôt github expérimental. Mais ensuite, Clemens a eu une autre idée que nous avions en tête, celle de créer de véritables petits blocs de construction granulaires à partir de la base de l'API OGC (j'essaierai de faire un article complet à ce sujet à l'avenir). Cela a donné lieu à un très propre 'Collection', extrait de OGC API – Features, mais écrit comme une ressource JSON indépendante qui pourrait être réutilisée dans n'importe quel contexte. Et nous avons donc une véritable « collection OGC statique », capable de vivre de manière statique sur un stockage cloud. Cela peut pointer vers un GeoJSON, GeoPackage, Shapefile ou tout autre nouveau format plus natif du cloud. Vous pouvez voir un exemple de ceci dans un dépôt que j'ai créé pour expérimenter des exemples de collections statiques. Celui-ci a plusieurs représentations des mêmes données sous différents formats, mais il pourrait facilement n'en avoir qu'un seul.
Enregistrements + alignement STAC
J'ai également consacré une part importante de mon temps à une tâche qui n'est pas directement liée au cloud : l'alignement complet de STAC avec l'API Records de l'OGC . Nombreux étaient ceux qui s'interrogeaient sur la relation exacte entre les deux spécifications, même si j'avais toujours eu une idée claire (bien que difficilement communiquée). Ces derniers mois m'ont donc permis de me concerter pleinement avec l'équipe Records et de définir la marche à suivre. En résumé, l'API Records a un rôle essentiel à jouer dans STAC, car nous avons différé la recherche au niveau des collections afin de l'aligner complètement avec Records. Cependant, la confusion vient du fait qu'une API Records peut également être utilisée pour rechercher des éléments similaires à ceux de STAC, et qu'elle est d'ailleurs conçue pour la recherche de presque tout.
Le déclic a été de réaliser que les auteurs de la spécification Records avaient toujours envisagé un « enregistrement de données », ce qui correspond exactement aux besoins de STAC. Ce type d'enregistrement est plus spécifique qu'un enregistrement général et flexible. Le concept de Collection de STAC se concentre uniquement sur ce que l'OGC considère comme des « jeux de données », mais il n'existait pas de spécification claire de ce concept dans l'API de base de l'OGC. J'ai donc créé une pull request dans le dépôt Records pour l'ajouter et je proposerai également une « Collection de données » qui étend la Collection OGC de base avec des champs supplémentaires. Une Collection STAC devrait ensuite s'aligner sur ce concept de Collection de jeux de données. À l'avenir, nous travaillerons ensemble à la création d'un « enregistrement STAC » qui alignera pleinement un élément STAC sur les exigences plus générales relatives aux enregistrements.
L'autre avantage de cette synchronisation réside dans la refonte réussie de la spécification de l'API Records par Peter Vretanos. L'objectif a toujours été de concevoir l'API Records comme une API de fonctionnalités, enrichie de fonctionnalités supplémentaires (tri, requêtes plus poussées, etc.) et d'un modèle de données plus structuré. La nouvelle version clarifie ce point, en soulignant les différences avec les API OGC de base, et devrait faciliter l'alignement avec STAC.
Enregistrements statiques
Ce travail a parfaitement posé les bases du prochain composant géospatial natif du cloud : un catalogue explorable composé d'enregistrements statiques accessibles via le web ! Peter a fourni un exemple de catalogue explorable (et j'ai une pull request qui l'enrichit d'une « collection OGC statique » avec des données vectorielles). Ce catalogue nécessite encore quelques ajustements pour être conforme à STAC, mais il respecte tous nos principes géospatiaux natifs du cloud. Nous disposons donc désormais de la quasi-totalité des éléments nécessaires pour les métadonnées requises pour une infrastructure géospatiale native du cloud. Les enregistrements et les collections sont deux instanciations alternatives des mêmes modèles de données de base : l'une est au format GeoJSON, ce qui facilite la visualisation simultanée de nombreux enregistrements, et l'autre correspond à la structure de collection de l'API OGC, largement utilisée. À court terme, il sera probablement préférable d'utiliser les deux, mais à terme, des outils permettront une conversion aisée de l'un à l'autre, notamment si nous parvenons à une compatibilité totale des modèles de données de base.
Tout mettre ensemble
Nous sommes donc très proches de la suite complète de métadonnées statiques nécessaires pour gérer la plupart des données géospatiales natives du cloud. La principale tâche à venir consiste à aligner entièrement le travail dans OGC API – Records and – Features pour qu'il soit compatible avec STAC et à mieux décrire tous les champs de métadonnées nécessaires. Il existe quelques différences entre les deux approches, il serait donc intéressant de simplifier un peu les choses entre les deux approches.
Pour illustrer le fonctionnement de l'ensemble, j'ai créé un dépôt intitulé « Exemples OGC statiques » afin de démontrer comment accéder à divers jeux de données et formats depuis une structure entièrement statique. Je continuerai à l'enrichir et à faire évoluer les exemples, et à étoffer les fichiers README pour expliquer son fonctionnement. Plus tard, je publierai un article de blog détaillant le tout.
Les prochains articles approfondiront davantage l'état actuel des formats géospatiaux natifs du cloud. Les données vectorielles sont le domaine sur lequel j'ai passé la majeure partie de mon temps ces derniers temps, car il n'existe pas de réponse très claire. J'espère également passer plus de temps à mettre en avant zarr et copc, car ce sont deux efforts vraiment formidables qui s'intègrent bien et complètent vraiment un écosystème complet de formats.
