Standard OGC

ISO/AWI TS 19176-1 Données prêtes pour l’analyse – Partie 1 : Structure et principes de base

Présentation

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

Standards de base

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 :

 

Travaux en cours

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.

 

OGC API Common

Présentation

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 bouding-box par exemple).

Exemples de mise en œuvre

il n’y a pas de mise en œuvre directe de ce standard; il est mis en œuvre au travers des autres API OGC :

Notes de version

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

Travaux en cours

Le groupe OGC API Common SWG travaille sur les prochaines parties du standard https://github.com/opengeospatial/ogcapi-common :

OGC API Tiles

Présentation

Le standard OGC API – Tiles est un standard modulaire permettant de diffuser des tuiles de données (raster, vecteur, …) . Il est l’évolution naturelle du service WMTS vers une API. Actuellement une seule partie est publiée : Core.

Exemples de mise en œuvre

OGC API Tiles– Core https://github.com/opengeospatial/ogcapi-tiles/blob/master/implementations.adoc 

Notes de version

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

Travaux en cours

Le groupe OGC API Tiles SWG travaille sur les prochaines parties du standard https://github.com/opengeospatial/ogcapi-tiles.

GeoDCAT

Présentation

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.

Travaux en cours

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.

CityJSON

Présentation

CityJSON est une spécification qui implémente en partie le modèle conceptuel défini par CityGML.

La page officielle de CityJSON est https://www.cityjson.org/

Notes de versions

CityJSON v1.0

La version v1.0 a été adoptée comme standard communautaire par l’OGC. Elle implémente l’essentiel du modèle de données CityGML v2.0 et tous les modules CityGML ont été mappés sur des objets CityJSON et encodés en JSON. Cependant, par souci de simplicité et d’efficacité, certains modules et fonctionnalités ont été omis et/ou simplifiés. Les différences dans la structure des modules ont été faites pour améliorer la facilité de mise en œuvre de CityJSON ; ces décisions ont été prises pour que les développeurs puissent facilement manipuler les fichiers.

CityJSON v1.0 est conforme à un sous-ensemble de CityGML v2.0, et les principales fonctionnalités non supportées sont :

  • LoD4 non supporté : l’intérieur des bâtiments et des ponts n’est pas autorisé ;
  • Pas de ExternalReferences, c’est-à-dire que toutes les fonctionnalités doivent être dans le même fichier ;
  • divers CRS dans le même ensemble de données ;
  • usage d’identifiants pour les géométries de bas niveau ;
  • mécanisme ADE remplacé par extension et simplifié.

La liste exhaustive des différences entre l’implémentation de CityJSON v1.0 et CityGML v2.0 est disponible sur cette page Web.

CityJSON v1.1

La version 1.1 de CItyJSON présentée sur le site de CityJSON implémente partiellement selon le même principe le modèle conceptuel de CityGML v3.0 partie 1.

Les écarts entre l’implémentation CityJSON v1.1 et CityGML v3.0 sont présentés sur cette page web dédiée.

Travaux en cours

Une version candidate 2.0 de CityJSON a été soumise à l’OGC en avril 2023 pour être adoptée comme standard communautaire. Cette version implémente le modèle conceptuel CityGML v3.0 et devrait supplanter la version 1.3 qui n’a pas fait l’objet d’une standardisation particulière.

Standards de base

Le standard CityJSON v1.0 peut être considéré comme un profil du modèle CityGML 2.0, avec une simplification et un encodage JSON.

Mise en œuvre

CityJSON est supporté par un ensemble d’outils opensource dont 3DCityDB (dont la majorité est issue de l’université TU Delft) ainsi que par FME (de SAFE Software).

2 outils de validation supportent CityJSON, dont Val3Dity et cjio (CityJSON/io) développés en python.

La liste des outils supportant CityJSON (import, export, conversion, visualisation) est disponible à https://www.cityjson.org/software/

Des jeux de données test (en LoD2) sont disponibles sous https://www.cityjson.org/datasets/.

Avis technique

L’usage de JSON (au lieu de GML) et la simplification du modèle selon les schémas JSON conduit à un volume moindre des fichiers JSON (une taille des fichiers de l’ordre de 5 fois plus faible).

Note: Le service des développements métiers (SDM) de l’IGN a évalué avec succès CityJSON.

I3S/SLPK

Présentation

I3S (et son format de stockage associé SLPK) est un standard OGC communautaire (soumis par ESRI) destiné à la diffusion et le rendu de contenus géospatiaux 3D (très) volumineux tels que l’imagerie 3D (photogrammétrique), les bâtiments 3D, et autres objets vecteur et les nuages de points.

Un ensemble de données I3S, appelé Scene Layer, est un standard de conteneur pour des données géographiques 3D (pouvant être volumineuses) réparties de manière hétérogène. Les Scene Layers sont conçus pour être utilisées dans des flux en streaming pour des environnements de travail mobiles, ordinateurs  et sur serveur et sont accessibles sur le Web ou sous forme de fichiers locaux.

