scieee AI-readable full text Open interactive document viewer

Standards OGC

Barde, Julien

Abstract

Historique des standards, pourquoi les utiliser : interopérabilité technique et syntaxique, mais aussi sémantique (via des standards métier comme WaterML)Nouveau type de norme : OGC API. Usage transparent si on utilise des services standards tels que ceux disponibles dans GeoServer, mais à implémenter si on développe côté client.

Full text

Standards OGC …depuis 1994 Julien Barde 2025-09-09, La Rochelle https://tinyurl.com/SIST2025 Contexte en 2002 : “back in the days…” ● Normes nationales : FGDC, CEN/TC 287, ANZLIC …. ● Cartes en Europe ? géologie, hydrographie, transports …. => INSPIRE ! ●Standards OGC (Open Geospatial Consortium) ○normes ISO TC 211 = spécifications abstraites / diagrammes UML : DTD puis schémas XML (XSD) avec des librairies pour les implémenter (Java, Python..) ○ Web services : SOAP + XML + HTTP pour gérer les échanges clients & serveurs ○ Interopérabilité +/- simple en pratique avec les premières normes (Formats & protocoles) : ■métadonnées / Records : 19115 & CSW (après Z3950) en 2003 ■cartes / Maps : OGC Web Map Service 1.0 en 2000 ■ données vecteur / Feature : GML & WFS (lent : implémentation de GML complexe) ■ données raster / Coverage : GeoTIFF & WCS ■ données capteurs / Sensor : SWE, SensorML, SOS, TransducerML…2006 Quelques points clés ● Web Services ou API ≠> interopérabilité ● Interopérabilité, en informatique => normes (au moins des standards) ○ Standards OGC : Interopérabilité syntaxique et sémantique des données spatiales ○ Tim Berners Lee (CERN) en 1989 : Web pour les humains et les machines (machine to machine) ■ W3C => Web sémantique, gestion de connaissance et vocabulaires contrôlés : ontologies, thésaurus, glossaires. AI => mort du Web de Tim Berners Lee ? ● La directive INSPIRE en 2007 : “when there is a will there is a way” ○ faciliter l'échange de données spatiales au sein de l’UE => Interopérabilité des IDGs / SIG ○ directive EU ≠ norme mais est transposée dans une loi nationale ■ implémentation obligatoire des formats et protocoles de l’OGC (OWS) : catalogues de métadonnées, accès.. ■ 34 domaines thématiques ■ directive EU => amendes , coût estimé à 115 millions d’euros par an pendant 10 ans ● Web Services (SOAP + XML) vs API (REST / Json ou différents formats) Standards OGC et principes FAIR Deux types de normes pour appliquer les principes FAIR aux données géospatiales : ●“formats & transfert de données” : échange de données entre les systèmes ○Findable : 19115/39 et service de catalogue pour le Web (CSW) ○Accessible : ■ Formats : SFS, GML, GeoPackage, COG (GeoTIFF), GeoParquet, KML, 3D Tiles, .. ■ protocoles : WMS, WFS, WCS (ex : géoportail), WPS… ○Reusable : formats + Feature Catalog (ISO 19110) ●“interopérabilité sémantique” : compréhension partagée du sens des données => Reusable ○WaterML ○CityGML ○PipelineML .. ○OGC RAINBOW (ex OGC Definitions Server) => definitions published with SKOS Web Services OGC : retour d’expérience "Le roi est mort, vive le roi" : besoin de moderniser ● INSPIRE est trop complexe pour les fournisseurs et les utilisateurs : ○ approche Top down ○ les profils devraient être abandonnés… ● normes des services Web de l'OGC parfaitement fonctionnelles mais .. ○ 18 années écoulées depuis 2007… ○ ne suivent pas complètement les pratiques modernes sur le Web : ■ nouvelles approches de co-création de standards qui impliquent les utilisateurs (AGILE standards) ■ difficiles d’accès pour des développeurs qui ne connaissent pas le domaine, ■ passer à une architecture orientée ressources : les standards actuels se concentrent sur les ressources, plus sur les opérations (JRC report) OGC APIs = nouveau type de normes Depuis 2017, évolution naturelle de OGC WS vers des API Web ouvertes ● Définition des ressources et utilisation de méthodes HTTP pour les récupérer (html/json) : ○OGC API – Common : base partagée par toutes les autres API OGC (~ OWS-Common pour les services OGC W*S): ■landing page = URL + “/conformance” | “/collections” | “/collection/collectionId/items/featureId”.. ■filters : bbox, datetime, full text search… ○ chaque API OGC possède des fonctionnalités différentes avec un core minimaliste + extensions / blocks ajoutés “step by step” ■ CSW -> OGC API – Records ■ WFS -> OGC API – Features (WFS3).. Maps, SensorThings, Processes… ● spécification OpenAPI pour définir les blocs de construction d'API ○ décrire / documenter / développer / tester les APIs conformes à l’architecture REST (lien GitHub) ○ norme auto-décrite, indépendante du langage pour documenter les API HTTP ○ UI interactive pour les tests (ex : swagger, BGS..) ● Open development : Repositories GitHub OGC APIs = nouveau type de normes C’est en train de beaucoup bouger mais surtout ne faites rien si vous n’êtes pas développeurs ! Laissez les autres travaillez pour vous… Pour conclure IDGs Software Quelques références ● A creuser avec les stands SIST : ○ Data Terra / ODATIS et autres IDGs (InDoRES, Geodata Inrae…) ○ geoflow.. ● OGC : ○Le rôle de l'OGC dans la promotion des normes de données géospatiales FAIR ■Engineering report ○Moderniser INSPIRE ○GitHub repositories ● IGN / EDEN ●JRC report : bilan INSPIRE ● Vidéos : ○[Live+] SIG 2022 - Travailler avec les nouveaux standards OGC dans ArcGIS ○From OGC Web Services to OGC APIs | #EsriDevSummit2024 ○Short Introduction to OGC APIs ○ Introduction to OGC API - Records Specification ○FOSS4G 2022 | OGC API Standards: Past, Present, and Towards an Exciting Future ○FOSS4GE 2024 | Demystifing OGC APIs with GeoServer: introduction and status of implementation