Archives de l’auteur : Gilles CEBELIEU

ISO/TS 19124-1 – Calibration and validation of remote sensing data and derived products – Part 1: Fundamentals

Présentation

La série ISO 19124 traite de l’étalonnage et de la validation des données de télédétection, qui sont collectées par un capteur à bord d’une plate-forme dans le cadre d’une mission, et des produits dérivés en partie ou en totalité des données. Elle définit les métadonnées relatives au processus d’étalonnage et de validation qui n’ont pas été définies dans d’autres normes internationales ISO/TC 211. Les métadonnées permettent aux fournisseurs de données de fournir une description normalisée du processus d’étalonnage et de validation qu’ils ont appliqué aux données. Elles permettent aux utilisateurs de données d’obtenir les mêmes formes de métadonnées auprès de différents fournisseurs de données.

Cette première partie de la série traite du cadre général et des processus communs d’étalonnage et de validation relatifs aux données d’observation de la Terre et aux produits dérivés provenant de différents types de capteurs à distance. Les parties suivantes de la série ISO 19124 porteront sur des données provenant de capteurs spécifiques, par exemple, infrarouge, ultraviolet/visible/ proche infrarouge, micro-ondes ou large bande, sur des produits dérivés de ces données et sur des sites d’étalonnage et de validation.

L’étalonnage consiste en une correction géométrique, radiométrique ou spectrale des données. La validation est une évaluation de la qualité et de la précision des données et des produits dérivés.

 

ISO TS 19159-4 – Calibration et validation – Partie 4 – Radiomètres spatiaux à micro-onde passive

Présentation

Cette Spécification Technique, partie 4 de la spécification pour la Calibration et Validation de capteurs d’imagerie (ISO 19159), a pour objectif de définir les paramètres de calibration et de validation de capteurs de type radiomètres spatiaux à micro-onde passive.  La calibration se réfère à la géométrie et la radiométrie, et comprend l’étalonnage de l’instrument dans un laboratoire ainsi que des méthodes de calibration in situ. Les méthodes de validation portent sur la validation des informations de calibration.

Cette spécification n’a pas de relation avec la partie 1 dédiée aux capteurs optiques. Toutefois, le nommage (Namespace) du package est CA (pour Calibration) pour toutes les parties de cette série de normes.

Point Cloud DWG

Présentation

Le « Point Cloud DWG » est un groupe de discussion de l’OGC qui s’intéresse aux aspects de normalisation autour des données de type nuages de points. Il est motivé par la popularité et l’utilisation croissantes des technologies liées à ce type de données. Celles-ci comprennent un certain nombre de formats et de types tels que : les balayages laser de plates-formes aériennes et terrestres (par exemple, LIDAR), les points d’élévation triangulés, et les observations denses de la communauté météorologique, et autres.

Travaux en cours

Les axes de discussions et les objectifs de ce groupe de travail sont les suivants :

  1. Discuter de la variété des formats d’encodage des nuages de points afin de mieux comprendre les exigences d’encodage et de partage des ensembles de données de nuages de points.
  2. Servir de point de contact privilégié du Comité Technique de l’OGC pour les organisations complémentaires qui travaillent sur les meilleures pratiques et normes en matière de nuages de points, comme l’ASPRS
  3. Évaluer la possibilité d’utiliser une interface de service pour abstraire les types de formats de nuages de points. Cela implique l’évaluation des services OGC existants aussi bien que la création éventuelle d’une nouvelle norme de service.
  4. Faire des recommandations pour l’adoption des meilleures pratiques et des normes à utiliser par la communauté des nuages de points. Incluant notamment l’évaluation des formats de nuages de points LAS et LAS optimisé/compressé.
  5. D’autres discussions relatives aux données de nuages de points peuvent également avoir lieu au sein de ce groupe. Notamment :
    • les problématiques de compression ;
    • les bases de données, le support par GeoPackage ;
    • l’Indexation, le tuilage, et la décomposition hiérarchique ;
    • les services web, la diffusion en flux ;
    • les modèles de métadonnées.

 

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.

Travaux en cours

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

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.

LandInfra (OGC)

Présentation

Le modèle conceptuel LandInfra résulte d’un projet conjoint entre bSI (Building Smart) et l’OGC avec les objectifs suivants :

  • remplacement de LandXML
  • aménagement du terrain et conception des installations
  • modèle de l’environnement sur lequel les installations existent (Subsurface, Terrain, LandDivision, Survey)
  • focus sur les sites (comme les IFC – ISO 16739 – Classes IFC pour le partage des données dans le secteur de la construction et de la gestion de patrimoine)
  • basé sur un modèle conceptuel (UML), dans l’écosystème OGC.

LandInfra est destiné (dans sa conception) à servir de modèle conceptuel commun pour InfraGML et les IFC pour les Infrastructures (Alignement, Rail,Route,…). Ses paquetages comprennent :

  • Le noyau (Core)
  • Alignement : concept clé pour les infras : ponts, tunnels, voies routières / ferroviaires (points kilométriques)
  • LandFeature: LandElement et LandSurface (TIN)
  • LandDivision
  • Facility (le thème générique pour les infrastructures)
  • Chemin de fer (Rail)
  • Route (Road)
  • Condominium (gestion de copropriété).

A noter qu’au contraire de CityGML, LandInfra ne possède pas de concept de niveau de détail.

Notes de version

La version actuelle est 1.0.

Avis technique

LandInfra Alignment a servi pour le développement de IFC Alignment (IFC 4). Malheurseuement pour les autres packages, il n’y a pas d’utilisation de LandInfra pour les travaux IFC Road et Rail en cours.

Par ailleurs LandInfra souffre d’un manque de support par des outils / logiciels.