Standard OGC

OGC API Coverages

Présentation

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

Notes de version

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

Travaux en cours

Le groupe OGC API Coverages SWG travaille à finaliser le standard. Le standard candidat est relativement stable, les dépendances en dur au schéma CIS ont été supprimées de façon à permettre la description du domaine et des valeurs dans la description de la couverture. Les travaux portent sur la résolution des dernières issues. Des travaux ont été menés en relation avec le Testbed 20 sur l’OGC API GeoDataCube pour que l’API Coverages serve de base pour cette API.

OGC API DGGS

Présentation

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.

Notes de version

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

Travaux en cours

Élaboration de la partie 1 : OGC API – Discrete Global Grid Systems – Part 1: Core

OGC API Joins

Présentation

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.

Standards de base

OGC API Common

Notes de version

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

Travaux en cours

Un appel à commentaires pourra être lancé d’ici fin 2024 de façon à avoir une version candidate au vote pour juin 2025.

Geozarr

Présentation

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 ambiguïté.

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

Standards de base

Ce standard est un profil de :

Travaux en cours

Le groupe GeoZarr SWG travaille sur différents aspects :

  1. Compatibilité : Assure une compatibilité aisée avec les outils de cartographie et d’analyse de données populaires tels que GDAL, Xarray, ArcGIS, QGIS et d’autres outils de visualisation, permettant une intégration transparente dans les flux de travail existants.
  2. Dimensions : Prise en charge de données multidimensionnelles, telles que les informations hyperspectrales et d’altitude, pour répondre à diverses exigences en matière de données géospatiales.
  3. Découverte de données : fourniture de métadonnées pour la découverte, l’accès et la récupération des données, y compris des produits composites constitués de plusieurs tableaux de données.
  4. Mélange de données : faciliter la combinaison de différents types de données géospatiales, notamment des images satellites, des cartes d’élévation et des modèles météorologiques, pour créer des ensembles de données complets et informatifs.
  5. Flexibilité : Permettre aux scientifiques et aux chercheurs de travailler avec divers types de données et projections dans leurs logiciels et langages de programmation préférés, favorisant ainsi la flexibilité et l’adaptabilité dans le traitement et l’analyse des données géospatiales.

 

Cloud Optimized GeoTIFF (COG)

Présentation

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 :

  • des règles d’organisation des pixels des images au sein du fichier TIFF selon une logique de découpage spatial de façon à permettre de ne lire qu’une partie du fichier pour accéder à une zone géographique données couverte par l’image
  • des exigences relatives au support  des HTTP range request de façon à permettre le téléchargement partiel de parties du fichier via le protocole HTTP 

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.

Standards de base

Ce standard est un profil de :

 

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.

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.

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.