Thèmes

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.

DOP – Defence Orthoimagery Product (DGIWG)

Présentation

Cette spécification DGIWG (Défense) de gamme de produits orthoimagerie multi-résolutions (25m à 0,1m) 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 orthoimagerie.

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-résolutions selon 10 niveaux allant du niveau DOP 0 (25m) au niveau DOP 9 (0,1m).
    • 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

DOP 1.0 a été publié en mai 2021. Cette spécification utilise DMF 2.0 pour les éléments de métadonnées DOP.

Des échantillons de données sont disponibles en téléchargement sur le site web du DGIWG.

Travaux en cours

L’extension de la spécification DOP aux zones polaires reste à faire.

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 trois parties sont publiées : 1 )Core, 2) CRS, 3) Filtering.

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

Les premières partie publiées en sont à leur première version.

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.

La partie 4 “create, replace, update, delete” est en cours de validation.

La partie 5 “schemas” va bientôt être soumise à validation. Elle devrait fusionner avec la partie 3 de l’API Common : OGC API – Features – Part 5 / OGC API – Common – Part 3: Schemas.

Un redécoupage des parties et de nouvelles parties sont prévus. Partie 6 “Property selection”, partie 7 “GeometrySimplification”, partie 8 “sorting”, partie 9 “Text Search”, partie 10 “Search/Queries”.

Pour pallier les limitations du GeoJSON qui ne supporte pas les schémas, les notions temporelles…un format JSON-FG (OGC Features and Geometries JSON) est en cours de développement.

Une version 1.1 de la partie “core “devrait être publiée.

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

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.

Notes de version

La partie 1 de base est adoptée: OGC API – Records – Part 1: Core

Travaux en cours

La partie OGC API – Records – Part 2: Facets qui permet d’agréger des enregistrements dans des “buckets” et fournir des statistiques au sujet du nombre d’enregistrements dans chaque “bucket”;  et la partie [DRAFT] OGC API – Records – Part 3: Create, Replace, Update, Delete, Harvest inspirée de la partie 4 de l’API Features, sont en cours de rédaction active. La notion de “harvest” permettrait plutôt que de laisser le client déterminer quels enregistrements créer pour rendre une ressource détectable, de transférer cette responsabilité au serveur. Des recherches pour incorporer les cas d’utilisation du Protocole d’Initiative des Archives Ouvertes pour la Moissonnage de Métadonnées (OAI-PMH) sont en cours.

A l’avenir est prévue une partie 4 sur les catalogues “fédérés” à savoir un ensemble de catalogues agrégés et listés.

Des questions se posent sur la nécessité d’une partie supplémentaire sur les extensions STAC.

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

Notes de version

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.

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

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

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.

Des échantillons de données sont disponibles en téléchargement sur le site web du DGIWG.

Travaux en cours

L’évolution du standard DRP au zones polaires est en stand-by faute de nations volontaires pour y travailler dessus.

 

Thème Qualité

Présentation

La qualité des données géographiques : qu’est-ce-que c’est ?

La qualité désigne la capacité de la donnée à être fiable, précise, complète, cohérente ou encore pertinente, afin de répondre à des besoins spécifiques​. Cette capacité se mesure et est retransmise dans la fiche de métadonnée ou dans un rapport de qualité liés à la donnée.

Les mesures de qualité s’expriment au travers de critères variés relatifs à la donnée elle-même ou à sa mise à disposition. La qualité s’évalue au regard de l’usage : à chaque usage ses critères de qualité.

Au-delà de ces principes généraux, il existe des normes et guides pour accompagner la gestion de la qualité, pour établir les bonnes mesures de la qualité au regard des usages et sécuriser la confiance des utilisateurs envers les données.

L’utilisation de mesures basées sur des méthodes standardisées permet pour un utilisateur d’effectuer une meilleure comparaison entre les jeux de données et une estimation claire de l’adéquation du jeu de de donnée pour son usage. ​

La principale famille de normes concernant la qualité est l’ ISO 19157.

À noter que la qualité peut être exprimée au niveau d’un jeu de données ou au niveau des objets.

La qualité est présente dans tous les domaines thématiques car elle est intrinsèquement​ liée à la donnée et représentée dans sa métadonnée.

Il existe différents groupes de travail consacrés à ce domaine (le Data Quality DWG à l’OGC, le Q-KEN de l’EuroGeographics, le QuaDoGéo du CNIG) auxquels l’IGN participe.

À l’ISO/TC 211

Normes publiées

  • ISO 19113
    Information Géographique – Principes qualité
  • ISO 19114
    Information Géographique – Procédures d’évaluation de la qualité
  • ISO/TS 19138
    Information Géographique – Mesures de la qualité des données

Normes en révision

  • ISO TS/19158
    Assurance Qualité des Productions de Données

Nouveaux projets

  • ISO 19157-3
    Qualité des données – Registre de mesure

Au DGIWG

Standards publiés

    Néant

Travaux en cours

Projets actifs :

    Néant

Nouveaux standards en développement :

    Néant

Révisions :

    Néant

À l’OGC

Standards publiés

    Néant

Travaux en cours

DWG actifs:

    Néant

Nouveaux standards en développement :

Révisions :

    Néant

À l’OTAN

Standards publiés

    Néant

Travaux en cours

Groupes de travail actifs:

    Néant

Nouveaux standards en développement :

    Néant

Révisions :

    Néant

Autres sujets liés

  • Qualité des données pour l’IA / issues de traitements d’IA : La qualité des données est un sujet récurrent des discussions autour de l’IA géospatiale. Ces discussions sont largement relayées au sein de l’OGC. 
  • Qualité des données 3D : ​​Des réflexions sont en cours côté IGN ainsi que pour les besoins Défense.
  • Qualité des services : Des tests ont été ​fait à l’OGC concernant des mesures de qualités des services, sans être concluants. Il n’existe aucune norme dans le domaine. Voir les vidéos OGC sur les expérimentations en cours (1, 2, 3, 4)​
  • Qualité pour le web : Il existe un modèle de mesures qualité pour le web QualityML compatible avec l’ISO 19157 et avec une implémentation en XML. Le W3C a développé une ontologie sur la qualité : Data Quality Vocabulary DQV.