Cette norme décrit un encodage GeoJSON et JSON-LD pour les métadonnées des jeux de données d’observation de la Terre. Elle peut être appliquée pour encoder des métadonnées basées sur l’Earth Observation Metadata Profile of Observations and Measurements (O&M) OGC 10-157r4 ou en tant qu’encodage du modèle conceptuel Unified Metadata Model for Granules (UMM-G).
L’API OGC-Connected Systems est destinée à servir de passerelle entre des données statistiques d’entités géographiques (ou autre) et des données dynamiques (observations, commandes…). Elle s’appuie sur le format GeoJSON ainsi que sur des modèles d’informations OGC existants comme SensorML, O&M, SWE, SOSA/SNN (capteurs)
Il s’agit de la première version de ce standard
La version 1.0 du standard devrait être votée bientôt. C’est une extension de l’API OGC Features qui a un mécanisme supplémentaire pour retrouver les données statiques et dynamiques.
Les brouillons des deux premières parties sont disponibles ici :
OGC API Connected Systems Part 1 Draft
OGC API Connected Systems Part 2 Draft
L’élaboration d’une partie 3 pour implémenter Pub/Sub est à venir, ainsi qu’une partie 4 sur l’échantillonnage, et 5 sur les encodages binaires.
Par ailleurs et à toute fin utile, l’OpenSensorHub est un bon exemple d’implémentation de l’API Connected Systems.
La spécification projet de l’OGC API – Coverages définit une API Web pour accéder aux couvertures. Une couverture est une « fonction qui retourne des valeurs de son étendue pour toute position directe dans son domaine » (ISO 19123-1:2023).
Il s’agit de la première version de ce standard
La partie 1 “core” devrait être prête pour être soumise à commentaires à l’AOB (Architecture Office Board) d’ici fin juin 2025.
Un brouillon est disponible ici OGC API Coverages Part 1 Draft
Des parties à venir sur les filtres, l’agrégation de champs et les “scenes” (multi-couches) devraient ensuite être rédigées. Des questions se posent quant au fait de se rapprocher de l’API GeoDataCubes.
Il y a aussi eu des discussions sur la représentation du “no data” dans le format geoTIFF qui n’est pas adapté au standard en cours de rédaction mais il a été décidé de s’approcher de l’équipe en charge de ce format pour voir comment l’adapter.
Le standard OGC API – Maps décrit une API capable de fournir des cartes électroniques référencées spatialement, qu’elles soient statiques ou rendues dynamiquement, de manière indépendante de l’entrepôt de données sous-jacent.
Il s’agit de la première version 1.0.0 de ce standard qui vient d’être publiée
Le projet de norme OGC API – Discrete Global Grid Systems spécifie une API permettant d’accéder aux données organisées selon un Discrete Global Grid System (DGGS). L’idée étant de retrouver des données sur une zone/des cellules non rectangulaires comme c’est le cas pour Tiles.
Il s’agit de la première version de ce standard
Élaboration de la partie 1 : OGC API – Discrete Global Grid Systems – Part 1: Core
L’API OGC – Jointures standard spécifie les exigences pour une API Web qui prend en charge les opérations de jointure pour les fichiers de données tabulaires d’entrée qui peuvent être joints à des collections d’entités disponibles sur un serveur ou directement à l’aide d’autres fichiers d’entrée.
OGC API Common
Il s’agit de la première version de ce standard
L’appel à commentaires sur l’API Joins n’a finalement pas encore été lancé mais devrait l’être bientôt. Il est espéré de soumettre une version du standard d’ici fin 2025. Les premières fonctionnalités sont un retour de métadonnées pour les collections disponibles, la possibilité de faire une jointure sur un attribut d’une donnée chargée (ex : csv) avec un élément géospatial de la collection ou entre deux fichiers chargés, la possibilité de lister, retrouver ou supprimer des jointures.
Le brouillon est disponible ici OGC API Joins Part 1 Draft
Zarr est un format de données natif du cloud pour les tableaux à n dimensions qui permet d’accéder aux données dans des blocs compressés du tableau d’origine. Zarr facilite la portabilité et l’interopérabilité sur les entrepôts de données et les disques durs.
En tant que format de données générique, Zarr est devenu de plus en plus populaire à des fins géospatiales. À ce titre, en juin 2022, l’OGC a approuvé Zarr V2.0 en tant que Norme communautaire OGC. L’objectif du SWG GeoZarr est de faire adopter par l’OGC un standard Zarr explicitement géospatiale (GeoZarr) qui établit des conventions flexibles et inclusives pour le format cloud natif Zarr qui répondent aux diverses exigences du domaine géospatial. Ces conventions visent à fournir un cadre clair et normalisé pour l’organisation et la description des données qui garantit une représentation sans ambigüité.
En plus de l’encodage des données géospatiales et des métadonnées, la norme GeoZarr fournira une alternative multidimensionnelle à la norme bidimensionnelle. COG, qui a récemment gagné en popularité en raison de ses capacités cloud. Ces capacités permettront une prise en charge inhérente des fonctions traditionnelles, telles que la visualisation (similaire à OGC API – Maps), accès aux sous-ensembles de données (analogue à API OGC – Coverage), et la symbologie (équivalente à API OGC – Styles). Ces aspects sont prévus pour être intégrés en tant que profils facultatifs (par exemple, classes de conformité).
Ce standard est un profil de :
Le groupe GeoZarr SWG travaille sur différents aspects :
Le Cloud Optimized GeoTIFF (COG) s’appuie sur deux caractéristiques du format TIFF v6 (tuiles et sous-fichiers à résolution réduite), les clés GeoTIFF pour le géoréférencement et la plage HTTP, qui permet de télécharger efficacement des parties d’images et des données de couverture de grille sur le Web et de rendre possible une visualisation rapide des données des fichiers TIFF ou BigTIFF et des flux de traitement géospatial rapides. Les applications compatibles COG peuvent télécharger uniquement les informations dont elles ont besoin pour visualiser ou traiter les données sur le Web. De nombreux ensembles de données de télédétection sont disponibles dans des installations de stockage dans le cloud qui peuvent bénéficier d’une visualisation et d’un traitement optimisés. Cette norme formalise les exigences pour qu’un fichier TIFF devienne un fichier COG et pour que le serveur HTTP rende les fichiers COG disponibles de manière rapide sur le Web :
Elle s’appuie aussi sur la spécification BigTIFF pour permettre d’encoder des fichiers images dont la taille dépasse 4Go (limite supérieure pour les fichiers conformes à la spécification TIFF).
Le COG a été défini par une communauté d’utilisateurs dans le but d’améliorer la diffusion des images de télédétection sur le cloud. Ce standard respecte les décisions prises et les conventions adoptées par la communauté et les formalise dans des exigences et recommandations standard. Le nom du standard reflète toujours cet objectif initial : un format optimisé pour le cloud.
Ce standard est un profil de :
Ce nouveau projet de série de normes traite des données géographiques d’observation. Il vise à définir des exigences seuils et cibles en termes de qualité, de métadonnées, de prétraitement et d’organisation de ces données afin que celles-ci puissent être qualifiées de données « prêtes pour l’analyse », à savoir des données directement utilisables pour être exploitées en conjonction avec d’autres jeux de données pour des travaux d’analyse.
Le concept de données prêtes pour l’analyse s’inspire du label Analysis Ready Data définit par CEOS qui s’applique aux données d’observation satellitaires :
Il s’agit d’un travail mené conjointement par l’ISO TC211 (WG6) et l’OGC (ARD SWG)
La partie 1 de cette série de normes vise à définir les principes de base des données prêtes pour l’analyse. Les autres parties à venir devraient traiter plus spécifiquement de la déclinaison de ces principes en fonction du type de données concernée, selon qu’il s’agisse de données issues de capteurs ou thématiques.
Après des dissensions au sein du groupe sur la déclinaison thématique des ARD, les travaux du groupe ont été mis en stand-by après les meetings OGC et ISO de juin 2024.
Le standard OGC API – Common est un standard d’API servant de socle à toutes les autres API OGC, tout comme l’est OWS-Common pour l’ensemble des services OGC W*S.
Il définit notamment des briques communes (l’utilisation du protocole http, la page d’accueil des API OGC, l’utilisation d’OpenAPI 3.0 et la mise en place d’un registre des briques).
Enfin dans le cadre de la démarche plus globale et modulaire des API OGC, un registre est mis en place à l’adresse suivante https://blocks.ogc.org. Ce registre permet la découverte et de faciliter la réutilisation la plus large des différentes ressources OGC pour la mise en place d’API. Ces ressources peuvent être de différents nature, des API elles-mêmes, des briques d’API, ou encore des ressources plus granulaires (définition de classes, telle que la bounding-box par exemple).
Le rythme de développement des standards de cette API est très lent car il essaye de prendre en compte tous les besoins.
Il n’y a pas de mise en œuvre directe de ce standard ; il est mis en œuvre au travers des autres API OGC :
Il s’agit de la première version de ce standard.
Le groupe OGC API Common SWG travaille sur les prochaines parties du standard https://github.com/opengeospatial/ogcapi-common :
La partie 2 sur les collections devrait être prête pour l’AOB d’ici le prochain OGC de juin 2025 au Mexique. Des discussions sont encore en cours pour les parties 3 sur les schémas logiques et 4 sur la découvrabilité des collections (inclut filtres et ressources locales de catalogue).