In December 2018, the MetOean DWG conducted a two day API workshop/hackathon event in Northern Virginia. The goal of the workshop was to introduce the weather on the web data API work as a REST-based query pattern making use of the OpenAPI specification and discuss how the API tries to simplify the need to understand the OGC WCS standard or the need to know about Meteorological or Oceanographic terms. That the API was simply a quick means to an end goal, the product. Discussion topics included the URL request/response patterns, the query patterns, and user experiences making use of the demo APO. The full agenda for the workshop/hackathon can be found [[https://github.com/opengeospatial/Weather-on-the-Web-ER/blob/master/annex-agenda.adoc]]. Participants of the workshop included OGC staff, a number of Met Center Agencies, academia, and corporations. A complete listing of the participants can be found [[https://github.com/opengeospatial/Weather-on-the-Web-ER/blob/master/annex-attendees.adoc]].
Here are a couple of snapshots of the whiteboards during the event:
-
Created a GitHub collaborative workspace environment for MetOcean API: https://github.com/OGCMetOceanDWG/MetOceanAPI-Workshop
-
Demonstration of initial WotW capability, focused on gridded data
-
OpenAPI demo endpoint independent testing (Canadian Centre for Meteorological and Environmental Prediction)
-
Successfully conducted first pass testing against a generic WFS 3.0 client library (OWSLib - https://github.com/geopython/OWSLib)
-
Provided recommendations to align closer to WFS 3.0 patterns in GitHub: https://github.com/OGCMetOceanDWG/MetOceanAPI-Workshop/blob/master/api-review-comments.md
-
-
Initial cut at WOTW API conformance classes (See Conformance Class file)
4.1 Core (0): Use simple feature specification (point, line string, polygon). How do we interpret this in terms of parameters? How do we encode this? Start value, end value, interval, Begin, end, enumeration. This would be same for time and points. CRS is fixed on 4326. Parameter list would be a list of WMO vocabulary (Links to 2 Grib tables)
4.2 Spatial (1): required for start, stop, interval and enumeration. Not required for start and stop. Specify default for interpolation, vertical, time. For cross section and corridors use line string terminology (harder case though).
4.3 Weather parameters (2): Use WFS as the basis for query parameters. Create filter. The API should be self describing and therefore advertise what parameters are available. There will likely be restrictions to output encodes for Grib vs. json.
4.4 Temporal (3); Use MetOcean specification, Grib2, netCDF
4.5 Measurements (4):
4.6 Interpolation (5): Must specify interpolation method per axis. Must use well known method. Specify default as nearest neighbor. Work on other interpolations methods with vendors
4.7 Return(6): We inform. Json, covjson, grib, netcdf, xml
4.8 Vendor Extras (7): Outside of scope.
-
Initial cut at supported MetOcean API geometry query types (See: query pattern mappings file)
5.1 Point, point series
5.2 Polygon
5.3 Profile
5.4 grid
5.5 Corridor
5.6 Trajectory
Various related implementations already exist.
Finnish Meteorological Institute (FMI), Vaisala and Spatineo have developed a Proof-of-Concept OGC Core - Features (WFS3) server. The main goals of the project are to experiment feasibility of WFS3 in providing weather observations and forecasts and a new O&M Simple Feature Encodings-data model (OMFS).
Used encoding of OMFS data model is based on GeoJSON. It is designed to ease the use of environmental data in web-based applications without still keeping a required (minimal) level of metadata and semantics. The data model enables data sharing and processing with a variety of existing technologies having simple feature handling capabilities. The data model is one alternative to consider in Maintenance and Implementation Work Programme 2016-2020, Action 2017.2 on alternative encodings for INSPIRE data.
The API has been tested in several ways. One implementation is available in FMI Open Data portal with selected data sets. Feedback is also gathered in INSPIRE Helsinki 2019 event where project partners have a challenge Commuting 2.0 to boost environmentally-friendly commuting. Both FMI and Vaisala have open implementations available during the challenge.
The server is implemented with NodeJS and TypeScript. The server architecture is modular: the core takes care of API and data encoding while different data-store integrations extract and process requested information from the underlying data sources such as files, databases or other services.
| Content | Link |
|---|---|
Server core source code |
|
FMI data integration source code |
|
OMSF profile repository |
In support of the Canadian Centre for Climate Services (CCCS), the Meteorological Service of Canada (MSC), as part of their GeoMet platform, deployed an initial offering of weather, climate and water data via the OGC API - Features standard. Made available in 2018, initial datasets included historical hydrometric and climate data.
Data was encoded as GeoJSON and was also provided via HTML representation. The API was used as part of the CCCS Climate data extraction tool, allowing users to visualize and access/download archive data with spatial, aspatial and temporal criteria for just in time data extraction of data relevant to their use case. Future phases of the API will include real time weather observations and hydrometric data. The API is also used for climate data extraction via the recently launched collaborative portal at ClimateData.ca.
The server is implemented with in Python with pygeoapi and provides a robust plugin architecture for extensibility. Supported backends include Elasticsearch, PostgreSQL/PostGIS and GeoPackage.
| Content | Link |
|---|---|
OGC API - Feature endpoint |
|
Source code |
|
Website |