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
La série ISO 19124 traite de l’étalonnage et de la validation des données de télédétection, qui sont collectées par un capteur à bord d’une plate-forme dans le cadre d’une mission, et des produits dérivés en partie ou en totalité des données. Elle définit les métadonnées relatives au processus d’étalonnage et de validation qui n’ont pas été définies dans d’autres normes internationales ISO/TC 211. Ces métadonnées permettent aux fournisseurs de données de fournir une description normalisée du processus d’étalonnage et de validation qu’ils ont appliqué aux données. Elles permettent aux utilisateurs de données d’obtenir les mêmes formes de métadonnées auprès de différents fournisseurs de données.
Le terme d’étalonnage fait référence au processus de correction des données, non seulement du point de vue géométrique, radiométrique et spectral, mais aussi du point de vue des caractéristiques pour les applications qualitatives et quantitatives.
Le terme « validation » désigne le processus d’évaluation de la qualité et de la précision des données calibrées et des produits dérivés.
Le terme « produits dérivés » désigne les produits qui ne sont pas directement mesurés par des capteurs, mais qui sont dérivés des mesures directes des capteurs par des algorithmes ou des modèles.
Ce projet de spécification technique a pour but de définir l’étalonnage et la validation des données d’observation de la Terre acquises par des capteurs optiques et des produits dérivés des données optiques. Il ne traite pas de l’étalonnage des capteurs optiques ni de la validation de l’étalonnage des capteurs optiques, qui sont couverts par la norme ISO 19159-1.
Le projet a été lancé en octobre 2024 et prévoir une publication en Octobre 2027.
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 :
La série ISO 19124 traite de l’étalonnage et de la validation des données de télédétection, qui sont collectées par un capteur à bord d’une plate-forme dans le cadre d’une mission, et des produits dérivés en partie ou en totalité des données. Elle définit les métadonnées relatives au processus d’étalonnage et de validation qui n’ont pas été définies dans d’autres normes internationales ISO/TC 211. Les métadonnées permettent aux fournisseurs de données de fournir une description normalisée du processus d’étalonnage et de validation qu’ils ont appliqué aux données. Elles permettent aux utilisateurs de données d’obtenir les mêmes formes de métadonnées auprès de différents fournisseurs de données.
La partie 2 de cette spécification technique définit l’étalonnage et la validation des données d’observation de la Terre (OT) acquises par des capteurs SAR et des produits dérivés des données SAR.
Ce projet de spécification technique est en cours d’élaboration – stade DTS et a pour objectif d’être publiée en octobre 2025.
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é initialement 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. Les travaux ont redémarré au niveau de l’ISO depuis juin 2025 et visent à définir dans un premier temps un périmètre consensuel pour le premier volet de la série.
DCAT est un vocabulaire W3C largement utilisé pour décrire les ensembles de données et les services d’accès aux données. Certaines propriétés temporelles et géographiques de base font déjà parti du vocabulaire DCAT v2 et/ou sont prévues pour la v3, mais ces propriétés ne répondent pas à l’ensemble des exigences identifiées dans le Discussion Paper élaboré par l’OGC.
L’UE fait référence à GeoDCAT-AP en tant que « bonne pratique » et note qu' »un projet de document de bonnes pratiques de l’OGC (Open Geospatial Consortium) est en cours d’élaboration. » Des discussions sont en cours pour faire de GeoDCAT-AP une norme communautaire de l’OGC.
Les travaux visent à séparer un profil géospatial général de DCAT, appelé « GeoDCAT », de GeoDCAT-AP ; le profil d’application (AP) spécifique à l’Europe ne fera pas partie du travail de normalisation de l’OGC.
GeoDCAT fournira un vocabulaire et un encodage normalisés pour les descriptions d’ensembles de données spatiales et les descriptions de services (enregistrements de métadonnées) respectant les recommandations décrites dans les Spatial Data on the Web Best Practices. GeoDCAT pourrait à l’avenir être utilisé comme encodage dans les API tels que les API Records de l’OGC et STAC.
Le groupe GeoDCAT SWG travaille sur la standardisation de GeoDCAT. L’objectif de ce groupe de travail est de publier un standard GeoDCAT, un profil spatio-temporel de la recommandation DCAT du W3C. Il fait suite au Discussion Papers OGC 18-001 publié sur le sujet.
Ce nouveau standard a pour objet de créer un encodage JSON des métadonnées ISO 19115-1.
Les nouveaux usages tels que les APIs OGC par exemple se basent actuellement beaucoup sur des encodages en JSON. Le fait que la norme de métadonnées ISO ne possède qu’en encodage en XML est un frein à un certain nombre d’utilisations. Ce nouvel encodage devrait donc permettre une utilisation plus large de la norme de métadonnées.
L’encodage qui sera définit couvre pour l’instant uniquement une partie du périmètre d’ISO 19115. Les règles d’encodage associées pourront néanmoins être appliquées à d’autres éléments du modèle.
Cette norme permet de spécifier comment établir, maintenir et publier un registre de mesures qualité conformément à l’ISO 19135-1. Cette norme comprend également la définition des moyens d’accès machine (API) à ce registre.
Les travaux comprennent aussi l’initialisation du registre avec un jeu de mesures prédéfinies. Elle devrait permettre de mettre en place un registre de mesures qualité à l’ISO, accessible par une machine et dont la maintenance sera facilitée.
Concernant le financement et la gouvernance du registre, l’OGC a été élu organisme d’enregistrement du registre (hébergement, publication et maintien du registre). Passée au stade de Community draft à l’OGC et ouverte aux commentaires techniques, l’enjeu est aujourd’hui d’avoir des retours sur le déploiement technique.
Les travaux du groupe ont débuté en 2021. Le projet a été relancé en mai 2023, suite au retard d’ISO 19135 (lié à l’impact potentiel de la révision de l’ISO 19135 sur le registre géodésique).
L’API EDR (“Environmental Data Retrieval”) est un standard OGC qui définit une interface simple et unifiée permettant d’accéder via le web à des données spatiotemporelles d’origines multiples (météorologiques, océanographiques, géographiques raster mais aussi vecteur) selon une position, une zone, ou le long et autour d’une trajectoire donnée.
Elle est issue de l’expérience du développement du profil applicatif « Met Ocean » de WCS avec des cas d’usages similaires et en s’appuyant sur des bases technologiques différentes.
Elle s’inscrit dans la refonte engagée par l’OGC de ses standards vers la famille des « OGC API » en adoptant une approche modulaire, centrée sur les ressources et s’appuyant sur la spécification OpenAPI.
Elle s’appuie sur les concepts de base communs à la famille OGC API, définis par les deux spécifications :
Elle s’appuie aussi fortement sur spécification CoverageJSON (candidat pour être adopté comme community standard OGC) comme format de description des données de réponse aux requêtes qu’elle spécifie.
Le développement de cette API est poussé par le service national britannique de météorologie (Met Office) et le US National Weather Service. Ce dernier propose un serveur de démonstration référencé sur le dépôt Github de l’API.
De même l’université de Wuhan en Chine implémente cette API et propose un serveur de démonstration aussi référencé sur ce dépôt Github.
La dernière version de la partie 1.1 a été publiée en juillet 2023 OGC API – Environmental Data Retrieval Standard.
La partie 2 de l’API qui implémente le workflow PubSub (abonnement et réception de notifications, de nouvelles données) a été publiée en septembre 2024 OGC API – Environmental Data Retrieval – Part 2: Publish-Subscribe Workflow.
Une version 1.2 de la partie 1 (Core) de l’API devrait être bientôt soumise à l’architecture board de OGC. Elle implémente OpenAPI 3.1, ne supporte plus que le protocole HTTPS et permet de paginer les résultats si besoin.
La chaîne de traitement PubSub (abonnement et réception de notifications, de nouvelles données) a été adoptée et publiée dans la partie 2 du standard API EDR qui sert d’expérimentation. On reçoit des notifications sur les collections cartographiques quand on y souscrit et le retour est en GeoJSON. Elle peut fonctionner de manière asynchrone. D’autres APIs pourraient bénéficier de cette chaîne de traitement : Records, Features, Processes, Maps, Connected Systems.
La partie 3 “restrictive services profiles” est en cours de rédaction en prenant notamment en compte les demandes du DGIWG sur la restriction des accès et la rédaction de la partie 4 “aggregations and statistics” n’a pas encore débuté. Des inquiétudes ont été soulevées quant au fait que les travaux sur EDR sont relativement avancés et qu’il pourrait donc y avoir des divergences avec d’autres APIs, voire avec l’API Common.
L’API EDR a vocation à reprendre les spécialisations de WCS pour traiter les cas d’usages des domaines météorologique et océanographique en reprenant notamment les fonctionnalités du profil MetOcean de WCS. Elle propose en plus une approche simplifiée de l’accès aux données et elle étend aussi les capacités de WCS en permettant de s’appliquer aussi a des données de type vecteur et en intégrant un accès aux données par localisant autre que géographique.
En termes de fonctionnalités elle occupe de ce fait une place transversale vis à vis des nouvelles API OGC qui ont vocation à reprendre les anciennes spécifications : OGC API Coverages ou OGC API Features dans la mesure où elle peut répondre à certains cas d’usages identiques.
L’objectif à long terme de cette API est bien de proposer une combinaison d’APIs, étant elle-même peur restrictive.
En s’appuyant sur le format CoverageJSON, elle semble cibler plutôt des usages de consultation dans des applications web.
Zarr est une spécification open-source pour le stockage de tableaux de données multidimensionnels (également appelés tableaux N-dimensionnels, ND-arrays, ou tenseurs très répandus dans la recherche scientifique et l’ingénierie.
Zarr stocke les métadonnées à l’aide de fichiers texte .json et de données de tableau sous forme (facultative) de morceaux binaires compressés. Zarr peut stocker des données dans la plupart des systèmes de stockage, y compris les bases de données, les systèmes de fichiers standards « à base de répertoires » et le cloud. Cette flexibilité permet aux implémentations d’expérimenter de nouvelles technologies de stockage tout en maintenant une API uniforme pour les bibliothèques et les utilisateurs en aval.
Ce standard est un profil de :
La version proposée par l’OGC est la version 2.
Ce standard communautaire est adopté à l’OGC en tant que community standard.
Ce format émergent est prometteur car il permet un accès plus rapide aux données cloud (il n’est pas nécessaire de télécharger la donnée entière pour pouvoir l’utiliser). Il pourrait remplacer à terme le format NetCDF/HDF. D’ailleurs NetCDF pourrait prochainement proposer un encodage Zarr.