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 an Area, along a Trajectory or through a Corridor. A spatio-temporal data resource is a collection of spatio-temporal 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) 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 spatio-temporal coordinates.
The EDR API query patterns — Position, Area, Cube, Trajectory or Corridor — can be thought of as discrete sampling geometries, conceptually consistent with the feature of interest in the 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 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.
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 OGC API-Common, which defines the resources and access paths that are supported by all OGC APIs. The resources are listed in Table 1. This document extends that foundation to define the EDR API.
Table 1 — Overview of Resources
| 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 to determine supported capabilities and obtain information (metadata) about a distribution of a resource. This includes the API definition of 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 spatio-temporal, 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
The OGC API — EDR Standard is an extension of OGC API — Common — Part 1: Core. The OGC API — Common — Part 1: Core Standard does not mandate any specific security controls. However, the Standard was constructed so that security controls can be added without impacting conformance.
Apply Requirement /req/oas30/security for OpenAPI 3.0 Security support.
The OpenAPI specification, which is used by the OGC API — EDR Standard, 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.
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 |
OGC API - Environmental Data Retrieval Standard
1. Scope
This specification identifies resources, captures compliance classes, and specifies requirements which are applicable to OGC Environmental Data Retrieval APIs.
This specification 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 spatio-temporal data resources provided by the server.
A spatio-temporal data resource is a collection of spatio-temporal 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 spatio-temporal 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 of OGC API-EDR 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. 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 spatio-temporal data.
The Collections Requirements Class of the EDR API extends the common requirements to those specific to the query and retrieval of collections of spatio-temporal data. The 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 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. 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 spatio-temporal data.
OpenAPI 3.0, one Requirements Class
The OGC API — Common — Part 1: Core Standard does not mandate any encoding or format for the formal definition of the API. However, the preferred option is the OpenAPI 3.0 specification. Therefore, the EDR APIs are defined using OpenAPI 3.0.
The OpenAPI 3.0 Requirements Class is specified in Chapter 9 and Annex A in more detail.
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.
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 specified in Chapter 9 and 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.
Open API Initiative: OpenAPI Specification 3.0.3, https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T.: IETF RFC 2616, HTTP/1.1, https://tools.ietf.org/rfc/rfc2616.txt
Rescorla, E.: IETF RFC 2818, HTTP Over TLS, https://tools.ietf.org/rfc/rfc2818.txt
Klyne, G., Newman, C.: IETF RFC 3339, Date and Time on the Internet: Timestamps, https://tools.ietf.org/rfc/rfc3339.txt
Berners-Lee, T., Fielding, R., Masinter, L: IETF RFC 3896, Uniform Resource Identifier (URI): Generic Syntax, https://tools.ietf.org/rfc/rfc3896.txt
Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S., Schaub, T.: IETF RFC 7946, The GeoJSON Format, https://tools.ietf.org/rfc/rfc7946.txt
Nottingham, M.: IETF RFC 8288, Web Linking, https://tools.ietf.org/rfc/rfc8288.txt
Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., Orchard, D.: IETF RFC 6570, URI Template, https://datatracker.ietf.org/doc/html/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
Blower, J., Riechert, M., Roberts, B.: Overview of the CoverageJSON format, https://www.w3.org/TR/covjson-overview/
Weibel, S., Kunze, J., Lagoze, C., Wolf, M.: IETF RFC 2413, Dublin Core Metadata for Resource Discovery, https://tools.ietf.org/rfc/rfc2413.txt
John Herring: OGC 06-103r4, OpenGIS Implementation Specification for Geographic information — Simple feature access — Part 1: Common architecture. Open Geospatial Consortium (2011). https://portal.ogc.org/files/?artifact id=25355.
Roger Lott: OGC 18-010r7, Geographic information — Well-known text representation of coordinate reference systems. Open Geospatial Consortium (2019). https://docs.ogc.org/is/18-010r7/18-010r7.html.
Clemens Portele, Panagiotis (Peter) A. Vretanos, Charles Heazel: OGC 17-069r3, OGC API — Features — Part 1: Core. Open Geospatial Consortium (2019). https://docs.ogc.org/is/17-069r3/17-069r3.html.
Charles Heazel: OGC 19-072, OGC API — Common — Part 1: Core. Open Geospatial Consortium (2023). https://docs.ogc.org/is/19-072/19-072.html.
Charles Heazel: OGC API — Common — Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, http://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 specification.
4.1. area
region specified with a geographic envelope that may have a vertical extent
4.2. corridor
two-parameter set of points around a trajectory
(Note: generalized from the ISO definition of a trajectory)
4.3. cube
rectangular area, with a vertical extent
4.4. location
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).
4.5. instance
attribute, such as version, release, or run, of a given data collection
4.6. position
data type that describes a point or geometry potentially occupied by an object or person
(Source: ISO 19133:2005)
4.7. radius
region specified with a geographic position and radial distance
4.8. spatiotemporal data
data associated with a position in space-time
4.9. trajectory
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:
http://www.opengis.net/spec/ogcapi-edr-1/1.1
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 an 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 use 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, API implementations are required to implement the template as a path in their API. 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. It is envisaged that, 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 an OGC API that supports JSON are:
application/prs.coverage+json for resources that include coverage content encoded according to CoverageJSON
application/geo+json for feature collections and features
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 an OGC API 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=http://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=http://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
application/xml for all other resources
The typical HTML media type for all “web pages” in an OGC API would be text/html.
The media types for an OpenAPI definition are application/vnd.oai.openapi+json;version=3.0 (JSON) and application/vnd.oai.openapi;version=3.0 (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 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 use the API, good documentation is essential for any API. 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 way of doing so. In general, APIs will go beyond the requirements and recommendations stated in this standard. They will support additional operations, parameters, etc. that are specific to the API or the software tool used to implement the API.
5.7.2. Role of OpenAPI
This document uses OpenAPI 3.0 fragments as examples and to formally state requirements. Using OpenAPI 3.0 is not required for implementing an OGC API. Other API definition languages may be used along with, or instead of OpenAPI. However, any API definition language used should have an associated conformance class advertised through the /conformance path.
This approach is used to avoid lock-in to a specific approach to defining an API. This standard includes a conformance class for API definitions that follow the OpenAPI specification 3.0. Conformance classes for additional API definition languages will be added as the API landscape continues to evolve.
In this document, fragments of OpenAPI definitions are shown in YAML since YAML is easier to format than JSON and is typically used in OpenAPI editors.
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 must be “based upon” a schema or parameter component in the OGC schema repository.
In this case, 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.
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 EDR API definitions that do not conform to the OpenAPI Specification 3.0 the normative statement should 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 the base URL of a server. Unlike Web Services, an API is decoupled from the server(s). Some ramifications of this are:
An API may be hosted (replicated) on more than one server.
Parts of an API may be distributed across multiple servers.
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 the 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 an OGC API 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 created by the API in response to a standardized, coordinate orientated, query pattern;
To provide ‘building blocks’ allowing the construction of more complex applications.
An EDR API implemented according to this standard can be considered a ‘Sampling API’. The query creates a discrete sampling geometry against the spatiotemporal data resource of a relatively persistent data store. The query and its response are transient resources, but if required 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 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.
Table 2 — Environmental Data Retrieval API Paths
| 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
{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 OGC API-EDR shall first satisfy the appropriate Requirements Classes from OGC API — Common, namely:
Core, http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core
Collections, http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections
7.1. Overview
The OGC API — Environmental Data Retrieval Core Requirements Class defines the requirements for locating, understanding, and accessing spatio-temporal data resources.
See Requirements Class “OGC API — Environmental Data Retrieval Core” for a detailed specification of the Core Requirements Class.
The following five 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 spatio-temporal data.
Query Resources: operations for accessing spatio-temporal data resources through queries
Parameters: parameters for use in OGC API-EDR operations.
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.
Table 3 — Mapping OGC API — EDR Sections to OGC API — Common Requirements Classes
7.2. Platform
OGC API — Common defines a set of common capabilities which are applicable to any OGC Web API. Those capabilities provide the platform upon which resource-specific APIs can be built. This section describes those capabilities and any modifications needed to better support spatio-temporal data resources.
7.2.1. API landing page
The landing page provides links that support exploration of the resources offered via the API. The most important component of a landing page is a list of links. OGC API — Common already requires some common links, sufficient for this standard, that are stated in the following Requirements Class of 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 spatio-temporal 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 Figure 1.
type: object
required:
- links
properties:
title:
type: string
example: Meteorological data server
description:
type: string
example: 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
example:
- 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
example:
- 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
Figure 1 — Landing Page Response Schema
The following JSON fragment is an example of a response to an OGC API-EDR Landing Page operation.
{
"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"
}
]
}
Figure 2 — Landing Page Example
7.2.1.3. Error Handling
The requirements for handling unsuccessful requests are provided in Recommendation http://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.2.2. API definition
Every API 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, 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.2.2.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
Follow the service-desc or service-doc link on the landing page
Only the link is required by OGC API — Common.
7.2.2.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 format for the API Definition response to the API implementor. However, the options are limited to those which have been defined in the OGC API-Common standard. At this time OpenAPI 3.0 is the only option provided.
7.2.2.3. Error Handling
The requirements for handling unsuccessful requests are provided in Recommendation http://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.2.3. 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 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.2.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}/conformance path
Follow the conformance link on the landing page
Both techniques are required by OGC API — Common.
7.2.3.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 Figure 3.
Apply Requirement /req/core/conformance on declaration of Core conformance classes.
type: object
required:
- conformsTo
properties:
conformsTo:
type: array
items:
type: string
Figure 3 — Conformance Response Schema
The following JSON fragment is an example of a response to an OGC API-EDR conformance operation.
{
"conformsTo": [
"http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core",
"http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
"http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections",
"http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/oas30",
"http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/html",
"http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/geojson"
]
}
Figure 4 — Conformance Information Example
8. Query, Spatiotemporal and Information Resources
Query resources are spatiotemporal queries which support operation of the API for the 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 the API. 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 4.
8.1. Information Resources
Table 4 — Information Resource Paths
| Path Template | Resource |
|---|---|
| /collections | The root resource describing the collections of spatio-temporal data available from this API. |
| /collections/{collectionId} | Identifies a collection of spatio-temporal 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 5 provides a mapping of the initial query types proposed for the EDR API.
8.2. Query Resources
Table 5 — Query Types
| 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 spatio-temporal 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:
Table 6 — Position query structure
| 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/) |
|
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:
Table 7 — Radius query structure
| 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/) |
|
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:
Table 8 — Area query structure
| 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/) |
|
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:
Table 9 — Cube query structure
| 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 in 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) |
|
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:
Table 10 — Trajectory query structure
| 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:
Table 11 — Corridor query structure
| 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 for 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 for 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 for 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 is an OGC API — Features endpoint that may be used to catalog pre-existing EDR sampling features. The pre-existence of an EDR sampling feature may be because a particular query has been cached for later use,such as a monitoring location. Or there may be a catalog of spatiotemporal sampling features such as domains of anomalies in a dataset. A GeoJSON-compatible JSON-Schema is specified to document an EDR API query endpoint and valid query parameters including time range, parameters, and spatial characteristics. A service can define a custom GeoJSON schema in the OpenAPI definition for the service, with the default being the edr-geojson schema if no alternative is documented.
Recommendation 1 | |
|---|---|
| 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. |
8.2.7.1. Parameter itemId
If an itemId is not specified, the query will return a list of the available itemId’s. This behavior is specified in OGC API — Features. All other parameters for use with the Items query are defined by OGC API — Features.
The filter constraints are defined by the following query parameters:
Table 12 — Items query structure
| 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 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 | Maximum number of items to return |
|
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 SHALL return a GeoJSON features array of valid location identifiers, 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:
Table 13 — locations query structure
| Query Parameter | Type | Required | Description | Examples |
locationId | String | No | A unique identifier for the required location, such as a GeoHash, a World Meteorological Organization (WMO) station identifier or place name. |
|
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/) |
|
8.2.9. Instances query
Having multiple versions or instances of the same collection, where the same information is reprocessed or regenerated is not unusal. 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}/instance/{instanceId}
Example 1 — Return the Raw data instance metadata (instanceId = raw) for the Metar ((collectionId = metar) collection
/collections/metar/instance/raw
Example 2 — Return the Level 1 Quality controlled data instance (instanceId = qc_lvl_1) metadata for the Metar (collectionId = metar) collection
/collections/metar/instance/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 5 for the mappings of the query types. The queryType structure is:
/collections/{collectionId}/instance/{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/instance/raw/position
Example 2 — A trajectory query on a Raw data instance(instanceId = raw) for the Metar ((collectionId = metar) collection
/collections/metar/instance/raw/trajectory
8.2.10. Custom dimension support
Support for dimensions other than the standard spatiotemporal 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
Following the conventions used for the temporal or vertical extents, custom extent objects shall provide the following information:
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
Table 14 — Custom query parameter structure
| 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 apply to all OGC APIs.
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 15 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.
Table 15 — Typical HTTP status codes
| 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 1 | /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 15, 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).
Recommendation 2 | |
|---|---|
| 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.
Recommendation 3 | |
|---|---|
| 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 be possible. The EDR API standard does not specify how to handle asynchronous requests. Different services may propose 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, EDR APIs SHOULD support WGS84 longitude and latitude (http://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:
Recommendation 4 | |
|---|---|
| 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:
Recommendation 5 | |
|---|---|
| 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:
Recommendation 6 | |
|---|---|
| Statement | A: If the resource can be represented for the intended use in CoverageJSON, implementations SHOULD consider to support CoverageJSON as an encoding. |
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 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.
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. Link Headers
Recommendation 7 | |
|---|---|
| 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. |
9.9. OpenAPI 3.0
9.9.1. Basic requirements
Apply the OpenAPI 3.0 Requirements Class.
The OpenAPI 3.0 Requirements Class used in OGC API — Common is applicable to the EDR API as well. So an implementation of EDR API which supports OpenAPI 3.0 as an API Description format shall also comply with the OpenAPI 3.0 Requirements Class (http://www.opengis.net/spec/ogcapi-common-1/1.0/req/oas30) specified in OGC API — Common.
Apply Requirement /req/oas30/oas-definition-2 for OpenAPI 3.0 conformance.
Implementations shall also advertise conformance with this Requirements Class.
Apply Requirement /req/oas30/oas-impl for OpenAPI 3.0 implementation.
An example OpenAPI definition document is available at https://schemas.opengis.net/ogcapi/edr/1.1/openapi/ogcapi-environmental-data-retrieval-1.yaml
9.9.2. Complete definition
Apply Requirement /req/oas30/completeness for OpenAPI 3.0 Completeness.
Note, for example, that APIs which are access-controlled (see Security), support web cache validation, CORS, or that use HTTP redirection will make use of additional HTTP status codes as well as common codes such as 200 for successful GET requests and 400, 404 or 500 for error situations. See Clause 9.2.
Clients shall be prepared to receive responses not documented in the OpenAPI definition. For example, additional errors may occur in the transport layer outside of the server.
9.9.3. Exceptions
Apply Requirement /req/oas30/exceptions-codes for OpenAPI 3.0 Exception codes.
Example — An exception response object definition
description: An error occurred.
content:
application/json:
schema:
$ref: https://schemas.opengis.net/ogcapi/edr/1.1/openapi/schemas/core/exception.yaml
text/html:
schema:
type: string
Annex A
(informative)
Requirements Detail
A.1. Introduction
For clarity, the complete requirements class descriptions are omitted in the body of this specification. This annex contains the complete 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 | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/core |
| Obligation | requirement |
| Target type | Web API |
| Prerequisites | http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core http://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/api-definition-op Requirement A.4: /req/core/api-definition-success Requirement A.5: /req/core/conformance Requirement A.6: /req/core/conformance-success Requirement A.7: /req/core/http Requirement A.8: /req/core/crs |
Requirement A.1 | |
|---|---|
| Identifier | /req/core/root-op |
| Included in | Requirements class A.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/core |
| Statement | A: The server SHALL support the HTTP GET operation at the path /. |
Requirement A.2 | |
|---|---|
| Identifier | /req/core/root-success |
| Included in | Requirements class A.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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:
|
Requirement A.3 | |
|---|---|
| Identifier | /req/core/api-definition-op |
| Included in | Requirements class A.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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. |
Requirement A.4 | |
|---|---|
| Identifier | /req/core/api-definition-success |
| Included in | Requirements class A.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.
A.2.2. Requirement /req/core/conformance Core conformance classes
Requirement A.5 | |
|---|---|
| Identifier | /req/core/conformance |
| Included in | Requirements class A.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/core |
| Statement | A: The list of Conformance Classes advertised by the API SHALL include: |
Requirement A.6 | |
|---|---|
| Identifier | /req/core/conformance-success |
| Included in | Requirements class A.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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
Requirement A.7 | |
|---|---|
| Identifier | /req/core/http |
| Included in | Requirements class A.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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
Requirement A.8 | |
|---|---|
| Identifier | /req/core/crs |
| Included in | Requirements class A.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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
Requirements class A.2: Collections | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/collections |
| Obligation | requirement |
| Target type | Web API |
| Prerequisites | http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections http://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.9: /req/collections/rc-md-op Requirement A.10: /req/collections/rc-md-success Requirement A.11: /req/collections/src-md-op Requirement A.12: /req/collections/src-md-success Requirement A.13: /req/edr/rc-collection-info Requirement A.21: /req/core/rc-collection-info-links Requirement A.14: /req/edr/rc-data-queries Requirement A.22: /req/core/rc-extent Requirement A.23: /req/core/rc-md-query-links Requirement A.24: /req/edr/rc-crs Requirement A.25: /req/edr/rc-parameters |
Requirement A.9 | |
|---|---|
| Identifier | /req/collections/rc-md-op |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/collections |
| Statement | A: The API SHALL support the HTTP GET operation at the path /collections. |
Requirement A.10 | |
|---|---|
| Identifier | /req/collections/rc-md-success |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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. |
Requirement A.11 | |
|---|---|
| Identifier | /req/collections/src-md-op |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/collections |
| Statement | A: The API SHALL support the HTTP GET operation at the path /collections/{collectionId}. |
| Statement | B: The parameter collectionId is each id property in the resource collections response (JSONPath: $.collections[*].id). |
Requirement A.12 | |
|---|---|
| Identifier | /req/collections/src-md-success |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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. |
Requirement A.13 | |
|---|---|
| Identifier | /req/edr/rc-collection-info |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 crs parameter which SHALL comply with the requirement /req/edr/rc-crs. |
| Statement | H: Every Collection within a collections array MAY have a distanceunits parameter containing an array of supported distance units. |
| Statement | I: If the links parameter includes a link to a Radius query there SHALL be a distanceunits parameter. |
| Statement | J: Every Collection within a collections array SHALL have an f parameter containing an array of values which describe the output formats supported by the collection. |
| Statement | K: 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. |
Requirement A.14 | |
|---|---|
| Identifier | /req/edr/rc-data-queries |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 |
Requirement A.15 | |
|---|---|
| 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 MUST 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 MUST be an array of objects. |
| Statement | G: Objects in a crs_details array MUST have a crs and wkt property both of which are of type string. |
Requirement A.16 | |
|---|---|
| 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 SHALL include a variables property |
| Statement | E:
|
Requirement A.17 | |
|---|---|
| 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 |
Requirement A.18 | |
|---|---|
| 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 |
Requirement A.19 | |
|---|---|
| Identifier | /req/edr/rc-corridor-variables |
| Statement | A: A corridor data_queries object variables property MUST comply with the requirement /req/edr/rc-variables-common. |
| Statement | B: A corridor data_queries object variables property MUST include a height_units property which MUST be a string array |
| Statement | C: A corridor data_queries object variables property MUST include a width_units property which MUST be a string array |
Requirement A.20 | |
|---|---|
| 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 |
Requirement A.21 | |
|---|---|
| Identifier | /req/core/rc-collection-info-links |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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. |
Requirement A.22 | |
|---|---|
| Identifier | /req/core/rc-extent |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/collections |
| Statement | A: For each spatial resource collection, the extent property, if provided, SHALL provide 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 implementation whether only a single spatial or temporal geometry property is used to determine the extent or all relevant geometries. |
Requirement A.23 | |
|---|---|
| Identifier | /req/core/rc-md-query-links |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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. |
Requirement A.24 | |
|---|---|
| Identifier | /req/edr/rc-crs |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/collections |
| Statement | A: A crs object SHALL have a unique (to the collection) name 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. |
Requirement A.25 | |
|---|---|
| Identifier | /req/edr/rc-parameters |
| Included in | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 an i18n object that is the name of the parameter and which SHOULD be short. Note that this 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 an i18n object which is a, perhaps 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”, and “categories”. The value of “label” SHALL be an i18n object that 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 an i18n object with a textual description of the observed property. If given, the value of “categories” SHALL be a non-empty array of category objects. A category object SHALL an “id” and a “label” member, and MAY have a “description” member. The value of “id” SHALL be a valid URI string and SHOULD resolve to more detailed information. The value of “label” SHALL be an i18n object of the name of the category and SHOULD be short. If given, the value of “description” SHALL be an i18n object with a textual description of the category. |
| Statement | G: A parameter object MAY have a member with the name “categoryEncoding” where the value is an object where each key is equal to an “id” value of the “categories” array within the “observedProperty” member of the parameter object. There SHALL be no duplicate keys. The value is either an integer or an array of integers where each integer SHALL be unique within the object. |
| Statement | H: 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 “http://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 an i18n object 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 to reference a unit serialization scheme to allow automatic unit conversion. |
| Statement | I: A parameter object SHALL NOT have a “unit” member if the “observedProperty” member has a “categories” member. |
A.4. Requirements Class “Queries” for Position, Area, Cube, Trajectory, Corridor, Items, Locations, and Instances
A.4.1. Requirements Class: Queries
Requirements class A.3: Queries | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/queries |
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | Requirements class A.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/collections |
| Normative statements | Requirement A.26: /req/queries/position Requirement A.27: /req/edr/rc-area Requirement A.28: /req/edr/rc-cube Requirement A.29: /req/edr/rc-trajectory Requirement A.30: /req/edr/rc-corridor Requirement A.31: /req/queries/radius 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 |
A.4.2. Requirements for Position Queries
Requirement A.26 | |
|---|---|
| Identifier | /req/queries/position |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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}/position. |
| Statement | B: For every collection identified in the collections response (path /collections), the server MAY support the HTTP POST operation at the path /collections/{collectionId}/position. |
| Statement | C: The parameter collectionId is each id property in the collections response (JSONPath: $.collections[*].id). |
| Statement | D: A position GET or POST operation SHALL include a coords query parameter |
| Statement | E: If the coords query parameter is not specified a HTTP 400 error should be generated |
| Statement | F: A position GET or POST operation MAY include a z query parameter |
| Statement | G: A position GET or POST operation SHOULD include a parameter-name query parameter |
| Statement | H: A position GET or POST operation MAY include a datetime query parameter |
| Statement | I: A position GET or POST operation SHOULD include a crs query parameter |
| Statement | J: A position GET or POST operation SHOULD include an f query parameter |
A.4.3. Requirements for Area Queries
Requirement A.27 | |
|---|---|
| Identifier | /req/edr/rc-area |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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}/area. |
| Statement | B: For every collection identified in the collections response (path /collections), the server MAY support the HTTP POST operation at the path /collections/{collectionId}/area. |
| Statement | C: The parameter collectionId is each id property in the collections response (JSONPath: $.collections[*].id). |
| Statement | D: An area GET operation SHALL include a coords query parameter |
| Statement | E: If the coords query parameter is not specified a HTTP 400 error should be generated |
| Statement | F: An area GET or POST operation MAY include a z query parameter |
| Statement | G: An area GET or POST operation SHOULD include a parameter-name query parameter |
| Statement | H: An area GET or POST operation MAY include a datetime query parameter |
| Statement | I: An area GET or POST operation SHOULD include a crs query parameter |
| Statement | J: An area GET or POST operation SHOULD include a f query parameter |
A.4.4. Requirements for Cube Queries
Requirement A.28 | |
|---|---|
| Identifier | /req/edr/rc-cube |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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}/cube. |
| Statement | B: For every collection identified in the collections response (path /collections), the server MAY support the HTTP POST operation at the path /collections/{collectionId}/cube. |
| Statement | C: The parameter collectionId is each id property in the collections response (JSONPath: $.collections[*].id). |
| Statement | D: A cube GET or POST operation SHALL include a bbox query parameter |
| Statement | E: 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 | F: If the bbox query parameter is not specified a HTTP 400 error should be generated |
| Statement | G: A cube GET or POST operation SHALL include a z query parameter |
| Statement | H: If the z query parameter is not specified a HTTP 400 error should be generated |
| Statement | I: A cube GET or POST operation SHOULD include a parameter-name query parameter |
| Statement | J: A cube GET or POST operation MAY include a datetime query parameter |
| Statement | K: A cube GET or POST operation SHOULD include a crs query parameter |
| Statement | L: A cube GET or POST operation SHOULD include an f query parameter |
A.4.5. Requirements for Trajectory Queries
Requirement A.29 | |
|---|---|
| Identifier | /req/edr/rc-trajectory |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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}/trajectory. |
| Statement | B: For every collection identified in the collections response (path /collections), the server MAY support the HTTP POST operation at the path /collections/{collectionId}/trajectory. |
| Statement | C: The parameter collectionId is each id property in the collections response (JSONPath: $.collections[*].id). |
| Statement | D: A trajectory GET or POST operation SHALL include a coords query parameter |
| Statement | E: If the coords query parameter is not specified a HTTP 400 error should be generated |
| Statement | F: A trajectory GET or POST operation MAY include a z query parameter |
| Statement | G: A trajectory GET or POST operation SHOULD include a parameter-name query parameter |
| Statement | H: A trajectory GET or POST operation MAY include a datetime query parameter |
| Statement | I: A trajectory GET or POST operation SHOULD include a crs query parameter |
| Statement | J: A trajectory GET or POST operation SHOULD include an f query parameter |
A.4.6. Requirements for Corridor Queries
Requirement A.30 | |
|---|---|
| Identifier | /req/edr/rc-corridor |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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}/corridor. |
| Statement | B: For every collection identified in the collections response (path /collections), the server MAY support the HTTP POST operation at the path /collections/{collectionId}/corridor. |
| Statement | C: The parameter collectionId is each id property in the collections response (JSONPath: $.collections[*].id). |
| Statement | D: A corridor GET operation SHALL include a coords query parameter |
| Statement | E: If the coords query parameter is not specified, an HTTP 400 error should be generated |
| Statement | F: A corridor GET operation SHALL include a corridor-width query parameter |
| Statement | G: If the corridor-width query parameter is not specified, an HTTP 400 error should be generated |
| Statement | H: A corridor GET operation MUST include a corridor-height query parameter |
| Statement | I: If the corridor-height query parameter is not specified, an HTTP 400 error should be generated |
| Statement | J: A corridor GET operation MUST include a width-units query parameter |
| Statement | K: If the width-units query parameter is not specified, an HTTP 400 error should be generated |
| Statement | L: If the width-units query parameter value is not one of the supported values a HTTP 400 error should be generated |
| Statement | M: A corridor GET operation MUST include a height-units query parameter |
| Statement | N: If the height-units query parameter is not specified, an HTTP 400 error should be generated |
| Statement | O: If the height-units query parameter value is not one of the supported values a HTTP 400 error should be generated |
| Statement | P: A corridor GET or POST operation MAY include a z query parameter |
| Statement | Q: A corridor GET or POST operation SHOULD include a parameter-name query parameter |
| Statement | R: A corridor GET or POST operation MAY include a datetime query parameter |
| Statement | S: A corridor GET or POST operation SHOULD include a crs query parameter |
| Statement | T: A corridor GET or POST operation SHOULD include a f query parameter |
A.4.7. Requirements for Radius Queries
Requirement A.31 | |
|---|---|
| Identifier | /req/queries/radius |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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}/radius. |
| Statement | B: For every collection identified in the collections response (path /collections), the server MAY support the HTTP POST operation at the path /collections/{collectionId}/radius. |
| Statement | C: The parameter collectionId is each id property in the collections response (JSONPath: $.collections[*].id). |
| Statement | D: A radius GET or POST operation SHALL include a coords query parameter |
| Statement | E: If the coords query parameter is not specified, an HTTP 400 error should be generated |
| 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 MUST include a within-units query parameter |
| Statement | I: If the within-units query parameter is not specified, an HTTP 400 error should be generated |
| Statement | J: A radius GET or POST operation MAY include a z query parameter |
| Statement | K: A radius GET or POST operation SHOULD include a parameter-name query parameter |
| Statement | L: A radius GET or POST operation MAY include a datetime query parameter |
| Statement | M: A radius GET or POST operation SHOULD include a crs query parameter |
| Statement | N: A radius GET or POST operation SHOULD include an f query parameter |
A.4.8. Requirements for Items Queries
Requirement A.32 | |
|---|---|
| Identifier | /req/edr/rc-items |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 each id property in the feature collections response (JSONPath: $.collections[*].id). |
A.4.9. Requirements for Locations Queries
Requirement A.33 | |
|---|---|
| Identifier | /req/edr/rc-locations |
| 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}/locations. |
| Statement | B: For every collection identified in the collections response (path /collections), the server MAY support the HTTP POST operation at the path /collections/{collectionId}/locations. |
| Statement | C: The parameter collectionId is each id property in the feature collections response (JSONPath: $.collections[*].id). |
| Statement | D: If a locationId is not specified a list of valid locationId’s SHALL be returned with a description of their geospatial extent. |
| Statement | E: A locations GET or POST operation SHOULD include a parameter-name query parameter |
| Statement | F: A locations GET or POST operation MAY include a datetime query parameter |
| Statement | G: A locations GET or POST operation SHOULD include a crs query parameter |
| Statement | H: A locations GET or POST operation SHOULD include an f query parameter |
A.4.10. Requirements for Instances Queries
Requirement A.34 | |
|---|---|
| Identifier | /req/instances/rc-md-op |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/queries |
| Statement | A: The API MAY support the HTTP GET operation at the path /collections/{collection_id}/instances. |
Requirement A.35 | |
|---|---|
| Identifier | /req/instances/rc-md-success |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/queries |
| Statement | A: A successful execution of the operation SHALL be reported as a response with a HTTP status code 200. |
Requirement A.36 | |
|---|---|
| Identifier | /req/instances/src-md-op |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/queries |
| Statement | A: The API SHALL support the HTTP GET operation at the path /collections/{collectionId}/instances/{instanceId}. |
| Statement | B: The parameter collectionId is each id property in the resource collections response (JSONPath: $.collections[*].id) and instanceId is each id property of instances of the chosen collection. |
Requirement A.37 | |
|---|---|
| Identifier | /req/instances/src-md-success |
| Included in | Requirements class A.3: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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
Requirement A.38 | |
|---|---|
| Identifier | /req/core/rc-bbox-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.3. Requirement /req/core/rc-bbox-response Parameter bbox response
Requirement A.39 | |
|---|---|
| Identifier | /req/core/rc-bbox-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: Only features that have a spatial geometry that intersects the bounding box SHALL be part of the result set, if the bbox parameter is provided. |
| Statement | B: If a feature has multiple spatial geometry properties, it is the decision of the server 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, too. |
| 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, depending on whether the coordinate reference system includes a vertical axis (height or depth) and 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, depending on whether the coordinate reference system includes a vertical axis (height or depth) and 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/coords-definition Parameter coords definition
Requirement A.40 | |
|---|---|
| Identifier | /req/edr/coords-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 will 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.5. Requirement /req/edr/point-coords-response Parameter coords response
Requirement A.41 | |
|---|---|
| Identifier | /req/edr/point-coords-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 longitude/latitude 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"]] Figure A.3 unless a different coordinate reference system is specified in a parameter crs. |
A.5.6. Requirement /req/edr/polygon-coords-response Parameter coords response
Requirement A.42 | |
|---|---|
| Identifier | /req/edr/polygon-coords-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 longitude/latitude 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"]] Figure A.4 unless a different coordinate reference system is specified in a parameter crs. |
A.5.7. Requirement /req/edr/linestring-coords-response Parameter coords response
Requirement A.43 | |
|---|---|
| Identifier | /req/edr/linestring-coords-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 longitude/latitude 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"]] Figure A.5 unless a different coordinate reference system is specified in a parameter crs. |
A.5.8. Requirement /req/core/datetime-definition datetime definition
Requirement A.44 | |
|---|---|
| Identifier | /req/core/datetime-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: The datetime parameter SHALL have the following characteristics (using an OpenAPI Specification 3.0 fragment): name: datetime |
A.5.9. Requirement /req/core/datetime-response datetime response
Requirement A.45 | |
|---|---|
| Identifier | /req/core/datetime-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 implementor 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.10. Requirement /req/edr/REQ_rc-parameter-name-definition Parameter parameter-name definition
Requirement A.46 | |
|---|---|
| Identifier | /req/edr/REQ_rc-parameter-name-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.11. Requirement /req/edr/parameter-name-response Parameter parameter-name response
Requirement A.47 | |
|---|---|
| Identifier | /req/edr/parameter-name-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: If the parameter-name parameter is provided, only those parameters named 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.12. Requirement /req/edr/REQ_rc-crs-definition Parameter crs definition
Requirement A.48 | |
|---|---|
| Identifier | /req/edr/REQ_rc-crs-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.13. Requirement /req/edr/REQ_rc-crs-response Parameter crs response
Requirement A.49 | |
|---|---|
| Identifier | /req/edr/REQ_rc-crs-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: If the crs parameter is provided, the returned information should be reprojected (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 in 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.14. Requirement /req/edr/rc-f-definition Parameter f definition
Requirement A.50 | |
|---|---|
| Identifier | /req/edr/rc-f-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.15. Requirement /req/edr/REQ_rc-f-response Parameter f response
Requirement A.51 | |
|---|---|
| Identifier | /req/edr/REQ_rc-f-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.16. Requirement /req/edr/z-definition Parameter z definition
Requirement A.52 | |
|---|---|
| Identifier | /req/edr/z-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.17. Requirement /req/edr/z-response Parameter z response
Requirement A.53 | |
|---|---|
| Identifier | /req/edr/z-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: If the z parameter is provided, only resources that have a vertical geometry that intersects the vertical information in the z parameter SHALL be part of the result set. |
| Statement | B: The z can 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 can be defined be specifying a comma delimited list of values level1, level2, level3 etc |
| Statement | D: An Arithmetic sequence using Recurring height intervals can 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 |
single-level = level
interval-closed = min-level "/" max-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
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.18. Requirement /req/edr/within-definition Parameter within definition
Requirement A.54 | |
|---|---|
| Identifier | /req/edr/within-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 SHALL NOT support within queries: name: within |
A.5.19. Requirement /req/edr/REQ_rc-within-response Parameter within response
Requirement A.55 | |
|---|---|
| Identifier | /req/edr/REQ_rc-within-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 WILL be returned. |
A.5.20. Requirement /req/edr/within-units-definition Parameter within-units definition
Requirement A.56 | |
|---|---|
| Identifier | /req/edr/within-units-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.21. Requirement /req/edr/REQ_rc-within-units-response Parameter within-units response
Requirement A.57 | |
|---|---|
| Identifier | /req/edr/REQ_rc-within-units-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: The within-units parameter defines the distance units of the within query parameter value. |
A.5.22. Requirement /req/edr/resolution-x-definition Parameter resolution-x definition
Requirement A.58 | |
|---|---|
| Identifier | /req/edr/resolution-x-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.23. Requirement /req/edr/resolution-x-response Parameter resolution-x response
Requirement A.59 | |
|---|---|
| Identifier | /req/edr/resolution-x-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: If the resolution-x parameter is provided, it denotes the number of positions to retrieve data for, across the width of the corridor path, including its minimum and maximum width coordinates.  Figure A.15 — 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 coordinates of the defined corridor.  Figure A.16 — native resolution corridor example |
| Statement | C: If resolution-x is not specified, the API SHOULD return all available data at a resolution determined by the server, including the minimum and maximum coordinates of the defined corridor. resolution-x = number of intervals + 1 |
A.5.24. Requirement /req/edr/cube-z-response Parameter z response for cube queries
Requirement A.60 | |
|---|---|
| Identifier | /req/edr/cube-z-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: If the z parameter is provided, only resources that have a vertical geometry that intersects the vertical information in the z parameter SHALL be part of the result set. |
| Statement | B: The z can 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 can be defined by specifying a comma delimited list of values level1, level2, level3 etc |
| Statement | D: An Arithmetic sequence using Recurring height intervals can 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.25. Requirement /req/edr/resolution-y-definition Parameter resolution-y definition
Requirement A.61 | |
|---|---|
| Identifier | /req/edr/resolution-y-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.26. Requirement /req/edr/resolution-y-response Parameter resolution-y response
Requirement A.62 | |
|---|---|
| Identifier | /req/edr/resolution-y-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: If the resolution-y parameter is provided, 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 includes 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) resolution-y = number of intervals |
A.5.27. Requirement /req/edr/resolution-z-definition Parameter resolution-z definition
Requirement A.63 | |
|---|---|
| Identifier | /req/edr/resolution-z-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.28. Requirement /req/edr/resolution-z-response Parameter resolution-z response
Requirement A.64 | |
|---|---|
| Identifier | /req/edr/resolution-z-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.21 — 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.22 — native resolution corridor example |
| Statement | C: If resolution-z is not specified the API 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 |
A.5.29. Requirement /req/edr/REQ_rc-corridor-height-definition Parameter corridor-height definition
Requirement A.65 | |
|---|---|
| Identifier | /req/edr/REQ_rc-corridor-height-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.30. Requirement /req/edr/REQ_rc-corridor-height-response Parameter corridor-height response
Requirement A.66 | |
|---|---|
| Identifier | /req/edr/REQ_rc-corridor-height-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters |
| Statement | A: If the corridor-height parameter is defined the result set SHALL contain values derived from the chosen interpolation algorithm at the number of specified intervals. corridor-height = height |
| Statement | B: The height of the corridor parameter is the total height of the required corridor. |
| Statement | C: The coordinates of the coords parameter 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.31. Requirement /req/edr/REQ_rc-height-units-definition Parameter height-units definition
Requirement A.67 | |
|---|---|
| Identifier | /req/edr/REQ_rc-height-units-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.32. Requirement /req/edr/height-units-response Parameter height-units response
Requirement A.68 | |
|---|---|
| Identifier | /req/edr/height-units-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.33. Requirement /req/edr/corridor-width-definition Parameter corridor-width definition
Requirement A.69 | |
|---|---|
| Identifier | /req/edr/corridor-width-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.34. Requirement /req/edr/REQ_rc-corridor-width-response Parameter corridor-width response
Requirement A.70 | |
|---|---|
| Identifier | /req/edr/REQ_rc-corridor-width-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.35. Requirement /req/edr/REQ_rc-width-units-definition Parameter width-units definition
Requirement A.71 | |
|---|---|
| Identifier | /req/edr/REQ_rc-width-units-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.36. Requirement /req/edr/width-units-response Parameter width-units response
Requirement A.72 | |
|---|---|
| Identifier | /req/edr/width-units-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.37. Requirement /req/edr/custom-dimension-definition Custom Parameter definition
Requirement A.73 | |
|---|---|
| Identifier | /req/edr/custom-dimension-definition |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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.38. Requirement /req/edr/custom-dimension-response Custom Parameter response
Requirement A.74 | |
|---|---|
| Identifier | /req/edr/custom-dimension-response |
| Included in | Requirements class A.4: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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 can be defined as a value range by specifying a min-value and max-value separated by a forward slash “/” |
| Statement | C: A list of query values can be defined be specifying a comma delimited list of values value1, value2, value3 etc |
| Statement | D: An Arithmetic sequence using Recurring value intervals can be specified by Rnumber of intervals/min value/value interval |
| 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.6. Requirements Class “JSON” in Detail
A.6.1. Requirements Class: JSON
Requirements class A.5: JSON | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/json |
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | http://www.opengis.net/spec/ogcapi-common-1/1.0/req/json |
| Normative statements | Requirement A.75: /req/json/content Requirement A.76: /req/json/definition |
Requirement A.75 | |
|---|---|
| Identifier | /req/json/content |
| Included in | Requirements class A.5: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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. |
Requirement A.76 | |
|---|---|
| Identifier | /req/json/definition |
| Included in | Requirements class A.5: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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
Requirements class A.6: GeoJSON | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/geojson |
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statements | Requirement A.77: /req/geojson/content Requirement A.78: /req/geojson/definition |
Requirement A.77 | |
|---|---|
| Identifier | /req/geojson/content |
| Included in | Requirements class A.6: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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. |
Requirement A.78 | |
|---|---|
| Identifier | /req/geojson/definition |
| Included in | Requirements class A.6: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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
Requirements class A.7: EDR GeoJSON | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/edr-geojson |
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statements | Requirement A.79: /req/edr-geojson/content Requirement A.80: /req/edr-geojson/definition |
A.8.2. Requirement /req/edr-geojson/content
Requirement A.79 | |
|---|---|
| Identifier | /req/edr-geojson/content |
| Included in | Requirements class A.7: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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. |
Requirement A.80 | |
|---|---|
| Identifier | /req/edr-geojson/definition |
| Included in | Requirements class A.7: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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
Requirements class A.8: CoverageJSON | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/covjson |
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statements | Requirement A.81: /req/covjson/content Requirement A.82: /req/covjson/definition |
Requirement A.81 | |
|---|---|
| Identifier | /req/covjson/content |
| Included in | Requirements class A.8: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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/prs.coverage+json SHALL conform with the JSON Schema specified for the resource in the Core requirements class. |
Requirement A.82 | |
|---|---|
| Identifier | /req/covjson/definition |
| Included in | Requirements class A.8: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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
Requirements class A.9: HTML | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/html |
| Obligation | requirement |
| Target type | Web API |
| Prerequisite | http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core |
| Normative statements | Requirement A.83: /req/html/content Requirement A.84: /req/html/definition |
Requirement A.83 | |
|---|---|
| Identifier | /req/html/content |
| Included in | Requirements class A.9: http://www.opengis.net/spec/ogcapi-edr-1/1.1/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:
|
Requirement A.84 | |
|---|---|
| Identifier | /req/html/definition |
| Included in | Requirements class A.9: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/html |
| Statement | A: Every 200-response of an operation of the server SHALL support the media type text/html. |
A.11. Requirements Class “OpenAPI 3.0” in Detail
A.11.1. Requirements Class: OpenAPI 3.0
Requirements class A.10: OpenAPI 3.0 Requirements Class | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/oas30 |
| Obligation | requirement |
| Target type | Web API |
| Prerequisites | Requirements class A.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/core http://www.opengis.net/spec/ogcapi-common-1/1.0/req/oas30 OpenAPI Specification 3.0.3 |
| Normative statements | Requirement A.85: /req/oas30/oas-impl Requirement A.86: /req/oas30/oas-definition-1 Requirement A.87: /req/oas30/oas-definition-2 Requirement A.88: /req/oas30/completeness Requirement A.89: /req/oas30/exceptions-codes Requirement A.90: /req/oas30/security |
A.11.2. Requirement /req/oas30/oas-impl OpenAPI 3.0 implementation
Requirement A.85 | |
|---|---|
| Identifier | /req/oas30/oas-impl |
| Included in | Requirements class A.10: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/oas30 |
| Statement | A: The server SHALL implement all capabilities specified in the OpenAPI definition. |
A.11.3. Requirement /req/oas30/oas-definition-1
Requirement A.86 | |
|---|---|
| Identifier | /req/oas30/oas-definition-1 |
| Included in | Requirements class A.10: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/oas30 |
| 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:
|
A.11.4. Requirement /req/oas30/oas-definition-2 OpenAPI 3.0 conformance
Requirement A.87 | |
|---|---|
| Identifier | /req/oas30/oas-definition-2 |
| Included in | Requirements class A.10: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/oas30 |
| Statement | A: The JSON representation SHALL conform to the OpenAPI Specification, version 3.0. |
A.11.5. Requirement /req/oas30/completeness OpenAPI 3.0 Completeness
Requirement A.88 | |
|---|---|
| Identifier | /req/oas30/completeness |
| Included in | Requirements class A.10: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/oas30 |
| Statement | A: The OpenAPI definition SHALL specify for each operation all HTTP Status Codes and Response Objects that the API uses in responses. |
| Statement | B: This includes the successful execution of an operation as well as all error situations that originate from the server. |
A.11.6. Requirement /req/oas30/exceptions-codes OpenAPI 3.0 Exception codes
Requirement A.89 | |
|---|---|
| Identifier | /req/oas30/exceptions-codes |
| Included in | Requirements class A.10: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/oas30 |
| Statement | A: For error situations that originate from an API server, the API definition SHALL cover all applicable HTTP Status Codes. |
A.11.7. Requirement /req/oas30/security OpenAPI 3.0 Security
Requirement A.90 | |
|---|---|
| Identifier | /req/oas30/security |
| Included in | Requirements class A.10: http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/oas30 |
| Statement | A: For cases, where the operations of the API are access-controlled, the security scheme(s) and requirements SHALL be documented in the OpenAPI definition. |
Annex B
(informative)
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. 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.
The abstract test cases (assertions) are organized into test groups that correspond to distinct conformance test classes defined in the EDR API specification.
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 Programing 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 ignore resource paths which are not to be tested.
B.2. Conformance Class Core
Conformance class B.1: Core | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core |
| Subject | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/core |
| Prerequisite | http://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
Abstract test B.1 | |
|---|---|
| Identifier | /conf/core/http |
| Requirement | Requirement A.7: /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}/
Abstract test B.2 | |
|---|---|
| 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 |
|
Abstract test B.3 | |
|---|---|
| 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.
Table B.1 — Schema and Tests for Landing Pages
| 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)
Abstract test B.4 | |
|---|---|
| Identifier | /conf/core/api-definition |
| Requirement | Requirement A.3: /req/core/api-definition-op |
| Test purpose | Validate that the API Definition document can be retrieved from the expected location. |
| Test method |
|
Abstract test B.5 | |
|---|---|
| Identifier | /conf/core/api-definition-success |
| Requirement | Requirement A.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
Abstract test B.6 | |
|---|---|
| Identifier | /conf/core/conformance |
| Requirement | Requirement A.5: /req/core/conformance |
| Test purpose | Validate that a Conformance Declaration can be retrieved from the expected location. |
| Test method |
|
Abstract test B.7 | |
|---|---|
| Identifier | /conf/core/conformance-success |
| Requirement | Requirement A.6: /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
Abstract test B.8 | |
|---|---|
| Identifier | /conf/core/crs |
| Requirement | Requirement A.8: /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
Abstract test B.9 | |
|---|---|
| Identifier | /conf/collections/rc-md-op |
| Requirement | Requirement A.9: /req/collections/rc-md-op |
| Test purpose | Validate that information about the Collections can be retrieved from the expected location. |
| Test method |
|
Abstract test B.10 | |
|---|---|
| Identifier | /conf/rc-md-success |
| Requirement | Requirement A.10: /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.
Table B.2 — Schema and Tests for Collections content
| 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}
Abstract test B.11 | |
|---|---|
| Identifier | /conf/collections/src-md-op |
| Requirement | Requirement A.11: /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.
|
Abstract test B.12 | |
|---|---|
| Identifier | /conf/collections/src-md-success |
| Requirement | Requirement A.12: /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
Abstract test B.13 | |
|---|---|
| Identifier | /conf/core/rc-extent |
| Requirement | Requirement A.22: /req/core/rc-extent |
| Test purpose | Validate the extent property if it is present |
| Test method |
|
B.3.4.2. Collection Queries
Abstract test B.14 | |
|---|---|
| Identifier | /conf/edr/rc-collection-info |
| Requirement | Requirement A.13: /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.
Table B.3 — Schema and Tests for Collection Entries
| Format | Schema Document | Test ID |
|---|---|---|
| HTML | collection.yaml | /conf/html/content |
| JSON | collection.yaml | /conf/json/content |
Abstract test B.15 | |
|---|---|
| Identifier | /conf/edr/rc-data-queries |
| Requirement | Requirement A.14: /req/edr/rc-data-queries |
| Test purpose | Validate that the data_queries section in the collection is correctly defined. |
| Test method |
|
Abstract test B.16 | |
|---|---|
| Identifier | /conf/edr/rc-common-query-type |
| Requirement | Requirement A.16: /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 |
|
Abstract test B.17 | |
|---|---|
| Identifier | /conf/edr/rc-common-variables |
| Requirement | Requirement A.15: /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 |
|
Abstract test B.18 | |
|---|---|
| Identifier | /conf/edr/rc-radius-variables |
| Requirement | Requirement A.17: /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 |
|
Abstract test B.19 | |
|---|---|
| Identifier | /conf/edr/rc-cube-variables |
| Requirement | Requirement A.18: /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 |
|
Abstract test B.20 | |
|---|---|
| Identifier | /conf/edr/rc-corridor-variables |
| Requirement | Requirement A.19: /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 |
|
Abstract test B.21 | |
|---|---|
| Identifier | /conf/edr/rc-items-variables |
| Requirement | Requirement A.20: /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
|
Abstract test B.22 | |
|---|---|
| Identifier | /conf/edr/rc-md-query-links |
| Requirement | Requirement A.23: /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. |
B.3.4.3. Collection Links
Abstract test B.23 | |
|---|---|
| Identifier | /conf/core/rc-collection-info-links |
| Requirement | Requirement A.21: /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
Abstract test B.24 | |
|---|---|
| Identifier | /conf/edr/rc-parameters |
| Requirement | Requirement A.25: /req/edr/rc-parameters |
| Test purpose | Validate that each parameter in a collection is correctly defined. |
| Test method |
|
B.4. Conformance Class JSON
Conformance class B.3: JSON | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/json |
| Subject | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/json |
| Prerequisites | Conformance class B.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/json |
| Target Type | Web API |
| Conformance tests | Abstract test B.25: /conf/json/definition Abstract test B.26: /conf/json/content |
B.4.1. JSON Definition
Abstract test B.25 | |
|---|---|
| Identifier | /conf/json/definition |
| Requirement | Requirement A.76: /req/json/definition |
| Test purpose | Verify support for JSON |
| Test method |
|
B.4.2. JSON Content
Abstract test B.26 | |
|---|---|
| Identifier | /conf/json/content |
| Requirement | Requirement A.75: /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
Conformance class B.4: GeoJSON | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/geojson |
| Subject | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/geojson |
| Prerequisite | Conformance class B.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core |
| Target Type | Web API |
| Conformance tests | Abstract test B.27: /conf/geojson/definition Abstract test B.28: /conf/geojson/content |
B.5.1. GeoJSON Definition
Abstract test B.27 | |
|---|---|
| Identifier | /conf/geojson/definition |
| Requirement | Requirement A.78: /req/geojson/definition |
| Test purpose | Verify support for JSON and GeoJSON |
| Test method |
|
B.5.2. GeoJSON Content
Abstract test B.28 | |
|---|---|
| Identifier | /conf/geojson/content |
| Requirement | Requirement A.77: /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
Conformance class B.5: EDR GeoJSON | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/edr-geojson |
| Subject | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/edr-geojson |
| Prerequisite | Conformance class B.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core |
| Target Type | Web API |
| Conformance tests | Abstract test B.30: /conf/edr-geojson/content Abstract test B.29: /conf/edr-geojson/definition |
B.6.1. EDR GeoJSON Definition
Abstract test B.29 | |
|---|---|
| Identifier | /conf/edr-geojson/definition |
| Requirement | Requirement A.80: /req/edr-geojson/definition |
| Test purpose | Verify support for the EDR GeoJSON Schema |
| Test method |
|
B.6.2. EDR GeoJSON Content
Abstract test B.30 | |
|---|---|
| Identifier | /conf/edr-geojson/content |
| Requirement | Requirement A.79: /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
Conformance class B.6: CoverageJSON | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/covjson |
| Subject | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/covjson |
| Prerequisite | Conformance class B.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core |
| Target Type | Web API |
| Conformance tests | Abstract test B.32: /conf/covjson/content Abstract test B.31: /conf/covjson/definition |
B.7.1. CoverageJSON Definition
Abstract test B.31 | |
|---|---|
| Identifier | /conf/covjson/definition |
| Requirement | Requirement A.82: /req/covjson/definition |
| Test purpose | Verify support for CoverageJSON |
| Test method |
|
B.7.2. CoverageJSON Content
Abstract test B.32 | |
|---|---|
| Identifier | /conf/covjson/content |
| Requirement | Requirement A.81: /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
Conformance class B.7: HTML | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/html |
| Subject | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/html |
| Prerequisites | Conformance class B.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/html |
| Target Type | Web API |
| Conformance tests | Abstract test B.34: /conf/html/content Abstract test B.33: /conf/html/definition |
B.8.1. HTML Definition
Abstract test B.33 | |
|---|---|
| Identifier | /conf/html/definition |
| Requirement | Requirement A.84: /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
Abstract test B.34 | |
|---|---|
| Identifier | /conf/html/content |
| Requirement | Requirement A.83: /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
Conformance class B.8: OpenAPI 3.0 | |
|---|---|
| Identifier | http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/oas30 |
| Subject | http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/oas30 |
| Prerequisites | Conformance class B.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/oas30 |
| Target Type | Web API |
| Conformance tests | Abstract test B.35: /conf/oas30/completeness Abstract test B.36: /conf/oas30/exceptions-codes Abstract test B.37: /conf/oas30/oas-definition-1 Abstract test B.38: /conf/oas30/oas-definition-2 Abstract test B.39: /conf/oas30/oas-impl Abstract test B.40: /conf/oas30/security |
Abstract test B.35 | |
|---|---|
| Identifier | /conf/oas30/completeness |
| Requirement | Requirement A.88: /req/oas30/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. |
Abstract test B.36 | |
|---|---|
| Identifier | /conf/oas30/exceptions-codes |
| Requirement | Requirement A.89: /req/oas30/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. |
Abstract test B.37 | |
|---|---|
| Identifier | /conf/oas30/oas-definition-1 |
| Requirement | Requirement A.86: /req/oas30/oas-definition-1 |
| Test purpose | Verify that JSON and HTML versions of the OpenAPI document are available. |
| Test method |
|
Abstract test B.38 | |
|---|---|
| Identifier | /conf/oas30/oas-definition-2 |
| Requirement | Requirement A.87: /req/oas30/oas-definition-2 |
| 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. |
Abstract test B.39 | |
|---|---|
| Identifier | /conf/oas30/oas-impl |
| Requirement | Requirement A.85: /req/oas30/oas-impl |
| Test purpose | Verify that all capabilities specified in the OpenAPI definition are implemented by the API. |
| Test method |
|
Abstract test B.40 | |
|---|---|
| Identifier | /conf/oas30/security |
| Requirement | Requirement A.90: /req/oas30/security |
| Test purpose | Verify that any authentication protocols implemented by the API are documented in the OpenAPI document. |
| Test method |
|
B.10. Conformance Class Queries
B.10.1. Query Pattern Tests
B.10.1.1. Position
Abstract test B.41 | |
|---|---|
| Identifier | /conf/position/no-query-params |
| Requirement | Requirement A.26: /req/queries/position |
| Test purpose | Validate that an error is returned by a Position query if no query parameters are specified. |
| Test method |
|
Abstract test B.42 | |
|---|---|
| Identifier | /conf/position/no-coords-param |
| Requirement | Requirement A.26: /req/queries/position |
| Test purpose | Validate that an error is returned by a Position query when the coords query parameter is not specified. |
| Test method |
|
Abstract test B.43 | |
|---|---|
| Identifier | /conf/position/coords-param-invalid |
| Requirement | Requirement A.26: /req/queries/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 |
|
Abstract test B.44 | |
|---|---|
| Identifier | /conf/position/valid-query-params |
| Requirement | Requirement A.26: /req/queries/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. |
Abstract test B.45 | |
|---|---|
| Identifier | /conf/edr/rc-coords-definition-position |
| Requirement | Requirement A.40: /req/edr/coords-definition |
| Test purpose | Validate that the coords query parameters are constructed correctly. |
| Test method | Verify that the coords query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment): name: coords Use a coords value in all requests:
|
Abstract test B.46 | |
|---|---|
| Identifier | /conf/edr/rc-coords-response-position |
| Requirement | Requirement A.41: /req/edr/point-coords-response |
| Test purpose | Validate that the coords query parameters are processed correctly. |
| Test method |
|
Abstract test B.47 | |
|---|---|
| Identifier | /conf/edr/rc-z-definition-position |
| Requirement | Requirement A.52: /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.0 fragment): name: z |
Abstract test B.48 | |
|---|---|
| Identifier | /conf/edr/rc-z-response-position |
| Requirement | Requirement A.53: /req/edr/z-response |
| Test purpose | Validate that the vertical level query parameters are processed correctly. |
| Test method |
|
Abstract test B.49 | |
|---|---|
| Identifier | /conf/core/datetime-definition-position |
| Requirement | Requirement A.44: /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.0 fragment): name: datetime |
Abstract test B.50 | |
|---|---|
| Identifier | /conf/core/datetime-response-position |
| Requirement | Requirement A.45: /req/core/datetime-response |
| Test purpose | Validate that the datetime query parameters are processed correctly. |
| Test method |
|
Abstract test B.51 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-parameter-name-definition-position |
| Requirement | Requirement A.46: /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.0 fragment): name: parameter-name |
Abstract test B.52 | |
|---|---|
| Identifier | /conf/edr/rc-parameter-name-response-position |
| Requirement | Requirement A.47: /req/edr/parameter-name-response |
| Test purpose | Validate that the parameter-name query parameters are processed correctly. |
| Test method |
|
Abstract test B.53 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-definition-position |
| Requirement | Requirement A.48: /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.0 fragment): name: crs |
Abstract test B.54 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-response-position |
| Requirement | Requirement A.49: /req/edr/REQ_rc-crs-response |
| Test purpose | Validate that the crs query parameters are processed correctly. |
| Test method |
|
Abstract test B.55 | |
|---|---|
| Identifier | /conf/edr/rc-f-definition-position |
| Requirement | Requirement A.50: /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.0 fragment): name: f |
Abstract test B.56 | |
|---|---|
| Identifier | /conf/collections/rc-f-response-position |
| Requirement | Requirement A.51: /req/edr/REQ_rc-f-response |
| Test purpose | Validate that the f query parameters are processed correctly. |
| Test method |
|
B.10.1.2. Radius
Abstract test B.57 | |
|---|---|
| Identifier | /conf/radius/no-query-params |
| Requirement | Requirement A.31: /req/queries/radius |
| Test purpose | Validate that an error is returned by a radius query if no query parameters are specified. |
| Test method |
|
Abstract test B.58 | |
|---|---|
| Identifier | /conf/radius/no-coords-param |
| Requirement | Requirement A.31: /req/queries/radius |
| Test purpose | Validate that an error is returned by a radius query when the coords query parameter is not specified. |
| Test method |
|
Abstract test B.59 | |
|---|---|
| Identifier | /conf/radius/coords-param-invalid |
| Requirement | Requirement A.31: /req/queries/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 |
|
Abstract test B.60 | |
|---|---|
| Identifier | /conf/radius/no-within-param |
| Requirement | Requirement A.31: /req/queries/radius |
| Test purpose | Validate that an error is returned by a radius query when the within query parameter is not specified. |
| Test method |
|
Abstract test B.61 | |
|---|---|
| Identifier | /conf/radius/no-within_units-param |
| Requirement | Requirement A.31: /req/queries/radius |
| Test purpose | Validate that an error is returned by a radius query when the within_units query parameter is not specified. |
| Test method |
|
Abstract test B.62 | |
|---|---|
| Identifier | /conf/radius/valid-query-params |
| Requirement | Requirement A.31: /req/queries/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
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. |
Abstract test B.63 | |
|---|---|
| Identifier | /conf/edr/rc-coords-definition-radius |
| Requirement | Requirement A.40: /req/edr/coords-definition |
| Test purpose | Validate that the coords query parameters are constructed correctly. |
| Test method | Verify that the coords query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment): name: coords Use a coords value in all requests:
|
Abstract test B.64 | |
|---|---|
| Identifier | /conf/edr/rc-coords-response-radius |
| Requirement | Requirement A.41: /req/edr/point-coords-response |
| Test purpose | Validate that the coords query parameters are processed correctly. |
| Test method |
|
Abstract test B.65 | |
|---|---|
| Identifier | /conf/edr/rc-z-definition-radius |
| Requirement | Requirement A.52: /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.0 fragment): name: z |
Abstract test B.66 | |
|---|---|
| Identifier | /conf/edr/rc-z-response-radius |
| Requirement | Requirement A.53: /req/edr/z-response |
| Test purpose | Validate that the vertical level query parameters are processed correctly. |
| Test method |
|
Abstract test B.67 | |
|---|---|
| Identifier | /conf/core/datetime-definition-radius |
| Requirement | Requirement A.44: /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.0 fragment): name: datetime |
Abstract test B.68 | |
|---|---|
| Identifier | /conf/core/datetime-response-radius |
| Requirement | Requirement A.45: /req/core/datetime-response |
| Test purpose | Validate that the datetime query parameters are processed correctly. |
| Test method |
|
Abstract test B.69 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-parameter-name-definition-radius |
| Requirement | Requirement A.46: /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.0 fragment): name: parameter-name |
Abstract test B.70 | |
|---|---|
| Identifier | /conf/edr/rc-parameter-name-response-radius |
| Requirement | Requirement A.47: /req/edr/parameter-name-response |
| Test purpose | Validate that the parameter-name query parameters are processed correctly. |
| Test method |
|
Abstract test B.71 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-definition-radius |
| Requirement | Requirement A.48: /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.0 fragment): name: crs |
Abstract test B.72 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-response-radius |
| Requirement | Requirement A.49: /req/edr/REQ_rc-crs-response |
| Test purpose | Validate that the crs query parameters are processed correctly. |
| Test method |
|
Abstract test B.73 | |
|---|---|
| Identifier | /conf/edr/rc-f-definition-radius |
| Requirement | Requirement A.50: /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.0 fragment): name: f |
Abstract test B.74 | |
|---|---|
| Identifier | /conf/collections/rc-f-response-radius |
| Requirement | Requirement A.51: /req/edr/REQ_rc-f-response |
| Test purpose | Validate that the f query parameters are processed correctly. |
| Test method |
|
B.10.1.3. Area
Abstract test B.75 | |
|---|---|
| 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 |
|
Abstract test B.76 | |
|---|---|
| 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 |
|
Abstract test B.77 | |
|---|---|
| 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 |
|
Abstract test B.78 | |
|---|---|
| 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
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. |
Abstract test B.79 | |
|---|---|
| Identifier | /conf/edr/rc-coords-definition-area |
| Requirement | Requirement A.40: /req/edr/coords-definition |
| Test purpose | Validate that the coords query parameters are constructed correctly. |
| Test method | Verify that the coords query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment): name: coords Use a coords value in all requests:
|
Abstract test B.80 | |
|---|---|
| Identifier | /conf/edr/rc-coords-response-area |
| Requirement | Requirement A.42: /req/edr/polygon-coords-response |
| Test purpose | Validate that the coords query parameters are processed correctly. |
| Test method |
|
Abstract test B.81 | |
|---|---|
| Identifier | /conf/edr/rc-z-definition-area |
| Requirement | Requirement A.52: /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.0 fragment): name: z |
Abstract test B.82 | |
|---|---|
| Identifier | /conf/edr/rc-z-response-area |
| Requirement | Requirement A.53: /req/edr/z-response |
| Test purpose | Validate that the vertical level query parameters are processed correctly. |
| Test method |
|
Abstract test B.83 | |
|---|---|
| Identifier | /conf/core/datetime-definition-area |
| Requirement | Requirement A.44: /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.0 fragment): name: datetime |
Abstract test B.84 | |
|---|---|
| Identifier | /conf/core/datetime-response-area |
| Requirement | Requirement A.45: /req/core/datetime-response |
| Test purpose | Validate that the datetime query parameters are processed correctly. |
| Test method |
|
Abstract test B.85 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-parameter-name-definition-area |
| Requirement | Requirement A.46: /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.0 fragment): name: parameter-name |
Abstract test B.86 | |
|---|---|
| Identifier | /conf/edr/rc-parameter-name-response-area |
| Requirement | Requirement A.47: /req/edr/parameter-name-response |
| Test purpose | Validate that the parameter-name query parameters are processed correctly. |
| Test method |
|
Abstract test B.87 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-definition-area |
| Requirement | Requirement A.48: /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.0 fragment): name: crs |
Abstract test B.88 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-response-area |
| Requirement | Requirement A.49: /req/edr/REQ_rc-crs-response |
| Test purpose | Validate that the crs query parameters are processed correctly. |
| Test method |
|
Abstract test B.89 | |
|---|---|
| Identifier | /conf/edr/rc-f-definition-area |
| Requirement | Requirement A.50: /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.0 fragment): name: f |
Abstract test B.90 | |
|---|---|
| Identifier | /conf/collections/rc-f-response-area |
| Requirement | Requirement A.51: /req/edr/REQ_rc-f-response |
| Test purpose | Validate that the f query parameters are processed correctly. |
| Test method |
|
B.10.1.4. Cube
Abstract test B.91 | |
|---|---|
| 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 |
|
Abstract test B.92 | |
|---|---|
| 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 |
|
Abstract test B.93 | |
|---|---|
| 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 |
|
Abstract test B.94 | |
|---|---|
| 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
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. |
Abstract test B.95 | |
|---|---|
| Identifier | /conf/edr/rc-z-definition-cube |
| Requirement | Requirement A.52: /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.0 fragment): name: z |
Abstract test B.96 | |
|---|---|
| Identifier | /conf/edr/rc-z-response-cube |
| Requirement | Requirement A.60: /req/edr/cube-z-response |
| Test purpose | Validate that the vertical level query parameters are processed correctly. |
| Test method |
|
Abstract test B.97 | |
|---|---|
| Identifier | /conf/core/datetime-definition-cube |
| Requirement | Requirement A.44: /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.0 fragment): name: datetime |
Abstract test B.98 | |
|---|---|
| Identifier | /conf/core/datetime-response-cube |
| Requirement | Requirement A.45: /req/core/datetime-response |
| Test purpose | Validate that the datetime query parameters are processed correctly. |
| Test method |
|
Abstract test B.99 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-parameter-name-definition-cube |
| Requirement | Requirement A.46: /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.0 fragment): name: parameter-name |
Abstract test B.100 | |
|---|---|
| Identifier | /conf/edr/rc-parameter-name-response-cube |
| Requirement | Requirement A.47: /req/edr/parameter-name-response |
| Test purpose | Validate that the parameter-name query parameters are processed correctly. |
| Test method |
|
Abstract test B.101 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-definition-cube |
| Requirement | Requirement A.48: /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.0 fragment): name: crs |
Abstract test B.102 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-response-cube |
| Requirement | Requirement A.49: /req/edr/REQ_rc-crs-response |
| Test purpose | Validate that the crs query parameters are processed correctly. |
| Test method |
|
Abstract test B.103 | |
|---|---|
| Identifier | /conf/edr/rc-f-definition-cube |
| Requirement | Requirement A.50: /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.0 fragment): name: f |
Abstract test B.104 | |
|---|---|
| Identifier | /conf/collections/rc-f-response-cube |
| Requirement | Requirement A.51: /req/edr/REQ_rc-f-response |
| Test purpose | Validate that the f query parameters are processed correctly. |
| Test method |
|
B.10.1.5. Trajectory
Abstract test B.105 | |
|---|---|
| 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 |
|
Abstract test B.106 | |
|---|---|
| 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 |
|
Abstract test B.107 | |
|---|---|
| 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 |
|
Abstract test B.108 | |
|---|---|
| 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 |
|
Abstract test B.109 | |
|---|---|
| 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 |
|
Abstract test B.110 | |
|---|---|
| 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 |
|
Abstract test B.111 | |
|---|---|
| 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 |
|
Abstract test B.112 | |
|---|---|
| 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 |
|
Abstract test B.113 | |
|---|---|
| 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 |
|
Abstract test B.114 | |
|---|---|
| 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
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. |
Abstract test B.115 | |
|---|---|
| Identifier | /conf/edr/rc-coords-definition-trajectory |
| Requirement | Requirement A.40: /req/edr/coords-definition |
| Test purpose | Validate that the coords query parameters are constructed correctly. |
| Test method | Verify that the coords query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment): name: coords Use a coords value in all requests:
|
Abstract test B.116 | |
|---|---|
| Identifier | /conf/edr/rc-coords-response-trajectory |
| Requirement | Requirement A.43: /req/edr/linestring-coords-response |
| Test purpose | Validate that the coords query parameters are processed correctly. |
| Test method |
|
Abstract test B.117 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-parameter-name-definition-trajectory |
| Requirement | Requirement A.46: /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.0 fragment): name: parameter-name |
Abstract test B.118 | |
|---|---|
| Identifier | /conf/edr/rc-parameter-name-response-trajectory |
| Requirement | Requirement A.47: /req/edr/parameter-name-response |
| Test purpose | Validate that the parameter-name query parameters are processed correctly. |
| Test method |
|
Abstract test B.119 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-definition-trajectory |
| Requirement | Requirement A.48: /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.0 fragment): name: crs |
Abstract test B.120 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-response-trajectory |
| Requirement | Requirement A.49: /req/edr/REQ_rc-crs-response |
| Test purpose | Validate that the crs query parameters are processed correctly. |
| Test method |
|
Abstract test B.121 | |
|---|---|
| Identifier | /conf/edr/rc-f-definition-trajectory |
| Requirement | Requirement A.50: /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.0 fragment): name: f |
Abstract test B.122 | |
|---|---|
| Identifier | /conf/collections/rc-f-response-trajectory |
| Requirement | Requirement A.51: /req/edr/REQ_rc-f-response |
| Test purpose | Validate that the f query parameters are processed correctly. |
| Test method |
|
B.10.1.6. Corridor
Abstract test B.123 | |
|---|---|
| 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 |
|
Abstract test B.124 | |
|---|---|
| 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 |
|
Abstract test B.125 | |
|---|---|
| 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 |
|
Abstract test B.126 | |
|---|---|
| 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 |
|
Abstract test B.127 | |
|---|---|
| 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 |
|
Abstract test B.128 | |
|---|---|
| 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 |
|
Abstract test B.129 | |
|---|---|
| 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 |
|
Abstract test B.130 | |
|---|---|
| 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 |
|
Abstract test B.131 | |
|---|---|
| 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 |
|
Abstract test B.132 | |
|---|---|
| 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 |
|
Abstract test B.133 | |
|---|---|
| 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 |
|
Abstract test B.134 | |
|---|---|
| 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 |
|
Abstract test B.135 | |
|---|---|
| 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 |
|
Abstract test B.136 | |
|---|---|
| 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 |
|
Abstract test B.137 | |
|---|---|
| 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 |
|
Abstract test B.138 | |
|---|---|
| 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
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. |
Abstract test B.139 | |
|---|---|
| Identifier | /conf/edr/rc-coords-definition-corridor |
| Requirement | Requirement A.40: /req/edr/coords-definition |
| Test purpose | Validate that the coords query parameters are constructed correctly. |
| Test method | Verify that the coords query parameter complies with the following definition (using an OpenAPI Specification 3.0 fragment): name: coords Use a coords value in all requests:
|
Abstract test B.140 | |
|---|---|
| Identifier | /conf/edr/rc-coords-response-corridor |
| Requirement | Requirement A.43: /req/edr/linestring-coords-response |
| Test purpose | Validate that the coords query parameters are processed correctly. |
| Test method |
|
Abstract test B.141 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-corridor-width-definition |
| Requirement | Requirement A.69: /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.0 fragment): name: corridor-width |
Abstract test B.142 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-corridor-width-response |
| Requirement | Requirement A.70: /req/edr/REQ_rc-corridor-width-response |
| Test purpose | Validate that the corridor-width query parameters are processed correctly. |
| Test method |
|
Abstract test B.143 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-corridor-height-definition |
| Requirement | Requirement A.65: /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.0 fragment): name: corridor-height |
Abstract test B.144 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-corridor-height-response |
| Requirement | Requirement A.66: /req/edr/REQ_rc-corridor-height-response |
| Test purpose | Validate that the corridor-height query parameters are processed correctly. |
| Test method |
|
Abstract test B.145 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-width-units-definition |
| Requirement | Requirement A.71: /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.0 fragment): name: width-units |
Abstract test B.146 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-width-units-response |
| Requirement | Requirement A.72: /req/edr/width-units-response |
| Test purpose | Validate that the width-units query parameters are processed correctly. |
| Test method |
|
Abstract test B.147 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-height-units-definition |
| Requirement | Requirement A.67: /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.0 fragment): name: height-units |
Abstract test B.148 | |
|---|---|
| Identifier | /conf/collections/rc-height-units-response |
| Requirement | Requirement A.68: /req/edr/height-units-response |
| Test purpose | Validate that the height-units query parameters are processed correctly. |
| Test method |
|
Abstract test B.149 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-parameter-name-definition-corridor |
| Requirement | Requirement A.46: /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.0 fragment): name: parameter-name |
Abstract test B.150 | |
|---|---|
| Identifier | /conf/edr/rc-parameter-name-response-corridor |
| Requirement | Requirement A.47: /req/edr/parameter-name-response |
| Test purpose | Validate that the parameter-name query parameters are processed correctly. |
| Test method |
|
Abstract test B.151 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-definition-corridor |
| Requirement | Requirement A.48: /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.0 fragment): name: crs |
Abstract test B.152 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-response-corridor |
| Requirement | Requirement A.49: /req/edr/REQ_rc-crs-response |
| Test purpose | Validate that the crs query parameters are processed correctly. |
| Test method |
|
Abstract test B.153 | |
|---|---|
| Identifier | /conf/edr/rc-f-definition-corridor |
| Requirement | Requirement A.50: /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.0 fragment): name: f |
Abstract test B.154 | |
|---|---|
| Identifier | /conf/collections/rc-f-response-corridor |
| Requirement | Requirement A.51: /req/edr/REQ_rc-f-response |
| Test purpose | Validate that the f query parameters are processed correctly. |
| Test method |
|
B.10.1.7. Instances {root}/collections/{collectionId}/instances
Abstract test B.155 | |
|---|---|
| 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 |
|
Abstract test B.156 | |
|---|---|
| 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.
Table B.4 — Schema and Tests for Collections content
| Format | Schema Document | Test ID |
|---|---|---|
| HTML | collections.yaml | /conf/html/content |
| JSON | collections.yaml | /conf/geojson/content |
B.10.1.8. Instance {root}/collections/{collectionId}/instances/instanceId
Abstract test B.157 | |
|---|---|
| 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 |
|
Abstract test B.158 | |
|---|---|
| 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.10.1.9. Locations
Abstract test B.159 | |
|---|---|
| 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 |
|
Abstract test B.160 | |
|---|---|
| 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 |
|
Abstract test B.161 | |
|---|---|
| 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
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. |
Abstract test B.162 | |
|---|---|
| Identifier | /conf/core/datetime-definition-locations |
| Requirement | Requirement A.44: /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.0 fragment): name: datetime |
Abstract test B.163 | |
|---|---|
| Identifier | /conf/core/datetime-response-locations |
| Requirement | Requirement A.45: /req/core/datetime-response |
| Test purpose | Validate that the datetime query parameters are processed correctly. |
| Test method |
|
Abstract test B.164 | |
|---|---|
| Identifier | /conf/collections/REQ_rc-parameter-name-definition-locations |
| Requirement | Requirement A.46: /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.0 fragment): name: parameter-name |
Abstract test B.165 | |
|---|---|
| Identifier | /conf/edr/rc-parameter-name-response-locations |
| Requirement | Requirement A.47: /req/edr/parameter-name-response |
| Test purpose | Validate that the parameter-name query parameters are processed correctly. |
| Test method |
|
Abstract test B.166 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-definition-locations |
| Requirement | Requirement A.48: /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.0 fragment): name: crs |
Abstract test B.167 | |
|---|---|
| Identifier | /conf/edr/REQ_rc-crs-response-locations |
| Requirement | Requirement A.49: /req/edr/REQ_rc-crs-response |
| Test purpose | Validate that the crs query parameters are processed correctly. |
| Test method |
|
Abstract test B.168 | |
|---|---|
| Identifier | /conf/edr/rc-f-definition-locations |
| Requirement | Requirement A.50: /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.0 fragment): name: f |
Abstract test B.169 | |
|---|---|
| Identifier | /conf/collections/rc-f-response-locations |
| Requirement | Requirement A.51: /req/edr/REQ_rc-f-response |
| Test purpose | Validate that the f query parameters are processed correctly. |
| Test method |
|
Annex C
(informative)
Collection Response Metadata (Informative)
This Annex contains a more-easily 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 API.
C.1. EDR Collection Object Structure
Collection objects describe both collections and instances of a collection.
Table C.1 — EDR Collection Object Structure
| 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 | No | 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.
Table C.2 — Link Object
| 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 http://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.
Table C.3 — Variables Object
| 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 | No | 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.
Table C.4 — CRS Details Object
| 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.
"link" : {
"href": "https://www.example.org/sourcedata/help",
"hreflang": "en",
"rel": "service-doc",
"type": "text/html",
}
Figure C.1
A more complex link example supporting a templated href with a mandatory coords parameter is shown below.
"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"
}
}
Figure C.2
C.5. Extent Object
The extent object describes the spatio-temporal area covered by the information available in the collection.
Table C.5 — Extent Object
| 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 |
C.6. Spatial Object
The spatial object describes the spatial area covered by the information available in the collection.
Table C.6 — Spatial Object
| Field Name | Type | Required | Description |
|---|---|---|---|
| bbox | Number Array | Yes | A bounding box is provided as four numbers:
|
| crs | String | Yes | This can either be a Well Known Text definition of the CRS or follow a convention of http://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. Temporal Object
The temporal object describes the time period covered by the information available in the collection.
Table C.7 — Temporal Object
| 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 | Yes | 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.8. Vertical Object
The vertical object describes the vertical extent of information available in the collection.
Table C.8 — Vertical Object
| 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 | Yes | Array of height values supported by the collection. |
| vrs | String | Yes | Follows the conventions defined by the Well Known Text standard. |
A simple extent object example for collection with no vertical or temporal dimensions is shown below.
"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]]"
}
}
Figure C.3
Below is a more complex extent object example for a collection with vertical and temporal dimensions.
"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']]"
}
}
Figure C.4
C.9. Data Queries Object
The data queries object provides the extra metadata required for the queries supported by the collection.
Table C.9 — Data Queries Object
| 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 |
| item | EDRQuery object | No | Item query metadata |
| location | EDRQuery object | No | Location query metadata |
C.10. EDR Query Object
The EDR query object provides the metadata for the specified query type.
Table C.10 — EDR Query Object
| Field Name | Type | Required | Description |
|---|---|---|---|
| link | Link object | Yes | Array of height values supported by the collection. |
A data query object example for a collection that supports Position and Radius queries is shown below.
"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\"]]" }
]
}
}
}
}
Figure C.5
C.11. 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.12. Parameter Object
Table C.11 — 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 |
| data-type | 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.13. Unit Object
The unit object provides the information to describe the units of measure of the parameter values.
Table C.12 — Unit Object
| Field Name | Type | Required | Description |
|---|---|---|---|
| label | String | Yes | Name of the unit |
| symbol | symbol object | Yes | Information to describe the symbols used to represent the unit |
C.14. Symbol Object
The symbol object provides the information to describe the symbols which represent the unit of a value.
Table C.13 — Symbol Object
| Field Name | Type | Required | Description |
|---|---|---|---|
| title | String | No | Symbol name |
| description | String | No | A text description of the symbol |
| 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.15. Observed Property Object
The observedProperty object provides the metadata for the specified query type.
Table C.14 — Observed Property Object
| 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.16. Measurement Type object
The measurementType object provides basic information about how the parameter is calculated and over what time period.
Table C.15 — Measurement Type object
| 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.
"parameter_names": {
"Temperature_altitude_above_msl": {
"type": "Parameter",
"description": "Temperature for Specific altitude above MSL",
"unit": {
"label": "K",
"symbol": {
"value": "K",
"type": "http://qudt.org/vocab/unit/K"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-0-0",
"label": "Temperature_altitude_above_msl"
},
"measurementType": {
"method": "instantaneous",
"period": "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": "http://qudt.org/vocab/unit/M-PER-SEC.html"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-2",
"label": "u-component_of_wind_altitude_above_msl"
},
"measurementType": {
"method": "instantaneous",
"period": "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": "http://qudt.org/vocab/unit/M-PER-SEC.html"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-3",
"label": "v-component_of_wind_altitude_above_msl"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0S"
}
}
}
}
Figure C.6
Annex D
(informative)
Examples (Informative)
D.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" }
]
}
D.2. API Description Examples
The API is described using the OpenAPI 3.0 specification, example responses for a server which supports all possible EDR query patterns can be found at:
D.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": [
"http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core",
"http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
"http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections",
"http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/oas30",
"http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/html",
"http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/geojson"
]
}
D.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",
"query_type": "position",
"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",
"query_type": "radius",
"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",
"query_type": "area",
"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",
"query_type": "locations",
"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": [
"http://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": "http://codes.wmo.int/common/quantity-kind/_windDirection",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_windSpeed",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"Wind Gust": {
"type": "Parameter",
"description": "",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_maximumWindGustSpeed",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"period": "-PT10M/PT0M"
}
},
"Air Temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/bufr4/b/13/_009",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Dew point": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_dewPointTemperature",
"label": "Dew point"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Pressure": {
"type": "Parameter",
"description": "",
"unit": {
"label": "hPa",
"symbol": {
"value": "hPa",
"type": "https://example.org/edr/metadata/units/hPa"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/bufr4/b/10/_051",
"label": "Pressure"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Pressure Tendancy": {
"type": "Parameter",
"description": "",
"unit": {
"label": "tendency",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/units/hPa"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_pressureTendency",
"label": "Pressure Tendancy"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "m",
"symbol": {
"value": "m",
"type": "https://example.org/edr/metadata/units/m"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"period": "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",
"query_type": "position",
"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",
"query_type": "radius",
"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",
"query_type": "area",
"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": [
"http://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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"Wind Speed": {
"type": "Parameter",
"description":"Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Probability of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probability of precipitation"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
}
}
}
]
}
D.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",
"query_type": "position",
"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",
"query_type": "radius",
"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",
"query_type": "area",
"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",
"query_type": "location",
"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": [
"http://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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Probabilty of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probabilty of precipitation"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"period": "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",
"query_type": "position",
"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",
"query_type": "radius",
"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",
"query_type": "area",
"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",
"query_type": "location",
"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": [
"http://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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Probabilty of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probabilty of precipitation"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"period": "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",
"query_type": "position",
"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",
"query_type": "radius",
"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",
"query_type": "area",
"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",
"query_type": "location",
"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": [
"http://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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Probabilty of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probabilty of precipitation"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"period": "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",
"query_type": "position",
"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",
"query_type": "radius",
"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",
"query_type": "area",
"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",
"query_type": "location",
"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": [
"http://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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-0",
"label": "Wind Direction"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"Wind Speed": {
"type": "Parameter",
"description": "Average wind speed",
"unit": {
"label": "mph",
"symbol": {
"value": "mph",
"type": "https://example.org/edr/metadata/units/mph"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Speed"
},
"measurementType": {
"method": "mean",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/grib2/codeflag/4.2/_0-2-1",
"label": "Wind Gust"
},
"measurementType": {
"method": "maximum",
"period": "-PT10M/PT0M"
}
},
"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": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Air Temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Weather": {
"type": "Parameter",
"description": "",
"unit": {
"label": "weather",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_weather"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/wmdr/ObservedVariableAtmosphere/_266",
"label": "Weather"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Relative Humidity": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Relative Humidity"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Feels like temperature": {
"type": "Parameter",
"description": "",
"unit": {
"label": "degC",
"symbol": {
"value": "°C",
"type": "https://example.org/edr/metadata/units/degC"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_airTemperature",
"label": "Feels like temperature"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"UV index": {
"type": "Parameter",
"description": "",
"unit": {
"label": "UV_index",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_uv"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-4-51",
"label": "UV index"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Probabilty of precipitation": {
"type": "Parameter",
"description": "",
"unit": {
"label": "percent",
"symbol": {
"value": "%",
"type": "https://example.org/edr/metadata/units/percent"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/grib2/codeflag/4.2/_0-1-1",
"label": "Probabilty of precipitation"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
},
"Visibility": {
"type": "Parameter",
"description": "",
"unit": {
"label": "quality",
"symbol": {
"value": "",
"type": "https://example.org/edr/metadata/lookup/mo_dp_visibility"
}
},
"observedProperty": {
"id": "http://codes.wmo.int/common/quantity-kind/_horizontalVisibility",
"label": "Visibility"
},
"measurementType": {
"method": "instantaneous",
"period": "PT0M"
}
}
}
}
]
}
D.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 E
(informative)
Relationship With Other OGC Standards
E.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.
E.2. Relationship between OGC API-EDR and OGC API-Features
The EDR API 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 also supports the retrieval of spatiotemporal data by named location as well as coordinates.
E.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 does not have the concept of orientation, or foliation or prisms. EDR API is OpenAPI defined, over HTTP(S), and not defined in UML.
Moving Features and EDR API do share a common conceptual definition, from ISO, of a Trajectory, but the Moving Features Standards encode trajectories in GML, CSV and Moving Features JSON, whereas the EDR API encodes trajectories in WKT. The Moving Features Standards support relationships between trajectories and other features, including other trajectories, the EDR API does not. Moving Features also explicitly supports concepts such as velocity, acceleration and distance along a trajectory, whereas the EDR API does not.
The Moving Features Standards consider trajectories as a primary resource to be queried, manipulated and processed, whereas in the EDR API, a trajectory is simply a query sampling pattern, encoded in WKT and ISO 8601 Date Time Format, into a spatiotemporal data resource.
E.4. Relationships between OGC API-EDR and Web Coverage Service and Coverage Implementation Schema
The primary messaging mechanism of the EDR API is JSON, including CoverageJSON, over HTTP(S). Implementations of the EDR API are described using the OpenAPI V3.0 specification. The target users are web-developers and end-users who are not geospatial experts. The target data resources are any dataset described as spatiotemporal, accessible by coordinates.
The EDR API 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. The EDR API can also be used to generate a single query against a collection of coverages, providing the data coordinate reference systems are consistent. The EDR API can support any of the WCS and CIS output formats if required. At the time of publication of version 1.0.0 of the EDR API, at least one EDR API implementation had been created by building on top of a WCS/CIS implementation.
The EDR API, with only a single form of spatiotemporal query, allows the retrieval of data from other data stores adhering to data models that are not coverages, such as features or observations.
E.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 of the EDR API is JSON, including CoverageJSON, over HTTP(S). Implementations of the EDR API are described using the OpenAPI V3.0 specification. 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 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 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.
E.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 had overlaps with SOS within 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 specification for describing resource paths, query options, JSON schema, and other aspects.
Further, the EDR API allows 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 the EDR API to hide the extra complexity, while users that do need all the details can use the SensorThings API to retrieve those.
Annex F
(informative)
Glossary
F.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.
F.2. Collection
body of resources that belong or are used together. An aggregate, set, or group of related resources. (OGC 20-024)
F.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.
F.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.
F.5. dataset
collection of data, published or curated by a single agent, and available for access or download in one or more formats (DCAT)
F.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.
F.7. Executable Test Suite (ETS)
A 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)
F.8. 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)
F.9. 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)
F.10. Requirements Class
aggregate of all requirement modules that shall all be satisfied to satisfy a conformance test class (OGC 08-131r3)
F.11. Requirements Module
aggregate of requirements and recommendations of a specification against a single standardization target type (OGC 08-131r3)
F.12. Spatial Resource
resources usually considered as Geospatial Data. (OGC 19-072)
F.13. 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.
F.14. Web API
API using an architectural style that is founded on the technologies of the Web. (W3C Data on the Web Best Practices)
Annex G
(informative)
Revision History
Table G.1 — 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 |
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