Standard OGC

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.

SensorThings (OGC)

Présentation

L’API SensorThings offre un standard ouvert, géospatial et unifié pour interconnecter les appareils, les données et les applications de l’Internet des objets (IoT) sur le Web, basé sur le protocole MQTT.

L’API SensorThings est basée sur le modèle Observation de O&M et est inspirée par les standards OGC SWE : SensorML, SOS et SPS, dont elle fournit une interface géospatiale de profils « légers », adaptée à ces micro-capteurs. Elle est conforme aux principes REST, utilise les protocoles MQTT et OASIS OData et un encodage JSON.

SensorThings fournit deux fonctionnalités principales :

  • la partie détection (partie 1)
  • la partie programmation (tasking, partie 2).

La partie Détection fournit un moyen standard de gérer et de récupérer des observations et des métadonnées à partir de systèmes de capteurs IoT hétérogènes. Les principales entités de la spécification sont : thing, location, observation, sensor, feature-of-interest, observed-property.

L’API SensorThings adopte le style de service Web REST avec les fonctionnalités CRUD (Create, Read, Update, Delete).

Notes de version

La version 1.0 de SensorThings partie 1 a été publiée en août 2016.

La version 1.0 de SensorThings partie 2 a été publiée en janvier 2019.

Une version 1.1 de SensorThings partie 1 a été publiée en novembre 2020. L’évolution majeure est que désormais toutes les entités (sauf HistoricalLocation) ont désormais un champ de type JSON Object, nommé « properties » ou « parameters », pour les métadonnées associées à ces entités.

Travaux en cours

Le groupe SensorThings SWG finalise la révision 1.1 du standard SensorThings pour la partie 2 (Tasking).

Mise en oeuvre

A noter les 2 implémentations clientes suivantes :

  • FROST-Client : bibliothèque cliente Java pour communiquer avec un serveur SensorThings.
  • Geodan SensorThings .NET SDK : facilite l’ajout du support OGC SensorThings à une application .NET.

Plus d’information sur le github OGC sensorThings https://github.com/opengeospatial/sensorthings

On notera également la plateforme SensorThings SensorUp de SensorUp.com (startup issue de l’Université de Calgary) – cf. https://sensorup.com/platform/ – et la ressource de développement SensorThings API SDK – cf. https://developers.sensorup.com/InteractiveSDK/.

O&M 2.0 (OGC)

Présentation

Le standards OGC Abstract Topic 20 « Observations et mesures (O&M) », développé conjointement à l’OGC et à l’ISO/TC 211, vise à fournir un modèle standard pour représenter et échanger les résultats d’observations. Ce standard a été publiée en septembre 2013 à l’OGC.

Cf. également la page ISO 19156

Le document OGC AS Topic 20 0&M est disponible ici.

Mise en œuvre

Le standard OMXML, développé par l’OGC, est le schéma XML de mise en œuvre du modèle O&M, disponible sous schéma OGC OMXML.

Notes de version

La version actuelle est O&M 2.0. Pour OMXML, la version est également 2.0.

Travaux en cours

Un projet conjoint ISO 19156-1 et OGC de révision de cette norme a démarré mi 2019.

 

3D Tiles (OGC)

Présentation

3D Tiles est un standard OGC 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, le BIM (Building Information Model), et autres objets vecteur et les nuages de points.

3D Tiles définit une structure de données hiérarchique et un ensemble de formats de tuiles fournissant un contenu destiné à être rendu / représenté.

3D Tiles ne définit pas de règles explicites pour la visualisation du contenu ; un client peut visualiser les données 3D Tiles comme bon lui semble.

Un ensemble de données de tuiles 3D, appelé tileSet, contient toute combinaison de formats de tuiles organisés en une structure de données spatiales.

Exemples de mise en œuvre

3D Tiles est notamment utilisé par des globes virtuels tels que CESIUM (développé par le consortium du même nom).

Cesium maintient un dépot github pour le développement de la spécification 3D Tiles dont une des pages référence un ensemble de ressources autour de ce format (documentations, outils, données exemples, …).

Notes de version

La dernière version de 3D Tiles (1.1) appelée précédemment « 3D Tiles Next » a été adoptée comme standard communautaire par l’OGC en décembre 2022. Par rapport à la version précédente, elle intègre des métadonnées sémantiques plus robustes et efficaces, la prise en charge de tuilages implicites utilisés notamment dans les structures de type quadtree ou octree ainsi qu’une intégration complète du format glTF développé par le Khronos Group pour tous les types de tuiles de données.

