Weather on the Web (WotW)

Weather on the Web (WotW)

Mark Burgoyne and Peter Trevelyan

UK Met Office (UKMO)

FitzRoy Road, Exeter

Background:- This presentation outlines a proposal for changing the approach to providing access to Meteorological data. It is a response to the rapidly growing data volumes and the changes in the IT landscape which has increased the number and type of user who are interested in access to the information. It is important to recognise that for the majority of users outside of the Meteorological community, weather (whilst important) is only one of the pieces of information that their decision making process is based on. The cost (in both time and effort) may deter many organisations from using the data even though it would bring a real benefit. In short they simply want the best information required to make their decision in a timely manner.

API design principles:-

Currently the solution to making data available generally falls into two camps:

1) Build a system to provide access to a specific dataset:

• Pro: Rich query functionality
• Con: Query/API structure design tied to dataset

2) Platform is built which ingests the data and transforms the data from multiple sources into a canonical format.

• Pro: Common access patterns for multiple data types
• Con: Complex code base which gets increasingly difficult to change

To be truly useful the user needs to have an API that abstracts away any knowledge of the back end technology, but allows the user to access data using a query pattern suited to the problem being solved. This approach to API functionality makes it easier to provide standardised access to information without the need to build monolithic data platforms. This de-coupling makes it much easier to integrate new data types since any new compliant system would have support for the query patterns and output formats.

The query patterns are based on the NetCDF feature types, e.g. points, grids, profiles etc. and an important architectural principle is that the data supports some or all of these extraction patterns. If this is the case then the API will not need to be changed to access any new data type including observation.

Roadmap to standardization:-

To ensure uptake of this work it is essential that it is based on existing geo-spatial standards. To this end the design has been submitted as a draft OGC standard and after a comment period will be go for a final vote in the spring of 2020. The re-design of many of the OGC APIs to move away from an XML base to those using the OpenAPI specification 3.0 affords us real opportunity to create a MetOcean specific API (WotW) from the “ground up”. To help with this endeavour a number of industry partners have contributed to an engineering report ensuring that the interests of non-weather specialists are understood and have influenced the design. See https://github.com/opengeospatial/weather-on-the-web

In order to make Weather on the Web easier to implement, it will be based on a 'family' of API’s which follow a common pattern (based on the OGC core API guidelines and strongly influenced by WFS 3.0). The concept is that each API in the family should be based on a different query type, but follow common conventions for query parameter structures and output formats. The API’s discovery and query operations are implemented using the HTTP GET or POST methods. Discovery operations allow the server to be interrogated to determine what information is available, this includes the API definition of the server as well as metadata about the data collections provided by the server.

Query operations allow values to be retrieved from the underlying data store based upon selection criteria, defined by the clients.

Presentation:-

This presentation will present the draft design, an introduction to the API and a live demonstration of the API. Feedback will be vital in improving the utility of the API and it is hoped that this presentation will initiate a real cross community discussion.