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 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.
La spécification projet de l’OGC API – Coverages définit une API Web pour accéder aux couvertures. Une couverture est une « fonction qui retourne des valeurs de son étendue pour toute position directe dans son domaine » (ISO 19123-1:2023).
Il s’agit de la première version de ce standard
La partie 1 “core” est toujours en cours de rédaction OGC API Coverages Part 1 Draft
Des parties à venir sur les filtres, l’agrégation de champs et les “scenes” (multi-couches) devraient ensuite être rédigées. Des questions se posent quant au fait de se rapprocher de l’API GeoDataCubes.
Il y a aussi eu des discussions sur la représentation du “no data” dans le format geoTIFF qui n’est pas adapté au standard en cours de rédaction mais il a été décidé de s’approcher de l’équipe en charge de ce format pour voir comment l’adapter.
Le standard OGC API – Maps décrit une API capable de fournir des cartes électroniques référencées spatialement, qu’elles soient statiques ou rendues dynamiquement, de manière indépendante de l’entrepôt de données sous-jacent.
Il s’agit de la première version 1.0.0 de ce standard qui vient d’être publiée
Le projet de norme OGC API – Discrete Global Grid Systems spécifie une API permettant d’accéder aux données organisées selon un Discrete Global Grid System (DGGS). L’idée étant de retrouver des données sur une zone/des cellules non rectangulaires comme c’est le cas pour Tiles.
Il s’agit de la première version de ce standard
Élaboration de la partie 1 : OGC API – Discrete Global Grid Systems – Part 1: Core
L’API OGC – Jointures standard spécifie les exigences pour une API Web qui prend en charge les opérations de jointure pour les fichiers de données tabulaires d’entrée qui peuvent être joints à des collections d’entités disponibles sur un serveur ou directement à l’aide d’autres fichiers d’entrée.
OGC API Common
Il s’agit de la première version de ce standard
L’appel à commentaires sur l’API Joins n’a finalement pas encore été lancé mais devrait l’être bientôt. Il est espéré de soumettre une version du standard d’ici fin 2025. Les premières fonctionnalités sont un retour de métadonnées pour les collections disponibles, la possibilité de faire une jointure sur un attribut d’une donnée chargée (ex : csv) avec un élément géospatial de la collection ou entre deux fichiers chargés, la possibilité de lister, retrouver ou supprimer des jointures.
Le brouillon est disponible ici OGC API Joins Part 1 Draft