Le format de livraison et le modèle de persistance des Scene Layers, appelés respectivement Scene Layer indexée (I3S) et package de Scene Layers (SLPK), sont spécifiés en détail dans le standard communautaire OGC. Les deux formats sont encodés à l’aide de JSON et de ArrayBuffers binaires (ECMAScript 2015). I3S est conçu pour être compatible avec le Cloud, le Web et les mobiles.

I3S est basé sur JSON, REST et les standards du web et est facile à manipuler, à analyser et à rendre efficacement par les clients Web et mobiles. I3S est conçu pour diffuser de grands ensembles de données 3D et est conçu pour les performances et l’évolutivité. I3S est conçu pour prendre en charge le contenu géospatial 3D et les systèmes de référence de coordonnées et modèles altimétriques en conjonction avec un ensemble de types de couches.

La version communautaire ouverte GitHub de ce standard est ici : https://github.com/Esri/i3s-spec

Mise en œuvre

I3S/SLPK est supporté notamment par la suite ArcGIS, ainsi que par ArcMap (ESRI), et par FME (SAFE Software).

D’autres reférences de mises en oeuvre peuvent être trouvées sur le dépot github d’I3S.

Notes de version

La version 1.1 ajoute le support des nuages de points, et des améliorations de performance.

La version 1.2, adoptée en novembre 2021 par l’OGC ajoute des optimisation d’index et de la gestion avancée des textures.

La version 1.3, adoptée en décembre 2022 par l’OGC ajoute le support des scènes d’intérieur des bâtiments.

Avis technique

I3S est une spécification en concurrence avec 3D Tiles également standard communautaire OGC. Si I3S est bien sûr largement supporté par les logiciels ESRI et FME, à ce jour il manque un support opensource.

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=1022

OGC API Features – CRS https://www.ogc.org/resource/products/byspec/?specid=1121

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 prochaines parties du standard https://github.com/opengeospatial/ogcapi-features., notamment pour le support des fonctionnalités de filtrage avancées (équivalentes à ce qu’offre Filter Encoding) et de gestion des transactions (suppression, mise à jour et suppression des objets).

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 mineure 1.0.1 a été publiée en août 2022.

Travaux en cours

Les travaux sur les spécifications de l’API sont assez vivants et certaines évolutions pourraient donner lieu à des versions 1.1 ou 1.2 de la spécification.

Une version 1.1 a été soumise à commentaires publics. Elle intègre le support de la méthode POST pour les requêtes ainsi que la capacité à accéder à des données de couvertures sur présentant d’autres dimensions que les quatre spatiotemporelles classiques (x,y,z,t), telles que des gammes de fréquence.

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épendus 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 standard « à 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

*Nom complet de la norme

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 en cours d’adoption à l’OGC en tant que community standard (vote en cours).

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.

OGC Catalogue Service for the Web (CSW)

Présentation

Ce standard décrit les interfaces d’accès à un service de catalogues dont l’objectif est la publication de catalogues de métadonnées sur des données spatiales, sur des services et autres ressources ainsi que la recherche parmi les entrées de catalogues. Ces métadonnées sont des informations caractéristiques de ressources permettant l’évaluation de l’adéquation à un besoin ainsi que des traitements supplémentaires, que ce soit par un humain ou par un logiciel. Les services de catalogues permettent la découverte de ressources enregistrées au sein d’une communauté.
Le document est structuré de la façon suivante :

  • Cinq chapitres introductifs,
  • Le chapitre 6 présente un modèle d’information abstrait du concept de catalogue, incluant une syntaxe de requêtes sur les catalogues, la liste des éléments de métadonnées sur lesquels peuvent porter une requête ainsi que la liste des éléments de métadonnées pouvant être renvoyés.
  • Le chapitre 7 décrit un modèle d’interfaces pour l’accès aux catalogues. Ces interfaces doivent supporter un certain nombre d’opérations, comme getCapabilities, harvestRecords, etc.
  • Les chapitres 8, 9 et 10 décrivent les mises en œuvre de services de catalogue suivant différents protocoles : Z39.50, CORBA/IIOP et HTTP. Cette dernière mise en œuvre est connue sous le nom de « Catalog Service for the Web » ou CSW.

L’implémentation peut se faire en KVP, XML ou SOAP

Profils

Exemples de mise en œuvre

Notes de version

version 3.0
Cette version introduit quelques nouveautés intéressantes comme des nouveaux queryables (TemporalExtent), UnHarvest, des suppressions d’opérations comme DescribeRecord et des améliorations (support d’OWS 2.0 et Filter 2.0, OpenSearch, toutes versions de GML…).
L’implémentation suivant le protocole HTTP est décrite dans le document OGC 12-176r7.

Travaux en cours

Le groupe Catalogue API SWG travaille sur une mise à niveau de ce service en accord avec OpenAPI.

Avis technique

Il est conseillé d’utiliser la version 2.0.2 avec le profil d’utilisation ISO.