Standards

OGC API Features

Présentation

Le standard OGC API – Features est un standard modulaire permettant d’accéder à des données géospatiales de type Feature. Il est l’évolution naturelle du service WFS vers une API. Actuellement deux parties sont publiées : Core, CRS.

Exemples de mise en œuvre

OGC API Features – Core https://www.ogc.org/resource/products/byspec/?specid=1022https://docs.ogc.org/is/17-069r4/17-069r4.html

OGC API Features – CRS https://www.ogc.org/resource/products/byspec/?specid=1121https://docs.ogc.org/is/18-058r1/18-058r1.html

OGC API Features – Filtering https://docs.ogc.org/is/19-079r2/19-079r2.html

Notes de version

Il s’agit de la première version de ce standard.

Travaux en cours

Le groupe OGC API Feature SWG travaille sur les parties 4 et 5 du standard https://github.com/opengeospatial/ogcapi-features, notamment la gestion des transactions (suppression, mise à jour et suppression des objets) et la description par un schéma logique des données géospatiales telles que les entités.

OGC API Records

Présentation

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.

Travaux en cours

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.

STANAG 6015

Présentation

Le STANAG 6015 décrit les formats codés utilisés à l’OTAN pour les opérations METOC. Pour le domaines maritime, les formats codés sont les suivants :
– VELO Code
– Noise Measurement Code
– Standard Format for Oceanographic Forecasts
– OPTASK METOC
– OPTASK REA
– MIHUSOFOR Forecast Format
– Marine Mammal Sighting Report Format
– BATHY Code
– Additional Military Layers (AML)
– BOWWAVE Acronym
Les données sont codées au format texte ou binaire selon une method prédéfinie, le STANAG définit également des listes de codes pour certains paramètres.

OGC API EDR

Présentation

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.

Standards de base

Elle s’appuie sur les concepts de base communs à la famille OGC API, définis par les deux spécifications :

  • OGC API Common : Core
  • OGC API Common : Geospatial Data.

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.

Exemples de mise en œuvre

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.

Notes de version

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.

Travaux en cours

Une version 1.2 de la partie 1 (Core) de l’API devrait être bientôt soumise à l’architecture board de OGC.

Avis technique

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

Présentation

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.

Standards de base

Ce standard est un profil de :

  • JSON

Exemples de mise en œuvre

  • Climate Science: The CMIP6 Google Cloud Public Dataset
  • Oceanography: The ECCOv4r3 Ocean State Estimate
  • Atmospheric Science: Global cloud-resolving aquaplanet simulations with the System for Atmospheric Modeling

Notes de version

La version proposée par l’OGC est la version 2.

Travaux en cours

Ce standard communautaire est adopté à l’OGC en tant que community standard.

Avis technique

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.

DRP – Defence Raster Product (DGIWG)

Présentation

Cette spécification DGIWG (Défense) de gamme de produits cartographiques raster multi-échelles (5M à 5k) spécifie les règles des produits, exigences de qualité et règles d’encodage selon divers formats (GeoTIFF, NSIF et GMLJP2), ainsi que les métadonnées de produits cartographiques raster.

La spécification comprend essentiellement :

  • la définition de 2 systèmes géodésiques de référence et de grilles cohérentes (à l’intérieur d’un système de grille donné) multi-échelles allant du niveau OTAN L0 (i.e. échelles 5M à 1M) au niveau OTAN L5 (échelle 5K)
    • une grille basée sur WGS84 géographique (code EPSG 4326)
    • une grille basée sur UTM/WGS84
  • spécification de contenu
  • spécification des métadonnées et exigences de qualité
  • spécification d’encodage et mise à disposition (découpage / tuilage, nommage et structure des produits).

À noter que la spécification ne couvre pas les zones polaires.

Notes de version

DRP 1.0 a été publiée en juin 2020. Cette spécification utilise DMF 2.0 pour les éléments de métadonnées DRP.

Travaux en cours

Un échantillon DRP ARC 50K GMLJP2 a été soumis par la France et validé en mai 2021.

Le wiki DRP a été également soumis et validé en session DGIWG TP de mai 2021, et avec délai de validation à fin juin 2021.

D’autres échantillons (par ex. UTM voire avec un autre encodage) ont été demandés aux autres nations, en vain en date de mi-novembre 2021.

ISO 19139-1

Présentation

Cette norme définit les règles d’encodage en XML à partir de schémas conceptuels.  La structure des données XML est définies sous forme de XSD.

Ces règles ne s’appliquent qu’aux classes qui décrivent des ressources géographiques, les métadonnées, pour les données ce sont les règles définies dans ISO 19136 (GML) qui s’appliquent.

Exemples de mise en œuvre

Ces règles sont utilisées par la norme ISO 19115-

Notes de version

Cette norme remplace  ISO/TS 19139:2012 

 

ISO 19165-2

Présentation

Préservation des métadonnées d’observation

Cette norme vise à étendre la norme généraliste de préservation des données géospatiales numériques afin de fournir des détails sur le contenu décrivant la provenance et le contexte spécifiques aux données provenant de missions d’observation de la Terre à l’aide d’instruments spatiaux, aériens ou in situ.

AML IWC – Integrated Water Column

Présentation

La phase 1 d’AML IWC est conçue pour faciliter l’encodage des composants suivants :
– Propriétés physiques de la colonne d’eau à différents niveaux de profondeur, de la surface de la mer au fond sous forme de donnée maillée (X,Y).
– Courants océaniques à différents niveaux de profondeur, de la surface de la mer au fond sous forme de donnée maillée (X,Y).
– Répartition et activité des mammifères marins sous forme de donnée maillée (X,Y).
Note : Dans la phase 1, les niveaux de profondeur sont fixes.
L’implémentation se fait au format NetCDF v3.6.0.

Standard de base

Ce standard est un profil de :

Travaux en cours

Il est prévu une mise à jour des AML pour les adapter au contexte S-100.

Avis technique

S-104 – Spécification de produit pour les informations de marée pour la navigation de surface

Présentation

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)).

Standard de base

Ce standard est un profil de :

Travaux en cours

La publication est prévue pour 2019.

Avis technique

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.