search

EURODEO / rodeo-edr-profile

This is a repository to make EDR profiles used in EURODEO visible for all use
https://rodeo-project.eu/rodeo-edr-profile
Creative Commons Attribution 4.0 International
1 stars 0 forks source link

readme

Build Status

RODEO EDR Profile

Purpose

The purpose of these EDR profiles is to constrain the OGC-API EDR standard such that clients can consume meteorological data from multiple EDR API services without having to write custom code for each of those APIs.

The profiles are meant to be used as described here: https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/issues/404.

Approach

Build an OpenAPI specification for each profile, along with human readable documentation and an automatic validation tool.

The OpenAPI specification can be used to validate that a service is compliant with the profile. It could potentially also be used to generate client and server code in multiple programming languages.

We plan to build a set of profiles roughly mirroring the data types handled by the RODEO project: That is, a separate profile for:

The work is 100% open source and the goal is to have a community driven effort that can be used by everyone.

Lastly, we want to make the job of implementing clients and servers compliant with the profile as simple as possible. Hence, we plan to build supporting validation tools and link to examples of clients and servers.

Links

Roadmap

A tentative plan for what to do when.

Starting august 2024: Observations data

Define the profile needs for meteorological ground observations data.

Work roughly in this order:

  1. Create a rough set of annotated examples of /collections and data query response, to document how responses from a compliant service will look.

  2. We want to tackle the metadata about parameters, units and coordinate systems, e.g decide on which vocabularies to use.

  3. How to map observations into collections? One collection pr. country, one pr. station? Or rather pr. parameter or pr. data type (core / recommended etc.)?

  4. work more directly on the OpenAPI specification, with things like:

    • the details of the content of /collections.
    • which queries to support
    • response formats for the data queries.

Lastly, there are some open questions about scope: Should the profile include constraints on how to publish metadata? E.g specific rules on using OGC-API Records to publish metadata about stations? Are there overlaps between the job of WIGOS and Oscar (WMDS, WMDR?) and this profile? Also, as a matter of practicality the profile needs to be built with some understanding of how WIS2 is implemented.

Late 2024: Forecast / radar / alerts / climate data?

Define the profile needs for meteorological weather forecast data. Reuse as much of the observations data profile as possible. Go back and refactor observations profile if that is required.

License

Shield: CC BY 4.0

This work is licensed under a Creative Commons Attribution 4.0 International License.

CC BY 4.0