Article rédigé par Chris Holmes, chercheur invité de l'OGC -
Dans mon article précédent, j'ai exposé la vision du géospatial natif du cloud, mais avec cet article, je veux entrer dans les détails de ce qui est nécessaire. Je vais exposer les domaines clés où des normes fondamentales sont nécessaires, puis examiner l'état actuel de chaque domaine. Ils vont de bien établis à assez spéculatifs, mais tous sont éminemment réalisables. Et puis je plongerai en profondeur dans le domaine sur lequel je me suis concentré le plus au cours de ces derniers mois en tant que chercheur invité de 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 une architecture géospatiale native du cloud, l'objectif principal doit être l'indexation par les moteurs de recherche et la liaison aux formats existants. Elle doit 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 être suffisamment flexible pour fonctionner avec n'importe quel type de données. Elle doit être fondamentalement géospatiale et ne pas tenter de décrire des données de manière générique.
- 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 le OGC API – Features Le concept de « collection ». Collection STAC L'API OGC – Record étend ensuite cette fonctionnalité en fournissant un équivalent GeoJSON utilisable comme résultat dans les requêtes de recherche. Cependant, ces éléments n'étaient pas encore totalement interconnectés, et l'utilisation « statique » (simple envoi vers S3) n'avait pas été entièrement développée. Ce point a constitué l'essentiel de mon travail ces derniers mois ; je l'aborderai donc plus en détail 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, il n'est pas encore possible de déterminer si une spécification de tuiles Web appartient réellement à une véritable base géospatiale native du cloud. Je pense que pour les tuiles raster (png, jpeg, etc.), elles n'ont pas de sens, car un GeoTIFF optimisé pour le cloud peut facilement être transformé à la volée en tuiles Web, à l'aide de tuileurs sans serveur comme TitulaireLe modèle consiste donc à utiliser un format natif du cloud performant qui permette un rendu et un traitement à la volée, dans le format requis par les clients. Les tuiles sont essentielles pour les clients basés sur un navigateur, mais d'autres outils tirent davantage profit d'un accès direct aux données. Une fois que OGC API – Tiles Une fois la norme finalisée, il sera probablement judicieux de créer un « bloc de construction 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érerais les deux MVTs et PBFLes formats vectoriels natifs du cloud sont des formats géospatiaux natifs du cloud, dans la mesure où ils peuvent être stockés dans un compartiment de stockage cloud et utilisés par diverses applications. Mais je pense qu'il existe un potentiel pour qu'un bon format vectoriel natif du cloud fonctionne comme les COG, avec un serveur de tuiles sans serveur capable de restituer des tuiles vectorielles à la volée. J'explorerai cette idée plus en profondeur dans un prochain article sur les formats vectoriels.
Comment s'intègrent les API OGC ?
Le Initiative API de l'OGC est une réinvention de la base de données OGC W*S en API JSON/REST plus modernes. En général, elle se situe un niveau « au-dessus » des constructions géospatiales natives du cloud décrites ici, définissant des interfaces API pour les services qui utiliseraient les formats natifs du cloud (mais pourraient également utiliser des formats plus traditionnels et des bases de données spatiales). Elles permettent bien plus de choses, comme la recherche dynamique ou le traitement à la volée des données, mais nécessitent également davantage. La plupart des constructions de métadonnées natives du cloud ont été extraites des API, de sorte que les variantes natives du cloud devraient être compatibles avec les API OGC, mais avec beaucoup moins de capacités (mais aussi beaucoup plus faciles à mettre en œuvre).
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 qui a émergé dans l'évolution du STAC est le « STAC statique ». Catalogues d'actifs spatiotemporels statiques en profondeur postez un excellent résumé de ce qu'ils sont et de leur fonctionnement. Pour citer le «les meilleures 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 de manière dynamique aux requêtes. Il s'agit simplement d'un ensemble de fichiers sur un serveur Web qui sont liés les uns aux autres de manière à pouvoir être explorés, souvent stockés dans un service de stockage cloud comme Amazon S3, Stockage Azure et Google Cloud Storage…Un catalogue statique ne peut être réellement exploré que par les moteurs de recherche et les catalogues actifs ; il ne peut pas répondre aux requêtes. Mais il est incroyablement fiable, car il n’y a pas de pièces mobiles, pas de clusters ou de bases de données à maintenir.
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 ».
Si STAC a ouvert la voie à des options statiques claires pour les images individuelles 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 – Fonctionnalité Collection (que STAC étend pour ses Collection) comme spécifié n'est qu'une partie d'une réponse API, pas une ressource JSON indépendante qui peut être utilisée indépendamment. Mais c'était une partie modulaire bien conçue, et Clemens Portele et Peter Vretanos, les éditeurs de la spécification Features, ont toujours soutenu son retrait.
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
Une autre grande partie de mon temps a été consacrée à des travaux qui ne sont pas directement liés au cloud : l'alignement complet de STAC avec API OGC – Enregistrements. Beaucoup n'étaient pas sûrs de la relation exacte entre les deux spécifications, même si j'ai toujours eu des idées claires (mais pas bien communiquées). Les derniers mois ont donc permis de se synchroniser pleinement avec l'équipe principale de Records et de parvenir à un accord sur la voie à suivre. La version rapide est que Records API a un véritable rôle à jouer dans STAC, car nous avons retardé 'recherche au niveau de la collection", car nous voulions aligner cela entièrement avec Records. Mais ce qui est déroutant, c'est qu'une API Records peut également être utilisée pour rechercher des éléments de type STAC, et est en effet conçue pour rechercher presque tout.
Donc, le moment « aha » a été de réaliser que les auteurs de spécifications Records ont toujours eu à l'esprit un « Data Record », qui est vraiment ce dont STAC a besoin, qui est un peu plus spécifique qu'un Record totalement général et flexible. La construction de collection de STAC est vraiment uniquement axée sur ce que l'OGC considère comme des « ensembles de données », c'est juste qu'il n'y a pas eu de spécification claire de cette construction dans la base de référence émergente de l'API OGC. J'ai commencé une demande d'extraction dans les enregistrements Nous allons ajouter ce référentiel et proposer également une « collection de données » qui étend la collection principale de l'OGC avec des champs supplémentaires. Une collection STAC devrait à son tour s'aligner sur cette construction de collection de jeux de données. Et à l'avenir, nous travaillerons ensemble pour avoir un « enregistrement STAC » qui aligne entièrement un élément STAC avec les exigences d'enregistrement plus générales.
L’autre effet intéressant de cette synchronisation a été un très belle refactorisation de la spécification de base de l'API Records par Peter Vretanos. La vision a toujours été que l'API Records est une API de fonctionnalités, mais avec des fonctionnalités supplémentaires (par exemple, le tri et des requêtes plus riches) et un modèle de données plus contrôlé. La nouvelle version rend cela beaucoup plus clair, en mettant l'accent sur les parties qui sont différentes des API OGC de base, et il devrait être beaucoup plus facile de s'aligner sur STAC.
Enregistrements statiques
Ce travail a bien posé les bases du prochain composant géospatial natif du cloud, un catalogue explorable composé d'enregistrements statiques accessibles sur le Web ! Peter a mis en place un exemple de catalogue explorable (et j'ai un Des relations publiques qui s'élargissent L'exemple d'une « collection OGC statique » avec des données vectorielles, qui nécessite un peu plus de travail pour s'aligner sur STAC, mais qui correspond à tous nos principes géospatiaux natifs du cloud. Nous avons donc maintenant à peu près tous les éléments nécessaires pour toutes les métadonnées appropriées dont nous avons besoin pour une base de référence géospatiale native du cloud. Les enregistrements et les collections sont fondamentalement deux instanciations alternatives des mêmes modèles de données de base, l'un est GeoJSON, ce qui permet de visualiser facilement un grand nombre d'entre eux ensemble, et l'autre correspond à la construction de collection API OGC de base qui est largement utilisée. À court terme, la meilleure pratique sera probablement d'utiliser les deux, mais avec le temps, il y aura probablement des outils qui se traduiront facilement de l'un à l'autre, surtout si nous parvenons à ce que les modèles de données de base soient totalement compatibles.
Tout mettre ensemble
Nous sommes donc tout près de disposer de l'ensemble complet des métadonnées statiques nécessaires à la gestion de la plupart des données géospatiales natives du cloud. Le principal défi consiste à harmoniser pleinement les travaux menés dans l'API OGC (enregistrements et fonctionnalités) avec STAC et à mieux décrire tous les champs de métadonnées requis. Il existe actuellement quelques différences ; il serait donc judicieux de simplifier la transition entre les deux approches.
Pour aider à montrer comment tout pourrait fonctionner ensemble, j'ai mis en place un «exemples d'ogc statiques' référentiel pour montrer comment vous pourriez avoir un certain nombre d'ensembles de données et de formats divers, tous disponibles à partir d'une structure complètement statique. Je continuerai à le développer et à faire évoluer les exemples, et à étoffer les readmes pour montrer ce qui se passe. Et à l'avenir, j'essaierai de faire un article de blog approfondissant les détails.
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.
