Standards

CityJSON

Présentation

CityJSON v1.0 implémente l’essentiel du modèle de données CityGML v2.0.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.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.0 est disponible sur cette page Web.

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

Standards de base

Ce standard 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é 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 (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).

Notes de version

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

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

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.

Travaux en cours

Développement et publication d’échantillons.

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.

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.

Travaux en cours

Une nouvelle version du draft est attendue pour la fin de l’année. 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.

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

EDR (Environmental Data Retrieval) est un standard en développement pour la communauté Météo. Le but est d’avoir l’équivalent d’un WFS pour les données tabulaires.

Standards de base

Ce standard est un profil de :

  • OGC API Common

Exemples de mise en œuvre

Un test de l’API est accessible ici.

Travaux en cours

Le groupe OGC API EDR SWG a soumi un projet de standard à vote.

Avis technique<

En l’état, ce standard semble redondant avec l’API feature qui est capable de récupérer des données de type coverage, et la notion de données environnementale (ED de EDR) n’est pas explicitée.

Ne pas oublier de renseigner l’extrait plus bas !

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.

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

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

Développement et publication d’échantillons. Un échantillon DRP ARC 50K GMLJP2 a été soumis par la France et validé en mai 2021. D’autres échantillons (par ex. UTM voire avec un autre encodage) ont été demandés aux autres nations.

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