Ce standard spécifie un profil du standard OGC API Processes, prenant en compte besoins Défense.
Une proposition de profil est en cours de rédaction.
La plupart du “core” soit le modèle générique de l’API Processes tel que définit par l’OGC peut être repris.
Des précisions devront être apportées sur certains éléments comme les SRC, les encodages, les langues, les restrictions…
Des travaux avaient été initiés dans un premier temps pour éditer un profil DGIWG du Service « Web Processes Service » (WPS) de l’OGC. Finalement l’intérêt se portant à présent sur l »OGC API Processes , il a finalement été décidé de se restreindre à un guide d’accompagnement pour l’implémentation de traitements spécifiques Défense.
Le guide technique est en cours de finalisation.
Il contient des recommandations et des références informatives.
On évitera de mentionner les références au WPS 2.0 dans les exemples xml pour ne pas contraindre certains clients basés sur du WPS 1.0. Les exemples sont juste donnés à titre d’exemple.
Ce rapport technique a pour objectif de fournir une mise en correspondance « officielle » entre ISO 19115-1 et GeoDCAT. De nombreuses mises en correspondances entre l’ISO et le vocabulaire DCAT existent localement mais elles différent entre elles et ne fournissent en général pas une mise en correspondance exhaustive.
Les travaux démarrent. Le premier élément à préciser est de déterminer exactement quel est le périmètre de la cible de départ et celle d’arrivée.
Le groupe de travail JSON de l’OGC sur les entités et les géométries a pour mission de développer un encodage JSON pour les données d’entités géospatiales. Cet encodage doit s’appuyer sur les normes fondamentales de l’OGC (telles que Simple Features), inclure d’autres encodages JSON géospatiaux (tels que GeoJSON) et prendre en charge la fourniture de contenu conformément à la suite de normes API de l’OGC.
Le FeatGeoJSON SWG travaille sur la norme OGC Features and Geometries JSON – Part 1: Core
Cette norme décrit un encodage GeoJSON et JSON-LD pour les métadonnées des jeux de données d’observation de la Terre. Elle peut être appliquée pour encoder des métadonnées basées sur l’Earth Observation Metadata Profile of Observations and Measurements (O&M) OGC 10-157r4 ou en tant qu’encodage du modèle conceptuel Unified Metadata Model for Granules (UMM-G).
Ce document donne les orientations et priorités du DGIWG en termes d’adaptation des standards API OGC en profils Défense.
Les normes suivantes sont prioritaires pour le profilage par le DGIWG, car elles représentent les normes approuvées les plus demandées au sein du DGIWG :
o OGC API – Environmental Data Retrieval (EDR)
o OGC API – Features
o OGC API – Processes
o OGC API – Tiles
Par ailleurs le DGIWG cherche activement à influencer le développement de l’API OGC – Records.
La première version 1.0 est publiée sur le portail du DGIWG pour consultation interne. La publication grand public est attendue.
La rédaction du profil de l’OGC API Features n’a pas commencé. Le panel Web Services et APIs peine à trouver un éditeur stable et investit.
Un exemple de déploiement d’une implémentation de l’OGC API Features sur des données Geopackage conformes DGIF 3.0 par la République Tchèque dans un contexte militaire avait été présenté par la Finlande.
Le client Merlin développé par les États-Unis a été testé et s’est connecté à cette instance de l’OGC API Features de la Finlande.
Ce standard spécifie un profil du standard OGC API EDR, prenant en compte besoins Défense. Des exigences définissent notamment comment remplir le document de capacité du service.
Un premier brouillon du profil défense, basé sur la version 1.2 de l’API EDR OGC (y compris la partie 2 sur les Pub/Sub) et la partie 1 de l’API Features pour la découvrabilité est en cours de relecture.
Se pose la question des « minimum metadata » exigées et de la duplication des métadonnées avec d’une part celles du service REST intrinsèque aux APIs OGC et d’autre part le profil DMF requis par le DGIWG.
Le panel suit attentivement les travaux réalisés par l’OGC pour d’éventuelles modifications notamment pour inclure la partie 3 en développement côté OGC.
L’API OGC-Connected Systems est destinée à servir de passerelle entre des données statistiques d’entités géographiques (ou autre) et des données dynamiques (observations, commandes…). Elle s’appuie sur le format GeoJSON ainsi que sur des modèles d’informations OGC existants comme SensorML, O&M, SWE, SOSA/SNN (capteurs)
La version 1.0 du standard est publiée. C’est une extension de l’API OGC Features qui a un mécanisme supplémentaire pour retrouver les données statiques et dynamiques.
Les premières publications :
OGC API – Connected Systems – Part 1: Feature Resources
OGC API – Connected Systems – Part 2: Dynamic Data
OGC SensorML Encoding Standard
OGC SWE Common Data Model Encoding Standard
La partie 3 “Pub/Sub” est en cours de développement par le sous-groupe SWG Pub/Sub qui s’est récemment reconstitué. Il sera basé sur le même modèle que la partie 3 des APIs EDR. Différents services de communication sont envisagés (MQTT, AMQP, DDS, Kafka…)
La partie 4 sur l’échantillonnage “sampling features” est complétée à 90%.
La partie 5 sur les encodages binaires « encoding format” est la moins avancée. Plusieurs sont évoqués (FlatGeobuf, FlatBuffers, Protobuf) ainsi que des formats vidéo pour certains modèles d’observation. Le SWG cherche des volontaires pour étudier cette partie.
Par ailleurs et à toute fin utile, l’OpenSensorHub est un bon exemple d’implémentation de l’API Connected Systems.
Ce projet de STANAG développé par le JGSWG a pour but d’améliorer l’interopérabilité pour l’échange de données d’élévation de plus haute résolution que celles couvertes par le STANAG 3809 – DTED.
Ce standard repose sur le standard DGIWG 250 – DGED.