Thèmes

ISO 19152-2 Modèle du domaine de l’administration des terres (LADM) — Partie 2: Enregistrement foncier

Présentation

La partie 2 inclut les parties (personne et organisations), les unités administratives, les droits, les responsabilités et restrictions, les unités spatiales et la terminologie du cadastre.

Travaux en cours

Le WG7 de l’ISO travaille sur la norme.

ISO 19152-4 Modèle du domaine de l’administration territoriale (LADM) — Partie 4: Informations sur l’évaluation

Présentation

La partie 4 de la norme traite sur l’évaluation foncière. Elle comprend le prix des transactions, les statistiques des ventes et les unités d’évaluations.

Travaux en cours

Le groupe WG7 de l’ISO travaille sur la norme.

ISO 19152-3 Modèle du domaine de l’administration des terres (LADM) — Partie 3: Régulation géographique de l’espace maritime

Présentation

La partie 3 de la norme traite des structures d’information sur les espaces juridiques et leurs représentations dans l’espace marin. Cela inclut les limites, les espaces protégés, les ressources, ainsi que les droits et les obligations qui en découlent.

Travaux en cours

Le groupe WG7 de l’ISO travaille sur la norme.

ISO 19157-3

Présentation

Cette norme permet de spécifier comment établir, maintenir et publier un registre de mesures qualité conformément à l’ISO 19135-1. Cette norme comprend également la définition des moyens d’accès machine (API) à ce registre.

Les travaux comprennent aussi l’initialisation du registre avec un jeu de mesures prédéfinies.

Travaux en cours

Les travaux du groupe ont débuté en 2021.

 

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

À 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

Un échantillon DOP ARC Pleiades GMLJP2 avec une résolution de 50cm a été soumis par la France et validé en septembre / octobre 2021.

Un échantillon DOP UTM GeoTIFF provenant de prise de vue aérienne avec une résolution de 20cm a été soumis par la République Tchèque, et validé.

Le wiki DOP a été également soumis et validé en session DGIWG TP de octobre 2021, et avec délai de validation à fin novembre 2021.

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 version du draft est aaccessible ici : http://docs.ogc.org/DRAFTS/20-004.html. 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.

Data Preservation DWG

Présentation

Ce groupe de travail est dédié à l’archivage des données de manière à pouvoir les exploiter dans le futur.

Travaux en cours

Une première réunion s’est tenue en virtuel lors du TC OGC de septembre 2020. La base de réflexion présentée est le projet européen d’archivage eArchiving . A terme, il s’agira de disposer d’une plate-forme européenne d’archives permettant l’exploitation future de leur contenu.
Il est basé sur le format e-ark, composé de packages thématiques dont un pour l’information géospatiale qui est en cours de revue et qui devrait être proposé comme community standard à l’OGC.