Skip to content

Latest commit

 

History

History
79 lines (45 loc) · 5.21 KB

7-challenges.adoc

File metadata and controls

79 lines (45 loc) · 5.21 KB
Raw

API Interoperability

SOFP WFS3 Weather Server

To gain maximal interoperability, the defined API should be as general as possible. The general parts empower existing libraries and software to communicate with the API. Excessively general design, however, present unnecessary confusion since the API is not intuitive and/or it works inconsistently.

SOFP WFS3 Weather Server were build to fully meet OGC API - Features Core to gain maximal client support and easy access to the data to developers outside the geospatial community. Following challenges and shortcomings in the current standard were identified.

Simple Observation Time Series

To request all temperature and humidity observations from a time range inside the given area, the following request could be used:

GET /datasets/weather/observation/aws/items?
  parametername=Temperature,Humidity
  &time=20181204T150000/20181204T180000
  &bbox=20,60,30,70

The request is OGC API - Features Core compatible except the time definition, which would need an extension. Time range support is widely adopted in a broad range of applications and would be reasonable to define in OGC API - Features standard. However, other time definitions used in many environmental domains such as origin time and lead time are not commonly recognised and would require a domain-specific specification.

Resampled Weather Forecast Model Output

To request a weather model output inside some area, following request could be used:

GET /datasets/weather/forecast/harmonie/items?
  parametername=Temperature,Humidity
  &time=20181204T150000/20181204T180000
  &bbox=20,60,30,70
  &limit=100

The request returns a collection of features containing a resampled regular grid with 100 points (10x10) inside the given bounding box. All features are resampled and generated on-demand based on the request. Smaller bounding box would return more detailed information and a larger one less detailed. The pattern is fully compatible with OGC API - Features Core but may be unintuitive to the users used to handle pre-existing features.

Single Point Weather Forecast Model Output

SOFP WFS3 Weather Server allows users to request any single point as well. In those cases, it interpolates the response on-demand to the exact requested location in space and time. The functionality is achieved with a (mis)usage of standard filtering defined in OGC API - Features Core:

GET /datasets/weather/forecast/harmonie/items?
  parametername=Temperature,Humidity
  &time=20181204T150000/20181204T180000
  &bbox=20,60,30,70
  &lat=60.159900&lon=24.876116

The pattern is fully Core-compatible but clients are allowed to request any latitude and longitude inside the data area. The upside of such behaviour is wide client support and the downside is possible obscurity. The functionality can, of course, be described to the developers in OpenAPI definition and API can be extended with query parameters such as interpolation_method, but the main concern of the balance between interpretability and clarity remains.

Data Format

OGC Observations and Measurements - Simple Feature model & encodings (OMSF)

TBD

Other Notes

Feature IDs

OGC API - Features standard assumes that all features have a unique identifier, which may be problematic if responses are generated on-demand (for example in SOFP WFS3 Weather Server). In case of weather forecasts, IDs can be formed in a unique manner on-demand following:

parameter:producer:level_type:level:forecast_type:ensemble_number:origin_time:area:time:area_interpolation_method:time_interpolation_method:level_interpolation_method

This convention makes the feature ID to a query language itself, which may be beneficial for power users.

Forming Collections

OGC API - Features leaves relatively lot degree of freedom to form collections in different ways. To serve a wide range of domains, this is naturally necessary. In a more specific domain, such as serving weather data, different conventions may be confusing to the end-users. It would be advisable to harmonise at least the following aspects:

  • One collection per weather model or one collection per parameter?

  • One entry point per organisation or on entry point per dataset (i.e. weather model) or one entry point per data type (i.e. observations/forecast/climatology)?

Meteorological Service of Canada GeoMet OGC API

The OGC API - Features Core specification provides a valuable developer experience and lowers the barrier to interacting with geosaptial data. Below are some considerations for further research and collaboration.

Hierarchy

The current MSC OGC API offering provides a flat list of collections. Community input and consensus will provide value into better organizing and categorizing collection trees which will help with user navigation of the API.

Complex Filtering

By design, the OGC API - Features Core specification provides query capability via spatial, aspatial and temporal predicates. More complex query capabilities (spatial operators [clip by polygon, etc.], comparisons [greater than, less than, etc.], as well as logical operators [And/Or/Not, etc.]) are required for more complex use cases. This is best implemented as an extension that a given server can implement/conform to.