I. Abstract
The OGC API-Environmental Data Retrieval (EDR) Standard provides a family of lightweight query interfaces to access spatiotemporal data resources by requesting data at a Position, within a Radius, Area or Cube, along a Trajectory or through a Corridor, from a predefined Location or as an existing data Item. A spatiotemporal data resource is a collection of spatiotemporal data that can be sampled using the EDR query pattern geometries. These patterns are described in the section describing the Core Requirements Class.
The goals of the EDR Application Programming Interface (API), often abbreviated to EDR API, that is specified by this Standard are to:
Make it easier to access a wide range of data through a uniform, well-defined simple Web interface;
To achieve data reduction to just the data needed by the user or client while hiding much of the data storage complexity.
A major use case for the EDR API is to retrieve small subsets from large collections of environmental data, such as weather forecasts, though many other types of data can be accessed. The important aspect is that the requested data can be unambiguously specified by spatiotemporal coordinates.
The EDR API query patterns-Position, radius, Area, Cube, Trajectory, Corridor or Location -can be thought of as discrete sampling geometries, conceptually consistent with the feature of interest in the OGC Sensor Observation Service (SOS) Standard. A typical data resource accessed by an EDR API instance is a multidimensional dataset that could be accessed via an implementation of the OGC Web Coverage Service (WCS) Standard. In contrast to SOS and WCS, the EDR API is fully consistent with the patterns of the OGC API family of standards and aims to provide a single set of simple-to-use query patterns. Use cases for EDR range from real or virtual time-series observation retrievals, to sub-setting 4-dimensional data cubes along user-supplied sampling geometries. These query patterns do not attempt to satisfy the full scope of either SOS or WCS, but instead provide useful building blocks to enable the composition of APIs that satisfy a wide range of geospatial data use cases. By defining a small set of query patterns (and no requirement to implement all of them), the EDR API should help to simplify the design of systems (as they can be performance tuned for the supported queries) making it easier to build robust and scalable infrastructures.
The EDR API Item query pattern provides a way of discovering and retrieving existing data objects available from the service.
With the OGC API family of standards, the OGC community has extended its suite of standards to include Resource Oriented Architectures and Web Application Programming Interfaces (APIs). These standards are based on a shared foundation, specified in the OGC API-Common Standard, which defines the resources and access paths that are specified by all OGC API Standards. The resources are listed in Table 1. This document extends that foundation to define the EDR API.
| Resource | Path | HTTP Method | Document Reference |
|---|---|---|---|
| Landing page | / | GET | API Landing Page |
| API definition | /{api} | GET | API Definition |
| Conformance classes | /conformance | GET | Declaration of Conformance Classes |
| Collections metadata | /collections | GET | Collections Metadata |
| Collection instance metadata | /collections/{collection_id} | GET | Collection Metadata |
The resources identified in Table 1 primarily support Discovery operations. Discovery operations allow clients to query via the API implementation instance to determine supported capabilities and obtain information (metadata) about a distribution of a resource. This includes the details of the API supported by the server(s) as well as metadata about the resources provided by those servers.
The OGC API-EDR Standard extends the common query operations listed in Table 1 by defining simple, coordinate-based, queries which are applicable to many spatiotemporal, including geospatial, resource types. Other OGC API Standards may define additional query capabilities specific to their resource type. EDR Query operations allow resources or values to be retrieved from the underlying spatio-temporal resource data store. The information returned is based upon the selection criteria (query string) provided by the client.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, property, geographic information, spatial data, spatial thing, spatio-temporal, dataset, distribution, API, JSON, geoJSON, coverageJSON, HTML, OpenAPI, AsyncAPI, REST, Common, position, area, trajectory, corridor, cube, time-series, radius, polygon, WKT
III. Preface
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium SHALL not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
IV. Security considerations
No security considerations have been made for this document.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- UK Met Office
- US Geological Survey (USGS)
- US National Weather Service
- Wuhan University
- Meteorological Service of Canada
- Finnish Meteorological Institute
- Esri
- National Aeronautics and Space Administration (NASA)
- Météo-France
VI. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
| Name | Affiliation |
| Mark Burgoyne (editor) | Met Office |
| Chris Little (editor) | Met Office |
| Charles Heazel (editor) | HeazelTech LLC |
| David Blodgett (editor) | USGS |
| Tom Kralidis (contributor) | Meteorological Service of Canada |
1. Scope
This Standard identifies resources, captures compliance classes, and specifies requirements which are applicable to OGC Environmental Data Retrieval APIs.
This Standard addresses two fundamental operations: discovery and query.
Discovery operations allow the API to be interrogated to determine its capabilities and retrieve information (metadata) about a distribution of a resource. This includes the API definition of the server as well as metadata about the spatiotemporal data resources provided by the server.
A spatio-temporal data resource is a collection of spatiotemporal data that can be sampled using OGC-API Environmental Data Retrieval query patterns.
Query operations allow other data resources, such as environmental ones, to be sampled from the underlying spatiotemporal data resource, or data store, based upon EDR query geometry and other selection criteria, defined by this Standard and selected by the client.
2. Conformance
Conformance with this Standard SHALL be checked using the tests specified in Annex B of this document. The framework, concepts, and methodology for testing, and the criteria to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.
The one Standardization Target for this Standard is Web APIs.
OGC API-Common-Part 1: Core defines an API module intended for re-use by other OGC Web API standards. This OGC API-EDR Standard is an extension of OGC API-Common-Part 1: Core and OGC API-Common-Part 2: Geospatial Data. Conformance to the OGC API-EDR Standard requires demonstrated conformance to the applicable Conformance Classes of OGC API-Common.
This OGC API-EDR Standard identifies a set of Conformance Classes. The Conformance Classes implemented by an API are advertised through the /conformance path on the landing page. Each Conformance Class is defined by one or more Requirements Classes. The requirements in Annex A are organized by Requirements Class. The Requirements Classes therefore define the functional requirements which are tested through the associated Conformance Class.
2.1. Mandatory Requirements Classes
The mandatory requirements classes specified in the OGC API-EDR Standard include:
Requirements Class “OGC API - Environmental Data Retrieval Core”: This requirements class inherits from the Core Requirements Class of OGC API-Common-Part 1: Core which specifies the minimal useful service interface for an OGC API endpoint. The requirements specified in the Requirements Class “OGC API - Environmental Data Retrieval Core” are mandatory for all implementations of the EDR API. The requirements are specified in Chapter 7 and in Annex A.2 in more detail.
Requirements Class “Collections”: This requirements class inherits from the Collections Requirements Class of OGC API-Common-Part 2: Geospatial Data which extends the Core Requirements class of OGC API-Common-Part 1: Core to enable discovery and query access to collections of spatial resources.
The structure and organization of a collection of spatio-temporal data is very much dependent on the nature of that data and the expected access patterns. This is information which cannot be specified in a common manner. The OGC API-Common-Part 2: Geospatial Data Candidate Standard, specifies the requirements necessary to discover and understand a generic collection of spatiotemporal data.
The Collections Requirements Class of the EDR API extends the common requirements to those specific to the query and retrieval of collections of spatiotemporal data. The Collections Requirements Class is specified in Chapter 8 and specified in more detail in Annex A.3.
2.2. Optional Requirements Classes
Neither the Core nor Collections requirements classes mandate specific encodings or formats for representing resources. The optional HTML, GeoJSON and CoverageJSON requirements classes specify representations for these resources in frequently used encodings for spatial data on the web.
The JSON and EDR GeoJSON conformance classes ensure that basic discovery of Core and Collection resources for the EDR API can be performed. They have one Requirements Class each:
Encodings, three Requirements Classes
The Encoding Requirements Classes are specified in Chapter 9 and specified in more detail in Annex A.6, A.8, and A.9.
None of these encodings are mandatory. A developer of an implementation of the EDR API may decide to implement another encoding instead of, or in addition to, those listed. However, a common format does simplify interoperability, so support for CoverageJSON is highly recommended as an established, efficient and effective format for a variety of spatiotemporal data.
The EDR API Core does not mandate any encoding or format for the formal, machinable, definition of the API, such as using schemas and schema fragments. The recommended option is to use the OpenAPI specification (either Version 3.0 or 3.1). Three requirements classes have been specified for OpenAPI:
OpenAPI Specification (depends on Core);
OpenAPI Specification 3.0 (depends on OpenAPI Specification); and
OpenAPI Specification 3.1 (depends on OpenAPI Specification).
The Core requirements class can also decide to use other API definition representations in addition or instead of an OpenAPI 3.x definition. Examples for alternative API definitions: OpenAPI 2.0 (Swagger), future versions of the OpenAPI specification, an OWS Common 2.0 capabilities document or WSDL.
Queries, one Requirements Class
The EDR API Queries Conformance class does not mandate any specific query patterns for querying resources. The requirements class specifies query patterns for which there are ubiquitous use cases.
The developer of an implementation of the EDR API may decide to implement another query pattern instead of, or in addition to, those listed. However, a minimal query pattern of retrieving data at a position (with elevation and time) does simplify interoperability so support for the position query is highly recommended.
At least one of the following queries: Position, Radius, Area, Cube, Trajectory, Corridor, Items, or Locations SHALL be implemented.
The Queries Requirements Class is described in Chapter 8 and to ease readability, fully specified in detail in Annex A.4.
3. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
OpenAPI Initiative (OAI). OpenAPI Specification 3.0 [online]. 2020 [viewed 2025-01-03]. The latest patch version at the time of publication of this standard was 3.0.4, available at https://spec.openapis.org/oas/v3.0.4
OpenAPI Initiative (OAI). OpenAPI Specification 3.1 [online]. 2021 [viewed 2025-01-03]. The latest patch version at the time of publication of this standard was 3.1.1, available at https://spec.openapis.org/oas/v3.1.1
Fielding R, Gettys J, Mogul J, Frystyk H, Masinter L, Leach P, Berners-Lee T, Internet Engineering Task Force: IETF RFC 2616, Hypertext Transfer Protocol — HTTP/1.1. RFC Publisher (1999). https://www.rfc-editor.org/info/rfc2616.
Rescorla E, Internet Engineering Task Force: IETF RFC 2818, HTTP Over TLS. RFC Publisher (2000). https://www.rfc-editor.org/info/rfc2818.
Klyne G, Newman C, Internet Engineering Task Force: IETF RFC 3339, Date and Time on the Internet: Timestamps. RFC Publisher (2002). https://www.rfc-editor.org/info/rfc3339.
Berners-Lee T, Fielding R, Masinter L: IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. RFC Publisher (2005). https://www.rfc-editor.org/info/rfc3986.
Butler H, Daly M, Doyle A, Gillies S, Hagen S, Schaub T, Internet Engineering Task Force: IETF RFC 7946, The GeoJSON Format. RFC Publisher (2016). https://www.rfc-editor.org/info/rfc7946.
Nottingham M: IETF RFC 8288, Web Linking. RFC Publisher (2017). https://www.rfc-editor.org/info/rfc8288.
Gregorio J, Fielding R, Hadley M, Nottingham M, Orchard D: IETF RFC 6570, URI Template. RFC Publisher (2012). https://www.rfc-editor.org/info/rfc6570.
Fielding, R., Reschke, J.: IETF RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.3
W3C: HTML5, W3C Recommendation, https://www.w3.org/TR/html5/
Schema.org: https://schema.org/docs/schemas.html
Chris Little, Jon Blower, Maik Riechert, Open Geospatial Consortium: OGC 21-069r2, OGC CoverageJSON Community Standard. Open Geospatial Consortium (2023). http://www.opengis.net/doc/CS/covjson/1.0.
Weibel S, Kunze J, Lagoze C, Wolf M: IETF RFC 2413, Dublin Core Metadata for Resource Discovery. RFC Publisher (1998). https://www.rfc-editor.org/info/rfc2413.
John Herring, Open Geospatial Consortium: OGC 06-103r4, OpenGIS Implementation Specification for Geographic information — Simple feature access — Part 1: Common architecture. Open Geospatial Consortium (2011). http://www.opengis.net/doc/is/sfa/1.2.1.
Roger Lott, Open Geospatial Consortium: OGC 18-010r7, Geographic information — Well-known text representation of coordinate reference systems. Open Geospatial Consortium (2019). http://www.opengis.net/doc/is/wkt-crs/2.0.6.
Clemens Portele, Panagiotis (Peter) A. Vretanos, Charles Heazel, Open Geospatial Consortium: OGC 17-069r3, OGC API — Features — Part 1: Core. Open Geospatial Consortium (2019). http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.0.
Charles Heazel, Open Geospatial Consortium: OGC 19-072, OGC API — Common — Part 1: Core. Open Geospatial Consortium (2023). http://www.opengis.net/doc/is/ogcapi-common-1/1.0.0.
Charles Heazel: OGC API-Common-Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, https://docs.ogc.org/DRAFTS/20-024.html
4. Terms and definitions
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
The Glossary includes terms from other standards and specifications that, while not normative, are critical to accurately understand this Standard.
region specified with a geographic envelope that may have a vertical extent
two-parameter set of points around a trajectory
(Note: generalized from the ISO definition of a trajectory)
rectangular area, with a vertical extent
identifiable geographic place
(Source: ISO 19112:2019)
Note 1 to entry: A location is represented by one of a set of data types that describe a position, along with metadata about that data, including coordinates (from a coordinate reference system), a measure (from a linear referencing system), or an address (from an address system).
attribute, such as version, release, or run, of a given data collection
data type that describes a point or geometry potentially occupied by an object or person
(Source: ISO 19133:2005)
region specified with a geographic position and radial distance
data associated with a position in space-time
path of a moving point described by a one-parameter set of points
(Source: ISO 19141:2008)
5. Conventions
5.1. Identifiers
The Architecture of the World Wide Web establishes the Uniform Resource Identifier (URI) as the single global identification system for the Web. Therefore, URIs or URI Templates are used in OGC Web API standards to identify key entities in those standards.
The normative provisions in this Standard are denoted by the URI:
https://www.opengis.net/spec/ogcapi-edr-1/1.2
All Requirements and Conformance Tests that appear in this document are denoted by partial URIs which are relative to this base.
A key requirement of Web API standards is the unambiguous identification of the resources they address. In the implementation of such a standard, URIs would be used to identify those resources. A standard, however, is not an implementation. A standard can identify potential resources, but not the resources themselves. Therefore, OGC Web API Standards specify URI Templates to identify resource categories. These resource categories are instantiated in the implementation of the standard.
The scope of each URI Template is specified in the standard. In some cases, implementations of an OGC API Standard are required to implement the template as a path. In most cases they are optional.
Implementation of the URI Templates is recommended in that they provide a common look and feel to implementations of OGC Web API Standards.
5.2. Link relations
To express relationships between resources, RFC 8288 (Web Linking) and registered link relation types are used wherever possible and denoted below with [IANA]. Additional link relation types are registered with the OGC Link Relation Type Register. These are denoted below with [OGC].
The following link-relations are in common use by OGC Web API Standards.
alternate: Refers to a substitute for this context. [IANA]
collection: The target IRI points to a resource which represents the collection resource for the context IRI. [IANA]
conformance: Refers to a resource that identifies the specifications that the link’s context conforms to. [OGC]
data: refers to the root resource of a dataset in an API. [OGC]
describedby: Refers to a resource providing information about the link’s context. [IANA]
item: The target IRI points to a resource that is a member of the collection represented by the context IRI. [IANA]
items: Refers to a resource that comprises members of the collection represented by the link’s context. [OGC]
license: Refers to a license associated with this context. [IANA]
self: Conveys an identifier for the link’s context. [IANA]
service-desc: Identifies service description for the context that is primarily intended for consumption by machines. [IANA]
service-doc: Identifies service documentation for the context that is primarily intended for human consumption. [IANA]
NOTE 1: API definitions are considered service descriptions.
Each resource representation includes an array of links. Implementations are free to add additional links for all resources provided by the API. For example, an enclosure link could reference a bulk download of a collection. Or a related link on a feature could reference a related feature.
A license link could be used for constraints on the data retrieved. Multiple license links could be provided for different content types. Alternatively, if all data retrieved via the API is available under the same license, the link MAY instead be added to the top-level links property of the response.
NOTE 2: The query patterns of the EDR API use the link relation data. In the future this link relation may be replaced by position, area, and trajectory which would all be specializations of the currently used data.
5.3. Media Types
JSON media types that would typically be used in implementations of an OGC API endpoint that supports JSON are:
application/vnd.cov+json for resources that include coverage content encoded according to CoverageJSON;
application/geo+json for feature collections and features; and
application/json for all other resource representations, as well as coverage content encoded according to the Coverage Implementation Schema (CIS).
XML media types that would typically occur in implementation of an OGC API endpoint that supports XML are:
application/gml+xml;version=3.2 for any Geography Markup Language (GML) 3.2 feature collections and features;
application/gml+xml;version=3.2;profile=https://www.opengis.net/def/profile/ogc/2.0/gml-sf0 for GML 3.2 feature collections and features conforming to the GML Simple Feature Level 0 profile;
application/gml+xml;version=3.2;profile=https://www.opengis.net/def/profile/ogc/2.0/gml-sf2 for GML 3.2 feature collections and features conforming to the GML Simple Feature Level 2 profile; and
application/xml for all other resources.
The typical HTML media type for all “web pages” in an implementation of an OGC API service endpoint would be text/html.
The media types for an OpenAPI definition are application/vnd.oai.openapi+json;version=3.0.4 or application/vnd.oai.openapi+json;version=3.1.1 (JSON) and application/vnd.oai.openapi;version=3.0.4 or application/vnd.oai.openapi;version=3.1.1 (YAML).
NOTE 1: The OpenAPI media type has not been registered yet with IANA and may change.
NOTE 2: The CoverageJSON media type has not been registered yet with IANA and may change.
5.4. Examples
Most of the examples provided in this OGC API-EDR Standard are encoded in JSON. JSON was chosen because it is widely understood by implementors and easy to include in a text document. This convention should NOT be interpreted as a requirement that JSON must be used. Implementors are free to use any format they desire as long as there is a Conformance Class for that format and the API advertises its support for that Conformance Class.
5.5. Schema
JSON Schema is used throughout this Standard to define the structure of resources. These schemas are typically represented using YAML encoding, a human-readable data-serialization language. This convention is for the ease of the user. This Standard does not prohibit the use of another schema language or encoding. Nor does the Standard specify that JSON Schema is required. Implementations should use a schema language and encoding appropriate for the format of the resource.
5.6. Use of HTTPS
For simplicity, this Standard generally refers to the HTTP protocol. This is not meant to exclude the use of HTTPS and is simply a shorthand notation for “HTTP or HTTPS”. In fact, most servers are expected to use HTTPS, not HTTP.
5.7. API definition
5.7.1. General remarks
So that developers can more easily learn how to implement the EDR API, good documentation is essential for any OGC API Standard. In the best case, documentation would be available both in HTML for human consumption and in a machine-readable format that can be best processed by software for run-time binding.
This OGC Standard specifies requirements and recommendations for implementation APIs that share spatiotemporal resources and want to follow a standard interoperable way of doing so. In general, API deployments will go beyond the requirements and recommendations stated in this Standard. They will support additional operations, parameters, etc. that are specific to the specific API deployment or the software tool used to implement the API.
5.7.2. Role of OpenAPI
This document uses OpenAPI 3.1 fragments as examples and to formally state requirements. However, using OpenAPI 3.1 is not required for implementing a server.
Therefore, the EDR API Core requirements class only requires that an API definition is provided and linked from the landing page resource at {root}/.
Separate requirements classes are specified for API definitions that follow the OpenAPI Specification 3.0 and OpenAPI Specification 3.1. This does not preclude that in the future or in parallel other versions of OpenAPI or other API descriptions are provided by a server.
NOTE: This approach is used to avoid lock-in to a specific approach to defining an API as it is expected that the API landscape will continue to evolve.
In this document, fragments of OpenAPI definitions are shown in YAML (YAML Ain’t Markup Language) since YAML is easier to read than JSON and is typically used in OpenAPI editors. YAML is described by its authors as a human friendly data serialization standard for all programming languages.
5.7.3. References to OpenAPI components in normative statements
Some normative statements (requirements, recommendations and permissions) use a phrase that a component in the API definition of the server has to be “based upon” a schema or parameter component in the OGC schema repository.
In the case above, the following changes to the pre-defined OpenAPI component are permitted.
If the server supports an XML encoding, xml properties may be added to the relevant OpenAPI schema components.
The range of values of a parameter or property may be extended (additional values) or constrained (if a subset of all possible values are applicable to the server). An example for a constrained range of values is to explicitly specify the supported values of a string parameter or property using an enum.
The default value of a parameter may be changed or added unless a requirement explicitly prohibits this.
Additional properties may be added to the schema definition of a Response Object.
Informative text may be changed or added, like comments or description properties.
For API definitions that do not conform to the OpenAPI Specification 3.1, the normative statement has to be interpreted in the context of the API definition language used.
5.7.4. Paths in OpenAPI definitions
All paths in an OpenAPI definition are relative to a base URL of the server.
Example — URL of the OpenAPI definition
If the OpenAPI Server Object looks like this:
servers:
- url: https://dev.example.org/
description: Development server
- url: https://data.example.org/
description: Production server
The path “/mypath” in the OpenAPI definition of a Web API would be the URL https://data.example.org/mypath for the production server.
5.7.5. Reusable OpenAPI components
Reusable components for OpenAPI definitions for implementations of the OGC API-Features Standard are referenced from this document.
6. Overview
6.1. General
The OGC API Standards enable access to resources using the HTTP protocol and its associated operations (GET, PUT, POST, etc.). OGC API-Common defines a set of facilities which are applicable to all OGC APIs. Other OGC Standards extend API-Common with facilities specific to a resource type.
The OGC API-Environmental Data Retrieval Standard defines an API with the following goals:
To make it easier to access a wide range of data through a uniform, well-defined simple Web interface;
To allow clients to retrieve a subset of data hosted and selected by a server via the API in response to a standardized, coordinate orientated, query pattern;
To provide ‘building blocks’ enabling the construction of more complex applications.
An EDR API implementation conformant to this Standard can be considered a ‘Sampling API’. The query creates a discrete sampling geometry against the spatio-temporal data resource of a relatively persistent data store. The query and its response are transient resources, but if required the resource could be made persistent for re-use.
The functionality provided by the EDR query patterns could be realized through specific implementation of the SOS (and to some extent WCS) from the OGC Web Services family of (XML-based) standards. The OGC API-EDR Standard introduces a streamlined JSON-based OGC API implementation of building blocks that could be used for many of the simple similar use cases addressed by SOS and WCS in the past.
The EDR API defines behavior for the HTTP GET and POST operations. Future versions may introduce additional methods as required, consistent with RFC 7231. The HTTP methods supported by an EDR service SHALL be defined by the service OpenAPI description.
6.2. Resource Paths
Table 2 summarizes the access paths and relation types defined in this Standard.
| Path Template | Relation | Method | Resource |
|---|---|---|---|
| Common | |||
| {root}/ | none | GET | Landing page |
| {root}/{api} | service-desc or service-doc | GET | API Description (optional) |
| {root}/conformance | conformance | GET | Conformance Classes |
| Collections | |||
| {root}/collections | data | GET | Metadata describing the collections of data available from this API. |
| {root}/collections/{collectionId} | GET | Metadata describing the collection of data which has the unique identifier {collectionId} | |
| Features | |||
| {root}/collections/{collectionId}/items | items | GET | Retrieve metadata about available items |
| Queries | |||
| {root}/collections/{collectionId}/{queryType} | GET, POST(Optional) | Retrieve data according to the query pattern from a collection with the unique identifier {collectionId} | |
| {root}/collections/{collectionId}/instances | GET | Retrieve metadata about instances of a collection | |
| {root}/collections/{collectionId}/instances/{instanceId} | GET | Retrieve metadata from a specific instance of a collection with the unique identifiers {collectionId} and {instanceId} | |
| {root}/collections/{collectionId}/instances/{instanceId}/{queryType} | GET, POST(Optional) | Retrieve data according to the query pattern from a specific instance of a collection with the unique identifiers {collectionId} and {instanceId} | |
Where:
{root} = Base URI for the API server
{api} = an identifier for an optional description of the API
{collectionId} = an identifier for a specific collection of data
{instanceId} = an identifier for a specific version or instance of a collection of data
{queryType} = an identifier for a specific query pattern to retrieve data from a specific collection of data
7. Dependencies on Core and Collections Requirements Classes of OGC API-Common
The OGC API-EDR Standard is an extension of OGC API-Common-Part 1: Core and OGC API-Common-Part 2: Geospatial Data. Therefore, an implementation of the OGC API-EDR Standard SHALL first satisfy the appropriate Requirements Classes from OGC API-Common, namely:
7.1. Overview
The OGC API - Environmental Data Retrieval Core Requirements Class defines the requirements for locating, understanding, and accessing spatiotemporal data resources.
See Requirements Class “OGC API - Environmental Data Retrieval Core” for a detailed specification of the Core Requirements Class.
The following four sections explain aspects of the Core, Collections and Queries Requirements Classes:
API Platform: A set of common capabilities;
Collection Access: Operations for accessing collections of spatiotemporal data;
Query Resources: Operations for accessing spatio-temporal data resources through queries; and
General: General principles for use with this Standard.
Table 3 Identifies the OGC API - Common Requirements Classes which are applicable to each section of this Standard. Instructions on when and how to apply these Requirements Classes are provided in each section.
7.2. Platform
The OGC API - Common Standard defines a set of common capabilities which are applicable to any implementation of an OGC Web API Standard. Those capabilities provide the platform upon which resource-specific APIs can be built and deployed. This section describes those capabilities and any modifications needed to better support spatiotemporal data resources.
7.2.1. API landing page
The landing page provides links that support exploration of the resources offered via the API endpoint. The most important component of a landing page is a list of links. The OGC API-Common Standard requires some common links, sufficient for this Standard, that are stated in the following Requirements Class of the OGC API-Common Standard (hereafter referred to as OGC API -Common):
Dependencies
7.2.1.1. Operation
The Landing Page operation is defined in the Core conformance class of OGC API - Common. No modifications are needed to support spatiotemporal data resources. The Core conformance class specifies only one way of performing this operation:
Issue a GET request on the {root}/ path
Support for GET on the {root}/ path is required by OGC API — Common.
7.2.1.2. Response
A successful response to the Landing Page operation is defined in OGC API - Common. The schema for this resource is provided in Listing 1.
Listing 1 — Landing Page Response Schema
type: object
required:
- links
properties:
title:
type: string
examples:
- Meteorological data server
description:
type: string
examples:
- Access to Meteorological data via a Web API that conforms to the OGC API Environmental Data Retrieval specification.
links:
type: array
items:
$ref: link.yaml
examples:
- - href: https://example.org/edr/api
hreflang: en
rel: service-desc
type: application/vnd.oai.openapi+json;version=3.0
title: ""
- href: https://example.org/edr/conformance
hreflang: en
rel: data
type: application/json
title: ""
- href: https://example.org/edr/collections
hreflang: en
rel: data
type: application/json
title: ""
keywords:
type: array
items:
type: string
examples:
- - Temperature
- Wind
- Point
- Trajectory
provider:
type: object
properties:
name:
description: Name of organization providing the service
type: string
url:
description: Link to service providers website
type: string
contact:
type: object
properties:
email:
description: Email address of service provider
type: string
phone:
description: Phone number of service provider
type: string
fax:
description: Fax number of service provider
type: string
hours:
type: string
instructions:
type: string
address:
type: string
postalCode:
type: string
city:
type: string
stateorprovince:
type: string
country:
type: string
The following JSON fragment is an example of a response to an OGC API-EDR Landing Page operation.
Listing 2 — Landing Page Example
{
"title": "string",
"description": "string",
"links": [
{
"href": "https://example.org/",
"rel": "self",
"type": "application/json",
"title": "this document"
},
{
"href": "https://example.org/api",
"rel": "service-desc",
"type": "application/vnd.oai.openapi+json;version=3.0",
"title": "the API definition"
},
{
"href": "https://example.org/conformance",
"rel": "conformance",
"type": "application/json",
"title": "OGC conformance classes implemented by this API"
},
{
"href": "https://example.org/collections",
"title": "Metadata about the resource collections"
}
]
}
7.2.1.3. Error Handling
The requirements for handling unsuccessful requests are provided in Recommendation https://www.opengis.net/spec/ogcapi-common-1/1.0/rec/core/problem-details of OGC API-Common. General guidance on HTTP status codes and how they should be handled is provided in Clause 9.2-HTTP Status Codes.
7.3. API definition
7.3.1. Operation
Every OGC Web API is expected to provide a definition that describes the capabilities of the server and which can be used by developers to understand the API, by software clients to connect to the server, or by development tools to support the implementation of servers and clients.
| Identifier | /req/core/api-definition-op |
|---|---|
| Included in | Requirements class A.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Statement | A: The server SHALL support the HTTP GET operation on all links from the landing page which have the relation type service-desc. |
| Statement | B: The server SHALL support the HTTP GET operation on all links from the landing page which have the relation type service-doc. |
| Statement | C: The responses to all HTTP GET requests issued in A and B SHALL satisfy requirement /req/core/api-definition-success. |
| Permission 1 | /per/core/api-definition-uri |
| A | The API definition is metadata about the API implementation and strictly not part of the API implementation itself, but it MAY be hosted as a sub-resource to the base path of the API endpoint, for example, at path /api. There is no need to include the path of the API definition in the API definition itself. |
Note that multiple API definition formats can be supported.
7.3.2. Response
| Identifier | /req/core/api-definition-success |
|---|---|
| Included in | Requirements class A.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Statement | A: A successful execution of the operation SHALL be reported as a response with an HTTP status code 200. |
| Statement | B: The content of that response SHALL be an API Definition document. |
| Statement | C: The API Definition document SHALL be consistent with the media type identified through HTTP content negotiation. |
NOTE: The f parameter SHOULD be used to satisfy this requirement.
| Recommendation 1 | /rec/core/api-definition-oas |
| A | If the API definition document uses the OpenAPI Specification 3.0, the document SHOULD conform to the OpenAPI Specification 3.0 requirements class. |
| B | If the API definition document uses the OpenAPI Specification 3.1, the document SHOULD conform to the OpenAPI Specification 3.1 requirements class. |
If the server hosts the API definition under the base path of the API endpoint (for example, at path /api), there is no need to include the path of the API definition in the API definition itself.
The idea is that any implementation of the OGC API Features Standard may be used by developers that are familiar with the API definition language(s) supported by the server. For example, if an OpenAPI definition is used, it is possible to create a working client using the OpenAPI definition. The developer may need to learn a little bit about geometry data types, etc., but it is not necessary to read this Standard to access the data via an API endpoint.
In case the API definition is based on OpenAPI 3.1, consider the two approaches discussed in OpenAPI requirements class.
7.3.3. API definition
Every API implementation is required to provide a definition document that describes the capabilities of that API. This definition document can be used by developers to understand the API deployment, by software clients to connect to the server, or by development tools to support the implementation of servers and clients.
Support for an API definition is specified in the following Requirements Class of OGC API-Common:
Dependencies
7.3.3.1. Operation
This operation is defined in the Core conformance class of OGC API — Common. No modifications are needed to support spatio-temporal data resources. The Core conformance class describes two ways of performing this operation:
Issue a GET request on the {root}/{api} path; and
Follow the service-desc or service-doc link on the landing page.
Only the link is required by OGC API - Common.
7.3.3.2. Response
A successful response to the API Definition request is a resource which documents the design of the API. OGC API - Common leaves the selection of the format for the API Definition response to the API implementor. However, the options are limited to those which are defined in the OGC API-Common Standard. OpenAPI 3.0 is the only option provided, though OpenAPI 3.1 is expected to be supported.
7.3.3.3. Error Handling
The requirements for handling unsuccessful requests are provided in Recommendation https://www.opengis.net/spec/ogcapi-common-1/1.0/rec/core/problem-details of OGC API-Common. General guidance on HTTP status codes and how they should be handled is provided in Clause 9.2-HTTP Status Codes.
7.3.4. Declaration of conformance classes
To support “generic” clients that want to access implementations of multiple OGC API Standards and extensions-and not “just” a specific API server, the EDR API implementation has to declare the conformance classes it claims to have implemented.
Support for the declaration of conformance classes is specified in the following Requirements Class of OGC API-Common:
Dependencies
7.3.4.1. Operation
This operation is defined in the Core conformance class of OGC API - Common. No modifications are needed to support spatio-temporal data resources. The Core conformance class describes two ways of performing this operation:
Issue a GET request on the {root}/conformance path; and
Follow the conformance link on the landing page.
Both techniques are required by OGC API - Common.
7.3.4.2. Response
A successful response to the Conformance operation is a list of URLs. Each URL identifies an OGC Conformance Class for which this EDR API claims conformance. The schema for this resource is defined in OGC API - Common and provided for reference in Listing 3.
Apply Requirement /req/core/conformance on declaration of Core conformance classes.
Listing 3 — Conformance Response Schema
type: object
required:
- conformsTo
properties:
conformsTo:
type: array
items:
type: string
The following JSON fragment is an example of a response to an OGC API-EDR conformance operation.
Listing 4 — Conformance Information Example
{
"conformsTo": [
"https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core",
"https://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
"https://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections",
"https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/oas30",
"https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/html",
"https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/geojson"
]
}
8. Query, Spatiotemporal and Information Resources
Query resources are spatiotemporal queries which support operation of the API implementation instance for access and use of the spatiotemporal data resources. The OGC API-EDR Standard has identified an initial set of common queryTypes to implement. These are described in Clause 8.2. This list may change as the Standard is used and experience gained.
A spatiotemporal data resource is a collection of spatiotemporal data that can be sampled using the OGC API-EDR query patterns.
This clause specifies the “Collections” Requirements Class. The detailed specification of the Requirements Class is in Annex A.3.1.
Query resources related to spatiotemporal data resources (collections of spatiotemporal data) can be exposed using the path templates:
/collections/{collectionId}/{queryType}
/collections/{collectionId}/instances/{instanceId}/{queryType}
Where
{collectionId} = A unique identifier for a collection of spatiotemporal data.
{instanceId} = A text string identifying the version or instance of the chosen collection.
{queryType} = A text string identifying the query pattern performed by the API.
The instanceId parameter supports multiple instances or versions of the same underlying data source to be accessed by a request to the API endpoint. This is applicable when the entire data source has been regenerated rather than individual values in the data source being changed. If only one instance of the data source exists a value of default or latest could be used.
Information resources associated with a specific collection should be accessed through the /collections path. Information resources not associated with a specific collection should be accessed via the /{instanceId}/{queryType} path template.
The resources returned from each node in these templates are described in Table 6.
NOTE 1: An EDR collection is a set of data that shares the same coordinate dimensions (i.e. the same units of space, height and time) as specified in the collection’s extent.
NOTE 2: All coordinates defined in an EDR collection’s extent must be mutually consistent, ensuring that a valid query can subset the data across all coordinate axes simultaneously
8.1. Information Resources
| Path Template | Resource |
|---|---|
| /collections | The root resource describing the collections of spatiotemporal data available from this API. |
| /collections/{collectionId} | Identifies a collection of spatiotemporal data with the unique identifier {collectionId} |
| /collections/{collectionId}/{queryType} | Identifies an Information Resource of type {queryType} associated with the {collectionId} collection. |
The OGC API - Common Standard does not define any information resource types. However Table 7 provides a mapping of the initial query types proposed for the EDR API.
8.2. Query Resources
The following tables are the informative definition for the EDR query types. The query types support a mix of optional and required query parameters. Where necessary an EDR implementation can use its OpenAPI document response (i.e. /api) to provide a normative definition of the functionality of the service. This allows a service to advertise which parameters, although optional as part of the EDR API Standard, are required for the service or vice versa (i.e. the parameter is optional in the EDR API Standard but not supported by the service).
The OpenAPI document for an EDR service SHALL be the definitive (NORMATIVE) reference of whether a query parameter is required in any request to the EDR server.
ALL EDR implementations SHALL implement query parameters that are required by the EDR Standard.
At least one of the following queries: Position, Radius, Area, Cube, Trajectory, Corridor, Items, or Locations SHALL be implemented.
| Path Template | Query Type | Description |
|---|---|---|
| /collections/{collectionId}/position | Position | Return data for the requested position |
| /collections/{collectionId}/radius | Radius | Return data within a given radius of a position |
| /collections/{collectionId}/area | Area | Return data for the requested area |
| /collections/{collectionId}/cube | Cube | Return data for a spatial cube |
| /collections/{collectionId}/trajectory | Trajectory | Return data along a defined trajectory |
| /collections/{collectionId}/corridor | Corridor | Return data within a spatiotemporal corridor |
| /collections/{collectionId}/items | Items | Items associated with the {collectionId} collection. |
| /collections/{collectionId}/locations | Locations | Location identifiers associated with the {collectionId} collection. |
| /collections/{collectionId}/instances | Instances | List the available instances of the collection |
8.2.1. Position query
The Position query returns data for the requested coordinate. Logic for identifying the best match for the coordinate will depend on the collection and is at the discretion of the query service implementer. The filter constraints are defined by the following query parameters:
| Query Parameter | Type | Required | Description | Examples |
coords | WKT string | Yes | The coordinates are defined by a Point Well Known Text (WKT) string |
|
z | String | No | The vertical level to return data for (available options are defined in the vertical attribute of the extent section in the collections metadata response) |
|
datetime | String | No | Datetime range to return data for (the available range is defined in the temporal attribute of the extent section in the collections metadata response) |
|
parameter-name | String | No | Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) |
|
crs | String | No | Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) |
|
f | String | No | Data format for the output data (available options are listed in the collections response), schemas describing JSON and XML outputs can be defined in the OpenAPI documentation (see https://swagger.io/docs/specification/data-models/) |
|
limit | String | No | The limit parameter may be used to control subsets of the selected features that should be returned in multiple responses. The full response is “paged” into smaller responses. The limit parameter determines a size of the paged responses. Each response may include information about the number of selected and returned features (numberMatched and numberReturned) as well as links to support paging (link relation next). This value will be ignored if the requested format or the server does not support paging |
|
If a client request has a coords value which includes a height value and defines a z query parameter, the z query parameter will be the requested height value.
8.2.2. Radius query
The Radius query returns data within the defined radius of the requested coordinate. The filter constraints are defined by the following query parameters:
| Query Parameter | Type | Required | Description | Examples |
coords | WKT string | Yes | The coordinates are defined by a Point Well Known Text (WKT) string |
|
z | String | No | The vertical level to return data for (available options are defined in the vertical attribute of the extent section in the collections metadata response) |
|
datetime | String | No | Datetime range to return data for (the available range is defined in the temporal attribute of the extent section in the collections metadata response) |
|
parameter-name | String | No | Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) |
|
within | String | Yes | Defines radius of area around defined coordinates to include in the data selection |
|
within-units | String | Yes | Distance units for the within parameter (available options are defined in the within_units attribute of the radius data_query section in the collections metadata response) |
|
crs | String | No | Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) |
|
f | String | No | Data format for the output data (available options are listed in the collections response), schemas describing JSON and XML outputs can be defined in the OpenAPI documentation (see https://swagger.io/docs/specification/data-models/) |
|
limit | String | No | The limit parameter may be used to control subsets of the selected features that should be returned in multiple responses. The full response is “paged” into smaller responses. The limit parameter determines a size of the paged responses. Each response may include information about the number of selected and returned features (numberMatched and numberReturned) as well as links to support paging (link relation next). This value will be ignored if the requested format or the server does not support paging |
|
If a client request has a coords value which includes a height value and defines a z query parameter the z query parameter will be the requested height value.
8.2.3. Area query
The Area query returns data within the polygon defined by the coords parameter. Logic for identifying the best match for the requested area will depend on the collection and is at the discretion of the query service implementer. The height or time of the area are specified through separate parameters. The results are further filtered by the constraints defined by the following query parameters:
| Query Parameter | Type | Required | Description | Examples |
coords | WKT string | Yes | The coordinates are defined by a Polygon Well Known Text (WKT) string | |
z | String | No | The vertical level to return data for (available options are defined in the vertical attribute of the extent section in the collections metadata response) |
|
datetime | String | No | Datetime range to return data for (the available range is defined in the temporal attribute of the extent section in the collections metadata response) |
|
parameter-name | String | No | Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) |
|
crs | String | No | Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) |
|
f | String | No | Data format for the output data (available options are listed in the collections response), schemas describing JSON and XML outputs can be defined in the OpenAPI documentation (see https://swagger.io/docs/specification/data-models/) |
|
limit | String | No | The limit parameter may be used to control subsets of the selected features that should be returned in multiple responses. The full response is “paged” into smaller responses. The limit parameter determines a size of the paged responses. Each response may include information about the number of selected and returned features (numberMatched and numberReturned) as well as links to support paging (link relation next). This value will be ignored if the requested format or the server does not support paging |
|
If a client request has a coords value which includes a height value and defines a z query parameter the z query parameter will be the requested height value.
8.2.4. Cube query
The Cube query returns a data cube defined by the bbox and z parameters. The results are further filtered by the constraints defined by the following query parameters:
| Query Parameter | Type | Required | Description | Examples |
bbox | String | Yes | The coordinates are defined by a BBOX string. Only data that has a geometry that intersects the area defined by the bbox are selected.
bbox=minx,miny,maxx,maxy The X and Y coordinates are values in the coordinate system defined by the crs query parameter. If crs is not defined, the values will be assumed to be WGS84 longitude/latitude coordinates and heights will be assumed to be meters above mean sea level, or below for negative values. |
|
z | String | No | The vertical level to return data for (available options are defined in the vertical attribute of the extent section in the collections metadata response) |
|
datetime | String | No | Datetime range to return data for (the available range is defined in the temporal attribute of the extent section in the collections metadata response) |
|
parameter-name | String | No | Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) |
|
resolution-x | String | No | Defined if the user requires data at a different resolution from the native resolution of the data along the x-axis, it denotes the number of intervals to retrieve data along the x-axis |
|
resolution-y | String | No | Defined if the user requires data at a different resolution from the native resolution of the data along the y-axis, it denotes the number of intervals to retrieve data along the y-axis |
|
resolution-z | String | No | Defined if the user requires data at a different resolution from the native resolution of the data along the z-axis, it denotes the number of intervals to retrieve data along the z-axis |
|
crs | String | No | Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) |
|
f | String | No | Data format for the output data (available options are listed in the collections response), schemas describing JSON and XML outputs can be defined in the OpenAPI documentation (see https://swagger.io/docs/specification/data-models/) |
|
If a client request has a bbox value which includes height values and defines a z query parameter the z query parameter will be the definition of the requested height value.
8.2.5. Trajectory query
The Trajectory query returns data along the path defined by the coords parameter. Logic for identifying the best matches for the requested trajectory will depend on the collection and is at the discretion of the query service implementer . The results are further filtered by the constraints defined by the following query parameters:
| Query Parameter | Type | Required | Description | Examples |
coords | WKT string | Yes | The coordinates are defined by one of the following Well Known Text (WKT) strings:
|
|
z | String | No | The vertical level to return data for (available options are defined in the vertical attribute of the extent section in the collections metadata response) |
|
datetime | String | No | Datetime range to return data for (the available range is defined in the temporal attribute of the extent section in the collections metadata response) |
|
parameter-name | String | No | Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) |
|
crs | String | No | Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) |
|
f | String | No | Data format for the output data (available options are listed in the collections response), schemas describing JSON and XML outputs can be defined in the OpenAPI documentation (see https://swagger.io/docs/specification/data-models/) |
|
If any of the following occurs:
client request contains coords=LINESTRINGZ(…) and a z query parameter
client request contains coords=LINESTRINGM(…) and a datetime query parameter
client request contains coords=LINESTRINGZM(…) and z or datetime query parameters
An error SHALL be thrown by the server
8.2.6. Corridor query
The Corridor query returns data along and around the path defined by the coords parameter. Logic for identifying the best match for the requested corridor will depend on the collection and is at the discretion of the query service implementer . The results are further filtered by the constraints defined by the following query parameters:
| Query Parameter | Type | Required | Description | Examples |
coords | WKT string | Yes | The coordinates are defined by one of the following Well Known Text (WKT) strings:
|
|
z | String | No | The vertical level to return data for (available options are defined in the vertical attribute of the extent section in the collections metadata response) |
|
datetime | String | No | Datetime range to return data for (the available range is defined in the temporal attribute of the extent section in the collections metadata response) |
|
parameter-name | String | No | Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) |
|
resolution-x | String | No | Defined if the user requires data at a different resolution from the native resolution of the data along the x-axis, it denotes the number of intervals to retrieve data along the x-axis |
|
resolution-y | String | No | Defined if the user requires data at a different resolution from the native resolution of the data along the y-axis, it denotes the number of intervals to retrieve data along the y-axis |
|
resolution-z | String | No | Defined if the user requires data at a different resolution from the native resolution of the data along the z-axis, it denotes the number of intervals to retrieve data along the z-axis |
|
corridor-width | String | Yes | The width value represents the whole width of the corridor where the trajectory supplied in the coords query parameter is the center point of the corridor |
|
width-units | String | Yes | Distance units for the corridor-width parameter (available options are defined in the width_units attribute of the corridor data_query section in the collections metadata response) |
|
corridor-height | String | Yes | The height value represents the whole height of the corridor where the trajectory supplied in the coords query parameter is the center point of the corridor |
|
height-units | String | Yes | Distance units for the corridor-height parameter (available options are defined in the height_units attribute of the corridor data_query section in the collections metadata response) |
|
crs | String | No | coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) |
|
f | String | No | Data format for the output data (available options are listed in the collections response), schemas describing JSON and XML outputs can be defined in the OpenAPI documentation (see https://swagger.io/docs/specification/data-models/) |
|
If any of the following occurs:
Client request contains coords=LINESTRINGZ(…) and a z query parameter
Client request contains coords=LINESTRINGM(…) and a datetime query parameter
Client request contains coords=LINESTRINGZM(…) and z or datetime query parameters
An error SHALL be thrown by the server
8.2.7. Items query
The EDR API Items query may be used to provide the contents of a collection as an enumerable set of geospatial features following the OGC API — Features Item access semantics and filtering mechanisms, such as time range, parameters, and spatial characteristics.
Examples of use include offering the entire collection data contents as pre-compiled feature entities, or providing access to sampling features related to the data contents of the collection, such as the monitoring locations used for collecting the provided observational data. Other examples include a catalogue of spatiotemporal sampling features such as domains of anomalies in a dataset, or specific EDR queries that have been cached for later use,
A https://schemas.opengis.net/ogcapi/edr/1.2/openapi/ogcapi-environmental-data-retrieval-1. yaml[GeoJSON-compatible JSON-Schema] is specified to document the EDR API Item query endpoint with a default edr-geojson schema, but alternative custom GeoJSON schemas can be specified for the service.
| Statement | A: If a collection using other EDR queries uses the items query, implementations SHOULD consider support for the EDR GeoJSON Schema as an encoding. |
|---|---|
If an itemId is not specified, the query will return a list of the available itemId’s. This behavior is specified in the OGC API-Features Standard. All other parameters for use with the Items query are defined by OGC API-Features.
| Path Parameter | Type | Required | Description | Examples |
itemId | String | No | Identifier for the required item. | * |
The filter constraints are defined by the following query parameters:
| Query Parameter | Type | Required | Description | Examples |
bbox | String | No | The coordinates are defined by a BBOX string. Only data that has a geometry that intersects the area defined by the bbox are selected.
bbox=minx,miny,maxx,maxy The X and Y coordinates are values in the coordinate system defined by the crs query parameter. If crs is not defined, the values will be assumed to be WGS84 longitude/latitude coordinates and heights will be assumed to be in meters above mean sea level. |
|
datetime | String | No | Datetime range to return data (the available range is defined in the temporal attribute of the extent section in the collections metadata response) |
|
limit | String | No | The limit parameter may be used to control the subset of the selected features that should be returned in the response, the page size. Each page may include information about the number of selected and returned features (numberMatched and numberReturned) as well as links to support paging (link relation next). This value will be ignored if the requested format or the server does not support paging |
|
Example — itemId
To retrieve an item, specify the required Item identifier:
/collections/{collectionId}/items/{itemId}
The following example returns information for the requested item with an id of KIAD_2020-05-19T00Z from the Metar collection. Returned data would include a location query end point, time range, a list of available parameters, and a representative geometry for the KIAD METAR station.
/collections/metar/items/KIAD_2020-05-19T00Z
The following example returns information for the requested item with an id of warning_12345 from the forecast collection. Returned data would include an area query end point, time range, a list of available parameters and a representative geometry for the warning_12345 warning area.
/collections/forecast/items/warning_12345
8.2.8. Locations query
The Locations query returns data for the named location. Logic for identifying the best match for the coordinate will depend on the collection and is at the discretion of the query service implementer. If a location id is not defined, the API implementation SHALL return a GeoJSON features array of valid location identifiers and the schema of the GeoJSON response SHOULD be defined in the OpenAPI definition of the EDR service.
The filter constraints are defined by the following query parameters:
| Path Parameter | Type | Required | Description | Examples |
locationId | String | No | Unique identifier(s) for the required location(s), such as a GeoHash, a World Meteorological Organization (WMO) station identifier or place name. |
|
| Query Parameter | Type | Required | Description | Examples |
datetime | String | No | Datetime range to return data for (the available range is defined in the temporal attribute of the extent section in the collections metadata response) |
|
parameter-name | String | No | Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) |
|
crs | String | No | Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) |
|
f | String | No | Data format for the output data (available options are listed in the collections response), schemas describing JSON and XML outputs can be defined in the OpenAPI documentation (see https://swagger.io/docs/specification/data-models/) |
|
limit | String | No | The limit parameter may be used to control subsets of the selected features that should be returned in multiple responses. The full response is “paged” into smaller responses. The limit parameter determines a size of the paged responses. Each response may include information about the number of selected and returned features (numberMatched and numberReturned) as well as links to support paging (link relation next). This value will be ignored if the requested format or the server does not support paging |
|
8.2.9. Instances query
Having multiple versions or instances of the same collection, where the same information is reprocessed or regenerated is not unusual. Although these versions could be described as new collections the instance query type allows this data to be described as different views of the same collection.
8.2.9.1. Parameter instanceId
A unique identifier for the instance of the collection is specified as:
/collections/{collectionId}/instances/{instanceId}
Example 1 — Return the Raw data instance metadata (instanceId = raw) for the Metar ((collectionId = metar) collection
/collections/metar/instances/raw
Example 2 — Return the Level 1 Quality controlled data instance (instanceId = qc_lvl_1) metadata for the Metar (collectionId = metar) collection
/collections/metar/instances/qc_lvl_1
8.2.9.2. Parameter queryType
The queryType options are exactly the same as those available for collections that do not have multiple instances and support the same query parameters and functionality. See Table 7 for the mappings of the query types. The queryType structure is:
/collections/{collectionId}/instances/{instanceId}/{queryType}
See Clause 8.2 for details of the query parameters supported by the queryTypes.
Example 1 — A position query on a Raw data instance(instanceId = raw) for the Metar ((collectionId = metar) collection
/collections/metar/instances/raw/position
Example 2 — A trajectory query on a Raw data instance(instanceId = raw) for the Metar ((collectionId = metar) collection
/collections/metar/instances/raw/trajectory
8.2.10. Custom dimension support
Support for dimensions other than the standard spatio-temporal dimensions can be provided by adding the custom dimension type to the EDR API extent object in the collections response. The custom dimension type allows for an array of custom query dimensions to be defined. Each custom dimension item is defined with the following characteristics (using an OpenAPI Specification 3.0 fragment)
Example 1 — Schema for custom query parameter metadata
type: object
required:
- id
- interval
- reference
properties:
id:
type: string
interval:
type: array
minItems: 1
items:
type: array
minItems: 2
items:
anyOf:
- type: string
- type: number
nullable: true
values:
type: array
minItems: 1
items:
anyOf:
- type: string
- type: number
nullable: true
reference:
type: string
Consistent with the conventions used for temporal and vertical extents, a custom extent SHALL define a structured set of metadata describing the dimension it represents. A custom extent is used when a collection contains an axis that is neither purely spatial, temporal, nor vertical, but is nevertheless required for correctly interpreting or subsetting the data. To ensure interoperability and predictable behaviour across EDR implementations, each custom extent SHALL include the following properties:
id: Name of the custom dimension.
interval: data value range of the dimension (minimum value, maximum value).
values: defines all of the supported data values.
reference: string which describes the custom dimension (this can be a link to a detailed description).
Example 2 — custom dimension definitions in a collections response
"extent": {
"spatial": {
"bbox": [[-180,-90,180,90]],
"crs": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",
SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\","7030"]],
AUTHORITY[\"EPSG\",\"6326\"]],
PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],
UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9122\"]],
AUTHORITY[\"EPSG\",\"4326\"]]",
},
"temporal": {
"interval": [["2017-06-14T00:00:00Z","2017-06-14T12:00:00Z"]],
"values": ["2017-06-14T00:00:00Z","2017-06-14T06:00:00Z",
"2017-06-14T12:00:00Z","2017-06-14T18:00:00Z"],
"trs": "TIMECRS[\"DateTime\",TDATUM[\"Gregorian Calendar\"],
CS[TemporalDateTime,1],
AXIS[\"Time (T)\",future]]"
},
"custom": [
{
"id": "realisations",
"interval": [[1,50]],
"values": ["R50/1/1"],
"reference": "Ensemble members"
},
{
"id": "icao_ids",
"interval": [["EB", "EB"]],
"values": ["EBAW","EBBR","EBBR","EBKT","EBLG","EBOS"],
"reference": "https://en.wikipedia.org/wiki/ICAO_airport_code"
}
]
}
The id field can then be used as the name of a query parameter in any of the query_types supported by the collection. The query parameter value definition will follow the same conventions as the datetime and z query parameters by supporting single value, value lists and value ranges as valid inputs.
Custom query parameter definition
| Query Parameter | Type | Required | Description | Examples |
custom_dimension_name1 | String | No | The value range to return data for (available options are defined in the values attribute of the custom dimension definition in the extent section in the collections metadata response) |
|
1 The names of the custom dimension query parameters are defined as the id value within the custom attribute of the extent object in the collection metadata response.
Example 3 — Return the 5th, 10th, 15th and 20th ensemble members between 2022-05-10T00:00Z and 2022-05-10T06:00Z at height level 2.0
https://server.example/collections/global_model/area?
coords=POLYGON((-12.602 59.367,-12.954 46.580,2.169 47.061,2.169 60.769,-12.602 59.367))
¶meter-name=Temperature
&datetime=2022-05-10T00:00Z/2022-05-10T06:00Z
&realisations=R4/5/5
&z=2.0
&crs=EPSG:4326
&f=CoverageJSON
Example 4 — Only return data for EBBR EBOS between 2022-05-10T00:00Z and 2022-05-10T06:00Z from the available sites in the European area.
https://server.example/collections/observations/locations/europe?
¶meter-name=wind_speed,wind_direction
&datetime=2022-05-10T00:00Z/2022-05-10T06:00Z
&icao_ids=EBBR,EBOS
&crs=EPSG:4326
&f=CoverageJSON
9. General Requirements
The following general requirements and recommendations are applicable to most implementations of OGC API standards.
9.1. HTTP 1.1
The standards used for Web APIs are built on the HTTP protocol. Therefore, conformance with HTTP or a closely related protocol is required.
Apply Requirement /req/core/http for HTTP support.
9.2. HTTP Status Codes
Table 19 lists the main HTTP status codes that clients should be prepared to receive. This includes support for specific security schemes or URI redirection. In addition, other error situations may occur in the transport layer outside of the server.
| Status code | Description |
|---|---|
| 200 | A successful request. |
| 202 | A successful request, but the response is still being generated. The response will include a Retry-After header field giving a recommendation in seconds for the client to retry. |
| 204 | A successful request, but the resource has no data resulting from the request. No additional content or message body is provided. |
| 304 | An entity tag was provided in the request and the resource has not been changed since the previous request. |
| 308 | The server cannot process the data through a synchronous request. The response includes a Location header field which contains the URI of the location the result will be available at once the query is complete Asynchronous queries. |
| 400 | The server cannot or will not process the request due to an apparent client error. For example, a query parameter had an incorrect value. |
| 401 | The request requires user authentication. The response includes a WWW-Authenticate header field containing a challenge applicable to the requested resource. |
| 403 | The server understood the request, but is refusing to fulfill it. While status code 401 indicates missing or bad authentication, status code 403 indicates that authentication is not the issue, but the client is not authorized to perform the requested operation on the resource. |
| 404 | The requested resource does not exist on the server. For example, a path parameter had an incorrect value. |
| 405 | The request method is not supported. For example, a POST request was submitted, but the resource only supports GET requests. |
| 406 | Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource. |
| 413 | Request entity too large. For example, the query would involve returning more data than the server is capable of processing, the implementation should return a message explaining the query limits imposed by the server implementation. |
| 500 | An internal error occurred in the server. |
More specific guidance is provided for each resource, where applicable.
| Permission 2 | /per/core/additional-status-codes |
| A | Servers MAY support other capabilities of the HTTP protocol and, therefore, MAY return other status codes than those listed in Table 19, too. |
9.3. Web Caching
Entity tags are a mechanism for web cache validation and for supporting conditional requests to reduce network traffic. Entity tags are specified by HTTP/1.1 (RFC 2616).
| Statement | A: The service SHOULD support entity tags and the associated headers as specified by HTTP/1.1. |
|---|---|
9.4. Support for Cross-Origin Requests
If data is located on another host than the webpage (“same-origin policy”), access to data from a HTML page is by default prohibited for security reasons. A typical example is a web-application accessing feature data from multiple distributed datasets.
| Statement | A: If the server is intended to be accessed from the browser, cross-origin requests SHOULD be supported. Note that support can also be added in a proxy layer on top of the server. |
|---|---|
Two common mechanisms to support cross-origin requests are:
9.5. Asynchronous queries
Responding to queries synchronously is not always possible. The EDR API Standard does not specify how to handle asynchronous requests. Different services may offer different best practices.
For example, if the query requires handling requests asynchronously, one option of many, is that the system could respond with a HTTP code of 308 and include a Location response header field with the URI of the location of the data once the query has completed. If the user queries the URI of the product of the query before the data is available that response should respond with a HTTP code of 202 and include a Retry-after response header field with a suggested interval in seconds to retry the data retrieval.
9.6. Coordinate Reference Systems
As discussed in Chapter 9 of the OGC/W3C Spatial Data on the Web Best Practices document, how to express and share the location of resources in a consistent way is one of the most fundamental aspects of publishing geospatial or spatio-temporal data and it is important to be clear about the coordinate reference system that the coordinates use.
For the reasons discussed in the Best Practices, implementations of EDR APIs SHOULD support WGS84 longitude and latitude (https://www.opengis.net/def/crs/OGC/1.3/CRS84) as a coordinate reference system.
9.7. Encodings
While the OGC API-EDR Standard does not specify any mandatory encoding, the following encodings are recommended. See Clause 2.2 (Optional Requirements Classes) for a discussion of this issue.
HTML encoding recommendation:
| Statement | A: To support browsing an API definition through a web browser and to enable search engines to crawl and index the dataset, implementations SHOULD consider supporting an HTML encoding. |
|---|---|
GeoJSON encoding recommendation:
| Statement | A: If the resource can be represented for the intended use in GeoJSON, implementations SHOULD consider supporting GeoJSON as an encoding. |
|---|---|
CoverageJSON encoding recommendation. This is specific to the EDR API:
| Statement | A: If the resource can be represented for the intended use in CoverageJSON, implementations SHOULD consider supporting CoverageJSON as an encoding. |
|---|---|
Requirement Requirement /req/core/http implies that the encoding of a response is determined using content negotiation as specified by the HTTP RFC.
The section Media Types includes guidance on media types for encodings that are specified in this document.
Note that any API deployment that supports multiple encodings will have to support a mechanism to create encoding-specific URIs for resources to express links, such as for alternative representations of the same resource. This document does not mandate any approach to how this is supported by the API deployment.
As clients simply need to dereference the URI of the link, the implementation details and the mechanism of how the encoding is included in the URI of the link are not important. Developers interested in the approach of a particular implementation, can study the API definition.
NOTE: Two common approaches are:
An additional path for each encoding of each resource (this can be expressed, for example, using format specific suffixes like .html);
An additional query parameter (for example, accept or f) that overrides the Accept header of the HTTP request.
9.8. Support for limit query parameter
An EDR enabled server MAY provide support for a limit query parameter when the requested output format can support data paging. Note: If either the server or the requested data format do not support paging responses the limit query parameter value will be ignored.
If the limit query parameter is supported the following applies.
The number of features returned depends on the server and the parameter limit.
The client can request a limit it is interested in.
The server likely has a default value for the limit, and a maximum limit.
If the server has any more results available than it returns (the number the server returns is less than or equal to the requested/default/maximum limit) then the server will include a link to the next set of results.
So (using the default/maximum values of 10/10000 from the OpenAPI fragment in requirement /req/core/fc-limit-definition):
Asking for 10 will return 0 to 10 (as requested) and if there are more, a next link;
Asking without a limit will return 0 to 10 (default) and if there are more, a next link;
Asking for 50000 will return up to 10000 (server-limited) and if there are more, a next link; and
Following the next link from the previous response will return up to 10000 additional features and if there are more, a next link.
| Statement | A: A HTTP 200 OK response SHOULD include a link to the next “page” (relation: next), if more features have been selected than returned in the response. |
|---|---|
| Statement | A: Dereferencing a next link SHOULD return additional features from the set of selected features that have not yet been returned. |
|---|---|
| Statement | A: If there are more features in the selection that have not yet been returned, the number of features in a response to a next link SHOULD follow the same rules as for the response to the original query and again include a next link. |
|---|---|
This Standard does not mandate any specific implementation approach for the next links.
An implementation could use opaque links that are managed by the server. It is up to the server to determine how long these links can be de-referenced. Clients have to be prepared to receive a 404 response.
Another implementation approach is to use an implementation-specific parameter that specifies the index within the result set from which the server begins presenting results in the response.
If all selected features are returned, the API endpoint will return no next link. However, the server can not be aware that it has already returned all selected features. For example, if the request states limit=10 and the query to the backend datastore returns 10 features, the server may not know, if there are more features or not (in most cases there will be more features), unless the total number of matches is also computed, which can be too costly. The server will then add the next link, and if there are no more features, dereferencing the next link will return an empty feature collection and no next link. This behavior is consistent with the statements above.
Clients cannot assume that paging is safe against changes to dataset while a client iterates through next links. If a server provides opaque links these could be safe and maintain the dataset state during the original request. Using a parameter for the start index, however, will not be safe.
Additional requirements classes for safe paging or an index parameter can be added in extensions to this Standard.
| Permission 3 | /per/core/rc-prev |
| A | A response to a next link MAY include a prev link to the resource that included the next link. |
Providing prev links supports navigating back and forth between pages, but depending on the implementation approach it can be too complex to implement.
9.8.1. Requirement /req/core/rc-numberMatched number matched
| Identifier | /req/core/rc-numberMatched |
|---|---|
| Statement | A: If a property numberMatched is included in the response, the value SHALL be identical to the number of features in the feature collections that match the selection parameters like bbox, datetime or additional filter parameters. B: If the information about the number of matching features is not known or difficult to compute, a server MAY omit this information in a response. |
9.8.2. Requirement /req/core/rc-numberReturned number returned
| Identifier | /req/core/rc-numberReturned |
|---|---|
| Statement | A: If a property numberReturned is included in the response, the value SHALL be identical to the number of features in the response. A: If the information about the number of features in the response is not known or difficult to compute, a server MAY omit this information in a response. |
| Statement | A: If the response is a partial, paged response (i.e., the number of features in the response is less than the number of features that match the selection parameters) and the response includes information about the extent of the response (e.g. the member bbox in a GeoJSON feature collection), the extent SHOULD be the extent of the complete result set, not the extent of the features in the response / page. |
|---|---|
NOTE: The representation of the links and the other properties in the payload depends on the encoding of the feature collection
9.9. Link Headers
| Statement | A: Links included in the payloads of responses SHOULD also be included as Link headers in the HTTP response according to RFC 8288, Clause 3. |
|---|---|
| Statement | B: This recommendation does not apply, if there are a large number of links included in a response or a link is not known when the HTTP headers of the response are created. |
10. OpenAPI requirements classes
10.1. Requirements Class “OpenAPI Specification”
NOTE: This OpenAPI specification requirements class is abstract. Implementations can only conform to the concrete requirements classes OpenAPI Specification 3.0 or OpenAPI Specification 3.1.
10.1.1. Basic requirements
Servers conforming to this requirements class provide an API definition as an OpenAPI Document. Note that this requirements class is not specific to a particular version of the OpenAPI specification. Requirements specific to a particular version are defined in separate, dependent requirements classes.
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | Requirements class A.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Normative statements | Requirement 5: /req/oas/oas-definition Requirement 6: /req/oas/oas-impl Requirement 7: /req/oas/completeness Requirement 8: /req/oas/exceptions-codes Requirement 9: /req/oas/security |
10.1.2. Requirement /req/oas/oas-definition OpenAPI definition
| Identifier | /req/oas/oas-definition |
|---|---|
| Included in | Requirements class 1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas |
| Statement | A: The content of the response of the HTTP GET operation at the landing page SHALL include the following links to the API definition:
|
The requirements /req/core/root-success and /req/core/api-definition-success in Core require that the API definition documents are referenced from the landing page.
OpenAPI definitions can be created using different approaches. A typical example is the representation of the feature collections. One approach is to use a path parameter collectionId, i.e., the API definition has only a single path entry for all feature collections. Another approach is to explicitly define each feature collection in a separate path and without a path parameter, which enables specifying filter parameters or explicit feature schemas per feature collection. Both approaches are valid.
10.1.3. Requirement /req/oas/oas-impl OpenAPI implementation
| Identifier | /req/oas/oas-impl |
|---|---|
| Included in | Requirements class 1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas |
| Statement | A: The server SHALL implement all capabilities specified in the OpenAPI definition. |
10.1.5. Requirement /req/oas/completeness OpenAPI Completeness
| Identifier | /req/oas/completeness |
|---|---|
| Included in | Requirements class 1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas |
| Statement | A: The OpenAPI definition SHALL specify for each operation all HTTP Status Codes and Response Objects that the server uses in responses. This includes the successful execution of an operation as well as all error situations that originate from the server. |
| Statement | B: This includes the successful execution of an operation as well as all error situations that originate from the server. |
Note that servers that are access-controlled (see Security), support web cache validation, CORS or that use HTTP redirection will make use of additional HTTP status codes beyond regular codes such as 200 for successful GET requests and 400, 404 or 500 for error situations. See [http_status_codes].
Clients have to be prepared to receive responses not documented in the OpenAPI definition. For example, additional errors can occur in the transport layer outside of the server.
10.1.7. Requirement /req/oas/exceptions-codes OpenAPI Exception codes
| Identifier | /req/oas/exceptions-codes |
|---|---|
| Included in | Requirements class 1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas |
| Statement | A: For error situations that originate from an API server, the API definition SHALL cover all applicable HTTP Status Codes. |
Listing 5 — An exception response object definition
description: An error occurred.
content:
application/json:
schema:
$ref: https://schemas.opengis.net/ogcapi/edr/1.2/openapi/schemas/core/exception.yaml
text/html:
schema:
type: string
10.1.9. Requirement /req/oas/security OpenAPI Security
| Identifier | /req/oas/security |
|---|---|
| Included in | Requirements class 1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas |
| Statement | A: For cases, where the operations of the API implementation are access-controlled, the security scheme(s) and requirements SHALL be documented in the OpenAPI definition. |
The OpenAPI specification currently supports the following security schemes:
HTTP authentication,
an API key (either as a header or as a query parameter),
OAuth2’s common flows (implicit, password, application and access code) as defined in RFC6749, and
OpenID Connect Discovery.
10.2. Requirements Class “OpenAPI Specification 3.0”
Servers conforming to OpenAPI Specification 3.0 requirements class provide their API definition as an OpenAPI 3.0 Document.
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas30 |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisites | Requirements class 1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas https://spec.openapis.org/oas/v3.0.4 |
10.2.1. Requirement /req/oas30/oas-definition OpenAPI 3.0 definition
| Identifier | /req/oas30/oas-definition |
|---|---|
| Statement | A: The JSON representation SHALL conform to the OpenAPI Specification 3.0. |
10.3. Requirements Class “OpenAPI Specification 3.1”
Servers conforming to this requirements class provide their API definition as an OpenAPI 3.1 Document.
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas31 |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisites | Requirements class 1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/oas https://spec.openapis.org/oas/v3.1.1 |
10.3.1. Requirement /req/oas31/oas-definition OpenAPI 3.1 definition
| Identifier | /req/oas31/oas-definition |
|---|---|
| Statement | A: The JSON representation SHALL conform to the OpenAPI Specification 3.1. |
Annex A
(normative)
Requirements Detail
A.1. Introduction
For clarity, the complete requirements class descriptions are omitted in the body of this Standard. This annex contains the complete set of requirements classes.
A.2. Requirements Class “Core” in Detail
A.2.1. Requirements Class: OGC API-Environmental Data Retrieval Core
Requirements class A.1: OGC API-Environmental Data Retrieval Core | |
|---|---|
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Obligation | requirement |
| Target type | Web API |
| Prerequisites | https://www.opengis.net/spec/ogcapi-common-1/1.0/req/core https://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections |
| Normative statements | Requirement A.1: /req/core/root-op Requirement A.2: /req/core/root-success Requirement A.3: /req/core/conformance Requirement A.4: /req/core/conformance-success Requirement A.5: /req/core/http Requirement A.6: /req/core/crs Requirement A.1-3: /req/core/api-definition-op Requirement A.1-4: /req/core/api-definition-success |
| Identifier | /req/core/root-op |
|---|---|
| Included in | Requirements class A.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Statement | A: The server SHALL support the HTTP GET operation at the path /. |
| Identifier | /req/core/root-success |
|---|---|
| Included in | Requirements class A.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Statement | A: A successful execution of the operation SHALL be reported as a response with an HTTP status code 200. |
| Statement | B: The content of that response SHALL be based upon the OpenAPI 3.0 schema landingPage.yaml and include at least links to the following resources:
|
A.2.2. Requirement /req/core/conformance Core conformance classes
| Identifier | /req/core/conformance |
|---|---|
| Included in | Requirements class A.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Statement | A: The list of Conformance Classes advertised by the API endpoint SHALL include: |
| Identifier | /req/core/conformance-success |
|---|---|
| Included in | Requirements class A.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Statement | A: A successful execution of the operation SHALL be reported as a response with an HTTP status code 200. |
| Statement | B: The content of that response SHALL be based upon the schema confClasses.yaml and list all OGC API conformance classes that the API conforms to. |
A.2.3. Requirement /req/core/http HTTP
| Identifier | /req/core/http |
|---|---|
| Included in | Requirements class A.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Statement | A: The API SHALL conform to HTTP 1.1. |
| Statement | B: If the API supports HTTPS, then the API SHALL also conform to HTTP over TLS. |
A.2.4. Requirement /req/core/crs CRS
| Identifier | /req/core/crs |
|---|---|
| Included in | Requirements class A.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/core |
| Statement | A: Unless the client explicitly requests a different coordinate reference system, all spatial geometries SHALL be in the CRS defined by the spatial element of the extent section in the collection response. |
A.3. Requirements Class “Collections” in Detail
A.3.1. Requirements Class: Collections
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisites | https://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections https://www.opengis.net/spec/ogcapi-common-1/1.0/req/core ISO 19107 ISO 19108 ISO 19111 ISO 19108 ISO 8601 |
| Normative statements | Requirement A.7: /req/collections/rc-md-op Requirement A.8: /req/collections/rc-md-success Requirement A.9: /req/collections/src-md-op Requirement A.10: /req/collections/src-md-success Requirement A.11: /req/edr/rc-collection-info Requirement A.20: /req/core/rc-collection-info-links Requirement A.12: /req/edr/rc-data-queries Requirement A.21: /req/core/rc-extent Requirement A.22: /req/core/rc-md-query-links Requirement A.23: /req/edr/rc-crs Requirement A.24: /req/edr/rc-parameters |
| Identifier | /req/collections/rc-md-op |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: The API implementation SHALL support the HTTP GET operation at the path /collections. |
| Identifier | /req/collections/rc-md-success |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: A successful execution of the operation SHALL be reported as a response with an HTTP status code 200. |
| Statement | B: The content of that response SHALL be based upon the schema collections.yaml. |
| Identifier | /req/collections/src-md-op |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: The API implementation SHALL support the HTTP GET operation at the path /collections/{collectionId}. |
| Statement | B: The parameter collectionId is the id property in the resource collection response (JSONPath: $.collections[*].id). |
| Identifier | /req/collections/src-md-success |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: A successful execution of the operation SHALL be reported as a response with an HTTP status code 200. |
| Statement | B: The content of that response SHALL be based upon the schema collection.yaml. |
| Statement | C: The content of that response SHALL be consistent with the content for this resource collection in the /collections response. That is, the values for id, title, description and extent SHALL be identical. |
| Identifier | /req/edr/rc-collection-info |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: Every Collection within a collections array SHALL have a unique (within the array) id parameter. |
| Statement | B: Every Collection within a collections array SHOULD have a title parameter. |
| Statement | C: Every Collection within a collections array SHOULD have a description parameter. |
| Statement | D: Every Collection within a collections array SHOULD have a Keywords parameter containing an array of values which describe the collection. |
| Statement | E: Every Collection within a collections array SHALL have a links parameter which SHALL comply with the requirement /req/core/rc-collection-info-links. |
| Statement | F: Every Collection within a collections array SHALL have an extent parameter which SHALL comply with the requirement /req/core/rc-extent. |
| Statement | G: Every Collection within a collections array SHALL have a data_queries parameter which SHALL comply with the requirement /req/edr/rc-data-queries. |
| Statement | H: Every Collection within a collections array SHALL have a crs parameter which SHALL comply with the requirement /req/edr/rc-crs. |
| Statement | I: Every Collection within a collections array MAY have a within_units parameter containing an array of supported distance units. |
| Statement | J: If the links parameter includes a link to a Radius query there SHALL be a within_units parameter. |
| Statement | K: Every Collection within a collections array SHALL have an output_formats parameter containing an array of values which describe the output formats supported by the collection. |
| Statement | L: Every Collection within a collections array SHALL have a parameter_names attribute containing a list of parameters that SHALL comply with the requirement /req/edr/rc-parameters. |
| Identifier | /req/edr/rc-data-queries |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: A data_queries object SHALL have a least one of the following query data types defined:
|
| Statement | B: All query types defined in the data_queries object SHALL comply with the requirement /req/edr/rc-common-query-type |
| Identifier | /req/edr/rc-common-variables |
|---|---|
| Statement | A: A variables property SHALL include a query_type property with a value which matches the query type name. |
| Statement | B: A variables property MAY include a title property of type string |
| Statement | C: A variables property MAY include an output_formats property which SHALL be a string array |
| Statement | D: A variables property SHOULD include a default_output_format property of type string |
| Statement | E: If a default_output_format property exists the defined value SHALL be a value contained either in the output_formats defined in the variables section or in the parent collection output_formats. |
| Statement | F: A variables property MAY include a crs_details property which SHALL be an array of objects. |
| Statement | G: Objects in a crs_details array SHALL have a crs and wkt property both of which are of type string. |
| Identifier | /req/edr/rc-common-query-type |
|---|---|
| Statement | A: A data_queries object SHALL include a link property |
| Statement | B: A link property SHALL include an href property |
| Statement | C: A link property SHALL include a rel property |
| Statement | D: A link property of a data_queries object SHALL include a variables property |
| Statement | E:
|
| Identifier | /req/edr/rc-radius-variables |
|---|---|
| Statement | A: A variables property SHALL comply with the requirement /req/edr/rc-variables-common. |
| Statement | B: A variables property SHALL include a within_units property which SHALL be a string array |
| Identifier | /req/edr/rc-cube-variables |
|---|---|
| Statement | A: A cube data_queries object variables property SHALL comply with the requirement /req/edr/rc-variables-common. |
| Statement | B: A cube data_queries object variables property SHALL include a height_units property which SHALL be a string array |
| Identifier | /req/edr/rc-corridor-variables |
|---|---|
| Statement | A: A corridor data_queries object variables property SHALL comply with the requirement /req/edr/rc-variables-common. |
| Statement | B: A corridor data_queries object variables property SHALL include a height_units property which SHALL be a string array |
| Statement | C: A corridor data_queries object variables property SHALL include a width_units property which SHALL be a string array |
| Identifier | /req/edr/rc-locations-variables |
|---|---|
| Statement | A: A locations data_queries object variables property SHALL comply with the requirement /req/edr/rc-variables-common. |
| Statement | B: A locations data_queries object variables property MAY include a multiple_locations property which SHALL be a boolean value (true/false). |
| Statement | C: If the variables property of a data_queries object does not include a multiple_locations property, the client SHALL assume that the server does not support requests for multiple locations. |
| Identifier | /req/edr/rc-items-variables |
|---|---|
| Statement | A: An items data_queries object variables property SHALL include a query_type property the value of which SHALL match the query type |
| Statement | B: An items data_queries object variables property MAY include a title property of type string |
| Identifier | /req/core/rc-collection-info-links |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: A 200-response SHALL include the following links in the links property of the response:
|
| Statement | B: All links SHALL include the rel and type link parameters. |
| Identifier | /req/core/rc-extent |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: For each spatial resource collection, the extent property (if provided) SHALL specify bounding boxes that include all spatial geometries and time intervals that include all temporal geometries in this collection. The temporal extent may use null values to indicate an open time interval. |
| Statement | B: If a spatial resource has multiple properties with spatial or temporal information, it is the decision of the API server implementation whether only a single spatial or temporal geometry property is used to determine the extent or all relevant geometries. |
| Identifier | /req/core/rc-md-query-links |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: For each collection included in the response, the links property of the collection SHALL include at least one link to a query resource (relation: data) or an instance resource (relation: instance). |
| Statement | B: All links SHALL include the rel and type link parameters. |
| Identifier | /req/edr/rc-crs |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: A crs object SHALL have a unique (to the collection) crs property. It MAY be an EPSG code. |
| Statement | B: A crs object SHALL have a wkt property which SHALL be a correctly structured Well Known Text definition for the CRS. |
| Identifier | /req/edr/rc-parameters |
|---|---|
| Included in | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Statement | A: A parameter object MAY have any number of members (name/value pairs). |
| Statement | B: A parameter object SHALL have a member with the name “type” and the value “Parameter”. |
| Statement | C: A parameter object MAY have a member with the name “id” where the value SHALL be a string and SHOULD be a common identifier. |
| Statement | D: A parameter object MAY have a member with the name “label” where the value SHALL be a string that is the name of the parameter and which SHOULD be short. Note that this parameter SHOULD be left out if it would be identical to the “label” of the “observedProperty” member. |
| Statement | E: A parameter object MAY have a member with the name “description” where the value SHALL be a string which is perhaps a lengthy, textual description of the parameter. |
| Statement | F: A parameter object SHALL have a member with the name “observedProperty” where the value is an object which SHALL have the members “label” and “id” and which MAY have the members “description”. The value of “label” SHALL be a string which is the name of the observed property and which SHOULD be short. The value of “id” SHALL be a string and SHOULD be a common identifier. If given, the value of “description” SHALL be a string with a textual description of the observed property. |
| Statement | G: A parameter object MAY have a member with the name “unit” where the value is an object which SHALL have either or both the members “label” or/and “symbol”, and which MAY have the member “id”. If given, the value of “symbol” SHALL either be a string of the symbolic notation of the unit, or an object with the members “value” and “type” where “value” is the symbolic unit notation and “type” references the unit serialization scheme that is used. “type” SHALL HAVE the value “https://www.opengis.net/def/uom/UCUM/” if UCUM is used, or a custom value as recommended in section “Extensions”. If given, the value of “label” SHALL be a string of the name of the unit and SHOULD be short. If given, the value of “id” SHALL be a string and SHOULD be a common identifier. It is RECOMMENDED referencing a unit serialization scheme to allow automatic unit conversion. |
A.4. Requirements Class “Queries” for Position, Area, Cube, Trajectory, Corridor, Items, Locations, and Instances
A.4.1. Requirements Class: Queries
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | Requirements class A.2: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/collections |
| Normative statements | Requirement A.25: /req/edr/rc-core-query-parameters Requirement A.26: /req/edr/rc-position Requirement A.27: /req/edr/rc-area Requirement A.28: /req/edr/rc-cube Requirement A.29: /req/edr/rc-trajectory Requirement A.32: /req/edr/rc-items Requirement A.33: /req/edr/rc-locations Requirement A.34: /req/instances/rc-md-op Requirement A.35: /req/instances/rc-md-success Requirement A.36: /req/instances/src-md-op Requirement A.37: /req/instances/src-md-success Requirement A.3-6: /req/edr/rc-corridor requirement::/req/edr/rc-radius |
A.4.2. Common Requirements for Data Queries
| Identifier | /req/edr/rc-core-query-parameters |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: Every data query defined within a collection SHALL support at least one of the following operations: HTTP GET, HTTP POST, or both. |
| Statement | B: The parameter collectionId is the id property in the collection response (JSONPath: $.collections[*].id). |
| Statement | C: When a collection contains instances the parameter instanceId is the id property in the instances response (JSONPath: $.instances[*].id). |
| Statement | E: A data query GET or POST operation SHOULD include a parameter-name query parameter |
| Statement | H: When a collection defines a temporal extent a data query GET or POST operation SHOULD include a datetime query parameter |
| Statement | H: When a collection defines a vertical extent a data query GET or POST operation SHOULD include a z query parameter |
| Statement | I: A data query GET or POST operation SHOULD include a crs query parameter |
| Statement | J: A data query GET or POST operation SHOULD include an f query parameter |
| Statement | K: When a custom_dimension is defined within a collection a data query GET or POST operation MAY include the custom query parameter. |
| Statement | L: A data query using GET or POST MAY include a limit parameter. If the chosen output format does not support paged responses, the limit parameter SHALL be ignored. |
A.4.3. Requirements for Position Queries
| Identifier | /req/edr/rc-position |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: A position operation SHALL support all common query base requirements |
| Statement | B: A position GET or POST operation SHALL include a coords query parameter |
| Statement | C: A position coords query parameter value SHALL be either a WKT POINT or a WKT MULTIPOINT value |
| Statement | D: If the coords query parameter includes a z coordinate value and the z query parameter is also specified, the z query parameter must be used as the vertical coordinate filter. |
| Statement | E: If the coords query parameter is not specified a HTTP 400 error SHOULD be generated |
A.4.4. Requirements for Area Queries
| Identifier | /req/edr/rc-area |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: An area operation SHALL support all common query base requirements |
| Statement | B: An area GET operation SHALL include a coords query parameter |
| Statement | C: If the coords query parameter is not specified a HTTP 400 error SHOULD be generated |
| Statement | D: An area coords query parameter value SHALL be either a WKT POLYGON or a WKT MULTIPOLYGON value |
| Statement | E: If the coords query parameter includes a z coordinate value and the z query parameter is also specified, the z query parameter must be used as the vertical coordinate filter. |
A.4.5. Requirements for Cube Queries
| Identifier | /req/edr/rc-cube |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: A cube operation SHALL support all common query base requirements |
| Statement | B: A cube GET or POST operation SHALL include a bbox query parameter |
| Statement | C: A bbox query parameter SHOULD only consist of four values, any vertical values defined by bbox will be overridden by the values assigned to the z query parameter |
| Statement | D: If the bbox query parameter is not specified a HTTP 400 error should be generated |
| Statement | E: If the z query parameter is not specified a HTTP 400 error SHOULD be generated |
A.4.6. Requirements for Trajectory Queries
| Identifier | /req/edr/rc-trajectory |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: A trajectory operation SHALL support all common query base requirements |
| Statement | B: A trajectory GET or POST operation SHALL include a coords query parameter |
| Statement | C: If the coords query parameter is not specified a HTTP 400 error SHOULD be generated |
| Statement | D: A trajectory coords query parameter value SHALL be either a WKT LINESTRING, WKT LINESTRINGZ, WKT LINESTRINGM or WKT LINESTRINGZM value |
A.4.7. Requirements for Corridor Queries
| Identifier | /req/edr/rc-corridor |
|---|---|
| Statement | A: A corridor operation SHALL support all common query base requirements |
| Statement | B: A corridor GET operation SHALL include a coords query parameter |
| Statement | C: If the coords query parameter is not specified, an HTTP 400 error SHOULD be generated |
| Statement | D: A corridor coords query parameter value SHALL be either a WKT LINESTRING, WKT LINESTRINGZ, WKT LINESTRINGM or WKT LINESTRINGZM value |
| Statement | E: A corridor GET operation SHALL include a corridor-width query parameter |
| Statement | F: If the corridor-width query parameter is not specified, an HTTP 400 error SHOULD be generated |
| Statement | G: A corridor GET operation SHALL include a corridor-height query parameter |
| Statement | H: If the corridor-height query parameter is not specified, an HTTP 400 error SHOULD be generated |
| Statement | I: A corridor GET operation SHALL include a width-units query parameter |
| Statement | J: If the width-units query parameter is not specified, an HTTP 400 error SHOULD be generated |
| Statement | K: If the width-units query parameter value is not one of the supported values a HTTP 400 error SHOULD be generated |
| Statement | L: A corridor GET operation SHALL include a height-units query parameter |
| Statement | M: If the height-units query parameter is not specified, an HTTP 400 error SHOULD be generated |
| Statement | N: If the height-units query parameter value is not one of the supported values a HTTP 400 error SHOULD be generated |
| Statement | O: If a corridor operation includes a datetime query parameter and the coords parameter is a WKT LINESTRINGM or WKT LINESTRINGZM value a HTTP 400 error SHALL be thrown by the server |
| Statement | P: If a corridor operation includes a z query parameter and the coords parameter is a WKT LINESTRINGZ or WKT LINESTRINGZM value a HTTP 400 error SHALL be thrown by the server |
A.4.8. Requirements for Radius Queries
| Statement | identifier::/req/edr/rc-radius A: A radius operation SHALL support all common query base requirements |
|---|---|
| Statement | B: A radius GET or POST operation SHALL include a coords query parameter |
| Statement | C: If the coords query parameter includes a z coordinate value and the z query parameter is also specified, the z query parameter must be used as the vertical coordinate filter. |
| Statement | D: If the coords query parameter is not specified, an HTTP 400 error should be generated |
| Statement | E: A radius coords query parameter value SHALL be either a WKT POINT or a WKT MULTIPOINT value |
| Statement | F: A radius GET or POST operation SHALL include a within query parameter |
| Statement | G: If the within query parameter is not specified, an HTTP 400 error should be generated |
| Statement | H: A radius GET or POST operation SHALL include a within-units query parameter |
| Statement | I: If the within-units query parameter is not specified, an HTTP 400 error should be generated |
| Identifier | /req/edr/rc-items |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: For every collection identified in the collections response (path /collections), the server MAY support the HTTP GET operation at the path /collections/{collectionId}/items. |
| Statement | B: The parameter collectionId is the id property in the feature collection response (JSONPath: $.collections[*].id). |
| Statement | C: When a collection contains instances the parameter instanceId is the id property in the instances response (JSONPath: $.instances[*].id). |
A.4.9. Requirements for Locations Queries
| Identifier | /req/edr/rc-locations |
|---|---|
| Statement | A: A location operation SHALL support all common query base requirements |
| Statement | B: If a locationId is not specified a list of valid locationId’s SHALL be returned with a description of their geospatial extent. |
A.4.11. Requirements for Instances Queries
| Identifier | /req/instances/rc-md-op |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: The API implementation MAY support the HTTP GET operation at the path /collections/{collection_id}/instances. |
| Identifier | /req/instances/rc-md-success |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: A successful execution of the operation SHALL be reported as a response with a HTTP status code 200. |
| Identifier | /req/instances/src-md-op |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: The API implementation SHALL support the HTTP GET operation at the path /collections/{collectionId}/instances/{instanceId}. |
| Statement | B: The parameter collectionId is the id property in the resource collection response (JSONPath: $.collections[*].id) and instanceId is the id property of the chosen instance of the chosen collection. |
| Identifier | /req/instances/src-md-success |
|---|---|
| Included in | Requirements class A.3: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/queries |
| Statement | A: A successful execution of the operation SHALL be reported as a response with a HTTP status code 200. |
| Statement | B: The content of that response SHALL be based upon the JSON schema instances.yaml. |
| Statement | C: The content of that response SHALL be consistent with the content for this resource collection in the /collections response. That is, the values for id, title, description and extent SHALL be identical. |
A.5. Requirements Class “Query parameters” in Detail
A.5.1. Requirements Class: Query parameters
A.5.2. Requirement /req/core/rc-bbox-definition Parameter bbox definition
| Identifier | /req/core/rc-bbox-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: A query against a Collection SHALL support a parameter bbox with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: bbox |
A.5.3. Requirement /req/core/rc-bbox-response Parameter bbox response
| Identifier | /req/core/rc-bbox-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: if the bbox parameter is provided, only features that have a spatial geometry that intersects the bounding box SHALL be part of the result set. |
| Statement | B: If a feature has multiple spatial geometry properties, server logic SHALL determine whether only a single spatial geometry property is used to determine the extent or all relevant geometries. |
| Statement | C: The bbox parameter SHALL match all features in the collection that are not associated with a spatial geometry. |
| Statement | D: The bounding box is provided as four or six numbers, depending on whether the coordinate reference system includes a vertical axis (height or depth):
|
| Statement | E: The bounding box SHALL consist of four or six numbers. The number, depending on whether the coordinate reference system includes a vertical axis (height or depth). The coordinate reference system of the values SHALL be interpreted as the coordinate reference system that is specified in a parameter crs. |
| Statement | F: If the crs query parameter is not defined, the bounding box SHALL consist of four or six numbers. The number depends on whether the coordinate reference system includes a vertical axis (height or depth). The coordinate reference system of the values SHALL be interpreted as the default coordinate reference system specified for the query type. |
| Statement | G: If the crs query parameter is not defined and a default crs is not defined for the query, the bounding box SHALL consist of four numbers and the coordinate reference system of the values SHALL be in the CRS defined by the spatial element of the extent section in the collection response. |
| Statement | H: The coordinate values SHALL be within the extent specified for the coordinate reference system. |
A.5.4. Requirement /req/edr/rc-bbox-definition-cube Parameter bbox definition
| Identifier | /req/edr/rc-bbox-definition-cube |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: The operation SHALL support a parameter bbox with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: bbox |
A.5.5. Requirement /req/edr/rc-bbox-response-cube Parameter bbox response
| Identifier | /req/edr/rc-bbox-response-cube |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the bbox parameter is provided, only features that have a spatial geometry that intersects the bounding box SHALL be part of the result set. |
| Statement | B: If a feature has multiple spatial geometry properties, server logic SHALL determine whether only a single spatial geometry property is used to determine the extent or all relevant geometries. |
| Statement | C: The bbox parameter SHALL match all features in the collection that are not associated with a spatial geometry. |
| Statement | D: The bounding box is provided as four or six numbers, depending on whether the coordinate reference system includes a vertical axis (height or depth):
|
| Statement | E: The bounding box SHALL consist of four or six numbers. The number depends on whether the coordinate reference system includes a vertical axis (height or depth). The coordinate reference system of the values SHALL be interpreted as the coordinate reference system that is specified in a parameter crs. |
| Statement | F: If the crs query parameter is not defined, the bounding box SHALL consist of four or six numbers. The number depends on whether the coordinate reference system includes a vertical axis (height or depth). The coordinate reference system of the values SHALL be interpreted as the default coordinate reference system specified for the query type. |
| Statement | G: If the crs query parameter is not defined and a default crs is not defined for the query, the bounding box SHALL consist of four numbers. The coordinate reference system of the values SHALL be in the CRS defined by the spatial element of the extent section in the collection response. |
| Statement | H: The coordinate values SHALL be within the extent specified for the coordinate reference system. |
A.5.6. Requirement /req/edr/coords-definition Parameter coords definition
| Identifier | /req/edr/coords-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each geometry based resource (Position, Radius, Area, Trajectory, Corridor) collection operation SHALL support a parameter coords with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: coords |
| Statement | B: The coords string value SHALL be a Well Known Text representation of geometry as defined in Simple Feature Access — Part 1: Common Architecture. The representation type will depend on the queryType of the API |
A.5.7. Requirement /req/edr/point-coords-response Parameter coords response
| Identifier | /req/edr/point-coords-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Only those resources that are representative of the requested geometry that is defined by the coords parameter SHALL be part of the result set. |
| Statement | B: The coordinates SHALL consist of a Well Known Text (WKT) POINT or (if supported by the collection) MULTIPOINT geometry string. |
| Statement | C: If an unsupported Well Known Text (WKT) geometry is requested a 400 error SHOULD be returned. |
| Statement | D: The coordinate reference system of the values SHALL be interpreted as WGS84 with axis order longitude/latitude. GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84", 6378137, 298.257223563, AUTHORITY["EPSG", "7030"]], unless a different coordinate reference system is specified in a parameter crs. |
A.5.8. Requirement /req/edr/polygon-coords-response Parameter coords response
| Identifier | /req/edr/polygon-coords-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Only those resources that are representative of the requested geometry that is defined by the coords parameter SHALL be part of the result set. |
| Statement | B: The coordinates SHALL consist of a Well Known Text (WKT) POLYGON or (if supported by the collection) MULTIPOLYGON geometry string. |
| Statement | C: If an unsupported Well Known Text (WKT) geometry is requested a 400 error SHOULD be returned. |
| Statement | D: The coordinate reference system of the values SHALL be interpreted as WGS84 with axis order longitude/latitude GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84", 6378137, 298.257223563, AUTHORITY["EPSG", "7030"]], unless a different coordinate reference system is specified in a parameter crs. |
A.5.9. Requirement /req/edr/linestring-coords-response Parameter coords response
| Identifier | /req/edr/linestring-coords-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Only those resources that are representative of the requested geometry that is defined by the coords parameter SHALL be part of the result set. |
| Statement | B: The coordinates SHALL consist of a Well Known Text (WKT) LINESTRING or (if supported by the collection) MULTILINESTRING geometry string. |
| Statement | C: If an unsupported Well Known Text (WKT) geometry is requested a 400 error SHOULD be returned. |
| Statement | D: The coordinate reference system of the values SHALL be interpreted as WGS84 with axis order longitude/latitude GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84", 6378137, 298.257223563, AUTHORITY["EPSG", "7030"]], unless a different coordinate reference system is specified in a parameter crs. |
A.5.10. Requirement /req/core/datetime-definition datetime definition
| Identifier | /req/core/datetime-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: The datetime parameter SHALL have the following characteristics (using an OpenAPI Specification 3.0 fragment): name: datetime |
A.5.11. Requirement /req/core/datetime-response datetime response
| Identifier | /req/core/datetime-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the datetime parameter is provided, only resources that have a temporal geometry that intersects the temporal information in the datetime parameter SHALL be part of the result set. |
| Statement | B: If a resource has multiple temporal properties, the API service implementation decides whether only a single temporal property is used to determine the extent or all relevant temporal properties. |
| Statement | C: The datetime parameter SHALL match all resources in the collection that are not associated with a temporal geometry. |
| Statement | D: The temporal information is either a date-time or a time interval. The parameter value SHALL conform to the following syntax (using ABNF): interval-closed = date-time "/" date-time |
| Statement | E: The syntax of date-time is specified by RFC 3339, 5.6. |
| Statement | F: Open ranges in time intervals at the start or end SHALL be supported using a double-dot (..). |
A.5.12. Requirement /req/edr/REQ_rc-parameter-name-definition Parameter parameter-name definition
| Identifier | /req/edr/REQ_rc-parameter-name-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation SHALL support a parameter parameter-name with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: parameter-name |
A.5.13. Requirement /req/edr/parameter-name-response Parameter parameter-name response
| Identifier | /req/edr/parameter-name-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the parameter-name parameter is provided, only those parameters listed SHALL be returned. If the parameter-name parameter is not specified all parameters in the collection SHALL be returned. |
| Statement | B: The parameter-name parameter SHALL consist of a comma delimited string value based on an enumerated list of options listed in the collections metadata. |
A.5.14. Requirement /req/edr/REQ_rc-crs-definition Parameter crs definition
| Identifier | /req/edr/REQ_rc-crs-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation SHALL support a parameter crs with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: crs |
A.5.15. Requirement /req/edr/REQ_rc-crs-response Parameter crs response
| Identifier | /req/edr/REQ_rc-crs-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the crs parameter is provided, the returned information SHOULD be reprojected by the server (if required) to the defined coordinate system. If the crs parameter is not specified, the data SHALL be returned in the coordinate reference system defined by the spatial element of the extent section of the collection. |
| Statement | B: The crs parameter SHALL consist of an identifier selected from the enumerated list of valid values supplied in the collections metadata. |
| Statement | C: If an unsupported crs value is requested a 400 error message SHOULD be returned. |
A.5.16. Requirement /req/edr/rc-f-definition Parameter f definition
| Identifier | /req/edr/rc-f-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation SHALL support a parameter f with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: f |
A.5.17. Requirement /req/edr/REQ_rc-f-response Parameter f response
| Identifier | /req/edr/REQ_rc-f-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the f parameter is provided, the returned information SHOULD be transformed to the defined data format. |
| Statement | B: The f parameter SHALL consist of a string value based on an enumerated list of available options provided in the collections metadata. |
| Statement | C: If f value is not defined the returned data SHOULD be in the default format specified by the default_output_format attribute of the collections metadata response. If a default_output_format attribute is not specified, the data return SHOULD be in the native format of the source datastore. |
| Statement | D: If an unsupported f value is requested a 400 error message SHOULD be returned. |
A.5.18. Requirement /req/edr/z-definition Parameter z definition
| Identifier | /req/edr/z-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation MAY support a parameter z with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: z |
A.5.19. Requirement /req/edr/z-response Parameter z response
| Identifier | /req/edr/z-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the z parameter is provided and a vertical extent is not defined in a collection, the z value SHALL be ignored |
| Statement | B: If the z parameter is provided, only resources that have a vertical geometry intersecting the vertical information in the z parameter SHALL be part of the result set. |
| Statement | C: The z MAY be defined as a height range by specifying a min-level and max-level separated by a forward slash “/” |
| Statement | D: A list of z MAY be defined by specifying a comma delimited list of values level1, level2, level3 etc |
| Statement | E: An Arithmetic sequence using Recurring height intervals MAY be specified by Rnumber of intervals/min height/height interval |
| Statement | F: If the z parameter is not provided, the server SHOULD return data at all available vertical levels |
single-level = level
interval-closed = min-level "/" max-level
interval-open-start = "../" level
interval-open-end = level "/.."
level-list = level1 "," level2 "," level3
repeating-interval = "R"number of intervals "/" min-level "/" height to increment by
Single level at level 850
z=850
All data between levels 100 and 550
z=100/550
All data between the minimum level and 850
z=../850
All data between the 500 and the maximum level
z=500/..
Data at levels 10,80,100
z=10,80,200
Data at 20 levels at 50 unit intervals starting a level 100
z=R20/100/50
A.5.20. Requirement /req/edr/within-definition Parameter within definition
| Identifier | /req/edr/within-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation MAY support a parameter within with the following characteristics (using an OpenAPI Specification 3.0 fragment): |
| Statement | B: If the instance metadata does not provide within-units values the API implementation SHALL NOT support within queries: name: within |
A.5.21. Requirement /req/edr/REQ_rc-within-response Parameter within response
| Identifier | /req/edr/REQ_rc-within-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the within parameter is provided, all selected information within the specified radius SHALL be part of the result set. |
| Statement | B: If a within-units parameter is not provided, a 400 error SHALL be returned. |
A.5.22. Requirement /req/edr/within-units-definition Parameter within-units definition
| Identifier | /req/edr/within-units-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation MAY support a parameter within-units with the following characteristics (using an OpenAPI Specification 3.0 fragment): |
| Statement | B: A within-units value SHALL be one of the values defined in the instance metadata: name: within-units |
A.5.23. Requirement /req/edr/REQ_rc-within-units-response Parameter within-units response
| Identifier | /req/edr/REQ_rc-within-units-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: The within-units parameter SHALL define the distance units of the within query parameter value. |
A.5.24. Requirement /req/edr/resolution-x-definition Parameter resolution-x definition
| Identifier | /req/edr/resolution-x-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation MAY support a parameter resolution-x with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: resolution-x |
A.5.25. Requirement /req/edr/resolution-x-response Parameter resolution-x response
| Identifier | /req/edr/resolution-x-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the resolution-x parameter is provided, it denotes the number of positions to retrieve data for, along the path between (and including) the minimum and maximum x coordinates. Figure A.1 — interpolated corridor example |
| Statement | B: A resolution-x value of 0 SHALL return all available data at the stored resolution between (and including) the minimum and maximum x coordinates. Figure A.2 — native resolution corridor example |
| Statement | C: If resolution-x is not specified, the API implementation SHOULD return all available data at a resolution determined by the server, including the minimum and maximum coordinates. resolution-x = number of intervals + 1 D: If the specified resolution-x value is invalid the API implementation SHALL return a HTTP 400 error code with a message body which describes the range of valid resolution-x values. |
A.5.26. Requirement /req/edr/cube-z-response Parameter z response for cube queries
| Identifier | /req/edr/cube-z-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the z parameter is provided, only resources that have a vertical geometry intersecting the vertical information in the z parameter SHALL be part of the result set. |
| Statement | B: The z MAY be defined as a height range by specifying a min-level and max-level separated by a forward slash “/” |
| Statement | C: A list of z MAY be defined by specifying a comma delimited list of values level1, level2, level3 etc |
| Statement | D: An Arithmetic sequence using Recurring height intervals MAY be specified by Rnumber of intervals/min height/height interval |
| Statement | E: If the z parameter is not provided, the server SHOULD return data at all available vertical levels |
A.5.27. Requirement /req/edr/resolution-y-definition Parameter resolution-y definition
| Identifier | /req/edr/resolution-y-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation MAY support a parameter resolution-y with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: resolution-y |
A.5.28. Requirement /req/edr/resolution-y-response Parameter resolution-y response
| Identifier | /req/edr/resolution-y-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the resolution-y parameter is provided, it denotes the number of intervals to retrieve data for along the path between the minimum and maximum y coordinates |
| Statement | B: The total number of intervals SHALL include the values for the minimum and maximum coordinates |
| Statement | C: A resolution-y value of 0 SHALL return all available data at the native y resolution between the minimum and maximum coordinates |
| Statement | D: If resolution-y is not specified, data SHOULD be returned for just the locations specified in the requested coordinates (ONLY IF interpolation is supported by the API server implementation) resolution-y = number of intervals E: If the specified resolution-y value is invalid the API implementation SHALL return a HTTP 400 error code with a message body which describes the range of valid resolution-y values. |
A.5.29. Requirement /req/edr/resolution-z-definition Parameter resolution-z definition
| Identifier | /req/edr/resolution-z-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation MAY support a parameter resolution-z with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: resolution-z |
A.5.30. Requirement /req/edr/resolution-z-response Parameter resolution-z response
| Identifier | /req/edr/resolution-z-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the resolution-z parameter is provided, it denotes the number of positions to retrieve data for, over the depth of the corridor path including its minimum and maximum width coordinates. Figure A.3 — interpolated corridor example |
| Statement | B: A resolution-z value of 0 SHALL return all available data at the stored vertical resolution between (and including) the minimum and maximum coordinates of the defined corridor. Figure A.4 — native resolution corridor example |
| Statement | C: If resolution-z is not specified the API implementation SHOULD return all available data at a resolution determined by the server, including the minimum and maximum coordinates of the defined corridor. resolution-z = number of intervals + 1 D: If the specified resolution-z value is invalid the API implementation SHALL return a HTTP 400 error code with a message body which describes the range of valid resolution-z values. |
A.5.31. Requirement /req/edr/REQ_rc-corridor-height-definition Parameter corridor-height definition
| Identifier | /req/edr/REQ_rc-corridor-height-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation SHALL support a parameter corridor-height with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: corridor-height |
A.5.32. Requirement /req/edr/REQ_rc-corridor-height-response Parameter corridor-height response
| Identifier | /req/edr/REQ_rc-corridor-height-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the corridor-height parameter is defined, the result set SHALL contain values derived from the implemented interpolation algorithm at the number of specified intervals. corridor-height = height |
| Statement | B: The height of the corridor parameter SHALL be the total height of the required corridor. |
| Statement | C: The coordinates of the coords parameter SHALL define the center point of the corridor. |
| Statement | D: If an unsupported units value is requested, an HTTP 400 error SHOULD be returned. |
A.5.33. Requirement /req/edr/REQ_rc-height-units-definition Parameter height-units definition
| Identifier | /req/edr/REQ_rc-height-units-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each corridor resource collection operation SHALL support a parameter height-units with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: height-units |
A.5.34. Requirement /req/edr/height-units-response Parameter height-units response
| Identifier | /req/edr/height-units-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the height-units parameter is defined the result set SHALL contain values derived based on the chosen units. height-units = units |
| Statement | B: If an unsupported units value is requested, an HTTP 400 error SHOULD be returned. |
A.5.35. Requirement /req/edr/corridor-width-definition Parameter corridor-width definition
| Identifier | /req/edr/corridor-width-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation SHALL support a parameter corridor-width with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: corridor-width |
A.5.36. Requirement /req/edr/REQ_rc-corridor-width-response Parameter corridor-width response
| Identifier | /req/edr/REQ_rc-corridor-width-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: The corridor-width information SHALL be the total width of the required corridor. |
| Statement | B: The supported corridor-width width units SHALL be supplied by the query metadata information. corridor-width = width |
| Statement | C: If the width value SHALL be the total width of the corridor. |
| Statement | D: The coordinates of the coords parameter SHALL define the center point of the corridor. |
| Statement | E: If an unsupported units value is requested, an HTTP 400 error SHOULD be returned. |
A.5.37. Requirement /req/edr/REQ_rc-width-units-definition Parameter width-units definition
| Identifier | /req/edr/REQ_rc-width-units-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each corridor resource collection operation SHALL support a parameter width-units with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: width-units |
A.5.38. Requirement /req/edr/width-units-response Parameter width-units response
| Identifier | /req/edr/width-units-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If the width-units parameter is defined the result set SHALL contain values derived based on the chosen units. width-units = units |
| Statement | B: If an unsupported units value is requested a 400 error SHOULD be returned. |
A.5.39. Requirement /req/edr/rc-custom-dimension-definition Custom Parameter definition
| Identifier | /req/edr/rc-custom-dimension-definition |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: Each resource collection operation MAY support custom parameters with the following characteristics (using an OpenAPI Specification 3.0 fragment): in: query |
A.5.40. Requirement /req/edr/custom-dimension-response Custom Parameter response
| Identifier | /req/edr/custom-dimension-response |
|---|---|
| Included in | Requirements class A.4: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/query_parameters |
| Statement | A: If a custom parameter is provided, only resources that have values that are valid for the range defined in the custom query parameter SHALL be part of the result set. |
| Statement | B: The custom query parameter MAY be defined as a value range by specifying a minimum value and maximum value separated by a forward slash “/” |
| Statement | C: A list of query values MAY be defined be specifying a comma delimited list of values value1, value2, value3 etc |
| Statement | D: An Arithmetic sequence using Recurring value intervals MAY be specified by an expression: Rnumber of intervals/minimum value/interval value |
| Statement | E: If a custom dimension is defined in the collections response but not included in the query request all valid values SHOULD be returned with no subsetting by the custom dimension. |
single-value = value
interval-closed = min-value "/" max-value
value-list = value1 "," value2 "," value3
repeating-interval = "R"number of intervals "/" min-value "/" value to increment by
A.5.41. Requirement /req/edr/REQ_rc-locationid-definition Parameter locationId definition
| Identifier | /req/edr/REQ_rc-locationid-definition |
|---|---|
| Statement | A: The locationId value SHALL be a comma delimited string list of locations that data is being requested for. B: Each resource locations operation SHALL support a parameter locationId with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: locationId |
A.5.42. Requirement /req/edr/REQ_rc-locationid-response Parameter locationid response
| Identifier | /req/edr/REQ_rc-locationid-response |
|---|---|
| Statement | A: If the collection supports multiple locations the locationId parameter SHALL be a comma delimited string. Each delimited value representing a unique location. |
| Statement | B: If the locationId parameter is provided only data for locations matching the requested identifers SHOULD be returned. |
| Statement | C: If there is no data available for the requested location identifiers a HTTP 204 response SHOULD be returned |
A.5.43. Requirement /req/edr/rc-limit-definition Parameter limit definition
| Identifier | /req/edr/rc-limit-definition |
|---|---|
| Statement | A: The operation SHALL support a parameter limit with the following characteristics (using an OpenAPI Specification 3.0 fragment): name: limit |
A.5.44. Requirement /req/edr/REQ_rc-limit-response Parameter limit response
| Identifier | /req/edr/REQ_rc-limit-response |
|---|---|
| Statement | A: The response SHALL not contain more features than specified by the optional limit parameter. |
| Statement | B: If the API definition specifies a maximum value for limit parameter, the response SHALL not contain more features than this maximum value. |
| Statement | C: If the value of the limit parameter is larger than the maximum value, this SHALL NOT result in an error (instead use the maximum as the parameter value). |
| Statement | D: Only items are counted that are on the first level of the collection. Any nested objects contained within the explicitly requested items SHALL not be counted. |
A.6. Requirements Class “JSON” in Detail
A.6.1. Requirements Class: JSON
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/json |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-1/1.0/req/json |
| Normative statements | Requirement A.81: /req/json/content Requirement A.82: /req/json/definition |
| Identifier | /req/json/content |
|---|---|
| Included in | Requirements class A.5: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/json |
| Statement | A: Every 200-response with the media type application/json SHALL be a payload encoded according to the JSON Interchange Format. |
| Statement | B: The links specified in the requirements /req/core/rc-collection-info-links and /req/core/rc-collection-info-links MAY be added in an extension property (foreign member) with the name links. |
| Statement | C: The parameters specified in the requirements /req/edr/rc-parameters MAY be added in an extension property (foreign member) with the name parameters. |
| Statement | D: The schema of all responses with the media type application/json SHALL conform with the JSON Schema specified for the resource in the Core requirements class. |
| Identifier | /req/json/definition |
|---|---|
| Included in | Requirements class A.5: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/json |
| Statement | A: 200-responses of the server SHALL support the following media types:
|
A.7. Requirements Class “GeoJSON” in Detail
A.7.1. Requirements Class: GeoJSON
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/geojson |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statements | Requirement A.83: /req/geojson/content Requirement A.84: /req/geojson/definition |
| Identifier | /req/geojson/content |
|---|---|
| Included in | Requirements class A.6: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/geojson |
| Statement | A: Every 200-response with the media type application/geo+json SHALL be
|
| Statement | B: The links specified in the requirements /req/core/rc-collection-info-links and /req/core/rc-collection-info-links SHALL be added in an extension property (foreign member) with the name links. |
| Statement | C: The parameters specified in the requirements /req/edr/rc-parameters MAY be added in an extension property (foreign member) with the name parameters. |
| Statement | D: The schema of all responses with the media type application/json SHALL conform with the JSON Schema specified for the resource in the Core requirements class. |
| Identifier | /req/geojson/definition |
|---|---|
| Included in | Requirements class A.6: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/geojson |
| Statement | A: 200-responses of the server SHALL support the following media types:
|
A.8. Requirements Class “EDR GeoJSON” in Detail
A.8.1. Requirements Class: EDR GeoJSON
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/edr-geojson |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statements | Requirement A.85: /req/edr-geojson/content Requirement A.86: /req/edr-geojson/definition |
A.8.2. Requirement /req/edr-geojson/content
| Identifier | /req/edr-geojson/content |
|---|---|
| Included in | Requirements class A.7: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/edr-geojson |
| Statement | A: Every 200-response with the media type application/geo+json SHALL be
|
| Statement | B: The links specified in the requirements /req/core/rc-collection-info-links and /req/core/rc-collection-info-links SHALL be added in an extension property (foreign member) with the name links. |
| Statement | C: The parameters specified in the requirements /req/edr/rc-parameters MAY be added in an extension property (foreign member) with the name parameters. |
| Statement | D: The schema of all responses with the media type application/json SHALL conform with the JSON Schema specified for the resource in the Core requirements class. |
| Identifier | /req/edr-geojson/definition |
|---|---|
| Included in | Requirements class A.7: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/edr-geojson |
| Statement | A: 200-responses of the server SHALL support the following media types:
|
A.9. Requirements Class “CoverageJSON” in Detail
A.9.1. Requirements Class: CoverageJSON
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/covjson |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statements | Requirement A.87: /req/covjson/content Requirement A.88: /req/covjson/definition |
| Identifier | /req/covjson/content |
|---|---|
| Included in | Requirements class A.8: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/covjson |
| Statement | A: Every 200-response with the media type application/prs.coverage+json SHALL be |
| Statement | B: The schema of all responses with the media type application/vnd.cov+json SHALL conform with the JSON Schema specified for the resource in the Core requirements class. |
| Identifier | /req/covjson/definition |
|---|---|
| Included in | Requirements class A.8: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/covjson |
| Statement | A: 200-responses of the server SHALL support the following media types:
|
A.10. Requirements Class “HTML” in Detail
A.10.1. Requirements Class: HTML
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/html |
|---|---|
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statements | Requirement A.89: /req/html/content Requirement A.90: /req/html/definition |
| Identifier | /req/html/content |
|---|---|
| Included in | Requirements class A.9: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/html |
| Statement | A: Every 200-response of the server with the media type text/html SHALL be a HTML 5 document that includes the following information in the HTML body:
|
| Identifier | /req/html/definition |
|---|---|
| Included in | Requirements class A.9: https://www.opengis.net/spec/ogcapi-edr-1/1.2/req/html |
| Statement | A: Every 200-response of an operation of the server SHALL support the media type text/html. |
Annex B
(normative)
Abstract Test Suite (Normative)
B.1. Introduction
The Abstract Test Suite (ATS) is a compendium of test assertions applicable to implementations of the EDR API Standard. An ATS provides a basis for developing an Executable Test Suite to verify that the implementation being tested conforms to all the relevant functional Requirements. Recommendations and Permissions are not normally tested.
The abstract test cases (assertions) are organized into test groups that correspond one-to-one to distinct conformance test classes defined in the EDR API Standard.
OGC APIs are not Web Services in the traditional sense. Rather, they define the behavior and content of a set of Resources exposed through a Web Application Programming Interface (Web API). Therefore, an API may expose resources in addition to those defined by the standard. A test engine SHALL be able to traverse the API, identify and validate test points, and SHOULD ignore resource paths which are not to be tested.
B.2. Conformance Class Core
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core |
|---|---|
| Subject | |
| Prerequisite | https://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core |
| Target Type | Web API |
| Conformance tests | Abstract test B.1: /conf/core/http Abstract test B.2: /conf/core/root-op Abstract test B.3: /conf/core/root-success Abstract test B.4: /conf/core/api-definition Abstract test B.5: /conf/core/api-definition-success Abstract test B.6: /conf/core/conformance Abstract test B.7: /conf/core/conformance-success |
B.2.1. General Tests
B.2.1.1. HTTP
| Identifier | /conf/core/http |
|---|---|
| Requirement | Requirement A.5: /req/core/http |
| Test purpose | Validate that the resource paths advertised through the API conform with HTTP 1.1 and, where appropriate, TLS. |
| Test method |
|
B.2.2. Landing Page {root}/
| Identifier | /conf/core/root-op |
|---|---|
| Requirement | Requirement A.1: /req/core/root-op |
| Test purpose | Validate that a landing page can be retrieved from the expected location. |
| Test method |
|
| Identifier | /conf/core/root-success |
|---|---|
| Requirement | Requirement A.2: /req/core/root-success |
| Test purpose | Validate that the landing page complies with the required structure and contents. |
| Test method | Validate the landing page for all supported media types using the resources and tests identified in Table B.1 For formats that require manual inspection, perform the following:
|
The landing page may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the landing page against that schema. All supported formats should be exercised.
| Format | Schema Document | Test ID |
|---|---|---|
| HTML | landingPage.yaml | /conf/html/content |
| JSON | landingPage.yaml | /conf/geojson/content |
B.2.3. API Definition Path {root}/{api} (link)
| Identifier | /conf/core/api-definition |
|---|---|
| Requirement | Requirement A.1-3: /req/core/api-definition-op |
| Test purpose | Validate that the API Definition document can be retrieved from the expected location. |
| Test method |
|
| Identifier | /conf/core/api-definition-success |
|---|---|
| Requirement | Requirement A.1-4: /req/core/api-definition-success |
| Test purpose | Validate that the API Definition complies with the required structure and contents. |
| Test method | Validate the API Definition document against an appropriate schema document. |
B.2.4. Conformance Path {root}/conformance
| Identifier | /conf/core/conformance |
|---|---|
| Requirement | Requirement A.3: /req/core/conformance |
| Test purpose | Validate that a Conformance Declaration can be retrieved from the expected location. |
| Test method |
|
| Identifier | /conf/core/conformance-success |
|---|---|
| Requirement | Requirement A.4: /req/core/conformance-success |
| Test purpose | Validate that the Conformance Declaration response complies with the required structure and contents. |
| Test method |
|
B.3. Conformance Class Collections
B.3.1. General Tests
B.3.1.1. CRS
| Identifier | /conf/core/crs |
|---|---|
| Requirement | Requirement A.6: /req/core/crs |
| Test purpose | Validate that all spatial geometries provided through the API are in the data’s original coordinate reference system unless otherwise requested by the client. |
| Test method |
|
B.3.2. Environmental Data Collections {root}/collections
| Identifier | /conf/collections/rc-md-op |
|---|---|
| Requirement | Requirement A.7: /req/collections/rc-md-op |
| Test purpose | Validate that information about the Collections can be retrieved from the expected location. |
| Test method |
|
| Identifier | /conf/rc-md-success |
|---|---|
| Requirement | Requirement A.8: /req/collections/rc-md-success |
| Test purpose | Validate that the Collections content complies with the required structure and contents. |
| Test method |
|
The Collections content may be retrieved in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the against that schema. All supported formats should be exercised.
| Format | Schema Document | Test ID |
|---|---|---|
| HTML | collections.yaml | /conf/html/content |
| JSON | collections.yaml | /conf/geojson/content |
B.3.3. Environmental Data Collection {root}/collections/{collectionId}
| Identifier | /conf/collections/src-md-op |
|---|---|
| Requirement | Requirement A.9: /req/collections/src-md-op |
| Test purpose | Validate that the Collection content can be retrieved from the expected location. |
| Test method | For every collection described in the Collections content, issue an HTTP GET request to the URL /collections/{collectionId} where {collectionId} is the id property for the collection.
|
| Identifier | /conf/collections/src-md-success |
|---|---|
| Requirement | Requirement A.10: /req/collections/src-md-success |
| Test purpose | Validate that the Collection content complies with the required structure and contents. |
| Test method | Verify that the content of the response is consistent with the content for this Resource Collection in the /collections response. That is, the values for id, title, description and extent are identical. |
B.3.4. Second Tier Collections Tests
These tests are invoked by other tests.
B.3.4.1. Collection Extent
| Identifier | /conf/core/rc-extent |
|---|---|
| Requirement | Requirement A.21: /req/core/rc-extent |
| Test purpose | Validate the extent property if it is present |
| Test method |
|
B.3.4.2. Collection Queries
| Identifier | /conf/edr/rc-collection-info |
|---|---|
| Requirement | Requirement A.11: /req/edr/rc-collection-info |
| Test purpose | Validate that each collection provided by the server is described in the Collections Metadata. |
| Test method |
|
The collection entries may be encoded in a number of different formats. The following table identifies the applicable schema document for each format and the test to be used to validate the against that schema. All supported formats should be exercised.
| Format | Schema Document | Test ID |
|---|---|---|
| HTML | collection.yaml | /conf/html/content |
| JSON | collection.yaml | /conf/json/content |
| Identifier | /conf/edr/rc-data-queries |
|---|---|
| Requirement | Requirement A.12: /req/edr/rc-data-queries |
| Test purpose | Validate that the data_queries section in the collection is correctly defined. |
| Test method |
|
| Identifier | /conf/edr/rc-common-query-type |
|---|---|
| Requirement | Requirement A.14: /req/edr/rc-common-query-type |
| Test purpose | Validate that the variables property for a query data type in the data_queries section in the collection is correctly defined. |
| Test method |
|
| Identifier | /conf/edr/rc-common-variables |
|---|---|
| Requirement | Requirement A.13: /req/edr/rc-common-variables |
| Test purpose | Validate variables property for a query data type in the data_queries section in the collection is correctly defined. |
| Test method |
|
| Identifier | /conf/edr/rc-radius-variables |
|---|---|
| Requirement | Requirement A.15: /req/edr/rc-radius-variables |
| Test purpose | Validate variables property for a query data type in the data_queries section in the collection is correctly defined. |
| Test method |
|
| Identifier | /conf/edr/rc-cube-variables |
|---|---|
| Requirement | Requirement A.16: /req/edr/rc-cube-variables |
| Test purpose | Validate variables property for a query data type in the data_queries section in the collection is correctly defined. |
| Test method |
|
| Identifier | /conf/edr/rc-corridor-variables |
|---|---|
| Requirement | Requirement A.17: /req/edr/rc-corridor-variables |
| Test purpose | Validate that the variables property for a query data type in the data_queries section in the collection is correctly defined. |
| Test method |
|
| Identifier | /conf/edr/rc-locations-variables |
|---|---|
| Requirement | Requirement A.18: /req/edr/rc-locations-variables |
| Test purpose | Validate variables property for a query data type in the data_queries section in the collection is correctly defined. |
| Test method |
|
| Identifier | /conf/edr/rc-items-variables |
|---|---|
| Requirement | Requirement A.19: /req/edr/rc-items-variables |
| Test purpose | Validate variables property for a query data type in the data_queries section in the collection is correctly defined. |
| Test method | Verify that the variables object has a query_type property
|
| Identifier | /conf/edr/rc-md-query-links |
|---|---|
| Requirement | Requirement A.22: /req/core/rc-md-query-links |
| Test purpose | Validate that each Collection metadata entry in the Collections Metadata document includes all required links. |
| Test method | Verify that all links include the rel and type link parameters. |
| Identifier | /conf/edr/rc-crs |
|---|---|
| Requirement | Requirement A.23: /req/edr/rc-crs |
| Test purpose | Validate that each collection provided by the server is described in the Collections Metadata. |
| Test method |
|
B.3.4.3. Collection Links
| Identifier | /conf/core/rc-collection-info-links |
|---|---|
| Requirement | Requirement A.20: /req/core/rc-collection-info-links |
| Test purpose | Validate that the required links are included in the Collections Metadata document. |
| Test method | Verify that the response document includes:
Verify that all links include the rel and type link parameters. |
B.3.4.4. Collection Parameters
| Identifier | /conf/edr/rc-parameters |
|---|---|
| Requirement | Requirement A.24: /req/edr/rc-parameters |
| Test purpose | Validate that each parameter in a collection is correctly defined. |
| Test method |
|
B.4. Conformance Class JSON
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/json |
|---|---|
| Subject | |
| Prerequisites | Conformance class B.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core https://www.opengis.net/spec/ogcapi-common-1/1.0/conf/json |
| Target Type | Web API |
| Conformance tests | Abstract test B.27: /conf/json/definition Abstract test B.28: /conf/json/content |
B.4.1. JSON Definition
| Identifier | /conf/json/definition |
|---|---|
| Requirement | Requirement A.82: /req/json/definition |
| Test purpose | Verify support for JSON |
| Test method |
|
B.4.2. JSON Content
| Identifier | /conf/json/content |
|---|---|
| Requirement | Requirement A.81: /req/json/content |
| Test purpose | Verify the content of a JSON document given an input document and schema. |
| Test method |
|
B.5. Conformance Class GeoJSON
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/geojson |
|---|---|
| Subject | |
| Prerequisite | Conformance class B.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core |
| Target Type | Web API |
| Conformance tests | Abstract test B.29: /conf/geojson/definition Abstract test B.30: /conf/geojson/content |
B.5.1. GeoJSON Definition
| Identifier | /conf/geojson/definition |
|---|---|
| Requirement | Requirement A.84: /req/geojson/definition |
| Test purpose | Verify support for JSON and GeoJSON |
| Test method |
|
B.5.2. GeoJSON Content
| Identifier | /conf/geojson/content |
|---|---|
| Requirement | Requirement A.83: /req/geojson/content |
| Test purpose | Verify the content of a GeoJSON document given an input document and schema. |
| Test method |
|
B.6. Conformance Class EDR GeoJSON
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/edr-geojson |
|---|---|
| Subject | |
| Prerequisite | Conformance class B.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core |
| Target Type | Web API |
| Conformance tests | Abstract test B.32: /conf/edr-geojson/content Abstract test B.31: /conf/edr-geojson/definition |
B.6.1. EDR GeoJSON Definition
| Identifier | /conf/edr-geojson/definition |
|---|---|
| Requirement | Requirement A.86: /req/edr-geojson/definition |
| Test purpose | Verify support for the EDR GeoJSON Schema |
| Test method |
|
B.6.2. EDR GeoJSON Content
| Identifier | /conf/edr-geojson/content |
|---|---|
| Requirement | Requirement A.85: /req/edr-geojson/content |
| Test purpose | Verify the content of an EDR GeoJSON document given an input document and schema. |
| Test method |
|
B.7. Conformance Class CoverageJSON
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/covjson |
|---|---|
| Subject | |
| Prerequisite | Conformance class B.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core |
| Target Type | Web API |
| Conformance tests | Abstract test B.34: /conf/covjson/content Abstract test B.33: /conf/covjson/definition |
B.7.1. CoverageJSON Definition
| Identifier | /conf/covjson/definition |
|---|---|
| Requirement | Requirement A.88: /req/covjson/definition |
| Test purpose | Verify support for CoverageJSON |
| Test method |
|
B.7.2. CoverageJSON Content
| Identifier | /conf/covjson/content |
|---|---|
| Requirement | Requirement A.87: /req/covjson/content |
| Test purpose | Verify the content of a CoverageJSON document given an input document and schema. |
| Test method |
|
B.8. Conformance Class HTML
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/html |
|---|---|
| Subject | |
| Prerequisites | Conformance class B.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core https://www.opengis.net/spec/ogcapi-common-1/1.0/conf/html |
| Target Type | Web API |
| Conformance tests | Abstract test B.36: /conf/html/content Abstract test B.35: /conf/html/definition |
B.8.1. HTML Definition
| Identifier | /conf/html/definition |
|---|---|
| Requirement | Requirement A.90: /req/html/definition |
| Test purpose | Verify support for HTML test-method::Verify that every 200-response of every operation of the API where HTML was requested is of media type text/html |
B.8.2. HTML Content
| Identifier | /conf/html/content |
|---|---|
| Requirement | Requirement A.89: /req/html/content |
| Test purpose | Verify the content of an HTML document given an input document and schema. |
| Test method |
|
B.9. Conformance Class OpenAPI 3.0
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/oas30 |
|---|---|
| Subject | |
| Prerequisites | Conformance class B.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core https://www.opengis.net/spec/ogcapi-common-1/1.0/conf/oas30 |
| Target Type | Web API |
| Conformance tests | Abstract test B.37: /conf/oas30/completeness Abstract test B.38: /conf/oas30/exceptions-codes Abstract test B.39: /conf/oas30/oas-definition-1 Abstract test B.40: /conf/oas30/oas-definition-2 Abstract test B.41: /conf/oas30/oas-impl Abstract test B.42: /conf/oas30/security |
| Identifier | /conf/oas30/completeness |
|---|---|
| Requirement | Requirement 7: /req/oas/completeness |
| Test purpose | Verify the completeness of an OpenAPI document. |
| Test method | Verify that for each operation, the OpenAPI document describes all HTTP Status Codes and Response Objects that the API uses in responses. |
| Identifier | /conf/oas30/exceptions-codes |
|---|---|
| Requirement | Requirement 8: /req/oas/exceptions-codes |
| Test purpose | Verify that the OpenAPI document fully describes potential exception codes. |
| Test method | Verify that for each operation, the OpenAPI document describes all HTTP Status Codes that may be generated. |
| Identifier | /conf/oas30/oas-definition-1 |
|---|---|
| Requirement | Requirement 10: /req/oas30/oas-definition |
| Test purpose | Verify that JSON and HTML versions of the OpenAPI document are available. |
| Test method |
|
| Identifier | /conf/oas30/oas-definition-2 |
|---|---|
| Requirement | Requirement 10: /req/oas30/oas-definition |
| Test purpose | Verify that the OpenAPI document is valid JSON. |
| Test method | Verify that the JSON representation conforms to the OpenAPI Specification, version 3.0. |
| Identifier | /conf/oas30/oas-impl |
|---|---|
| Requirement | Requirement 6: /req/oas/oas-impl |
| Test purpose | Verify that all capabilities specified in the OpenAPI definition are implemented by the API. |
| Test method |
|
| Identifier | /conf/oas30/security |
|---|---|
| Requirement | Requirement 9: /req/oas/security |
| Test purpose | Verify that any authentication protocols implemented by the API are documented in the OpenAPI document. |
| Test method |
|
B.10. Conformance Class OpenAPI 3.1
| Identifier | https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/oas31 |
|---|---|
| Subject | |
| Prerequisite | Conformance class B.1: https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core |
| Target Type | Web API |
| Conformance tests | Abstract test B.43: /conf/oas31/completeness Abstract test B.44: /conf/oas31/exceptions-codes Abstract test B.45: /conf/oas31/oas-definition-1 Abstract test B.46: /conf/oas31/oas-definition-2 Abstract test B.47: /conf/oas31/oas-impl Abstract test B.48: /conf/oas31/security |
| Identifier | /conf/oas31/completeness |
|---|---|
| Requirement | Requirement 7: /req/oas/completeness |
| Test purpose | Verify the completeness of an OpenAPI document. |
| Test method | Verify that for each operation, the OpenAPI document describes all HTTP Status Codes and Response Objects that the API uses in responses. |
| Identifier | /conf/oas31/exceptions-codes |
|---|---|
| Requirement | Requirement 8: /req/oas/exceptions-codes |
| Test purpose | Verify that the OpenAPI document fully describes potential exception codes. |
| Test method | Verify that for each operation, the OpenAPI document describes all HTTP Status Codes that may be generated. |
| Identifier | /conf/oas31/oas-definition-1 |
|---|---|
| Requirement | Requirement 11: /req/oas31/oas-definition |
| Test purpose | Verify that JSON and HTML versions of the OpenAPI document are available. |
| Test method |
|
| Identifier | /conf/oas31/oas-definition-2 |
|---|---|
| Requirement | Requirement 11: /req/oas31/oas-definition |
| Test purpose | Verify that the OpenAPI document is valid JSON. |
| Test method | Verify that the JSON representation conforms to the OpenAPI Specification, version 3.1. |
| Identifier | /conf/oas31/oas-impl |
|---|---|
| Requirement | Requirement 6: /req/oas/oas-impl |
| Test purpose | Verify that all capabilities specified in the OpenAPI definition are implemented by the API. |
| Test method |
|
| Identifier | /conf/oas31/security |
|---|---|
| Requirement | Requirement 9: /req/oas/security |
| Test purpose | Verify that any authentication protocols implemented by the API are documented in the OpenAPI document. |
| Test method |
|
B.11. Conformance Class Queries
B.11.1. Query Pattern Tests
B.11.1.1. Core data query parameters
| Identifier | /conf/core-query-parameters/operation |
|---|---|
| Requirement | Requirement A.25: /req/edr/rc-core-query-parameters |
| Test purpose | Validate that the data query supports either a GET or POST operation. |
| Test method |
|
| Identifier | /conf/collections/REQ_rc-parameter-name-definition |
|---|---|
| Requirement | Requirement A.48: /req/edr/REQ_rc-parameter-name-definition |
| Test purpose | Validate that the parameter-name query parameters are constructed correctly. |
| Test method | Verify that the parameter-name query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: parameter-name |
| Identifier | /conf/edr/rc-parameter-name-response |
|---|---|
| Requirement | Requirement A.49: /req/edr/parameter-name-response |
| Test purpose | Validate that the parameter-name query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/core/datetime-definition |
|---|---|
| Requirement | Requirement A.46: /req/core/datetime-definition |
| Test purpose | Validate that the datetime query parameters are constructed correctly. |
| Test method | Verify that the datetime query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: datetime |
| Identifier | /conf/core/datetime-response |
|---|---|
| Requirement | Requirement A.47: /req/core/datetime-response |
| Test purpose | Validate that the datetime query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/rc-z-definition |
|---|---|
| Requirement | Requirement A.54: /req/edr/z-definition |
| Test purpose | Validate that the vertical level query parameters are constructed correctly. |
| Test method | Verify that the z query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: z |
| Identifier | /conf/edr/rc-z-response |
|---|---|
| Requirement | Requirement A.55: /req/edr/z-response |
| Test purpose | Validate that the vertical level query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/REQ_rc-crs-definition |
|---|---|
| Requirement | Requirement A.50: /req/edr/REQ_rc-crs-definition |
| Test purpose | Validate that the crs query parameters are constructed correctly. |
| Test method | Verify that the crs query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: crs |
| Identifier | /conf/edr/REQ_rc-crs-response |
|---|---|
| Requirement | Requirement A.51: /req/edr/REQ_rc-crs-response |
| Test purpose | Validate that the crs query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/rc-f-definition |
|---|---|
| Requirement | Requirement A.52: /req/edr/rc-f-definition |
| Test purpose | Validate that the f query parameter is constructed correctly. |
| Test method | Verify that the f query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: f |
| Identifier | /conf/collections/rc-f-response |
|---|---|
| Requirement | Requirement A.53: /req/edr/REQ_rc-f-response |
| Test purpose | Validate that the f query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/rc-custom-dimension-definition |
|---|---|
| Requirement | Requirement A.75: /req/edr/rc-custom-dimension-definition |
| Test purpose | Validate that any custom query parameters are constructed correctly. |
| Test method | Verify that any custom dimension query parameters comply with the following definition (using an OpenAPI Specification 3.1 fragment): in: query |
| Identifier | /conf/edr/rc-custom-dimension-response |
|---|---|
| Requirement | Requirement A.76: /req/edr/custom-dimension-response |
| Test purpose | Validate that the custom dimension parameters query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/core/rc-limit-definition |
|---|---|
| Requirement | Requirement A.79: /req/edr/rc-limit-definition |
| Test purpose | Validate that the limit query parameters are defined correctly. |
| Test method | Verify that the limit query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: limit Note that the API can define values for “minimum”, “maximum” and “default”. |
| Identifier | /conf/core/rc-limit-response |
|---|---|
| Requirement | Requirement A.80: /req/edr/REQ_rc-limit-response |
| Test purpose | Validate that the limit query parameters are evaluated correctly. |
| Test method |
|
B.11.1.2. Position
| Identifier | /conf/position/common-query-params |
|---|---|
| Requirement | Requirement A.26: /req/edr/rc-position |
| Test purpose | Validate that the Position query supports the core EDR query parameters. |
| Test method |
|
| Identifier | /conf/position/no-query-params |
|---|---|
| Requirement | Requirement A.26: /req/edr/rc-position |
| Test purpose | Validate that an error is returned by a Position query if no query parameters are specified. |
| Test method |
|
| Identifier | /conf/position/no-coords-param |
|---|---|
| Requirement | Requirement A.26: /req/edr/rc-position |
| Test purpose | Validate that an error is returned by a Position query when the coords query parameter is not specified. |
| Test method |
|
| Identifier | /conf/position/coords-param-invalid |
|---|---|
| Requirement | Requirement A.26: /req/edr/rc-position |
| Test purpose | Validate that an error is returned by a Position query when the coords query parameter does not contain a valid POINT or MULTIPOINT Well Known Text value. |
| Test method |
|
| Identifier | /conf/position/coords-and-z |
|---|---|
| Requirement | Requirement A.26: /req/edr/rc-position |
| Test purpose | Ensure that when the coords query parameter includes a z-coordinate and the z query parameter is also specified, the returned values are correct. |
| Test method |
|
| Identifier | /conf/position/valid-query-params |
|---|---|
| Requirement | Requirement A.26: /req/edr/rc-position |
| Test purpose | Validate that resources can be identified and extracted from a Collection with a Position query using query parameters. |
| Test method |
Repeat these tests using the following parameter tests: Coordinates
VerticalLevel
Parameters
DateTime
Execute requests with combinations of the coords,time,parameter-name,z,crs and f query parameters and verify that only information that matches the selection criteria is returned. |
B.11.1.3. Radius
| Identifier | /conf/radius/common-query-params |
|---|---|
| Requirement | /req/edr/rc-radius |
| Test purpose | Validate that the Radius query supports the core EDR query parameters. |
| Test method |
|
| Identifier | /conf/radius/no-query-params target::/req/edr/rc-radius |
|---|---|
| Test purpose | Validate that an error is returned by a radius query if no query parameters are specified. |
| Test method |
|
| Identifier | /conf/radius/no-coords-param target::/req/edr/rc-radius |
|---|---|
| Test purpose | Validate that an error is returned by a radius query when the coords query parameter is not specified. |
| Test method |
|
| Identifier | /conf/radius/coords-param-invalid target::/req/edr/rc-radius |
|---|---|
| Test purpose | Validate that an error is returned by a radius query when the coords query parameter does not contain a valid POINT or MULTIPOINT Well Known Text value. |
| Test method |
|
| Identifier | /conf/radius/coords-and-z |
|---|---|
| Requirement | /req/edr/rc-radius |
| Test purpose | Ensure that when the coords query parameter includes a z-coordinate and the z query parameter is also specified, the returned values are correct. |
| Test method |
|
| Identifier | /conf/radius/no-within-param target::/req/edr/rc-radius |
|---|---|
| Test purpose | Validate that an error is returned by a radius query when the within query parameter is not specified. |
| Test method |
|
| Identifier | /conf/radius/no-within_units-param target::/req/edr/rc-radius |
|---|---|
| Test purpose | Validate that an error is returned by a radius query when the within_units query parameter is not specified. |
| Test method |
|
| Identifier | /conf/radius/valid-query-params target::/req/edr/rc-radius |
|---|---|
| Test purpose | Validate that resources can be identified and extracted from a Collection with a radius query using query parameters. |
| Test method |
Repeat these tests using the following parameter tests: Coordinates
VerticalLevel
Custom dimensions
Parameters
DateTime
Execute requests with combinations of the coords,time,parameter-name,z,crs and f query parameters and verify that only information that matches the selection criteria is returned. |
| Identifier | /conf/edr/REQ_rc-within-definition |
|---|---|
| Requirement | Requirement A.56: /req/edr/within-definition |
| Test purpose | Validate that the within query parameter is constructed correctly. |
| Test method | Verify that the within query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: within |
| Identifier | /conf/collections/REQ_rc-within-response |
|---|---|
| Requirement | Requirement A.57: /req/edr/REQ_rc-within-response |
| Test purpose | Validate that the within query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/REQ_rc-within-units-definition |
|---|---|
| Requirement | Requirement A.58: /req/edr/within-units-definition |
| Test purpose | Validate that the within-units query parameter is constructed correctly. |
| Test method | Verify that the within-units query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: within-units |
| Identifier | /conf/collections/REQ_rc-within-units-response |
|---|---|
| Requirement | Requirement A.59: /req/edr/REQ_rc-within-units-response |
| Test purpose | Validate that the width-units query parameters are processed correctly |
| Test method |
|
B.11.1.4. Area
| Identifier | /conf/area/common-query-params |
|---|---|
| Requirement | Requirement A.27: /req/edr/rc-area |
| Test purpose | Validate that the Area query supports the core EDR query parameters. |
| Test method |
|
| Identifier | /conf/area/no-query-params |
|---|---|
| Requirement | Requirement A.27: /req/edr/rc-area |
| Test purpose | Validate that an error is returned by an Area query if no query parameters are specified. |
| Test method |
|
| Identifier | /conf/area/no-coords-param |
|---|---|
| Requirement | Requirement A.27: /req/edr/rc-area |
| Test purpose | Validate that an error is returned by an Area query when the coords query parameter is not specified. |
| Test method |
|
| Identifier | /conf/area/coords-param-invalid |
|---|---|
| Requirement | Requirement A.27: /req/edr/rc-area |
| Test purpose | Validate that an error is returned by an Area query when the coords query parameter does not contain a valid POLYGON or MULTIPOLYGON Well Known Text value. |
| Test method |
|
| Identifier | /conf/area/coords-and-z |
|---|---|
| Requirement | Requirement A.27: /req/edr/rc-area |
| Test purpose | Ensure that when the coords query parameter includes a z-coordinate and the z query parameter is also specified, the returned values are correct. |
| Test method |
|
| Identifier | /conf/area/valid-query-params |
|---|---|
| Requirement | Requirement A.27: /req/edr/rc-area |
| Test purpose | Validate that resources can be identified and extracted from a Collection with an Area query using query parameters. |
| Test method |
Repeat these tests using the following parameter tests: Coordinates
VerticalLevel
Custom dimensions
Parameters
DateTime
CRS
Execute requests with combinations of the coords,time,parameter-name,z,crs and f query parameters and verify that only information that matches the selection criteria is returned. |
B.11.1.5. Cube
| Identifier | /conf/cube/common-query-params |
|---|---|
| Requirement | Requirement A.28: /req/edr/rc-cube |
| Test purpose | Validate that the Cube query supports the core EDR query parameters. |
| Test method |
|
| Identifier | /conf/cube/no-query-params |
|---|---|
| Requirement | Requirement A.28: /req/edr/rc-cube |
| Test purpose | Validate that an error is returned by a Cube query if no query parameters are specified. |
| Test method |
|
| Identifier | /conf/cube/no-bbox-param |
|---|---|
| Requirement | Requirement A.28: /req/edr/rc-cube |
| Test purpose | Validate that an error is returned by a Cube query when the bbox query parameter is not specified. |
| Test method |
|
| Identifier | /conf/cube/bbox-param-invalid |
|---|---|
| Requirement | Requirement A.28: /req/edr/rc-cube |
| Test purpose | Validate that an error is returned by a Cube query when the bbox query parameter does not contain a valid bbox value. |
| Test method |
|
| Identifier | /conf/cube/valid-query-params |
|---|---|
| Requirement | Requirement A.28: /req/edr/rc-cube |
| Test purpose | Validate that resources can be identified and extracted from a Collection with a Cube query using query parameters. |
| Test method |
Repeat these tests using the following parameter tests: bbox
VerticalLevel
Custom dimensions
Parameters
DateTime
Execute requests with combinations of the bbox,time,parameter-name,z,crs and f query parameters and verify that only information that matches the selection criteria is returned. |
| Identifier | /conf/core/rc-bbox-definition-cube |
|---|---|
| Requirement | Requirement A.40: /req/edr/rc-bbox-definition-cube |
| Test purpose | Validate that the bounding box query parameters are constructed correctly. |
| Test method | Verify that the bbox query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment). name: bbox |
| Identifier | /conf/core/rc-bbox-response-cube |
|---|---|
| Requirement | Requirement A.41: /req/edr/rc-bbox-response-cube |
| Test purpose | Validate that the bounding box query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/core/rc-resolution-x-definition-cube |
|---|---|
| Requirement | Requirement A.60: /req/edr/resolution-x-definition |
| Test purpose | Validate that the resolution-x query parameters are constructed correctly. |
| Test method | Verify that the resolution-x query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment). name: resolution-x |
| Identifier | /conf/core/rc-resolution-x-response-cube |
|---|---|
| Requirement | Requirement A.61: /req/edr/resolution-x-response |
| Test purpose | Validate that the resolution-x query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/core/rc-resolution-y-definition-cube |
|---|---|
| Requirement | Requirement A.63: /req/edr/resolution-y-definition |
| Test purpose | Validate that the resolution-y query parameters are constructed correctly. |
| Test method | Verify that the resolution-y query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment). name: resolution-y |
| Identifier | /conf/core/rc-resolution-y-response-cube |
|---|---|
| Requirement | Requirement A.64: /req/edr/resolution-y-response |
| Test purpose | Validate that the resolution-y query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/core/rc-resolution-z-definition-cube |
|---|---|
| Requirement | Requirement A.65: /req/edr/resolution-z-definition |
| Test purpose | Validate that the resolution-z query parameters are constructed correctly. |
| Test method | Verify that the resolution-z query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment). name: resolution-z |
| Identifier | /conf/core/rc-resolution-z-response-cube |
|---|---|
| Requirement | Requirement A.66: /req/edr/resolution-z-response |
| Test purpose | Validate that the resolution-z query parameters are processed correctly. |
| Test method |
|
B.11.1.6. Trajectory
| Identifier | /conf/trajectory/common-query-params |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that the Trajectory query supports the core EDR query parameters. |
| Test method |
|
| Identifier | /conf/trajectory/no-query-params |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that an error is returned by a Trajectory query if no query parameters are specified. |
| Test method |
|
| Identifier | /conf/trajectory/no-coords-param |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that an error is returned by a Trajectory query when the coords query parameter is not specified. |
| Test method |
|
| Identifier | /conf/trajectory/coords-param-invalid-linestring |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that an error is returned by a Trajectory query when the coords query parameter does not contain a valid LINESTRING or MULTILINESTRING Well Known Text value. |
| Test method |
|
| Identifier | /conf/trajectory/coords-param-invalid-linestringm |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that an error is returned by a Trajectory query when the coords query parameter does not contain a valid LINESTRINGM or MULTILINESTRINGM Well Known Text value. |
| Test method |
|
| Identifier | /conf/trajectory/coords-param-separate-z-linestringz |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that an error is returned by a Trajectory query when the coords query parameter is a LINESTRINGZ or MULTILINESTRINGZ coordinate and the z query parameter is specified |
| Test method |
|
| Identifier | /conf/trajectory/coords-param-separate-z-linestringzm |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that an error is returned by a Trajectory query when the coords query parameter is a LINESTRINGZM or MULTILINESTRINGZM coordinate and the z query parameter is specified |
| Test method |
|
| Identifier | /conf/trajectory/coords-param-invalid-linestringzm |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that an error is returned by a Trajectory query when the coords query parameter does not contain a valid LINESTRINGZM or MULTILINESTRINGZM Well Known Text value. |
| Test method |
|
| Identifier | /conf/trajectory/coords-param-invalid-linestringz |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that an error is returned by a Trajectory query when the coords query parameter does not contain a valid LINESTRINGZ or MULTILINESTRINGZ Well Known Text value. |
| Test method |
|
| Identifier | /conf/trajectory/coords-param-invalid-time |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that an error is returned by a Trajectory query when the coords query parameter contains invalid time coordinates |
| Test method |
|
| Identifier | /conf/trajectory/valid-query-params |
|---|---|
| Requirement | Requirement A.29: /req/edr/rc-trajectory |
| Test purpose | Validate that resources can be identified and extracted from a Collection with a Trajectory query using query parameters. |
| Test method |
Repeat these tests using the following parameter tests: Coordinates
VerticalLevel
Custom dimensions
Parameters
DateTime
Execute requests with combinations of the coords, parameter-name,z,crs and f query parameters and verify that only information that matches the selection criteria is returned. |
B.11.1.7. Corridor
| Identifier | /conf/corridor/common-query-params |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that the Corridor query supports the core EDR query parameters. |
| Test method |
|
| Identifier | /conf/corridor/no-query-params |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query if no query parameters are specified. |
| Test method |
|
| Identifier | /conf/corridor/no-coords-param |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the coords query parameter is not specified. |
| Test method |
|
| Identifier | /conf/corridor/corridor-width-param-missing |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the corridor-width query parameter is not specified. |
| Test method |
|
| Identifier | /conf/corridor/corridor-height-param-missing |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the corridor-height query parameter is not specified. |
| Test method |
|
| Identifier | /conf/corridor/width-units-param-missing |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the width-units query parameter is not specified. |
| Test method |
|
| Identifier | /conf/corridor/height-units-param-missing |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the height-units query parameter is not specified. |
| Test method |
|
| Identifier | /conf/corridor/coords-param-invalid-linestring |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the coords query parameter does not contain a valid LINESTRING or MULTILINESTRING Well Known Text value. |
| Test method |
|
| Identifier | /conf/corridor/coords-param-invalid-linestringm |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the coords query parameter does not contain a valid LINESTRINGM or MULTILINESTRINGM Well Known Text value. |
| Test method |
|
| Identifier | /conf/corridor/coords-param-separate-z-linestringz |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the coords query parameter is a LINESTRINGZ or MULTILINESTRINGZ coordinate and the z query parameter is specified |
| Test method |
|
| Identifier | /conf/corridor/coords-param-separate-z-linestringzm |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the coords query parameter is a valid LINESTRINGZM or MULTILINESTRINGZM coordinate and the z query parameter is specified |
| Test method |
|
| Identifier | /conf/corridor/coords-param-invalid-linestringzm |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the coords query parameter does not contain a valid LINESTRINGZM or MULTILINESTRINGZM Well Known Text value. |
| Test method |
|
| Identifier | /conf/corridor/coords-param-invalid-linestringz |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the coords query parameter does not contain a valid LINESTRINGZ or MULTILINESTRINGZ Well Known Text value. |
| Test method |
|
| Identifier | /conf/corridor/coords-param-invalid-time |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the coords query parameter contains invalid time coordinates |
| Test method |
|
| Identifier | /conf/corridor/width-units-param-invalid |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the width-units query parameter contains invalid units |
| Test method |
|
| Identifier | /conf/corridor/height-units-param-invalid |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that an error is returned by a corridor query when the height-units query parameter contains invalid units |
| Test method |
|
| Identifier | /conf/corridor/valid-query-params |
|---|---|
| Requirement | Requirement A.30: /req/edr/rc-corridor |
| Test purpose | Validate that resources can be identified and extracted from a Collection with a corridor query using query parameters. |
| Test method |
Repeat these tests using the following parameter tests: Coordinates
VerticalLevel
Custom dimensions
Parameters
DateTime
Execute requests with combinations of the “coords”, “parameter-name”,”z”,”crs” and “f” query parameters and verify that only information that matches the selection criteria is returned. |
| Identifier | /conf/edr/REQ_rc-corridor-width-definition |
|---|---|
| Requirement | Requirement A.71: /req/edr/corridor-width-definition |
| Test purpose | Validate that the corridor-width query parameter is constructed correctly. |
| Test method | Verify that the corridor-width query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: corridor-width |
| Identifier | /conf/collections/REQ_rc-corridor-width-response |
|---|---|
| Requirement | Requirement A.72: /req/edr/REQ_rc-corridor-width-response |
| Test purpose | Validate that the corridor-width query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/REQ_rc-corridor-height-definition |
|---|---|
| Requirement | Requirement A.67: /req/edr/REQ_rc-corridor-height-definition |
| Test purpose | Validate that the corridor-height query parameter is constructed correctly. |
| Test method | Verify that the corridor-height query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: corridor-height |
| Identifier | /conf/collections/REQ_rc-corridor-height-response |
|---|---|
| Requirement | Requirement A.68: /req/edr/REQ_rc-corridor-height-response |
| Test purpose | Validate that the corridor-height query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/REQ_rc-width-units-definition |
|---|---|
| Requirement | Requirement A.73: /req/edr/REQ_rc-width-units-definition |
| Test purpose | Validate that the width-units query parameter is constructed correctly. |
| Test method | Verify that the width-units query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: width-units |
| Identifier | /conf/collections/REQ_rc-width-units-response |
|---|---|
| Requirement | Requirement A.74: /req/edr/width-units-response |
| Test purpose | Validate that the width-units query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/REQ_rc-height-units-definition |
|---|---|
| Requirement | Requirement A.69: /req/edr/REQ_rc-height-units-definition |
| Test purpose | Validate that the height-units query parameter is constructed correctly. |
| Test method | Verify that the within-units query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: height-units |
| Identifier | /conf/collections/rc-height-units-response |
|---|---|
| Requirement | Requirement A.70: /req/edr/height-units-response |
| Test purpose | Validate that the height-units query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/rc-resolution-x-definition-corridor |
|---|---|
| Requirement | Requirement A.60: /req/edr/resolution-x-definition |
| Test purpose | Validate that the resolution-x query parameters are constructed correctly. |
| Test method | Verify that the resolution-x query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment). name: resolution-x |
| Identifier | /conf/edr/rc-resolution-x-response-corridor |
|---|---|
| Requirement | Requirement A.61: /req/edr/resolution-x-response |
| Test purpose | Validate that the resolution-x query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/edr/rc-resolution-y-definition-corridor |
|---|---|
| Requirement | Requirement A.63: /req/edr/resolution-y-definition |
| Test purpose | Validate that the resolution-y query parameters are constructed correctly. |
| Test method | Verify that the resolution-y query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment). name: resolution-y |
| Identifier | /conf/edr/rc-resolution-y-response-corridor |
|---|---|
| Requirement | Requirement A.64: /req/edr/resolution-y-response |
| Test purpose | Validate that the resolution-y query parameters are processed correctly. |
| Test method |
|
B.11.1.8. Items
| Identifier | /conf/core/rc-items |
|---|---|
| Requirement | Requirement A.32: /req/edr/rc-items |
| Test purpose | Validate that resources can be identified and extracted from a Collection using query parameters. |
| Test method | For every resource collection identified in Collections, issue an HTTP GET request to the URL /collections/{collectionId}/items where {collectionId} is the id property for a Collection described in the Collections content. . Validate that a document was returned with a status code 200. Repeat these tests using the following parameter tests: bbox
DateTime
Execute requests with combinations of the bbox and time query parameters and verify that only information that matches the selection criteria is returned. |
| Identifier | /conf/core/rc-bbox-definition |
|---|---|
| Requirement | Requirement A.38: /req/core/rc-bbox-definition |
| Test purpose | Validate that the bounding box query parameters are constructed correctly. |
| Test method | Verify that the bbox query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment). name: bbox Use a bounding box with four numbers in all requests:
|
| Identifier | /conf/core/rc-bbox-response |
|---|---|
| Requirement | Requirement A.39: /req/core/rc-bbox-response |
| Test purpose | Validate that the bounding box query parameters are processed correctly. |
| Test method |
|
| Identifier | /conf/core/datetime-definition-items |
|---|---|
| Requirement | Requirement A.46: /req/core/datetime-definition |
| Test purpose | Validate that the datetime query parameters are constructed correctly. |
| Test method | Verify that the datetime query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: datetime |
| Identifier | /conf/core/datetime-response-items |
|---|---|
| Requirement | Requirement A.47: /req/core/datetime-response |
| Test purpose | Validate that the datetime query parameters are processed correctly. |
| Test method |
|
B.11.1.9. Instances {root}/collections/{collectionId}/instances
| Identifier | /conf/instances/rc-md-op |
|---|---|
| Requirement | Requirement A.34: /req/instances/rc-md-op |
| Test purpose | Validate that information about the instances of a Collection can be retrieved from the expected location. |
| Test method |
|
| Identifier | /conf/instances/rc-md-success |
|---|---|
| Requirement | Requirement A.35: /req/instances/rc-md-success |
| Test purpose | Validate that the instances of the Collection content comply with the required structure and contents. |
| Test method |
|
The Instances content, unlike the Collections content, may only be retrieved in the same formats as specified for the single parent collection.
| Format | Schema Document | Test ID |
|---|---|---|
| HTML | collections.yaml | /conf/html/content |
| JSON | collections.yaml | /conf/geojson/content |
B.11.1.10. Instance {root}/collections/{collectionId}/instances/instanceId
| Identifier | /conf/instances/src-md-op |
|---|---|
| Requirement | Requirement A.36: /req/instances/src-md-op |
| Test purpose | Validate that the Instances of the Collection content can be retrieved from the expected location. |
| Test method |
|
| Identifier | /conf/instances/src-md-success |
|---|---|
| Requirement | Requirement A.37: /req/instances/src-md-success |
| Test purpose | Validate that the Collection Instance content complies with the required structure and contents. |
| Test method | Verify that the content of the response is consistent with the content for this Resource Collection in the /collections response. That is, the values for id, title, description and extent are identical. |
B.11.1.11. Locations
| Identifier | /conf/locations/common-query-params |
|---|---|
| Requirement | Requirement A.33: /req/edr/rc-locations |
| Test purpose | Validate that the Locations query supports the core EDR query parameters. |
| Test method |
|
| Identifier | /conf/locations/no-query-params |
|---|---|
| Requirement | Requirement A.33: /req/edr/rc-locations |
| Test purpose | Validate that a list of valid locations is returned by a Locations query if no query parameters are specified. |
| Test method |
|
| Identifier | /conf/locations/location-identifier-invalid |
|---|---|
| Requirement | Requirement A.33: /req/edr/rc-locations |
| Test purpose | Validate that an error is returned by a Locations query when the locationId is invalid. |
| Test method |
|
| Identifier | /conf/locations/locations-nodata |
|---|---|
| Requirement | Requirement A.33: /req/edr/rc-locations |
| Test purpose | Validate that an HTTP 204 message is returned by a Locations query when there is no data available for the requested locations. |
| Test method |
|
| Identifier | /conf/locations/valid-query-params |
|---|---|
| Requirement | Requirement A.33: /req/edr/rc-locations |
| Test purpose | Validate that resources can be identified and extracted from a Collection with a Locations query using query parameters. |
| Test method |
Repeat these tests using the following parameter tests: Parameters
Custom dimensions
DateTime
Execute requests with combinations of the time,parameter-name,crs and f query parameters and verify that only information that matches the selection criteria is returned. |
| Identifier | /conf/edr/rc-locationid-definition |
|---|---|
| Requirement | Requirement A.77: /req/edr/REQ_rc-locationid-definition |
| Test purpose | Validate that the locationid parameter is constructed correctly. |
| Test method | Verify that the locationId query parameter complies with the following definition (using an OpenAPI Specification 3.1 fragment): name: locationId |
| Identifier | /conf/edr/rc-locationid-response |
|---|---|
| Requirement | Requirement A.78: /req/edr/REQ_rc-locationid-response |
| Test purpose | Validate that the locationid parameter is processed correctly. |
| Test method |
|
B.11.1.12. Response
| Identifier | /conf/core/rc-numberMatched |
|---|---|
| Requirement | Requirement 3: /req/core/rc-numberMatched |
| Test purpose | Validate the numberMatched parameter returned with a Features response |
| Test method |
|
| Identifier | /conf/core/rc-numberReturned |
|---|---|
| Requirement | Requirement 3: /req/core/rc-numberMatched |
| Test purpose | Validate the numberReturned parameter returned with a Features response |
| Test method |
|
Annex C
(informative)
Collection Response Metadata (Informative)
This Annex contains a more human-readable view of the content in the OpenAPI definitions.
The collection response structure provides the details which describe the information available and the query capabilities supported by the collections served by the implementation of an API incorporating OGC API-EDR Standard requirements.
C.1. EDR Collection Object Structure
Collection objects describe both collections and instances of a collection.
| Field Name | Type | Required | Description |
|---|---|---|---|
| links | link Array | Yes | Array of Link objects |
| id | String | Yes | Unique identifier string for the collection, used as the value for the collection_id path parameter in all queries on the collection |
| title | String | No | A short text label for the collection |
| description | String | No | A text description of the information provided by the collection |
| keywords | String Array | No | Array of words and phrases that define the information that the collection provides |
| extent | extent object | Yes | Object describing the spatio-temporal extent of the information provided by the collection |
| data_queries | data_queries object | Yes | Object providing query specific information |
| crs | String Array | No | Array of coordinate reference system names, which define the output coordinate systems supported by the collection |
| output_formats | String Array | No | Array of data format names, which define the data formats to which information in the collection can be output |
| parameter_names | parameter_names object | Yes | Describes the data values available in the collection |
C.2. Link Object
OGC Web API Standards use RFC 8288 (Web Linking) to express relationships between resources. The “link” elements provide a convention for associating resources related to the collection.
| Field Name | Type | Required | Description |
|---|---|---|---|
| href | String | Yes | URL being referenced |
| rel | String | Yes | Relation type of the URL. A list of valid relation types can be found at https://www.opengis.net/def/rel |
| type | String | No | Type of information being returned by the URL |
| hreflang | String | No | Attribute used to specify the language and geographical targeting of information accessed by the URL. Can be defined by using a value from either languages ISO 639-1 or countries ISO 3166-1 |
| title | String | No | A short text label to describe the URL |
| length | No | ||
| templated | Boolean | No | If True the URL includes templated values for mandatory Query parameters |
| variables | variables object | No | Object providing custom information relevant to the link |
C.3. Variables Object
The variables object provides fields to describe information that only applies to the owning link.
| Field Name | Type | Required | Description |
|---|---|---|---|
| title | String | No | A short text label for the query |
| description | String | No | A description of the query |
| query_type | String | Yes | One of: position, radius, area, cube, trajectory, corridor, items, locations, instances |
| coords | String | No | An example of valid coords query parameter values |
| within_units | String Array | No | A list of the valid within units for radius queries |
| width_units | String Array | No | A list of the valid width units |
| height_units | String Array | No | A list of the valid height units |
| output_formats | String Array | No | A list of output formats supported by the query, if this field exists it overrides the output formats definition supplied at a collection level. |
| default_output_format | String Array | No | Specifies the default output format for the query |
| crs_details | crs_details object Array | No | A list of coordinate reference systems supported by the query, if this field exists it overrides the crs values defined at a collection level. |
C.4. CRS Details Object
A crs details object describes a coordinate system.
| Field Name | Type | Required | Description |
|---|---|---|---|
| crs | String | Yes | Name of the coordinate reference system, used as the value in the crs query parameter to define the required output coordinate reference system |
| wkt | String | Yes | Well Known Text description of the coordinate reference system |
A simple link example is shown below.
Listing C.1
"link" : {
"href": "https://www.example.org/sourcedata/help",
"hreflang": "en",
"rel": "service-doc",
"type": "text/html",
}
A more complex link example supporting a templated href with a mandatory coords parameter is shown below.
Listing C.2
"link": {
"href": "https://example.org/sourcedata/position?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Position query",
"query_type": "position",
"output_formats": [
"CoverageJSON",
"GeoJSON",
"IWXXM"
],
"default_output_format": "GeoJSON"
}
}
C.5. Extent Object
The extent object describes the spatio-temporal area covered by the information available in the collection.
| Field Name | Type | Required | Description |
|---|---|---|---|
| spatial | spatial object | Yes | Object defining the spatial extent of the information in the collection |
| temporal | temporal object | No | Object defining the temporal extent of the information in the collection |
| vertical | vertical object | No | Object defining the vertical extent of the information in the collection |
| custom | custom Array | No | Array of custom dimension definitions |
C.6. Spatial Object
The spatial object describes the spatial area covered by the information available in the collection.
| Field Name | Type | Required | Description |
|---|---|---|---|
| bbox | Array of Number Array | Yes | An Array of bounding box’s each bbox is provided as four numbers:
|
| values | spatial values | No | Describes the spatial resolution of the data |
| crs | String | Yes | This can either be a Well Known Text definition of the CRS or follow a convention of https://www.opengis.net/def/crs/{authority}/{version}/{code} where the token {authority} is a placeholder for a code the designates to authority responsible for the definition of this CRS. Typical values include “EPSG” and “OGC”. The token {version} is a placeholder for the specific version of the coordinate reference system definition or 0 for the latest version or if the version is unknown. The token {code} is a placeholder for the authority’s code for the CRS. |
C.7. Spatial values object
The spatial values object describes the spatial resolution of the information available in the collection.
| Field Name | Type | Required | Description |
|---|---|---|---|
| x | Array | Yes | Provides information about the spatial resolution available in the collection for the xcoordinates as number of repetitions / minimum value / interval (e.g. “R720/0/0.5”) or a list of the values (e.g. 0, 0.5, 1.0, 1.5 … 719.5, 720) |
| y | Array | Yes | Provides information about the spatial resolution available in the collection for the xcoordinates as number of repetitions / minimum value / interval (e.g. “R361/90/-0.5”) or a list of the values (e.g. 90, 89.5, 89, 88.5 … -89.5,-90) |
C.8. Temporal Object
The temporal object describes the time period covered by the information available in the collection.
| Field Name | Type | Required | Description |
|---|---|---|---|
| interval | Array of ISO 8601 Date Array | Yes | An array of ISO 8601 Date Array, each ISO 8601 Date Array should contain two values first being the minimum date time and second the maximum date time for information in the collection (see https://en.wikipedia.org/wiki/ISO_8601) |
| values | ISO 8601 Date Array | No | An array of ISO 8601 datestrings which details the time intervals available in the collection, each member of the array can either be a single time, an ISO 8601 time interval or an ISO 8601 time duration (see https://en.wikipedia.org/wiki/ISO_8601) |
| trs | String | Yes | This defaults to Gregorian, but other temporal systems can be supported following the conventions defined by the Well Known Text standard. |
C.9. Vertical Object
The vertical object describes the vertical extent of information available in the collection.
| Field Name | Type | Required | Description |
|---|---|---|---|
| interval | String Array | Yes | Array of level values array, each Level value Array should contain two values first being the minimum vertical level and second the maximum vertical level for information in the collection |
| values | String Array | No | Array of height values supported by the collection. |
| vrs | String | Yes | Follows the conventions defined by the Well Known Text standard. |
C.10. Custom Object
Each custom object describes the extent of the custom dimension for the collection.
| Field Name | Type | Required | Description |
|---|---|---|---|
| id | String | Yes | Name of the custom dimension. |
| interval | String Array | Yes | Array of data values arrays, each value in the values array should contain two values, the first being the minimum value of the custom dimension and second the maximum value for the custom dimension for information in the collection |
| values | String Array | No | Array of data values for the custom dimension supported by the collection . |
| reference | String | Yes | A uri which links to a definition or description of the custom dimension. |
Repeating intervals
In the Vertical and Custom dimension objects values can be defined as repeating intervals. They are formed by adding “R[n]/” to the beginning of an interval expression, where R is used as the letter itself and [n] is replaced by the number of repetitions. Leaving out the value for [n] or specifying a value of -1, means an unbounded number of repetitions. A value of 0 for [n] means the interval is not repeated.
Rn/<start value>/<interval>
For example "R4/100/5" would be values start at 100 and increment by 5, 4 times which equates to [100,105,110,115,120].
A simple extent object example for collection with no vertical or temporal dimensions is shown below.
Listing C.3
"extent": {
"spatial": {
"bbox": [[1393.0196, 13494.9764, 671196.3657, 1230275.0454]],
"crs": "PROJCS[\"OSGB 1936 / British National Grid\",
GEOGCS[\"OSGB 1936\",DATUM[\"OSGB_1936\",
SPHEROID[\"Airy 1830\",6377563.396,299.3249646,
AUTHORITY[\"EPSG\",\"7001\"]],AUTHORITY[\"EPSG\",\"6277\"]],
PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],
UNIT[\"degree\",0.01745329251994328,
AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4277\"]],
UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],
PROJECTION[\"Transverse_Mercator\"],
PARAMETER[\"latitude_of_origin\",49],PARAMETER[\"central_meridian\",-2],
PARAMETER[\"scale_factor\",0.9996012717],PARAMETER[\"false_easting\",400000],
PARAMETER[\"false_northing\",-100000],AUTHORITY[\"EPSG\",\"27700\"],
AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"
}
}
Below is a more complex extent object example for a collection with vertical, temporal dimensions and a percentile custom dimension.
Listing C.4
"extent": {
"spatial": {
"bbox": [[-180.0,-90.0,180.0,90.0]],
"crs": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",
SPHEROID[\"WGS 84\",6378137,298.257223563,
AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],
PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],
UNIT[\"degree\",0.01745329251994328,
AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
},
"temporal": {
"interval": [["2021-04-22T00:00:00Z","2021-05-03T12:00:00Z"]],
"values": ["R82/2021-04-22T00:00:00Z/PT3H",
"R2/2021-05-02T12:00:00Z/PT12H"],
"trs": "TIMECRS[\"DateTime\",TDATUM[\"Gregorian Calendar\"],
CS[TemporalDateTime,1],AXIS[\"Time (T)\",future]]"
},
"vertical": {
"interval": [["1829.0","3658.0"]],
"values": ["1829.0","2743.0","3658.0"],
"vrs": "VERT_CS['MSL height',
VERT_DATUM['Mean Sea Level',2005,
AUTHORITY['EPSG','5100']],
UNIT['metre',1,AUTHORITY['EPSG','9001']],
AXIS['Up',UP],AUTHORITY['EPSG','5714']]"
},
"custom": [
{
"id": "percentile",
"interval": [
[
0,
100
]
],
"values": [
"R20/0/5"
],
"reference": "https://en.wikipedia.org/wiki/Percentile"
}
]
}
C.11. Data Queries Object
The data queries object provides the extra metadata required for the queries supported by the collection.
| Field Name | Type | Required | Description |
|---|---|---|---|
| position | EDRQuery object | No | Position query metadata |
| radius | EDRQuery object | No | Radius query metadata |
| area | EDRQuery object | No | Area query metadata |
| cube | EDRQuery object | No | Cube query metadata |
| trajectory | EDRQuery object | No | Trajectory query metadata |
| corridor | EDRQuery object | No | Corridor query metadata |
| items | EDRQuery object | No | Item query metadata |
| locations | EDRQuery object | No | Location query metadata |
C.12. EDR Query Object
The EDR query object provides the metadata for the specified query type.
| Field Name | Type | Required | Description |
|---|---|---|---|
| link | Link object | Yes | Link for the query. |
A data query object example for a collection that supports Position and Radius queries is shown below.
Listing C.5
"data_queries": {
"position": {
"link": {
"href": "https://example.org/collections/sampledata/position",
"hreflang": "en",
"rel": "data",
"templated":false,
"variables": {
"title": "Position query",
"query_type": "position",
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",
SPHEROID[\"WGS 84\",6378137,298.257223563,
AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],
PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],
UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],
AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"radius": {
"link": {
"href": "https://example.org/collections/sampledata/radius",
"hreflang": "en",
"rel": "data",
"variables": {
"title": "Radius query",
"description": "Radius query",
"query_type": "radius",
"output_formats": [
"CoverageJSON",
"GeoJSON",
"GeoTiff"
],
"default_output_format": "CoverageJSON",
"within_units": [
"km",
"miles"
],
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",
SPHEROID[\"WGS 84\",6378137,298.257223563,
AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],
PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],
UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],
AUTHORITY[\"EPSG\",\"4326\"]]" }
]
}
}
}
}
C.13. Parameter Names Object
The parameter-names object provides information about the data parameters supported by the collection. As a set of key-value pairs, where the key is the name of the parameter and the value is a Parameter object i.e. as a Dictionary (Python) or HashMap(Java).
C.14. Parameter Object
| Field Name | Type | Required | Description |
|---|---|---|---|
| id | String | No | parameter id |
| type | String | Yes | Always ‘Parameter’ |
| label | String | No | A short text label for the parameter |
| description | String | No | A description of the parameter |
| dataType | String | No | The data type of the parameter values [integer, float, string] |
| unit | unit object | No | A description of the units of the parameter values |
| observedProperty | observedProperty object | Yes | A formal definition of the parameter |
| extent | Extent object | No | Information on the spatio-temporal extent of the parameter values (if different from other parameters in the collection) |
| measurementType | measurementType object | No | Information on how the value was derived |
C.15. Unit Object
The unit object provides the information to describe the units of measure of the parameter values.
| Field Name | Type | Required | Description |
|---|---|---|---|
| label | String | No1 | Name of the unit |
| symbol | symbol object | No1 | Information to describe the symbols used to represent the unit |
1 Either one of label or symbol or both attributes SHALL be present in a unit object
C.16. Symbol Object
The symbol object provides the information to describe the symbols which represent the unit of a value.
| Field Name | Type | Required | Description |
|---|---|---|---|
| value | String | No | A Unicode representation for the symbol |
| type | String | No | A URI to a registry entry providing more detailed information about the unit (i.e. QUDT is one example of a registry that provide links for many common units) |
C.17. Observed Property Object
The observedProperty object provides the metadata for the specified query type.
| Field Name | Type | Required | Description |
|---|---|---|---|
| id | String | No | URI linking to an external registry which contains the definitive definition of the observed property |
| label | String | Yes | A short text label for the property |
| description | String | No | A description of the observed property |
C.18. Measurement Type object
The measurementType object provides basic information about how the parameter is calculated and over what time period.
| Field Name | Type | Required | Description |
|---|---|---|---|
| method | String | Yes | Calculation method e.g. Mean, Sum, Max, etc. |
| duration | String | Yes | Duration of calculation. For time durations, this follows the ISO 8601 Duration standard.
|
A Parameter names example is shown below.
Listing C.6
"parameter_names": {
"Temperature_altitude_above_msl": {
"type": "Parameter",
"description": "Temperature for Specific altitude above MSL",
"unit": {
"label": "K",
"symbol": {
"value": "K",
"type": "https://qudt.org/vocab/unit/K"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-0-0",
"label": "Temperature_altitude_above_msl"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0S"
}
},
"u-component_of_wind_altitude_above_msl": {
"type": "Parameter",
"description": "u-component of wind for Specific altitude above MSL",
"unit": {
"label": "m/s",
"symbol": {
"value": "m%20s",
"type": "https://qudt.org/vocab/unit/M-PER-SEC.html"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-2",
"label": "u-component_of_wind_altitude_above_msl"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0S"
}
},
"v-component_of_wind_altitude_above_msl": {
"type": "Parameter",
"description": "v-component of wind for Specific altitude above MSL",
"unit": {
"label": "m/s",
"symbol": {
"value": "m%20s",
"type": "https://qudt.org/vocab/unit/M-PER-SEC.html"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-3",
"label": "v-component_of_wind_altitude_above_msl"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0S"
}
}
}
Annex D
(informative)
Parameter measurementType Methods (Informative)
The parameter-names object provides information about the data parameters supported by the collection. Each parameter-names` object has an optional `measurementType` attribute which provides basic information about how the parameter is calculated and over what time period. The table below provides a list of recommended definitions for the `method` property of the `measurementType` attribute.
| Method | Description |
|---|---|
| instantaneous | The data values are representative of points in space or time |
| sum | The data values are representative of a sum or accumulation |
| maximum | Maximum |
| median | Median |
| mid_range | Average of maximum and minimum |
| minimum | Minimum |
| mean | Mean (average value) |
| mode | Mode (most common value) |
| range | Absolute difference between maximum and minimum |
| root_mean_square | Root mean square (RMS) |
| standard_deviation | Standard deviation |
In the example below the data in the collection consists of:
Air temperature values which represent an instantaneous value for the validity time Wind Speed and Wind direction values which represent a average value over the 10 minute period up to the validity time.
Listing D.1
"parameter_names": {
"air_temperature": {
"type": "Parameter",
"description": "Air temperature measured at screen level",
"unit": {
"label": "K",
"symbol": {
"value": "K",
"type": "https://qudt.org/vocab/unit/K"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/bufr4/b/12/004",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0S"
}
},
"wind_speed": {
"type": "Parameter",
"description": "10m wind speed value",
"unit": {
"label": "m/s",
"symbol": {
"value": "m%20s",
"type": "https://qudt.org/vocab/unit/M-PER-SEC.html"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/bufr4/b/11/012",
"label": "10m Wind Speed"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"wind_direction": {
"type": "Parameter",
"description": "10m wind direction value",
"unit": {
"label": "",
"symbol": {
"value": "deg",
"type": "https://qudt.org/vocab/unit/DEG.html"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/bufr4/b/11/011",
"label": "10m wind direction"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
}
}
Annex E
(informative)
Examples (Informative)
E.1. Example Landing Pages
Example — JSON Landing Page
{
"links": [
{ "href": "https://example.org/",
"rel": "self", "type": "application/json", "title": "this document" },
{ "href": "https://example.org/api",
"rel": "service-desc", "type": "application/vnd.oai.openapi+json;version=3.0", "title": "the API definition" },
{ "href": "https://example.org/conformance",
"rel": "conformance", "type": "application/json", "title": "OGC conformance classes implemented by this API" },
{ "href": "https://example.org/collections",
"rel": "data", "type": "application/json", "title": "Metadata about the resource collections" }
]
}E.2. API Description Examples
The EDR API is described using the OpenAPI 3.0 or OpenAPI 3.1 specifications. Example responses for a server which supports all possible EDR query patterns can be found at:
E.3. Conformance Examples
Example — Conformance Response
This example response in JSON is for an OGC API — EDR that supports OpenAPI 3.0 for the API definition and HTML and GeoJSON as encodings for resources.
{
"conformsTo": [
"https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/core",
"https://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
"https://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections",
"https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/oas30",
"https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/html",
"https://www.opengis.net/spec/ogcapi-edr-1/1.2/conf/geojson"
]
}E.4. Collections Metadata Examples
Example — Collections metadata response document
The example below shows a service with two collections, one for observations and another for forecast data. The forecast data is regenerated every hour so the collection provides access to multiple instances of the collection via an instances endpoint.
There are links to the responses of the collections (link relation type: “self”).
Representations of these resources in other formats are referenced using link relation type “alternate”.
The data queries that are supported by each collection are referenced using link relation type “data”.
There are also links to the license information for the observation and forecast data (link relation type “license”) and also the terms and conditions of service (link relation type “restrictions”) .
{
"links": [
{
"href": "https://example.org/edr/collections/",
"hreflang": "en",
"rel": "self",
"type": "application/json"
},
{
"href": "https://example.org/edr/collections/",
"hreflang": "en",
"rel": "alternate",
"type": "text/html"
},
{
"href": "https://example.org/edr/collections/",
"hreflang": "en",
"rel": "alternate",
"type": "application/xml"
}
],
"collections": [
{
"id": "hrly_obs",
"title": "Hourly Site Specific observations",
"description": "Observation data for UK observing sites",
"keywords": [
"Wind Direction",
"Wind Speed",
"Wind Gust",
"Air Temperature",
"Weather",
"Relative Humidity",
"Dew point",
"Pressure",
"Pressure Tendancy",
"Visibility"
],
"links": [
{
"href": "https://example.org/uk-hourly-site-specific-observations",
"hreflang": "en",
"rel": "service-doc",
"type": "text/html"
},
{
"href": "https://example.org/terms-and-conditions---datapoint#datalicence",
"hreflang": "en",
"rel": "license",
"type": "text/html"
},
{
"href": "https://example.org/services/data/
terms-and-conditions---datapoint#termsofservice",
"hreflang": "en",
"rel": "restrictions",
"type": "text/html"
}
],
"extent": {
"spatial": {
"bbox": [[
-15.0,
48.0,
5.0,
62.0
]],
"crs": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
},
"temporal": {
"interval": [
["2020-04-19T11:00:00Z","2020-06-30T09:00:00Z"]
],
"values": [
"2020-04-19T11:00:00Z/2020-06-30T09:00:00Z"
],
"trs": "TIMECRS[\"DateTime\",TDATUM[\"Gregorian Calendar\"],CS[TemporalDateTime,1],AXIS[\"Time (T)\",future]]"
}
},
"data_queries" : {
"position": {
"link": {
"href": "https://example.org/edr/collections/hrly_obs/position?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Position query",
"description": "Position query",
"coords" :{
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"IWXXM"
],
"default_output_format": "IWXXM",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"radius": {
"link": {
"href": "https://example.org/edr/collections/hrly_obs/radius?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Radius query",
"description": "Radius query",
"coords" :{
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"IWXXM"
],
"default_output_format": "GeoJSON",
"within_units": [
"km",
"miles"
],
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"area": {
"link": {
"href": "https://example.org/edr/collections/hrly_obs/area?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Area query",
"description": "Area query",
"coords" :{
"description": "Well Known Text POLYGON value i.e. POLYGON((-79 40,-79 38,-75 38,-75 41,-79 40))"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"BUFR",
"IWXXM"
],
"default_output_format": "CoverageJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"locations": {
"link": {
"href": "https://example.org/edr/collections/hrly_obs/locations",
"hreflang": "en",
"rel": "data",
"templated": false,
"variables": {
"title": "Location query",
"description": "Location query",
"output_formats": [
"CoverageJSON",
"GeoJSON",
"BUFR",
"IWXXM"
],
"default_output_format": "CoverageJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
}
},
"crs": [
"https://www.opengis.net/def/crs/OGC/1.3/CRS84"
],
"output_formats": [
"CoverageJSON",
"GeoJSON",
"IWXXM"
],
"parameter_names": {
"Wind Direction": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degree true",
"symbol": {
"value": "°",
"type": "https://example.org/edr/metadata/units/degree"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_windDirection",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_windSpeed",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Gust": {
"type": "Parameter",
"description": "",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_maximumWindGustSpeed",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"duration": "-PT10M"
}
},
"Air Temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/bufr4/b/13/_009",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Dew point": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_dewPointTemperature",
"label": "Dew point"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Pressure": {
"type": "Parameter",
"description": "",
"unit": {
"label": "hPa",
"symbol": {
"value": "hPa",
"type": "https://example.org/edr/metadata/units/hPa"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/bufr4/b/10/_051",
"label": "Pressure"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Pressure Tendancy": {
"type": "Parameter",
"description": "",
"unit": {
"label": "tendency",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/units/hPa"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_pressureTendency",
"label": "Pressure Tendancy"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "m",
"symbol": {
"value": "m",
"type": "https://example.org/edr/metadata/units/m"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
}
}
},
{
"id": "3_hrly_forecast",
"title": "UK 3 Hourly Site Specific Forecast",
"description": "Five day site specific forecast for 6000 UK locations",
"keywords": [
"Wind Direction",
"Wind Speed",
"Wind Gust",
"Air Temperature",
"Weather",
"Relative Humidity",
"Feels like temperature",
"UV index",
"Probability of precipitation",
"Visibility"
],
"links": [
{
"href": "https://example.org/uk-3-hourly-site-specific-forecast",
"hreflang": "en",
"rel": "service-doc",
"type": "text/html"
},
{
"href": "https://example.org/terms-and-conditions---datapoint#datalicence",
"hreflang": "en",
"rel": "licence",
"type": "text/html"
},
{
"href": "https://example.org/terms-and-conditions---datapoint#termsofservice",
"hreflang": "en",
"rel": "restrictions",
"type": "text/html"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances",
"hreflang": "en",
"rel": "collection"
}
],
"extent": {
"spatial": {
"bbox": [[
-15.0,
48.0,
5.0,
62.0
]],
"crs": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
},
"temporal": {
"interval": [
["2020-06-23T18:00:00Z","2020-07-04T21:00:00Z"]
],
"values": [
"2020-06-23T18:00:00Z/2020-07-04T21:00:00Z"
],
"trs": "TIMECRS[\"DateTime\",TDATUM[\"Gregorian Calendar\"],CS[TemporalDateTime,1],AXIS[\"Time (T)\",future]]"
}
},
"data_queries" : {
"position": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_forecast/position?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Position query",
"description": "Position query",
"coords" :{
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "IWXXM",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"radius": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_forecast/radius?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Radius query",
"description": "Radius query",
"coords" :{
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"within_units": [
"km",
"miles"
],
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"area": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_forecast/area?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Area query",
"description": "Area query",
"coords" :{
"description": "Well Known Text POLYGON value i.e. POLYGON((-79 40,-79 38,-75 38,-75 41,-79 40))"
},
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "CoverageJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"instances": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_forecast/instances",
"hreflang": "en",
"rel": "data",
"templated": false,
"variables": {
"title": "Instances query",
"description": "Instances query",
"query_type": "instances"
}
}
}
},
"crs": [
"https://www.opengis.net/def/crs/OGC/1.3/CRS84"
],
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"parameter_names": {
"Wind Direction": {
"type": "Parameter",
"description": "Direction wind is from",
"unit": {
"label": "degree true",
"symbol": {
"value": "°",
"type": "https://example.org/edr/metadata/units/degree"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Speed": {
"type": "Parameter",
"description":"Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Gust": {
"type": "Parameter",
"description": "Wind gusts are a rapid increase in strength of the wind relative to the wind speed.",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"duration": "-PT10M"
}
},
"Air Temperature": {
"type": "Parameter",
"description": "2m air temperature in the shade and out of the wind",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Probability of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probability of precipitation"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
}
}
}
]
}
E.5. Instance Metadata Examples
Example — Collection instance metadata response document
This is an example of the metadata returned by the instances query
(link relation type: “items”).
There is a link to the instance response itself (link relation type: “self”).
Representations of this resource in other formats are referenced using link relation type “alternate”.
The data queries that are supported by each instance are referenced using link relation type “data”.
There are also links to the license information for the observation and forecast data (link relation type “license”) and also the terms and conditions of service (link relation type “restrictions”) .
{
"links": [
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/",
"hreflang": "en",
"rel": "self",
"type": "application/json"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/?f=html",
"hreflang": "en",
"rel": "alternate",
"type": "text/html"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/?f=xml",
"hreflang": "en",
"rel": "alternate",
"type": "application/xml"
},
{
"href": "https://example.org/terms-and-conditions---datapoint#termsofservice",
"hreflang": "en",
"rel": "restrictions",
"type": "text/html",
"title": ""
},
{
"href": "https://example.org/terms-and-conditions---datapoint#datalicence",
"hreflang": "en",
"rel": "license",
"type": "text/html",
"title": ""
},
{
"href": "https://example.org/uk-3-hourly-site-specific-forecast",
"hreflang": "en",
"rel": "service-doc",
"type": "text/html",
"title": ""
}
],
"instances": [
{
"id": "2020-06-30T10:00:00Z",
"title": "3 hrly fcst",
"description": "Five day site specific forecast for 6000 UK locations 3 hrly fcst",
"keywords": [
"Wind Direction",
"Wind Speed",
"Wind Gust",
"Air Temperature",
"Weather",
"Relative Humidity",
"Feels like temperature",
"UV index",
"Probabilty of precipitation",
"Visibility"
],
"links": [
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z",
"hreflang": "en",
"rel": "self",
"type": "application/json"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z?f=html",
"hreflang": "en",
"rel": "alternate",
"type": "text/html"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z?f=xml",
"hreflang": "en",
"rel": "alternate",
"type": "application/xml"
}
],
"extent": {
"spatial": {
"bbox": [[
-15.0,
48.0,
5.0,
62.0
]],
"crs": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
},
"temporal": {
"interval": [
["2020-06-30T06:00:00Z","2020-07-04T21:00:00Z"]
],
"values": [
"2020-06-30T06:00:00Z/2020-07-04T21:00:00Z"
],
"trs": "TIMECRS[\"DateTime\",TDATUM[\"Gregorian Calendar\"],CS[TemporalDateTime,1],AXIS[\"Time (T)\",future]]"
}
},
"data_queries": {
"position": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/position?coords={coords}",
"hreflang": "en",
"rel": "data",
"title": "",
"templated": true,
"variables": {
"title": "Position query",
"description": "Position query",
"coords": {
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"radius": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/radius?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Radius query",
"description": "Radius query",
"coords": {
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"CSV"
],
"default_output_format": "GeoJSON",
"within_units": [
"km",
"miles"
],
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"area": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/area?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Area query",
"description": "Area query",
"coords": {
"description": "Well Known Text POLYGON value i.e. POLYGON((-79 40,-79 38,-75 38,-75 41,-79 40))"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"CSV"
],
"default_output_format": "CoverageJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"locations": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/locations",
"hreflang": "en",
"rel": "data",
"templated": false,
"variables": {
"title": "Locations query",
"description": "Locations query",
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
}
},
"crs": [
"https://www.opengis.net/def/crs/OGC/1.3/CRS84"
],
"output_formats": [
"GeoJSON",
"CoverageJSON",
"CSV"
],
"parameter_names": {
"Wind Direction": {
"type": "Parameter",
"description": "Direction wind is from",
"unit": {
"label": "degree true",
"symbol": {
"value": "°",
"type": "https://example.org/edr/metadata/units/degree"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Gust": {
"type": "Parameter",
"description": "Wind gusts are a rapid increase in strength of the wind relative to the wind speed.",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"duration": "-PT10M"
}
},
"Air Temperature": {
"type": "Parameter",
"description": "2m air temperature in the shade and out of the wind",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Probabilty of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probabilty of precipitation"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
}
}
},
{
"id": "2020-06-30T09:00:00Z",
"title": "3 hrly fcst",
"description": "Five day site specific forecast for 6000 UK locations 3 hrly fcst",
"keywords": [
"Wind Direction",
"Wind Speed",
"Wind Gust",
"Air Temperature",
"Weather",
"Relative Humidity",
"Feels like temperature",
"UV index",
"Probabilty of precipitation",
"Visibility"
],
"links": [
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T09:00:00Z",
"hreflang": "en",
"rel": "self",
"type": "application/json"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T09:00:00Z?f=html",
"hreflang": "en",
"rel": "alternate",
"type": "text/html"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T09:00:00Z?f=xml",
"hreflang": "en",
"rel": "alternate",
"type": "application/xml"
}
],
"extent": {
"spatial": {
"bbox": [[
-15.0,
48.0,
5.0,
62.0
]],
"crs": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
},
"temporal": {
"interval": [
["2020-06-30T06:00:00Z","2020-07-04T21:00:00Z"]
],
"values": [
"2020-06-30T06:00:00Z/2020-07-04T21:00:00Z"
],
"trs": "TIMECRS[\"DateTime\",TDATUM[\"Gregorian Calendar\"],CS[TemporalDateTime,1],AXIS[\"Time (T)\",future]]"
}
},
"data_queries": {
"position": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/position?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Position query",
"description": "Position query",
"coords": {
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"radius": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/radius?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Radius query",
"description": "Radius query",
"coords": {
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"CSV"
],
"default_output_format": "GeoJSON",
"within_units": [
"km",
"miles"
],
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"area": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/area?coords={coords}",
"hreflang": "en",
"rel": "data",
"title": "",
"templated": true,
"variables": {
"title": "Area query",
"description": "Area query",
"coords": {
"description": "Well Known Text POLYGON value i.e. POLYGON((-79 40,-79 38,-75 38,-75 41,-79 40))"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"CSV"
],
"default_output_format": "CoverageJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"locations": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/locations",
"hreflang": "en",
"rel": "data",
"templated": false,
"variables": {
"title": "Locations query",
"description": "Locations query",
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
}
},
"crs": [
"https://www.opengis.net/def/crs/OGC/1.3/CRS84"
],
"output_formats": [
"GeoJSON",
"CoverageJSON",
"CSV"
],
"parameter_names": {
"Wind Direction": {
"type": "Parameter",
"description": "Direction wind is from",
"unit": {
"label": "degree true",
"symbol": {
"value": "°",
"type": "https://example.org/edr/metadata/units/degree"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Gust": {
"type": "Parameter",
"description": "Wind gusts are a rapid increase in strength of the wind relative to the wind speed.",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"duration": "-PT10M"
}
},
"Air Temperature": {
"type": "Parameter",
"description": "2m air temperature in the shade and out of the wind",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Probabilty of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probabilty of precipitation"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
}
}
},
{
"id": "2020-06-30T08:00:00Z",
"title": "3 hrly fcst",
"description": "Five day site specific forecast for 6000 UK locations 3 hrly fcst",
"keywords": [
"Wind Direction",
"Wind Speed",
"Wind Gust",
"Air Temperature",
"Weather",
"Relative Humidity",
"Feels like temperature",
"UV index",
"Probabilty of precipitation",
"Visibility"
],
"links": [
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T08:00:00Z",
"hreflang": "en",
"rel": "self",
"type": "application/json"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T08:00:00Z?f=html",
"hreflang": "en",
"rel": "alternate",
"type": "text/html"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T08:00:00Z?f=xml",
"hreflang": "en",
"rel": "alternate",
"type": "application/xml"
}
],
"extent": {
"spatial": {
"bbox": [[
-15.0,
48.0,
5.0,
62.0
]],
"crs": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
},
"temporal": {
"interval": [
["2020-06-30T06:00:00Z","2020-07-04T21:00:00Z"]
],
"values": [
"2020-06-30T06:00:00Z/2020-07-04T21:00:00Z"
],
"trs": "TIMECRS[\"DateTime\",TDATUM[\"Gregorian Calendar\"],CS[TemporalDateTime,1],AXIS[\"Time (T)\",future]]"
}
},
"data_queries": {
"position": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/position?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Position query",
"description": "Position query",
"coords": {
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"radius": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/radius?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Radius query",
"description": "Radius query",
"coords": {
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"CSV"
],
"default_output_format": "GeoJSON",
"within_units": [
"km",
"miles"
],
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"area": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/area?coords={coords}",
"hreflang": "en",
"rel": "data",
"title": "",
"templated": true,
"variables": {
"title": "Area query",
"description": "Area query",
"coords": {
"description": "Well Known Text POLYGON value i.e. POLYGON((-79 40,-79 38,-75 38,-75 41,-79 40))"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"CSV"
],
"default_output_format": "CoverageJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"locations": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/locations",
"hreflang": "en",
"rel": "data",
"templated": false,
"variables": {
"title": "Locations query",
"description": "Locations query",
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
}
},
"crs": [
"https://www.opengis.net/def/crs/OGC/1.3/CRS84"
],
"output_formats": [
"GeoJSON",
"CoverageJSON",
"CSV"
],
"parameter_names": {
"Wind Direction": {
"type": "Parameter",
"description": "Direction wind is from",
"unit": {
"label": "degree true",
"symbol": {
"value": "°",
"type": "https://example.org/edr/metadata/units/degree"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Gust": {
"type": "Parameter",
"description": "Wind gusts are a rapid increase in strength of the wind relative to the wind speed.",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"duration": "-PT10M"
}
},
"Air Temperature": {
"type": "Parameter",
"description": "2m air temperature in the shade and out of the wind",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Probabilty of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probabilty of precipitation"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
}
}
},
{
"id": "2020-06-30T07:00:00Z",
"title": "3 hrly fcst",
"description": "Five day site specific forecast for 6000 UK locations 3 hrly fcst",
"keywords": [
"Wind Direction",
"Wind Speed",
"Wind Gust",
"Air Temperature",
"Weather",
"Relative Humidity",
"Feels like temperature",
"UV index",
"Probabilty of precipitation",
"Visibility"
],
"links": [
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T07:00:00Z",
"hreflang": "en",
"rel": "self",
"type": "application/json"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T07:00:00Z?f=html",
"hreflang": "en",
"rel": "alternate",
"type": "text/html"
},
{
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T07:00:00Z?f=xml",
"hreflang": "en",
"rel": "alternate",
"type": "application/xml"
}
],
"extent": {
"spatial": {
"bbox": [[
-15.0,
48.0,
5.0,
62.0
]],
"crs": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
},
"temporal": {
"interval": [
["2020-06-30T06:00:00Z","2020-07-04T21:00:00Z"]
],
"values": [
"2020-06-30T06:00:00Z/2020-07-04T21:00:00Z"
],
"trs": "TIMECRS[\"DateTime\",TDATUM[\"Gregorian Calendar\"],CS[TemporalDateTime,1],AXIS[\"Time (T)\",future]]"
}
},
"data_queries": {
"position": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/position?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Position query",
"description": "Position query",
"coords": {
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"radius": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/radius?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Radius query",
"description": "Radius query",
"coords": {
"description": "Well Known Text POINT value i.e. POINT(-120, 55)"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"CSV"
],
"default_output_format": "GeoJSON",
"within_units": [
"km",
"miles"
],
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"area": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/area?coords={coords}",
"hreflang": "en",
"rel": "data",
"templated": true,
"variables": {
"title": "Area query",
"description": "Area query",
"coords": {
"description": "Well Known Text POLYGON value i.e. POLYGON((-79 40,-79 38,-75 38,-75 41,-79 40))"
},
"output_formats": [
"CoverageJSON",
"GeoJSON",
"CSV"
],
"default_output_format": "CoverageJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
},
"locations": {
"link": {
"href": "https://example.org/edr/collections/3_hrly_fcst/instances/2020-06-30T10:00:00Z/locations",
"hreflang": "en",
"rel": "data",
"templated": false,
"variables": {
"title": "Locations query",
"description": "Locations query",
"output_formats": [
"CoverageJSON",
"GeoJSON"
],
"default_output_format": "GeoJSON",
"crs_details": [
{
"crs": "CRS84",
"wkt": "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],AUTHORITY[\"EPSG\",\"6326\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4326\"]]"
}
]
}
}
}
},
"crs": [
"https://www.opengis.net/def/crs/OGC/1.3/CRS84"
],
"output_formats": [
"GeoJSON",
"CoverageJSON",
"CSV"
],
"parameter_names": {
"Wind Direction": {
"type": "Parameter",
"description": "Direction wind is from",
"unit": {
"label": "degree true",
"symbol": {
"value": "°",
"type": "https://example.org/edr/metadata/units/degree"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"duration": "-PT10M"
}
},
"Wind Gust": {
"type": "Parameter",
"description": "Wind gusts are a rapid increase in strength of the wind relative to the wind speed.",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"duration": "-PT10M"
}
},
"Air Temperature": {
"type": "Parameter",
"description": "2m air temperature in the shade and out of the wind",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Probabilty of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probabilty of precipitation"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "https://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"duration": "PT0M"
}
}
}
}
]
}
E.6. Location Query Metadata Examples
Example — Collection instance metadata response document
An example of the Locations metadata from a collection that supports the Location query pattern.
(link relation type: “items”).
There is a link to the collections response itself (link relation type: “self”).
Representations of this resource in other formats are referenced using link relation type “alternate”.
Finally there are also links to the license information for the data (link relation type “license”).
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"id": 3002,
"geometry": {
"type": "Point",
"coordinates": [
-0.854,
60.749
]
},
"properties": {
"name": "BALTASOUND",
"datetime": "2020-03-30T19:00:00Z/2020-04-20T07:00:00Z",
"detail": "https://oscar.wmo.int/surface/rest/api/stations/station/1745/stationReport",
"WIGOS Station Identifier": "0-20000-0-03002"
}
},
{
"type": "Feature",
"id": 3005,
"geometry": {
"type": "Point",
"coordinates": [
-1.183,
60.139
]
},
"properties": {
"name": "LERWICK (S. SCREEN)",
"datetime": "2020-03-30T19:00:00Z/2020-04-20T07:00:00Z",
"detail": "https://oscar.wmo.int/surface/rest/api/stations/station/1746/stationReport",
"WIGOS Station Identifier": "0-20000-0-03005"
}
},
{
"type": "Feature",
"id": 3008,
"geometry": {
"type": "Point",
"coordinates": [
-1.628,
59.527
]
},
"properties": {
"name": "FAIR ISLE",
"datetime": "2020-03-30T19:00:00Z/2020-04-20T07:00:00Z",
"detail": "https://oscar.wmo.int/surface/rest/api/stations/station/1747/stationReport",
"WIGOS Station Identifier": "0-20000-0-03008"
}
},
{
"type": "Feature",
"id": 3017,
"geometry": {
"type": "Point",
"coordinates": [
-2.9,
58.954
]
},
"properties": {
"name": "KIRKWALL",
"datetime": "2020-03-30T19:00:00Z/2020-04-20T07:00:00Z",
"detail": "https://oscar.wmo.int/surface/rest/api/stations/station/1750/stationReport",
"WIGOS Station Identifier": "0-20000-0-03017"
}
},
{
"type": "Feature",
"id": 3023,
"geometry": {
"type": "Point",
"coordinates": [
-7.397,
57.358
]
},
"properties": {
"name": "SOUTH UIST RANGE",
"datetime": "2020-03-30T19:00:00Z/2020-04-20T07:00:00Z",
"detail": "https://oscar.wmo.int/surface/rest/api/stations/station/1751/stationReport",
"WIGOS Station Identifier": "0-20000-0-03023"
}
}
]
}
Annex F
(informative)
Relationship With Other OGC Standards
F.1. Introduction
This Annex outlines the relationships, in terms of underlying conceptual models, overlaps, gaps, and target use cases and technologies, with other OGC Standards.
F.2. Relationship between OGC API-EDR and OGC API-Features
The EDR API Standard is completely compatible with OGC API-Features-Part 1: Core (OGC 17-069r3), in that it supports Collections and Items. It extends the Collection functionality by allowing ‘Instances’, a form of ‘collection of collections’. The EDR API Standard also specifies requirements for the retrieval of spatiotemporal data by named location as well as coordinates.
F.3. Relationships between OGC API-EDR and Moving Features standards
There are four OGC Moving Features Standards: conceptual model with XML encoding (OGC 18-075), access (OGC 16-120r3), CSV encoding (OGC 14-084r2), and JSON encoding (OGC 19-045r3). The Moving Features Standards are concerned with things that move along a trajectory, and simultaneously change their orientation through rigid body rotation. The concepts are defined in Unified Modeling Language (UML) and encoded in GML. The EDR API Standard does not have the concept of orientation, or foliation or prisms. The EDR API Standard is defined using OpenAPI, over HTTP(S), and not defined in UML.
Moving Features and the EDR API Standard do share a common conceptual definition of a Trajectory. However, the Moving Features Standards specify encodings of trajectories in GML, CSV and Moving Features JSON, whereas the EDR API Standard encodes trajectories in WKT. The Moving Features Standards support relationships between trajectories and other features, including other trajectories. The EDR API Standard does not. Moving Features also explicitly defines concepts such as velocity, acceleration and distance along a trajectory, whereas the EDR API Standard does not.
The Moving Features Standards consider trajectories as a primary resource to be queried, manipulated and processed. In the EDR API Standard, a trajectory is simply a query sampling pattern, encoded in WKT and ISO 8601 Date Time Format, into a spatiotemporal data resource.
F.4. Relationships between OGC API-EDR and Web Coverage Service and Coverage Implementation Schema
The primary messaging mechanism used for EDR API implementations is JSON, including CoverageJSON, over HTTP(S). Implementations of the EDR API Standard are described using the OpenAPI V3.0 or V3.1 specifications. The target users are web-developers and end-users who are not geospatial experts. The target data resources are any dataset described as spatio-temporal, accessible by coordinates.
The EDR API Standard is consistent with the Web Coverage Service (WCS) and Coverage Implementation Schema (CIS) Standards but does not require the end user or developer to use the terms Domain and RangeSet. An implementation of the EDR API Standard can also be used to generate a single query against a collection of coverages, providing the data coordinate reference systems are consistent. An implementation of the EDR API Standard can support any of the WCS and CIS output formats if required. At the time of publication of the OGC API-EDR V1.0.0 Standard, at least one EDR API implementation had been created by building on top of a WCS/CIS implementation.
An implementation of the EDR API Standard, with only a single form of spatiotemporal query, can support the retrieval of data from other data stores adhering to data models that are not coverages, such as features or observations.
F.5. Relationship between OGC API-EDR and the OGC MetOcean Application profile of Web Coverage Service (WCS) 2.1
The OGC API-EDR standard was developed out of the experiences of creating Part 0, Part 1 and Part 2 of the WCS 2.1 Met Ocean Application Profile, ostensibly for similar use cases, but for differing technology bases.
The primary messaging mechanism used for implementation of the EDR API Standard is JSON, including CoverageJSON, over HTTP(S). Implementations of the EDR API Standard are described using the OpenAPI V3.0 or V3.1 specifications. The target users are web-developers and end-users who are not geospatial experts. The target data resources are any data described as spatiotemporal, accessible by coordinates, not just meteorological or oceanographic.
In contrast, the Met Ocean Application Profile of WCS 2.1 is designed primarily to support XML-encoded messaging, in particular, for GetCapabilities and GetCoverage requests. Responses returning coverages are modelled according to the OGC Coverage Implementation Schema (CIS), which can be XML, JSON or JSON-LD. Developers and end-users are expected to be familiar with the geospatial terminology of coverages, and use the Profile with predominantly meteorological or oceanographic data.
The EDR API Standard and the Met Ocean WCS Profile therefore support different use cases. Developers that are interested in extending their OWS or WCS solutions to support the Met Ocean domain are advised to use the Met Ocean Application Profile of WCS. Developers that are implementing Web APIs that make use of the OpenAPI specification are advised to use the EDR API Standard.
F.6. Relationships between OGC API-EDR, SOS and SensorThings API
Both the OGC Sensor Observation Service (SOS) and the OGC SensorThings API enable access to observations made by sensors and transmitted over networks. As stated in Part 1 of the SensorThings API Standard “The main difference between the SensorThings API and the OGC SOS and Sensor Planning Service (SPS) is that the SensorThings API is designed specifically for the resource-constrained IoT devices and the Web developer community” (OGC 15-078r6).
Therefore, although the SensorThings API Standard had overlaps with SOS for Web use cases, the OGC Membership acknowledged that there were some use cases within the IoT that could not be efficiently nor effectively addressed by the SOS. The same is true for the relationship between the EDR API and the SensorThings API.
SensorThings API follows OData’s specification for requesting entities. That means the entity control information, resource path usages, query options, the relevant JSON encodings, and batch-processing request follow OData 4.0. In contrast, the EDR API makes use of the OpenAPI V3.0 or V3.1 specifications for describing resource paths, query options, JSON schema, and other aspects.
Further, the EDR API Standard defines requirements for retrieval of coverage data and HTML responses – both of which are not supported by the SensorThings API. Therefore, developers that are interested in IoT devices and OData, and do not have a need for HTML previews of content are advised to make use of the SensorThings API instead. Similarly, developers that are interested in XML-encoded observations and sensor model descriptions are advised to make use of the SOS.
Similarly, an EDR or SensorThings API interface could be deployed on the same data set, so that users and developers that do not need the full details of observational, feature or coverage conceptual models and associated metadata could use implementations of the EDR API Standard to hide the extra complexity, while users that do need all the details can use the SensorThings API to retrieve those.
Annex G
(informative)
Glossary
G.1. Abstract Test Suite (ATS)
A compendium of test assertions applicable to implementations of a standard. An ATS provides a basis for developing an Executable Test Suite to verify that the implementation under test conforms to all the relevant functional specifications.
G.2. Collection
body of resources that belong or are used together. An aggregate, set, or group of related resources. (OGC 20-024)
G.3. Conformance Module; Conformance Test Module
set of related tests, all within a single conformance test class (OGC 08-131r3)
Note 1 to entry: When no ambiguity is possible, the word test may be omitted. i.e. conformance test module is the same as conformance module. Conformance modules may be nested in a hierarchical way.
G.4. Conformance Class; Conformance Test Class
set of conformance test modules that SHALL be applied to receive a single certificate of conformance (OGC 08-131r3)
Note 1 to entry: When no ambiguity is possible, the word test may be left out, so conformance test class maybe called a conformance class.
G.5. dataset
collection of data, published or curated by a single agent, and available for access or download in one or more formats (DCAT)
G.6. distribution
represents an accessible form of a dataset (DCAT)
Note 1 to entry: EXAMPLE: a downloadable file, an RSS feed or a web service that provides the data.
G.7. Executable Test Suite (ETS)
set of code (e.g., Java and Compliance Test Language) that provides runtime tests for the assertions defined by the ATS. Test data required to do the tests are part of the ETS (OGC 08-134)
G.8. Item
resource that is a member of a collection (IETF RFC 6573
G.9. Recommendation
expression in the content of a document conveying that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited (OGC 08-131r3)
G.10. Requirement
expression in the content of a document conveying criteria to be fulfilled if compliance with the document is to be claimed and from which no deviation is permitted (OGC 08-131r3)
G.11. Requirements Class
aggregate of all requirement modules that SHALL all be satisfied to satisfy a conformance test class (OGC 08-131r3)
G.12. Requirements Module
aggregate of requirements and recommendations of a specification against a single standardization target type (OGC 08-131r3)
G.13. Spatial Resource
resources usually considered as Geospatial Data. (OGC 19-072)
G.14. Standardization Target
entity to which some requirements of a standard apply (OGC 08-131r3)
Note 1 to entry: The standardization target is the entity which may receive a certificate of conformance for a requirements class.
G.15. Web API
API using an architectural style that is founded on the technologies of the Web. (W3C Data on the Web Best Practices)
Annex H
(informative)
Revision History
| Date | Release | Editor | Primary clauses modified | Description |
|---|---|---|---|---|
| 2019-10-31 | October 2019 snapshot | C. Heazel | all | Baseline update |
| 2020-06-04 | June 2020 master | Mark Burgoyne | all | Resolved Trajectory pattern |
| 2020-06-05 | June 2020 branch | Chris Little | all | Increase alignment with Common |
| 2020-07-15 | July 2020 branch | Chris Little | all | Editorial consistency |
| 2020-07-22 | Restructure branch | Chris Little | all | Restructure 7,8,9,10 |
| 2020-07-22 | Issues 106, 107 | Dave Blodgett | all | Fix broken links |
| 2020-10-20 | Oct 2020 Master | Chris Little | Definitions | Added missing Cube definition |
| 2021-01-14 | Issue 170 | Tom Kralidis | all | Normalize query parameters as kebab-case |
| 2021-01-20 | master branch | Tom Kralidis | all | Editorial updates, requirement update for z parameter |
| 2021-02-18 | Master branch | Mark Burgoyne | all | Add dedicated width and height query parameters to the corridor query |
| 2021-03-03 | Master branch | Mark Burgoyne | all | Simplify Cube query |
| 2021-03-03 | Master branch | Chris Little | all | Replace references to Environmental with spatio-temporal |
| 2021-03-26 | Master branch | Chris Little | Title Page | Capture r3 snapshot of document prior to Planning Committee Vote |
| 2021-04-20 | Master branch | Mark Burgoyne | all | Finalize collection response metadata |
| 2021-04-27 | Master branch | Chris Little and others | all | Improved realism of examples, editorial niceties |
| 2021-05-10 | Master branch | Mark Burgoyne | all | Fix broken links |
| 2021-09-09 | 1.0 | G.Hobona | all | Conversion to metanorma asciidoc |
| 2022-05-12 | Master branch | Mark Burgoyne | all | Add missing requirements and tests for data_queries metadata |
| 2022-06-01 | 1.0.1 | G.Hobona | all | Final OGC Staff review |
| 2023-06-30 | 1.1 | G.Hobona | all | Final OGC Staff review |
| 2024-09-19 | 1.2 | Mark Burgoyne | all | Changes for v1.2 (#321, #398, #414, #455, #479 #527, #529, #560, #565) |
| 2024-02-19 | Master branch | Chris Little | all | Editorial changes arising from OAB Review |
| 2025-09-04 | Master branch | Mark Burgoyne | all | Refactor requirements and abstract tests sections to reduce duplication |
| 2025-09-30 | Master branch | Mark Burgoyne, Chris Little | all | Editorial changes and fixes from Public Review agreed with OAB |
Bibliography
[1] Open Geospatial Consortium: The Specification Model — A Standard for Modular specifications, OGC 08-131
[2] W3C/OGC: Spatial Data on the Web Best Practices, W3C Working Group Note 28 September 2017, https://www.w3.org/TR/sdw-bp/
[3] W3C: Data on the Web Best Practices, W3C Recommendation 31 January 2017, https://www.w3.org/TR/dwbp/
[4] W3C: Data Catalog Vocabulary, W3C Recommendation 16 January 2014, https://www.w3.org/TR/vocab-dcat/
[5] IANA: Link Relation Types, https://www.iana.org/assignments/link-relations/link-relations.xml