Ce nouveau standard a pour objet de créer un encodage JSON des métadonnées ISO 19115-1.
Les travaux sont en cours afin de déterminer quelle est la meilleure forme de JSON à adopter. Il s’agit de trouver un compromis entre la complexité du schéma de métadonnées et la simplicité requise par l’usage du JSON.
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.
Les travaux du groupe ont débuté en 2021. Le projet redémarre après des ralentissements côté ISO 19135.
Projet de spécification d’une API de catalogage qui s’inscrit dans la lignée des APIs de l’OGC.
Le core est largement fondé sur API Feature et définit ce qu’est un enregistrement de métadonnées (Record) et quel mécanismes permettent de chercher/classer les résultats (mots clefs, titres, description, … ). Le modèle est analogue à ce qui est disponible dans un catalogue de type CSW.
Une extension OpenSearch est définie, comme dans la version 3.0 du standard CSW.
Enfin les résultats peuvent être renvoyés suivant trois formats : JSON, ATOM et HTML (chacun dispose de son extension).
Ce qui est intéressant est la possibilité de décrire l’accès aux services et données avec plus de détails (par exemple, un template d’URL pointant vers la bonne couche WMS/API Maps, ou collection de données API feature…), au lieu du seul lien vers un document de capacité (GetCapabilities). Cela devrait permettre une meilleure intégration de l’API Records avec l’ensemble des autres APIs.
Discussions à propos des paramètres/dimensions à ajouter à des collections (propriétés étendues). Propriétés pour couvrir tous les aspects des différentes API qui découlent de l’API Common.
Le groupe OGC API Records SWG travaille sur une version du draft accessible ici : http://docs.ogc.org/DRAFTS/20-004.html. Une harmonisation avec la spécification de catalogue STAC est souhaitée et des ajustements sont donc nécessaires pour que les fonctionnalités se correspondent au mieux (tri, pagination, etc).
L’intégration de l’OGC API Records parmi les autres API se fait selon deux mécanismes : Les ressources collections deviennent requêtables (il est possible de les filtrer) et la collection peut également être un catalogue de métadonnées.
La partie 1 est complète depuis septembre 2024. Il reste encore quelques petites étapes de validation et d’ajustement.
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épot github de l’API.
De même l’université de Whuan en Chine implémente cette API et propose un serveur de démonstration aussi référencé sur ce dépot github.
La dernière version de la partie 1.1 a été publiée en juillet 2023.
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.
Une version 1.2 de la partie 1 (Core) de l’API devrait être bientôt soumise à l’architecture board de OGC.
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 terme 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.
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.
La S-104, développée par le TWCWG de l’OHI, en cours de rédaction devrait spécifier la description des informations de marée, prédictives ou en temps réel sous forme de séries temporelles.
Deux encodages sont prévus, un pour les données temps réel (S-112) et un pour les données prédictives (S-100 (HDF5)).
Ce standard est un profil de :
La publication est prévue pour 2019.
Cette norme impose un encodage en S-100 (HDF5). HDF5 est un format émergeant dans la communauté GHOM et complètement intégré dans le format NetCDF4.
Cette spécification de produit décrit une modélisation améliorée des paramètres géo-acoustiques contenus dans l’AML ESB, notamment les propriétés géo-acoustiques de la couche sédimentaire sous forme de donnée maillée (X,Y).
Ce standard est un profil de :
Ce standard n’a pas été adopté.
Il est prévu une mise à jour des AML pour les adapter au contexte S-100.
Ce panel technique, piloté par la France, est chargée des tâches de coordination (inter DGIWG et avec les autres organismes de normalisation) et de la maintenance des standards Imagerie et données Grid (IGD) du DGIWG. Ses missions sont :
La spécification de produit d’information sur les aides à la navigation S-201, développée par l’AISM, fournit une structure commune pour l’échange d’information d’aide à la navigation. Cela comprend les bouées, les balises, les feux, les signaux sonores et les AIS. Le produit contient les positions, les propriétés, l’état de fonctionnement et les commentaires généraux relatifs aux aides à la navigation.
Le S-201 PS peut être utilisé pour échanger des informations d’aide à la navigation sous une forme cohérente entre les autorités des phares, les bureaux hydrographiques et d’autres organisations, y compris les agences commerciales et professionnelles.
L’implémentation se fera au format S-100 (GML).
Ce standard est un profil de :
Pour le moment, le standard en est au stade de brouillon.
Développée par le NIPWG de l’OHI, Il s’agit de la norme sur le catalogue des produits nautiques.
Un encodage spécifique est défini basé sur S-100 (GML).
Ce standard est un profil de :
La publication est prévue pour 2019.