Présentation
L’API EDR (“Environmental Data Retrieval”) est un standard OGC qui définit une interface simple et unifiée permettant d’accéder via le web à des données spatiotemporelles d’origines multiples (météorologiques, océanographiques, géographiques raster mais aussi vecteur) selon une position, une zone, ou le long et autour d’une trajectoire donnée.
Elle est issue de l’expérience du développement du profil applicatif « Met Ocean » de WCS avec des cas d’usages similaires et en s’appuyant sur des bases technologiques différentes.
Elle s’inscrit dans la refonte engagée par l’OGC de ses standards vers la famille des « OGC API » en adoptant une approche modulaire, centrée sur les ressources et s’appuyant sur la spécification OpenAPI.
Standards de base
Elle s’appuie sur les concepts de base communs à la famille OGC API, définis par les deux spécifications :
- OGC API Common : Core
- OGC API Common : Geospatial Data.
Elle s’appuie aussi fortement sur spécification CoverageJSON (candidat pour être adopté comme community standard OGC) comme format de description des données de réponse aux requêtes qu’elle spécifie.
Exemples de mise en œuvre
Le développement de cette API est poussé par le service national britannique de météorologie (Met Office) et le US National Weather Service. Ce dernier propose un serveur de démonstration référencé sur le dépôt Github de l’API.
De même l’université de Wuhan en Chine implémente cette API et propose un serveur de démonstration aussi référencé sur ce dépôt Github.
Notes de version
La dernière version de la partie 1.1 a été publiée en juillet 2023 OGC API – Environmental Data Retrieval Standard.
La partie 2 de l’API qui implémente le workflow PubSub (abonnement et réception de notifications, de nouvelles données) a été publiée en septembre 2024 OGC API – Environmental Data Retrieval – Part 2: Publish-Subscribe Workflow.
Travaux en cours
Une version 1.2 de la partie 1 (Core) de l’API devrait être bientôt soumise à l’architecture board de OGC. Elle implémente OpenAPI 3.1, ne supporte plus que le protocole HTTPS et permet de paginer les résultats si besoin.
La chaîne de traitement PubSub (abonnement et réception de notifications, de nouvelles données) a été adoptée et publiée dans la partie 2 du standard API EDR qui sert d’expérimentation. On reçoit des notifications sur les collections cartographiques quand on y souscrit et le retour est en GeoJSON. Elle peut fonctionner de manière asynchrone. D’autres APIs pourraient bénéficier de cette chaîne de traitement : Records, Features, Processes, Maps, Connected Systems.
La partie 3 “restrictive services profiles” est en cours de rédaction en prenant notamment en compte les demandes du DGIWG sur la restriction des accès et la rédaction de la partie 4 “aggregations and statistics” n’a pas encore débuté. Des inquiétudes ont été soulevées quant au fait que les travaux sur EDR sont relativement avancés et qu’il pourrait donc y avoir des divergences avec d’autres APIs, voire avec l’API Common.
Avis technique
L’API EDR a vocation à reprendre les spécialisations de WCS pour traiter les cas d’usages des domaines météorologique et océanographique en reprenant notamment les fonctionnalités du profil MetOcean de WCS. Elle propose en plus une approche simplifiée de l’accès aux données et elle étend aussi les capacités de WCS en permettant de s’appliquer aussi a des données de type vecteur et en intégrant un accès aux données par localisant autre que géographique.
En termes de fonctionnalités elle occupe de ce fait une place transversale vis à vis des nouvelles API OGC qui ont vocation à reprendre les anciennes spécifications : OGC API Coverages ou OGC API Features dans la mesure où elle peut répondre à certains cas d’usages identiques.
L’objectif à long terme de cette API est bien de proposer une combinaison d’APIs, étant elle-même peur restrictive.
En s’appuyant sur le format CoverageJSON, elle semble cibler plutôt des usages de consultation dans des applications web.
