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.
Le WG7 de l’ISO travaillent sur la norme.
Cette partie remplacera la norme ISO 19152:2012 et est en cours de publication.
La partie 5 de la norme concerne la représentation des différentes unités spatiales.
Le WG7 de l’ISO a travaillé sur la norme.
Cette partie a remplacé la norme ISO 19152:2012 et a été publiée en juillet 2025.
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.
Le groupe WG7 de l’ISO a travaillé sur la norme.
Cette partie a remplacé la norme ISO 19152:2012 et a été publié en juillet 2025.
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.
Le groupe WG7 de l’ISO travaillent sur la norme.
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. Elle devrait permettre de mettre en place un registre de mesures qualité à l’ISO, accessible par une machine et dont la maintenance sera facilitée.
Concernant le financement et la gouvernance du registre, l’OGC a été élu organisme d’enregistrement du registre (hébergement, publication et maintien du registre). Passée au stade de Community draft à l’OGC et ouverte aux commentaires techniques, l’enjeu est aujourd’hui d’avoir des retours sur le déploiement technique.
Les travaux du groupe ont débuté en 2021. Le projet a été relancé en mai 2023, suite au retard d’ISO 19135 (lié à l’impact potentiel de la révision de l’ISO 19135 sur le registre géodésique).
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/
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 :
La liste exhaustive des différences entre l’implémentation de CityJSON v1.0 et CityGML v2.0 est disponible sur cette page Web.
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.
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.
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.
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/.
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 (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
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.
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.
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.
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 :
À noter que la spécification ne couvre pas les zones polaires.
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.
L’extension de la spécification DOP aux zones polaires reste à faire.
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.
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
Les premières partie publiées en sont à leur première version.
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.
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.
La partie 1 de base est adoptée: OGC API – Records – Part 1: Core
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.