Avis technique

3D Tiles est utilisé par la plateforme iTowns de l’IGN.

3D Tiles est une spécification en concurrence avec I3S (Indexed 3D Scene Layers) également standard OGC soumis par ESRI. Même si les deux spécifications sont ouvertes, 3D Tiles est plus facilement implémentée par des solutions logicielles libres que sa concurente.

OGC netCDF

Présentation

Le standard CF-netCDF de l’OGC consiste en une série de documents qui supportent le codage de l’information géospatiale numérique représentant des phénomènes variant dans l’espace et le temps.
Bien que développé à l’origine pour la communauté des sciences de la Terre, netCDF peut être utilisé pour communiquer et stocker une grande variété de données multidimensionnelles. Le modèle de données et les codages netCDF sont particulièrement utilisés par les scientifiques de l’atmosphère et de l’océan, travaillant avec des ensembles de tableaux connexes.
Note : les encodages possibles sont :

  • OGC GML Coverage 2.0 (OGC 14-100r2)
  • NetCDF Classic et 64-bit Offset Format (OGC 10-092r3)
  • Moving Features (document en cours)
  • HDF5 (projet en cours)

Standards de base

Ce standard est un profil de :

  • OGC GML Coverage 2.0 (OGC 14-100r2)
  • UCAR NetCDF 3.0
  • CF 1.6

Travaux en cours

Il est prévu une adaptation de la version 4.0 de NetCDF (encodage HDF5) .

Avis technique

Ce standard est intéressant pour l’échange d’informations géographiques au format NetCDF 3.0 et bientôt aussi pour le format HDF5 (NetCDF 4.0).

Geospatial User Feedback (GUF)

Présentation

Ce standard définit un modèle conceptuel de données sur les retours utilisateurs dans le domaine géospatial (GUF).
Les retours utilisateurs sur les données géospatiales sont des métadonnées qui sont principalement produites par les consommateurs de produits de données géospatiales au fur et à mesure qu’ils utilisent ces produits et acquièrent de l’expérience avec ceux-ci.

Cette norme complète les conventions de métadonnées existantes selon lesquelles les documents enregistrant les caractéristiques des ensembles de données et les flux de production sont générés par le créateur, l’éditeur ou le conservateur d’un produit de données. Dans le cadre des métadonnées, le modèle de données GUF réutilise certains éléments de la norme ISO 19115-1:2014, mais pas la structure générale. Cette utilisation sélective des éléments de métadonnées ISO donne la priorité à l’interopérabilité future avec les modèles de métadonnées ISO en développement. Cette norme est conçue pour être utilisée en combinaison avec une norme d’encodage.
Initialement, un codage XML suivant les règles d’encodage ISO 19139 est spécifié dans une norme d’implémentation OGC séparée (OGC 15-098). A l’avenir, d’autres encodages pourront être définis, y compris des exemples tels que l’utilisation de JSON-LD basé sur des parties de schema.org.

Standards de base

Ce standard est un profil de :

Exemples de mise en œuvre

https://nextgeoss.eu/2019/03/31/user-feedback/
Geonetwork

Travaux en cours

Néant.

OGC ebRIM Profile of CSW

Présentation

Ce document décrit un profil basé sur l’option de mise en œuvre HTTP du service de catalogue Catalogue Service de l’OGC et le modèle d’information ebRIM (ebXML Registry Information Model) du consortium OASIS.

Ce modèle d’information est générique et peut donc être spécialisé pour les différents types de ressources à cataloguer. Cette spécialisation est documentée dans un « paquetage d’extension », qui contient les extensions au modèle de base. Un paquetage d’extension dit basique a été spécifié par l’OGC. Il contient des éléments de base pour le catalogage d’objets géographiques.

Si la généricité d’ebRIM permet son application à divers types de ressources, ce modèle est également critiqué pour sa complexité.

Standards de base

Ce standard est un profil d’application de  OGC Catalog Service for the web (CSW, version 2.0.2)

Avis technique

Ce standard visait des cas d’utilisation très spécifiques par la mise en oeuvre de modèles de métadonnées communautaires et permettant des fonctionnalités avancées au niveau du service de catalogage. Sa mise en oeuvre n’est pas recommandée.