Cette page présente les travaux liés à la questions des systèmes connectés au DGIWG regroupés sous le projet P5.07.
Les USA portent les besoins DGIWG auprès de l’OGC pour la rédaction de l’ OGC API Connected Systems et développent un client qui recense des capteurs et se base sur les API Connected Systems, SensorThings et Features.
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.
Le standard OGC GeoDCAT n’étant pas finalisé. la mise en correspondance a été d’abord faite avec le profil européen GeoDCAT-AP.
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.
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.
Ce projet de spécification technique a pour but de définir un modèle fondamental pour les schémas de tuilage de données de couverture s’appliquant à des espaces multi dimensionnels. Seuls les schémas de tuilages « hyper-rectangulaires » sont adressés.
Le projet a démarré mi-2024 et projette d’être publié début 2027.
La définition des tuilages pour la gestion des couvertures est certainement un sujet d’intérêt avec l’émergence des formats optimisés pour le cloud qui s’appuient sur des stratégies de découpage de l’espace pour optimiser l’accès à la donnée d’intérêt.
Dans ce contexte, ce projet de spécification technique pourrait avoir un intérêt à condition de bien s’articuler avec les spécifications déjà existantes sur le sujet.
La série ISO 19124 traite de l’étalonnage et de la validation des données de télédétection, qui sont collectées par un capteur à bord d’une plate-forme dans le cadre d’une mission, et des produits dérivés en partie ou en totalité des données. Elle définit les métadonnées relatives au processus d’étalonnage et de validation qui n’ont pas été définies dans d’autres normes internationales ISO/TC 211. Ces métadonnées permettent aux fournisseurs de données de fournir une description normalisée du processus d’étalonnage et de validation qu’ils ont appliqué aux données. Elles permettent aux utilisateurs de données d’obtenir les mêmes formes de métadonnées auprès de différents fournisseurs de données.
Le terme d’étalonnage fait référence au processus de correction des données, non seulement du point de vue géométrique, radiométrique et spectral, mais aussi du point de vue des caractéristiques pour les applications qualitatives et quantitatives.
Le terme « validation » désigne le processus d’évaluation de la qualité et de la précision des données calibrées et des produits dérivés.
Le terme « produits dérivés » désigne les produits qui ne sont pas directement mesurés par des capteurs, mais qui sont dérivés des mesures directes des capteurs par des algorithmes ou des modèles.
Ce projet de spécification technique a pour but de définir l’étalonnage et la validation des données d’observation de la Terre (EO) acquises par des capteurs Lidar et des produits dérivés des données Lidar. Les données Lidar spécifiées comprennent les modes forme d’onde et nuage de points. Il ne traite pas de l’étalonnage ni de la validation de l’étalonnage des capteurs Lidar, qui sont couverts par la norme ISO 19159-2.
Le projet a été lancé en octobre 2024 et prévoit une publication en octobre 2027.
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.