OGC API - Environmental Data Retrieval Standard Approved OGC Standard • OGC API - Environmental Data Retrieval Standard Mark Burgoyne Editor David Blodgett Editor Chuck Heazel Editor Chris Little Editor Submission Date: 2022-07-26 Approval Date: 2022-09-30 Publication Date: 2023-07-27 External identifier of this OGC® document: http://www.opengis.net/doc/IS/ogcapi-edr-1/1.1 Internal identifier of this OGC® document: 19-086r6 Version: 1.1 Additional Formats: PDF OGC Standard Approved Notice This document is an OGC Member approved international standard. This document is available on a royalty free, non-discriminatory basis. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. Document number: 19-086r6 Document type: OGC Standard Document subtype: Implementation Document stage: Approved Document language: English Copyright notice Copyright © 2023 Open Geospatial Consortium To obtain additional rights of use, visit https://www.ogc.org/legal Note 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. License Agreement Use of this document is subject to the license agreement at https://www.ogc.org/license Suggested additions, changes and comments on this document are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: http://ogc.standardstracker.org/ Contents I. Abstract II. Keywords III. Preface IV. Security considerations V. Submitting Organizations VI. Submitters 1. Scope 2. Conformance 2.1. Mandatory Requirements Classes 2.2. Optional Requirements Classes 3. Normative references 4. Terms and definitions 5. Conventions 5.1. Identifiers 5.2. Link relations 5.3. Media Types 5.4. Examples 5.5. Schema 5.6. Use of HTTPS 5.7. API definition 5.7.1. General remarks 5.7.2. Role of OpenAPI 5.7.3. References to OpenAPI components in normative statements 5.7.4. Paths in OpenAPI definitions 5.7.5. Reusable OpenAPI components 6. Overview 6.1. General 6.2. Resource Paths 7. Dependencies on Core and Collections Requirements Classes of OGC API — Common 7.1. Overview 7.2. Platform 7.2.1. API landing page 7.2.1.1. Operation 7.2.1.2. Response 7.2.1.3. Error Handling 7.2.2. API definition 7.2.2.1. Operation 7.2.2.2. Response 7.2.2.3. Error Handling 7.2.3. Declaration of conformance classes 7.2.3.1. Operation 7.2.3.2. Response 8. Query, Spatiotemporal and Information Resources 8.1. Information Resources 8.2. Query Resources 8.2.1. Position query 8.2.2. Radius query 8.2.3. Area query 8.2.4. Cube query 8.2.5. Trajectory query 8.2.6. Corridor query 8.2.7. Items query 8.2.7.1. Parameter itemId 8.2.8. Locations query 8.2.9. Instances query 8.2.9.1. Parameter instanceId 8.2.9.2. Parameter queryType 8.2.10. Custom dimension support 9. General Requirements 9.1. HTTP 1.1 9.2. HTTP Status Codes 9.3. Web Caching 9.4. Support for Cross-Origin Requests 9.5. Asynchronous queries 9.6. Coordinate Reference Systems 9.7. Encodings 9.8. Link Headers 9.9. OpenAPI 3.0 9.9.1. Basic requirements 9.9.2. Complete definition 9.9.3. Exceptions Annex A (informative) Requirements Detail A.1. Introduction A.2. Requirements Class “Core” in Detail A.2.1. Requirements Class: OGC API — Environmental Data Retrieval Core A.2.2. Requirement /req/core/conformance Core conformance classes A.2.3. Requirement /req/core/http HTTP A.2.4. Requirement /req/core/crs CRS A.3. Requirements Class “Collections” in Detail A.3.1. Requirements Class: Collections A.4. Requirements Class “Queries” for Position, Area, Cube, Trajectory, Corridor, Items, Locations, and Instances A.4.1. Requirements Class: Queries A.4.2. Requirements for Position Queries A.4.3. Requirements for Area Queries A.4.4. Requirements for Cube Queries A.4.5. Requirements for Trajectory Queries A.4.6. Requirements for Corridor Queries A.4.7. Requirements for Radius Queries A.4.8. Requirements for Items Queries A.4.9. Requirements for Locations Queries A.4.10. Requirements for Instances Queries 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 A.5.3. Requirement /req/core/rc-bbox-response Parameter bbox response A.5.4. Requirement /req/edr/coords-definition Parameter coords definition A.5.5. Requirement /req/edr/point-coords-response Parameter coords response A.5.6. Requirement /req/edr/polygon-coords-response Parameter coords response A.5.7. Requirement /req/edr/linestring-coords-response Parameter coords response A.5.8. Requirement /req/core/datetime-definition datetime definition A.5.9. Requirement /req/core/datetime-response datetime response A.5.10. Requirement /req/edr/REQ_rc-parameter-name-definition Parameter parameter-name definition A.5.11. Requirement /req/edr/parameter-name-response Parameter parameter-name response A.5.12. Requirement /req/edr/REQ_rc-crs-definition Parameter crs definition A.5.13. Requirement /req/edr/REQ_rc-crs-response Parameter crs response A.5.14. Requirement /req/edr/rc-f-definition Parameter f definition A.5.15. Requirement /req/edr/REQ_rc-f-response Parameter f response A.5.16. Requirement /req/edr/z-definition Parameter z definition A.5.17. Requirement /req/edr/z-response Parameter z response A.5.18. Requirement /req/edr/within-definition Parameter within definition A.5.19. Requirement /req/edr/REQ_rc-within-response Parameter within response A.5.20. Requirement /req/edr/within-units-definition Parameter within-units definition A.5.21. Requirement /req/edr/REQ_rc-within-units-response Parameter within-units response A.5.22. Requirement /req/edr/resolution-x-definition Parameter resolution-x definition A.5.23. Requirement /req/edr/resolution-x-response Parameter resolution-x response A.5.24. Requirement /req/edr/cube-z-response Parameter z response for cube queries A.5.25. Requirement /req/edr/resolution-y-definition Parameter resolution-y definition A.5.26. Requirement /req/edr/resolution-y-response Parameter resolution-y response A.5.27. Requirement /req/edr/resolution-z-definition Parameter resolution-z definition A.5.28. Requirement /req/edr/resolution-z-response Parameter resolution-z response A.5.29. Requirement /req/edr/REQ_rc-corridor-height-definition Parameter corridor-height definition A.5.30. Requirement /req/edr/REQ_rc-corridor-height-response Parameter corridor-height response A.5.31. Requirement /req/edr/REQ_rc-height-units-definition Parameter height-units definition A.5.32. Requirement /req/edr/height-units-response Parameter height-units response A.5.33. Requirement /req/edr/corridor-width-definition Parameter corridor-width definition A.5.34. Requirement /req/edr/REQ_rc-corridor-width-response Parameter corridor-width response A.5.35. Requirement /req/edr/REQ_rc-width-units-definition Parameter width-units definition A.5.36. Requirement /req/edr/width-units-response Parameter width-units response A.5.37. Requirement /req/edr/custom-dimension-definition Custom Parameter definition A.5.38. Requirement /req/edr/custom-dimension-response Custom Parameter response A.6. Requirements Class “JSON” in Detail A.6.1. Requirements Class: JSON A.7. Requirements Class “GeoJSON” in Detail A.7.1. Requirements Class: GeoJSON A.8. Requirements Class “EDR GeoJSON” in Detail A.8.1. Requirements Class: EDR GeoJSON A.8.2. Requirement /req/edr-geojson/content A.9. Requirements Class “CoverageJSON” in Detail A.9.1. Requirements Class: CoverageJSON A.10. Requirements Class “HTML” in Detail A.10.1. Requirements Class: HTML A.11. Requirements Class “OpenAPI 3.0” in Detail A.11.1. Requirements Class: OpenAPI 3.0 A.11.2. Requirement /req/oas30/oas-impl OpenAPI 3.0 implementation A.11.3. Requirement /req/oas30/oas-definition-1 A.11.4. Requirement /req/oas30/oas-definition-2 OpenAPI 3.0 conformance A.11.5. Requirement /req/oas30/completeness OpenAPI 3.0 Completeness A.11.6. Requirement /req/oas30/exceptions-codes OpenAPI 3.0 Exception codes A.11.7. Requirement /req/oas30/security OpenAPI 3.0 Security Annex B (informative) Abstract Test Suite (Normative) B.1. Introduction B.2. Conformance Class Core B.2.1. General Tests B.2.1.1. HTTP B.2.2. Landing Page {root}/ B.2.3. API Definition Path {root}/api (link) B.2.4. Conformance Path {root}/conformance B.3. Conformance Class Collections B.3.1. General Tests B.3.1.1. CRS B.3.2. Environmental Data Collections {root}/collections B.3.3. Environmental Data Collection {root}/collections/{collectionId} B.3.4. Second Tier Collections Tests B.3.4.1. Collection Extent B.3.4.2. Collection Queries B.3.4.3. Collection Links B.3.4.4. Collection Parameters B.4. Conformance Class JSON B.4.1. JSON Definition B.4.2. JSON Content B.5. Conformance Class GeoJSON B.5.1. GeoJSON Definition B.5.2. GeoJSON Content B.6. Conformance Class EDR GeoJSON B.6.1. EDR GeoJSON Definition B.6.2. EDR GeoJSON Content B.7. Conformance Class CoverageJSON B.7.1. CoverageJSON Definition B.7.2. CoverageJSON Content B.8. Conformance Class HTML B.8.1. HTML Definition B.8.2. HTML Content B.9. Conformance Class OpenAPI 3.0 B.10. Conformance Class Queries B.10.1. Query Pattern Tests B.10.1.1. Position B.10.1.2. Radius B.10.1.3. Area B.10.1.4. Cube B.10.1.5. Trajectory B.10.1.6. Corridor B.10.1.7. Instances {root}/collections/{collectionId}/instances B.10.1.8. Instance {root}/collections/{collectionId}/instances/instanceId B.10.1.9. Locations Annex C (informative) Collection Response Metadata (Informative) C.1. EDR Collection Object Structure C.2. Link Object C.3. Variables Object C.4. CRS Details Object C.5. Extent Object C.6. Spatial Object C.7. Temporal Object C.8. Vertical Object C.9. Data Queries Object C.10. EDR Query Object C.11. Parameter Names Object C.12. Parameter Object C.13. Unit Object C.14. Symbol Object C.15. Observed Property Object C.16. Measurement Type object Annex D (informative) Examples (Informative) D.1. Example Landing Pages D.2. API Description Examples D.3. Conformance Examples D.4. Collections Metadata Examples D.5. Instance Metadata Examples D.6. Location Query Metadata Examples Annex E (informative) Relationship With Other OGC Standards E.1. Introduction E.2. Relationship between OGC API-EDR and OGC API-Features E.3. Relationships between OGC API-EDR and Moving Features standards E.4. Relationships between OGC API-EDR and Web Coverage Service and Coverage Implementation Schema E.5. Relationship between OGC API-EDR and the OGC MetOcean Application profile of Web Coverage Service (WCS) 2.1 E.6. Relationships between OGC API-EDR, SOS and SensorThings API Annex F (informative) Glossary Annex G (informative) Revision History Bibliography Top 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 HTML GeoJSON CoverageJSON 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 Position Radius Area Cube Trajectory Corridor Items Locations Instances 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, https://docs.ogc.org/DRAFTS/20-024.html 4. Terms and definitions This document uses the terms defined in OGC Policy Directive 49 , which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2. This document also uses terms defined in the OGC Standard for Modular specifications ( OGC 08-131r3 ), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec. For the purposes of this document, the following additional terms and definitions apply. The Glossary includes terms from other standards and specifications that, while not normative, are critical to accurately understand this 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 API-EDR Section API-EDR Requirements Class API-Common Requirements Class API Landing Page http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/core http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core API Definition http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/core http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core Declaration of Conformance Classes http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/core http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core Collections http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/collections http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections OpenAPI 3.0 http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/oas30 http://www.opengis.net/spec/ogcapi-common-1/1.0/req/oas30 GeoJSON http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/geojson http://www.opengis.net/spec/ogcapi-common-1/1.0/req/json CoverageJSON http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/covjson http://www.opengis.net/spec/ogcapi-common-1/1.0/req/json HTML http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/html http://www.opengis.net/spec/ogcapi-common-1/1.0/req/html 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 Core, http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core 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 Core, http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core 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 Core, http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core 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 definition rules WKT string Yes The coordinates are defined by a Point Well Known Text (WKT) string coords=POINT(-3 51) coords= MULTIPOINT((-77 38.9),(2.35 48.85),(116.38 39.92),(149.1 -35.29),(-0.1 51.5)) z definition rules 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) z=850 z=1000,900,850,700 z=2/100 datetime definition rules 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) datetime=2018-02-12T00:00Z datetime=2018-02-12T00:00/2018-03-18T12:31Z datetime=2018-02-12T00:00Z,2018-02-12T01:00Z,2018-02-14T12:00Z parameter-name definition rules String No Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) parameter-name=Visibility,Air%20Temperature crs definition rules String No Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) crs=EPSG:4326 crs=A_CUSTOM_LABEL f definition rules 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/ ) f=GeoJSON f=netCDF4 f=CoverageJSON f=CSV 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 definition rules WKT string Yes The coordinates are defined by a Point Well Known Text (WKT) string coords=POINT(-3 51) coords= MULTIPOINT((-77 38.9),(2.35 48.85),(116.38 39.92),(149.1 -35.29),(-0.1 51.5)) z definition rules 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) z=850 z=1000,900,850,700 z=2/100 datetime definition rules 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) datetime=2018-02-12T00:00Z datetime=2018-02-12T00:00/2018-03-18T12:31Z datetime=2018-02-12T00:00Z,2018-02-12T01:00Z,2018-02-14T12:00Z parameter-name definition rules String No Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) parameter-name=Visibility,Air%20Temperature within definition rules String Yes Defines radius of area around defined coordinates to include in the data selection within=20 within-units definition rules 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) within-units=Miles crs definition rules String No Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) crs=EPSG:4326 crs=A_CUSTOM_LABEL f definition rules 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/ ) f=GeoJSON f=netCDF4 f=CoverageJSON f=CSV 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 definition rules WKT string Yes The coordinates are defined by a Polygon Well Known Text (WKT) string coords=POLYGON((-6.1 50.3,-4.35 51.4,-2.6 51.6,-2.8 50.6,-5.3 49.9,-6.1 50.3)) coords=MULTIPOLYGON(((-15 48.8,-15 60.95,5 60.85,5 48.8,-15 48.8)),-6.1 50.3,-4.35 51.4,-2.6 51.6,-2.8 50.6,-5.3 49.9,-6.1 50.3) z definition rules 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) z=850 z=1000,900,850,700 z=2/100 datetime definition rules 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) datetime=2018-02-12T00:00Z datetime=2018-02-12T00:00/2018-03-18T12:31Z datetime=2018-02-12T00:00Z,2018-02-12T01:00Z,2018-02-14T12:00Z parameter-name definition rules String No Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) parameter-name=Visibility,Air%20Temperature crs definition rules String No Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) crs=EPSG:4326 crs=A_CUSTOM_LABEL f definition rules 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/ ) f=GeoJSON f=netCDF4 f=CoverageJSON f=CSV 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 definition rules 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. Lower left corner, coordinate axis 1 Lower left corner, coordinate axis 2 Upper right corner, coordinate axis 1 Upper right corner, coordinate axis 2 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. bbox=-6.0,50.0,-4.35,52.0 z definition rules 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) z=850 z=1000,900,850,700 z=2/100 datetime definition rules 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) datetime=2018-02-12T00:00Z datetime=2018-02-12T00:00/2018-03-18T12:31Z datetime=2018-02-12T00:00Z,2018-02-12T01:00Z,2018-02-14T12:00Z parameter-name definition rules String No Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) parameter-name=Visibility,Air%20Temperature crs definition rules String No Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) crs=EPSG:4326 crs=A_CUSTOM_LABEL f definition rules 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/ ) f=GeoJSON f=netCDF4 f=CoverageJSON f=CSV 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 definition rules WKT string Yes The coordinates are defined by one of the following Well Known Text (WKT) strings: LINESTRING LINESTRINGZ LINESTRINGM LINESTRINGZM The Z in LINESTRINGZ and LINESTRINGZM refers to the height value. If the specified CRS does not define the height units, the heights units will default to meters above mean sea level The M in LINESTRINGM and LINESTRINGZM refers to the number of seconds that have elapsed since the Unix epoch, that is the time 00:00:00 UTC on 1 January 1970. See https://en.wikipedia.org/wiki/Unix_time A Simple 2D trajectory coords=LINESTRING(-3.53 50.72,-3.35 50.92,-3.11 51.02,-2.85 51.42,-2.59 51.46) A 2D trajectory with mutiple segments: coords=MULTILINESTRING-3.53 50.72,-3.35 50.92),(-3.11 51.02,-2.85 51.42,-2.59 51.46 A 2D trajectory with all waypoints at same time: coords=LINESTRING(-3.53 50.72,-3.35 50.92,-3.11 51.02,-2.85 51.42,-2.59 51.46)&datetime=2018-02-12T23:00:00Z A 2D trajectory, all waypoints at the same height : coords=LINESTRING(-3.53 50.72,-3.35 50.92,-3.11 51.02,-2.85 51.42,-2.59 51.46)&z=850 A 2D trajectory, all waypoints at the same time and height: coords=LINESTRING(51.14 -2.98, 51.36 -2.87, 51.03 -3.15, 50.74 -3.48, 50.9 -3.36)&datetime=2018-02-12T23:00:00Z&z=850 A 3D trajectory each waypoint at a different time: coords=LINESTRINGM(51.14 -2.98 1560507000, 51.36 -2.87 1560507600, 51.03 -3.15 1560508200, 50.74 -3.48 1560508500, 50.9 -3.36 1560510240) A 3D trajectory, each waypoint at a different time by at the same height: coords=LINESTRINGM(51.14 -2.98 1560507000, 51.36 -2.87 1560507600, 51.03 -3.15 1560508200, 50.74 -3.48 1560508500, 50.9 -3.36 1560510240)&z=200 A 3D trajectory, each waypoint at a different height: coords=LINESTRINGZ(-3.53 50.72 0.1,-3.35 50.92 0.2,-3.11 51.02 0.3,-2.85 51.42 0.4,-2.59 51.46 0.5) A 3D trajectory each waypoint at a different height but the same time: coords=LINESTRINGZ(-3.53 50.72 0.1,-3.35 50.92 0.2,-3.11 51.02 0.3,-2.85 51.42 0.4,-2.59 51.46 0.5)&datetime=2018-02-12T23:00:00Z A 4D trajectory, each waypoint at different heights and times: coords=LINESTRINGZM (-3.53 50.72 0.1 1560507000,-3.35 50.92 0.2 1560508800,-3.11 51.02 0.3 1560510600,-2.85 51.42 0.41560513600,-2.59 51.46 0.5 1560515400) z definition rules 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) z=850 z=1000,900,850,700 z=2/100 datetime definition rules 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) datetime=2018-02-12T00:00Z datetime=2018-02-12T00:00/2018-03-18T12:31Z datetime=2018-02-12T00:00Z,2018-02-12T01:00Z,2018-02-14T12:00Z parameter-name definition rules String No Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) parameter-name=Visibility,Air%20Temperature crs definition rules String No Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) crs=EPSG:4326 crs=A_CUSTOM_LABEL f definition rules 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/ ) f=GeoJSON f=netCDF4 f=CoverageJSON f=CSV 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 definition rules WKT string Yes The coordinates are defined by one of the following Well Known Text (WKT) strings: LINESTRING LINESTRINGZ LINESTRINGM LINESTRINGZM The Z in LINESTRINGZ and LINESTRINGZM refers to the height value. If the specified CRS does not define the height units, the height units will default to meters above mean sea level The M in LINESTRINGM and LINESTRINGZM refers to the number of seconds that have elapsed since the Unix epoch, that is the time 00:00:00 UTC on 1 January 1970. See https://en.wikipedia.org/wiki/Unix_time A 2D corridor, on the surface of earth with no time or vertical dimensions: coords=LINESTRING(-3.53 50.72,-3.35 50.92,-3.11 51.02,-2.85 51.42,-2.59 51.46) A 2D corridor with multiple segments, on the surface of earth with no time or vertical dimensions: coords=MULTILINESTRING-3.53 50.72,-3.35 50.92),(-3.11 51.02,-2.85 51.42,-2.59 51.46 A 2D corridor, on the surface of earth all at the same time and no vertical dimension, time value defined in ISO8601 format by the datetime query parameter : coords=LINESTRING(-3.53 50.72,-3.35 50.92,-3.11 51.02,-2.85 51.42,-2.59 51.46)&datetime=2018-02-12T23:00:00Z A 2D corridor, on the surface of earth with no time value but at a fixed vertical height, height defined in the collection height units by the z query parameter : coords=LINESTRING(-3.53 50.72,-3.35 50.92,-3.11 51.02,-2.85 51.42,-2.59 51.46)&z=850 A 2D corridor, on the surface of earth all at a the same time and at a fixed vertical height, time value defined in ISO8601 format by the datetime query parameter and height defined in the collection height units by the z query parameter : coords=LINESTRING(51.14 -2.98, 51.36 -2.87, 51.03 -3.15, 50.74 -3.48, 50.9 -3.36)&datetime=2018-02-12T23:00:00Z&z=850 A 3D corridor, on the surface of the earth but over a range of time values with no height values: coords=LINESTRINGM(51.14 -2.98 1560507000, 51.36 -2.87 1560507600, 51.03 -3.15 1560508200, 50.74 -3.48 1560508500, 50.9 -3.36 1560510240) A 3D corridor, on the surface of the earth but over a range of time values with a fixed height value, height defined in the collection height units by the z query parameter : coords=LINESTRINGM(51.14 -2.98 1560507000, 51.36 -2.87 1560507600, 51.03 -3.15 1560508200, 50.74 -3.48 1560508500, 50.9 -3.36 1560510240)&z=200 A 3D corridor, through a 3D volume with vertical height or depth, but no defined time: coords=LINESTRINGZ(-3.53 50.72 0.1,-3.35 50.92 0.2,-3.11 51.02 0.3,-2.85 51.42 0.4,-2.59 51.46 0.5) A 3D corridor, through a 3D volume with a vertical extent, but at a fixed time, time value defined in ISO8601 format by the datetime query parameter: coords=LINESTRINGZ(-3.53 50.72 0.1,-3.35 50.92 0.2,-3.11 51.02 0.3,-2.85 51.42 0.4,-2.59 51.46 0.5)&datetime=2018-02-12T23:00:00Z A 4D corridor, through a 3D volume but over a range of time values: coords=LINESTRINGZM (-3.53 50.72 0.1 1560507000,-3.35 50.92 0.2 1560508800,-3.11 51.02 0.3 1560510600,-2.85 51.42 0.41560513600,-2.59 51.46 0.5 1560515400) z definition rules 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) z=850 z=1000,900,850,700 z=2/100 datetime definition rules 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) datetime=2018-02-12T00:00Z datetime=2018-02-12T00:00/2018-03-18T12:31Z datetime=2018-02-12T00:00Z,2018-02-12T01:00Z,2018-02-14T12:00Z parameter-name definition rules String No Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) parameter-name=Visibility,Air%20Temperature resolution-x definition rules 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-x=10 resolution-y definition rules 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-y=5 resolution-z definition rules 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 resolution-z=100 corridor-width definition rules 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 corridor-width=100 width-units definition rules 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) width-units=KM corridor-height definition rules 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 corridor-height=100 height-units definition rules 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) height-units=hPa crs definition rules String No coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) crs=EPSG:4326 crs=A_CUSTOM_LABEL f definition rules 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/ ) f=GeoJSON f=netCDF4 f=CoverageJSON f=CSV 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 definition rules 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. Lower left corner, coordinate axis 1 Lower left corner, coordinate axis 2 Upper right corner, coordinate axis 1 Upper right corner, coordinate axis 2 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. bbox=-6.0,50.0,-4.35,52.0 datetime definition rules 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) datetime=2018-02-12T00:00Z datetime=2018-02-12T00:00/2018-03-18T12:31Z datetime=2018-02-12T00:00Z,2018-02-12T01:00Z,2018-02-14T12:00Z limit definition rules String No Maximum number of items to return limit=10 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. EGLL Ottawa limit.broom.flip gbsvn datetime definition rules 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) datetime=2018-02-12T00:00Z datetime=2018-02-12T00:00/2018-03-18T12:31Z datetime=2018-02-12T00:00Z,2018-02-12T01:00Z,2018-02-14T12:00Z parameter-name definition rules String No Comma delimited list of parameter names (available options are listed in the parameter_names section of the collections metadata response) parameter-name=Visibility,Air%20Temperature crs definition rules String No Coordinate reference system identifier for the coords values and output data (available options are listed in the collections metadata response) crs=EPSG:4326 crs=A_CUSTOM_LABEL f definition rules 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/ ) f=GeoJSON f=netCDF4 f=CoverageJSON f=CSV 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_name 1 definition rules 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) realisations=5 realisations=1,9,15,25 realisations=9/15 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)) & parameter-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 ? & parameter-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: Cross-origin resource sharing (CORS) JSONP (JSON with padding) 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: the API definition (relation type service-desc or service-doc ) /conformance (relation type conformance ) /collections (relation type data ) 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: 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/core 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: position radius area cube trajectory corridor items locations 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: if the attribute type has the value position verify the variables property complies with /req/edr/rc-common-variables if the attribute type has the value radius verify the variables property complies with /req/edr/rc-radius-variables if the attribute type has the value area verify the variables property complies with /req/edr/rc-common-variables if the attribute type has the value cube verify the variables property complies with /req/edr/rc-cube-variables if the attribute type has the value trajectory verify the variables property complies with /req/edr/rc-common-variables if the attribute type has the value corridor verify the variables property complies with /req/edr/rc-corridor-variables if the attribute type has the value items verify the variables property complies with /req/edr/rc-items-variables if the attribute type has the value locations verify the variables property complies with /req/edr/rc-common-variables 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: a link to this response document (relation: self ), a link to the response document in every other media type supported by the server (relation: alternate ). at least one link to a query end point. 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 Requirements class A.4: Query parameters Identifier http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/query_parameters 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.38: /req/core/rc-bbox-definition Requirement A.39: /req/core/rc-bbox-response Requirement A.40: /req/edr/coords-definition Requirement A.41: /req/edr/point-coords-response Requirement A.42: /req/edr/polygon-coords-response Requirement A.43: /req/edr/linestring-coords-response Requirement A.44: /req/core/datetime-definition Requirement A.45: /req/core/datetime-response Requirement A.46: /req/edr/REQ_rc-parameter-name-definition Requirement A.47: /req/edr/parameter-name-response Requirement A.48: /req/edr/REQ_rc-crs-definition Requirement A.49: /req/edr/REQ_rc-crs-response Requirement A.50: /req/edr/rc-f-definition Requirement A.51: /req/edr/REQ_rc-f-response Requirement A.52: /req/edr/z-definition Requirement A.53: /req/edr/z-response Requirement A.54: /req/edr/within-definition Requirement A.55: /req/edr/REQ_rc-within-response Requirement A.56: /req/edr/within-units-definition Requirement A.57: /req/edr/REQ_rc-within-units-response Requirement A.58: /req/edr/resolution-x-definition Requirement A.59: /req/edr/resolution-x-response Requirement A.60: /req/edr/cube-z-response Requirement A.61: /req/edr/resolution-y-definition Requirement A.62: /req/edr/resolution-y-response Requirement A.63: /req/edr/resolution-z-definition Requirement A.64: /req/edr/resolution-z-response Requirement A.65: /req/edr/REQ_rc-corridor-height-definition Requirement A.66: /req/edr/REQ_rc-corridor-height-response Requirement A.67: /req/edr/REQ_rc-height-units-definition Requirement A.68: /req/edr/height-units-response Requirement A.69: /req/edr/corridor-width-definition Requirement A.70: /req/edr/REQ_rc-corridor-width-response Requirement A.71: /req/edr/REQ_rc-width-units-definition Requirement A.72: /req/edr/width-units-response Requirement A.73: /req/edr/custom-dimension-definition Requirement A.74: /req/edr/custom-dimension-response 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 in: query required: false schema: oneOf: - items: minItems: 4 maxItems: 4 type: number type: array - items: minItems: 6 maxItems: 6 type: number type: array style: form explode: false 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): Lower left corner, coordinate axis 1 Lower left corner, coordinate axis 2 Minimum value, coordinate axis 3 (optional) Upper right corner, coordinate axis 1 Upper right corner, coordinate axis 2 Maximum value, coordinate axis 3 (optional) 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 in: query required: true schema: type: string style: form explode: false 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 in: query required: false schema: type: string style: form explode: false 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 interval - open - start = "../" date - time interval - open - end = date - time "/.." interval = interval - closed / interval - open - start / interval - open - end datetime = date - time / interval 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 in: query required: false explode: false schema: minItems: 1 type: array items: type: string 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 in: query required: false schema: type: string style: form explode: false 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 in: query required: false schema: type: string style: form explode: false 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 in: query required: false schema: type: string style: form explode: false 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 R number 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 in: query required: true schema: type: string style: form explode: false 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 in: query required: false schema: type: string style: form explode: false 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 in: query required: false schema: type: string style: form explode: false 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 R number 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 in: query required: false schema: type: string style: form explode: false 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 in: query required: false schema: type: string style: form explode: false 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 in: query required: true schema: type: string style: form explode: false 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 in: query required: true schema: type: string style: form explode: false 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 in: query required: true schema: type: string style: form explode: false 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 in: query required: true schema: type: string style: form explode: false 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 required: false schema: type: string style: form explode: false 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 R number 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: application/json for all resources. 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 a GeoJSON FeatureCollection Object for features, and a GeoJSON Feature Object for a single feature. 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: application/geo+json for resources that include feature content, and application/json for all other resources. 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 an EDR GeoJSON FeatureCollection Object for features, and an EDR GeoJSON Feature Object for a single feature. 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: application/geo+json for resources that include feature content, and application/json for all other resources. 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 a CoverageJSON Object 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: application/prs.coverage+json for resources that include data content, and application/json for all other resources. 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: all information identified in the schemas of the Response Object in the HTML <body> , and all links in HTML <a> elements 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: relation type service-desc and content type application/vnd.oai.openapi+json;version=3.0 , relation type service-doc and content type text/html . 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 All compliance tests shall be configured to use the HTTP 1.1 protocol exclusively. For APIs which support HTTPS, all compliance tests shall be configured to use HTTP over TLS (RFC 2818) with their HTTP 1.1 protocol. 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 Issue an HTTP GET request to the URL {root}/ Validate that a document was returned with a status code 200 Validate the contents of the returned document using test /conf/core/root-success . 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: Validate that the landing page includes a “service-desc” and/or “service-doc” link to an API Definition Validate that the landing page includes a “conformance” link to the conformance class declaration Validate that the landing page includes a “data” link to the Feature contents. 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 Construct a path for each API Definition link on the landing page Issue an HTTP GET request on each path Validate that a document was returned with a status code 200 Validate the contents of the returned document using test /conf/core/api-definition-success . 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 Construct a path for each “conformance” link on the landing page as well as for the {root}/conformance path. Issue an HTTP GET request on each path Validate that a document was returned with a status code 200 Validate the contents of the returned document using test /conf/core/conformance-success . 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 Validate the response document against OpenAPI 3.0 schema confClasses.yaml Validate that the document includes the conformance class “http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core” Validate that the document lists all OGC API conformance classes that the API implements. B.3. Conformance Class Collections Conformance class B.2: Collections Identifier http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/collections Subject http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/collections Prerequisite http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections Target Type Web API Conformance tests Abstract test B.8: /conf/core/crs Abstract test B.9: /conf/collections/rc-md-op Abstract test B.10: /conf/rc-md-success Abstract test B.11: /conf/collections/src-md-op Abstract test B.12: /conf/collections/src-md-success Abstract test B.13: /conf/core/rc-extent Abstract test B.14: /conf/edr/rc-collection-info Abstract test B.15: /conf/edr/rc-data-queries Abstract test B.16: /conf/edr/rc-common-query-type Abstract test B.17: /conf/edr/rc-common-variables Abstract test B.18: /conf/edr/rc-radius-variables Abstract test B.19: /conf/edr/rc-cube-variables Abstract test B.20: /conf/edr/rc-corridor-variables Abstract test B.21: /conf/edr/rc-items-variables Abstract test B.22: /conf/edr/rc-md-query-links Abstract test B.23: /conf/core/rc-collection-info-links Abstract test B.24: /conf/edr/rc-parameters 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 Do not specify a coordinate reference system in any request. All spatial data should be in the CRS defined by the spatial element of the extent section in the collection response. Validate retrieved spatial data is using the CRS defined by the spatial element of the extent section in the collection response. 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 Issue an HTTP GET request to the URL {root}/collections Validate that a document was returned with a status code 200 Validate the contents of the returned document using test /conf/rc-md-success . 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 Validate that all response documents comply with /req/core/rc-collection-info-links In case the response includes a “crs” property, validate that it includes a valid Well Known Text definition Validate the collections content for all supported media types using the resources and tests identified in Table B.2 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. Validate that a Collection was returned with a status code 200 Validate the contents of the returned document using test /conf/collections/src-md-success . 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 Verify that the extent provides bounding boxes that include all spatial geometries Verify that if the extent provides time intervals that they include all temporal geometries in this collection. A temporal extent of null indicates an open time interval. Verify that if the extent provides vertical intervals that they include all vertical geometries in this collection. A vertical extent of null indicates an open vertical interval. 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 Verify that all collections listed in the collections array of the Collections Metadata exist. Verify that each collection entry includes an identifier. Verify that each collection entry includes links in accordance with /conf/core/rc-collection-info-links . Verify that each collection entry includes an extent property in accordance with /conf/core/rc-extent Verify that the collection entry includes a data_queries property in accordance with /req/edr/rc-data-queries Verify that if the collection data_queries entry includes a crs property, the property complies with /conf/edr/rc-crs Verify that each collection entry includes a parameter_names property, and the property complies with /req/edr/rc-parameters Validate each collection entry for all supported media types using the resources and tests identified in Table B.3 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 Verify that at least one of the following data query types are defined in the data query section: position radius area cube trajectory corridor items locations verify that all query types defined comply with /conf/edr/rc-common-query-type 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 Verify that the data queries object has a link property Verify that the link property has a href property Verify that the link property has a rel property Verify that the link property has a variables property Verify that if the data_queries object is of type position , area , trajectory or locations the property complies with /req/edr/rc-common-variables Verify that if the data_queries object is of type `radius`the property complies with /req/edr/rc-radius-variables Verify that if the data_queries object is of type `cube`the property complies with /req/edr/rc-cube-variables Verify that if the data_queries object is of type `corridor`the property complies with /req/edr/rc-corridor-variables Verify that if the data_queries object is of type `items`the property complies with /req/edr/rc-items-variables 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 Verify that the variables object has a query_type property Verify that the value of the query_type property matches the name of the data query type If the variables object has an output_formats property verify that it is an array of strings If the variables object has a default_output_format property verify that the value is in either the output_formats property of the variables object or the output_formats property of the parent collection. If the variables object has a crs_details property verify that it is an array of crs objects, and each member object of the array has crs_details and wkt properties. 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 Verify that the variables property complies with /req/edr/rc-common-variables Verify that the variables property has a within_units property Verify that the within_units property is a string array 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 Verify that the variables property complies with /req/edr/rc-common-variables Verify that the variables property has a height_units property Verify that the height_units property is a string array 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 Verify that the variables property complies with /req/edr/rc-common-variables Verify that the variables property has a height_units property Verify that the height_units property is a string array Verify that the variables property has a width_units property Verify that the width_units property is a string array 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 Verify that the value of the query_type property is items 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: a link to this response document (relation: self ), a link to the response document in every other media type supported by the server (relation: alternate ). 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 Verify that all parameters listed in a collection have the required properties. Verify that each parameter property has a unique name (in the collection). Verify that each parameter property has a type property. Verify that each parameter property has an observedProperty property. Verify that the observedProperty property has a label property with correctly defined i18n compliant values. Verify that the observedProperty property has an id property. 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 A resource is requested with response media type of application/json All 200 -responses SHALL support the media type: application/json 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 Validate that the document is a JSON document. Validate the document against the schema using a JSON Schema validator. 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 A resource is requested with response media type of application/geo+json All 200 -responses SHALL support the following media types: application/geo+json for resources that include feature content, and application/json for all other resources. 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 Validate that the document is a GeoJSON document. Validate the document against the schema using a JSON Schema validator. Validate the document against the schema using a GeoJSON Schema validator. 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 A resource is requested with response media type of application/json and adheres to the EDR Feature Collection GeoJSON Schema. All 200 -responses SHALL support the following media types: application/json for resources 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 Validate that the document is an EDR GeoJSON document. Validate the document against one of the EDR GeoJSON schemas: FeatureCollection: edrFeatureCollectionGeoJSON.yaml Feature: featureGeoJSON.yaml GeometryCollection: geometrycollectionGeoJSON.yaml using a JSON Schema validator. 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 A resource is requested with response media type of application/prs.coverage+json All 200 -responses SHALL support the following media types: application/prs.coverage+json for resources 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 Validate that the document is a CoverageJSON document. Validate the document against the coverageJSON.yaml schema using a JSON Schema validator. 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 Validate that the document is an HTML 5 document Manually inspect the document against the schema. 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 Verify that an OpenAPI definition in JSON is available using the media type application/vnd.oai.openapi+json;version=3.0 and link relation service-desc Verify that an HTML version of the API definition is available using the media type text/html and link relation service-doc . 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 Construct a path from each URL template including all server URL options and all enumerated path parameters. For each path defined in the OpenAPI document, validate that the path performs in accordance with the API definition and the API-Features standard. 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 Identify all authentication protocols supported by the API. Validate that each authentication protocol is described in the OpenAPI document by a Security Schema Object and its use specified by a Security Requirement Object. B.10. Conformance Class Queries Conformance class B.9: Queries Identifier http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/queries Subject http://www.opengis.net/spec/ogcapi-edr-1/1.1/req/queries Prerequisites Conformance class B.1: http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/core Conformance class B.2: http://www.opengis.net/spec/ogcapi-edr-1/1.1/conf/collections Target Type Web API Conformance tests Abstract test B.41: /conf/position/no-query-params Abstract test B.42: /conf/position/no-coords-param Abstract test B.43: /conf/position/coords-param-invalid Abstract test B.44: /conf/position/valid-query-params Abstract test B.45: /conf/edr/rc-coords-definition-position Abstract test B.46: /conf/edr/rc-coords-response-position Abstract test B.47: /conf/edr/rc-z-definition-position Abstract test B.48: /conf/edr/rc-z-response-position Abstract test B.49: /conf/core/datetime-definition-position Abstract test B.50: /conf/core/datetime-response-position Abstract test B.51: /conf/collections/REQ_rc-parameter-name-definition-position Abstract test B.52: /conf/edr/rc-parameter-name-response-position Abstract test B.53: /conf/edr/REQ_rc-crs-definition-position Abstract test B.54: /conf/edr/REQ_rc-crs-response-position Abstract test B.55: /conf/edr/rc-f-definition-position Abstract test B.56: /conf/collections/rc-f-response-position Abstract test B.75: /conf/area/no-query-params Abstract test B.76: /conf/area/no-coords-param Abstract test B.77: /conf/area/coords-param-invalid Abstract test B.78: /conf/area/valid-query-params Abstract test B.79: /conf/edr/rc-coords-definition-area Abstract test B.80: /conf/edr/rc-coords-response-area Abstract test B.81: /conf/edr/rc-z-definition-area Abstract test B.82: /conf/edr/rc-z-response-area Abstract test B.83: /conf/core/datetime-definition-area Abstract test B.84: /conf/core/datetime-response-area Abstract test B.85: /conf/collections/REQ_rc-parameter-name-definition-area Abstract test B.86: /conf/edr/rc-parameter-name-response-area Abstract test B.87: /conf/edr/REQ_rc-crs-definition-area Abstract test B.88: /conf/edr/REQ_rc-crs-response-area Abstract test B.89: /conf/edr/rc-f-definition-area Abstract test B.90: /conf/collections/rc-f-response-area Abstract test B.91: /conf/cube/no-query-params Abstract test B.92: /conf/cube/no-bbox-param Abstract test B.93: /conf/cube/bbox-param-invalid Abstract test B.94: /conf/cube/valid-query-params Abstract test B.95: /conf/edr/rc-z-definition-cube Abstract test B.96: /conf/edr/rc-z-response-cube Abstract test B.97: /conf/core/datetime-definition-cube Abstract test B.98: /conf/core/datetime-response-cube Abstract test B.99: /conf/collections/REQ_rc-parameter-name-definition-cube Abstract test B.100: /conf/edr/rc-parameter-name-response-cube Abstract test B.101: /conf/edr/REQ_rc-crs-definition-cube Abstract test B.102: /conf/edr/REQ_rc-crs-response-cube Abstract test B.103: /conf/edr/rc-f-definition-cube Abstract test B.104: /conf/collections/rc-f-response-cube Abstract test B.105: /conf/trajectory/no-query-params Abstract test B.106: /conf/trajectory/no-coords-param Abstract test B.107: /conf/trajectory/coords-param-invalid-linestring Abstract test B.108: /conf/trajectory/coords-param-invalid-linestringm Abstract test B.109: /conf/trajectory/coords-param-separate-z-linestringz Abstract test B.110: /conf/trajectory/coords-param-separate-z-linestringzm Abstract test B.111: /conf/trajectory/coords-param-invalid-linestringzm Abstract test B.112: /conf/trajectory/coords-param-invalid-linestringz Abstract test B.113: /conf/trajectory/coords-param-invalid-time Abstract test B.114: /conf/trajectory/valid-query-params Abstract test B.115: /conf/edr/rc-coords-definition-trajectory Abstract test B.116: /conf/edr/rc-coords-response-trajectory Abstract test B.117: /conf/collections/REQ_rc-parameter-name-definition-trajectory Abstract test B.118: /conf/edr/rc-parameter-name-response-trajectory Abstract test B.119: /conf/edr/REQ_rc-crs-definition-trajectory Abstract test B.120: /conf/edr/REQ_rc-crs-response-trajectory Abstract test B.121: /conf/edr/rc-f-definition-trajectory Abstract test B.122: /conf/collections/rc-f-response-trajectory Abstract test B.123: /conf/corridor/no-query-params Abstract test B.124: /conf/corridor/no-coords-param Abstract test B.125: /conf/corridor/corridor-width-param-missing Abstract test B.126: /conf/corridor/corridor-height-param-missing Abstract test B.127: /conf/corridor/width-units-param-missing Abstract test B.128: /conf/corridor/height-units-param-missing Abstract test B.129: /conf/corridor/coords-param-invalid-linestring Abstract test B.130: /conf/corridor/coords-param-invalid-linestringm Abstract test B.131: /conf/corridor/coords-param-separate-z-linestringz Abstract test B.132: /conf/corridor/coords-param-separate-z-linestringzm Abstract test B.133: /conf/corridor/coords-param-invalid-linestringzm Abstract test B.134: /conf/corridor/coords-param-invalid-linestringz Abstract test B.135: /conf/corridor/coords-param-invalid-time Abstract test B.136: /conf/corridor/width-units-param-invalid Abstract test B.137: /conf/corridor/height-units-param-invalid Abstract test B.138: /conf/corridor/valid-query-params Abstract test B.139: /conf/edr/rc-coords-definition-corridor Abstract test B.140: /conf/edr/rc-coords-response-corridor Abstract test B.141: /conf/edr/REQ_rc-corridor-width-definition Abstract test B.142: /conf/collections/REQ_rc-corridor-width-response Abstract test B.143: /conf/edr/REQ_rc-corridor-height-definition Abstract test B.144: /conf/collections/REQ_rc-corridor-height-response Abstract test B.145: /conf/edr/REQ_rc-width-units-definition Abstract test B.146: /conf/collections/REQ_rc-width-units-response Abstract test B.147: /conf/edr/REQ_rc-height-units-definition Abstract test B.148: /conf/collections/rc-height-units-response Abstract test B.149: /conf/collections/REQ_rc-parameter-name-definition-corridor Abstract test B.150: /conf/edr/rc-parameter-name-response-corridor Abstract test B.151: /conf/edr/REQ_rc-crs-definition-corridor Abstract test B.152: /conf/edr/REQ_rc-crs-response-corridor Abstract test B.153: /conf/edr/rc-f-definition-corridor Abstract test B.154: /conf/collections/rc-f-response-corridor Abstract test B.155: /conf/instances/rc-md-op Abstract test B.156: /conf/instances/rc-md-success Abstract test B.157: /conf/instances/src-md-op Abstract test B.158: /conf/instances/src-md-success Abstract test B.159: /conf/locations/no-query-params Abstract test B.160: /conf/locations/location-identifier-invalid Abstract test B.161: /conf/locations/valid-query-params Abstract test B.162: /conf/core/datetime-definition-locations Abstract test B.163: /conf/core/datetime-response-locations Abstract test B.164: /conf/collections/REQ_rc-parameter-name-definition-locations Abstract test B.165: /conf/edr/rc-parameter-name-response-locations Abstract test B.166: /conf/edr/REQ_rc-crs-definition-locations Abstract test B.167: /conf/edr/REQ_rc-crs-response-locations Abstract test B.168: /conf/edr/rc-f-definition-locations Abstract test B.169: /conf/collections/rc-f-response-locations 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 No query parameters are specified Validate that a document was returned with a status code 400. 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 coords query parameter is not specified Validate that a document was returned with a status code 400. 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 Check coords query parameter is a valid Well Known Text Point or MultiPoint value Validate that a document was returned with a status code 400. 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 Test with valid query parameters Validate that a document was returned with a status code 200. Repeat these tests using the following parameter tests: Coordinates Parameter /req/edr/coords-definition Response /req/edr/point-coords-response VerticalLevel Parameter /req/edr/z-definition Response /req/edr/z-response Parameters Parameter /req/edr/REQ_rc-parameter-name-definition Response /req/edr/parameter-name-response DateTime Parameter /req/core/datetime-definition Response /req/core/datetime-response 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 in: query required: true schema: type: string style: form explode: false Use a coords value in all requests: A valid Well-Known Text (WKT) representation of geometry string 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 Verify that only resources that have a spatial geometry that intersects the coordinates are returned as part of the result set. Verify coords values are valid for the specified coordinate reference system Verify that the coordinate reference system of the geometries is valid for the parameter defined by crs . If the crs parameter is not defined the geometries shall be valid for the coordinate reference system defined by the spatial element of the extent section in the collection response. 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources that have a vertical geometry that intersects the vertical information in the z parameter were included in the result set Validate that the vertical level parameter complies with the syntax described in /req/edr/z-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources that have a temporal geometry that intersects the temporal information in the datetime parameter were included in the result set. Verify that all resources in the collection that are not associated with a temporal geometry are included in the result set. Validate that the datetime parameter complies with the syntax described in /req/core/datetime-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources for the requested parameters were included in the result set Validate that the parameter-name parameter complies with the syntax described in /req/edr/parameter-name-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the geometry of the resources returned are valid for the requested coordinate reference system Verify that all crs values defined in the collections metadata are supported by the collection Verify that all crs values not defined in the collections metadata will generate a HTTP 400 error Validate that the crs parameter complies with the syntax described in /req/edr/REQ_rc-crs-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the response is returned in the requested data format Verify that all output format values defined in the collections metadata are supported by the collection Validate that the f parameter complies with the syntax described in /req/edr/REQ_rc-f-response . 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 No query parameters are specified Validate that a document was returned with a status code 400. 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 coords query parameter is not specified Validate that a document was returned with a status code 400. 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 Check coords query parameter is a valid Well Known Text Point or MultiPoint value Validate that a document was returned with a status code 400. 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 within query parameter is not specified Validate that a document was returned with a status code 400. 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 within_units query parameter is not specified Validate that a document was returned with a status code 400. 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 Test with valid query parameters Validate that a document was returned with a status code 200. Repeat these tests using the following parameter tests: Coordinates Parameter /req/edr/coords-definition Response /req/edr/point-coords-response VerticalLevel Parameter /req/edr/z-definition Response /req/edr/z-response Parameters Parameter /req/edr/REQ_rc-parameter-name-definition Response /req/edr/parameter-name-response DateTime Parameter /req/core/datetime-definition Response /req/core/datetime-response 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 in: query required: true schema: type: string style: form explode: false Use a coords value in all requests: A valid Well-Known Text (WKT) representation of geometry string 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 Verify that only resources that have a spatial geometry that intersects the coordinates are returned as part of the result set. Verify coords values are valid for the specified coordinate reference system Verify that the coordinate reference system of the geometries is valid for the parameter defined by crs . If the crs parameter is not defined the geometries shall be valid for the coordinate reference system defined by the spatial element of the extent section in the collection response. 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources that have a vertical geometry that intersects the vertical information in the z parameter were included in the result set Validate that the vertical level parameter complies with the syntax described in /req/edr/z-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources that have a temporal geometry that intersects the temporal information in the datetime parameter were included in the result set. Verify that all resources in the collection that are not associated with a temporal geometry are included in the result set. Validate that the datetime parameter complies with the syntax described in /req/core/datetime-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources for the requested parameters were included in the result set Validate that the parameter-name parameter complies with the syntax described in /req/edr/parameter-name-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the geometry of the resources returned are valid for the requested coordinate reference system Verify that all crs values defined in the collections metadata are supported by the collection Verify that all crs values not defined in the collections metadata will generate a HTTP 400 error Validate that the crs parameter complies with the syntax described in /req/edr/REQ_rc-crs-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the response is returned in the requested data format Verify that all output format values defined in the collections metadata are supported by the collection Validate that the f parameter complies with the syntax described in /req/edr/REQ_rc-f-response . 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 No query parameters are specified Validate that a document was returned with a status code 400. 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 coords query parameter is not specified Validate that a document was returned with a status code 400. 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 Check coords query parameter is a valid Well Known Text POLYGON or MULTIPOLYGON value Validate that a document was returned with a status code 400. 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 Test with valid query parameters Validate that a document was returned with a status code 200. Repeat these tests using the following parameter tests: Coordinates Parameter /req/edr/coords-definition Response /req/edr/coords-response VerticalLevel Parameter /req/edr/z-definition Response /req/edr/z-response Parameters Parameter /req/edr/REQ_rc-parameter-name-definition Response /req/edr/parameter-name-response DateTime Parameter /req/core/datetime-definition Response /req/core/datetime-response 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 in: query required: true schema: type: string style: form explode: false Use a coords value in all requests: A valid Well-Known Text (WKT) representation of geometry string 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 Verify that only resources that have a spatial geometry that intersects the coordinates are returned as part of the result set. Verify coords values are valid for the specified coordinate reference system Verify that the coordinate reference system of the geometries is valid for the parameter defined by crs . If the crs parameter is not defined the geometries shall be valid for the coordinate reference system defined by the spatial element of the extent section in the collection response. 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources that have a vertical geometry that intersects the vertical information in the z parameter were included in the result set Validate that the vertical level parameter complies with the syntax described in /req/edr/z-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources that have a temporal geometry that intersects the temporal information in the datetime parameter were included in the result set. Verify that all resources in the collection that are not associated with a temporal geometry are included in the result set. Validate that the datetime parameter complies with the syntax described in /req/core/datetime-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources for the requested parameters were included in the result set Validate that the parameter-name parameter complies with the syntax described in /req/edr/parameter-name-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the geometry of the resources returned are valid for the requested coordinate reference system Verify that all crs values defined in the collections metadata are supported by the collection Verify that all crs values not defined in the collections metadata will generate a HTTP 400 error Validate that the crs parameter complies with the syntax described in /req/edr/REQ_rc-crs-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the response is returned in the requested data format Verify that all output format values defined in the collections metadata are supported by the collection Validate that the f parameter complies with the syntax described in /req/edr/REQ_rc-f-response . 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 No query parameters are specified Validate that a document was returned with a status code 400. 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 bbox query parameter is not specified Validate that a document was returned with a status code 400. 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 Check bbox query parameter is valid Validate that a document was returned with a status code 400. 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 Test with valid query parameters Validate that a document was returned with a status code 200. Repeat these tests using the following parameter tests: bbox Parameter /req/core/rc-bbox-definition Response /req/core/rc-bbox-response VerticalLevel Parameter /req/edr/z-definition Response /req/edr/cube-z-response Parameters Parameter /req/edr/REQ_rc-parameter-name-definition Response /req/edr/parameter-name-response DateTime Parameter /req/core/datetime-definition Response /req/core/datetime-response 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources that have a vertical geometry that intersects the vertical information in the z parameter were included in the result set Validate that the vertical level parameter complies with the syntax described in /req/edr/cube-z-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources that have a temporal geometry that intersects the temporal information in the datetime parameter were included in the result set. Verify that all resources in the collection that are not associated with a temporal geometry are included in the result set. Validate that the datetime parameter complies with the syntax described in /req/core/datetime-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources for the requested parameters were included in the result set Validate that the parameter-name parameter complies with the syntax described in /req/edr/parameter-name-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the geometry of the resources returned are valid for the requested coordinate reference system Verify that all crs values defined in the collections metadata are supported by the collection Verify that all crs values not defined in the collections metadata will generate a HTTP 400 error Validate that the crs parameter complies with the syntax described in /req/edr/REQ_rc-crs-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the response is returned in the requested data format Verify that all output format values defined in the collections metadata are supported by the collection Validate that the f parameter complies with the syntax described in /req/edr/REQ_rc-f-response . 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 No query parameters are specified Validate that a document was returned with a status code 400. 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 coords query parameter is not specified Validate that a document was returned with a status code 400. 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 Check coords query parameter is a valid Well Known Text LINESTRING or MULTILINESTRING value Validate that a document was returned with a status code 400. 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 Check coords query parameter with time parameter is a valid Well Known Text LINESTRINGM or MULTILINESTRINGM value, the M coordinate shall be a valid Epoch value (as known as UNIX time) Validate that a document was returned with a status code 400. 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 Check coords query parameter that the system throws an error when a vertical level is specified in both the coords and z parameters Validate that a document was returned with a status code 400. 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 Check coords query parameter that the system throws an error when a vertical level is specified in both the coords and z parameters Validate that a document was returned with a status code 400. 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 Check coords query parameter with time parameter is a valid Well Known Text LINESTRINGZM or MULTILINESTRINGZM value, the Z coordinate shall be within the range of vertical levels advertised in the Collection metadata Validate that a document was returned with a status code 400. 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 Check coords query parameter with time parameter is a valid Well Known Text LINESTRINGZ or MULTILINESTRINGZ value, the Z coordinate shall be within the range of vertical levels advertised in the Collection metadata Validate that a document was returned with a status code 400. 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 If time values are specified in the coords query parameter check that they are within the range of time values defined in the Collection metadata. Validate that a document was returned with a status code 400. 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 Test with valid query parameters Validate that a document was returned with a status code 200. Repeat these tests using the following parameter tests: Coordinates Parameter /req/edr/coords-definition Response /req/edr/linestring-coords-response VerticalLevel Parameter /req/edr/z-definition Response /req/edr/z-response Parameters Parameter /req/edr/REQ_rc-parameter-name-definition Response /req/edr/parameter-name-response DateTime Parameter /req/core/datetime-definition Response /req/core/datetime-response 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 in: query required: true schema: type: string style: form explode: false Use a coords value in all requests: A valid Well-Known Text (WKT) representation of geometry string 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 Verify that only resources that have a spatial geometry that intersects the coordinates are returned as part of the result set. Verify coords values are valid for the specified coordinate reference system Verify that the coordinate reference system of the geometries is valid for the parameter defined by crs . If the crs parameter is not defined the geometries shall be valid for the coordinate reference system defined by the spatial element of the extent section in the collection response. 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources for the requested parameters were included in the result set Validate that the parameter-name parameter complies with the syntax described in /req/edr/parameter-name-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the geometry of the resources returned are valid for the requested coordinate reference system Verify that all crs values defined in the collections metadata are supported by the collection Verify that all crs values not defined in the collections metadata will generate a HTTP 400 error Validate that the crs parameter complies with the syntax described in /req/edr/REQ_rc-crs-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the response is returned in the requested data format Verify that all output format values defined in the collections metadata are supported by the collection Validate that the f parameter complies with the syntax described in /req/edr/REQ_rc-f-response . 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 No query parameters are specified Validate that a document was returned with a status code 400. 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 coords query parameter is not specified Validate that a document was returned with a status code 400. 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 corridor-width query parameter is not specified Validate that a document was returned with a status code 400. 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 corridor-height query parameter is not specified Validate that a document was returned with a status code 400. 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 width-units query parameter is not specified Validate that a document was returned with a status code 400. 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 height-units query parameter is not specified Validate that a document was returned with a status code 400. 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 Check coords query parameter is a valid Well Known Text LINESTRING or MULTILINESTRING value Validate that a document was returned with a status code 400. 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 Check coords query parameter with time parameter is a valid Well Known Text LINESTRINGM or MULTILINESTRINGM value, the M coordinate shall be a valid Epoch value (as known as UNIX time) Validate that a document was returned with a status code 400. 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 Check coords query parameter that the system throws an error when a vertical level is specified in both the coords and z parameters Validate that a document was returned with a status code 400. 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 Check coords query parameter that the system throws an error when a vertical level is specified in both the coords and z parameters Validate that a document was returned with a status code 400. 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 Check coords query parameter with time parameter is a valid Well Known Text LLINESTRINGZM or MULTILINESTRINGZM value, the Z coordinate shall be within the range of vertical levels advertised in the Collection metadata Validate that a document was returned with a status code 400. 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 Check coords query parameter with time parameter is a valid Well Known Text LINESTRINGZ or MULTILINESTRINGZ value, the Z coordinate shall be within the range of vertical levels advertised in the Collection metadata Validate that a document was returned with a status code 400. 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 If time values are specified in the coords query parameter check that they are within the range of time values defined in the Collection metadata Validate that a document was returned with a status code 400. 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 Specify a width-units value that is not listed in the collection response Validate that a document was returned with a status code 400. 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 Specify a height-units value that is not listed in the collection response Validate that a document was returned with a status code 400. 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 Test with valid query parameters Validate that a document was returned with a status code 200. Repeat these tests using the following parameter tests: Coordinates Parameter /req/edr/coords-definition Response /req/edr/linestring-coords-response VerticalLevel Parameter /req/edr/z-definition Response /req/edr/z-response Parameters Parameter /req/edr/REQ_rc-parameter-name-definition Response /req/edr/parameter-name-response DateTime Parameter /req/core/datetime-definition Response /req/core/datetime-response 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 in: query required: true schema: type: string style: form explode: false Use a coords value in all requests: A valid Well-Known Text (WKT) representation of geometry string 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 Verify that only resources that have a spatial geometry that intersects the coordinates are returned as part of the result set. Verify coords values are valid for the specified coordinate reference system Verify that the coordinate reference system of the geometries is valid for the parameter defined by crs . If the crs parameter is not defined the geometries shall be valid for the coordinate reference system defined by the spatial element of the extent section in the collection response. 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 in: query required: true schema: type: string style: form explode: false 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 Verify that a 400 error will be generated if corridor-width is not specified Validate that the corridor-width parameter complies with the syntax described in /req/edr/REQ_rc-corridor-width-response . 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 in: query required: true schema: type: string style: form explode: false 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 Verify that a 400 error will be generated if corridor-height is not specified Validate that the corridor-height parameter complies with the syntax described in /req/edr/REQ_rc-corridor-height-response . 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 in: query required: true schema: type: string style: form explode: false 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 Verify that units not listed in the metadata will generate an error message Validate that the width-units parameter complies with the syntax described in /req/edr/width-units-response . 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 in: query required: true schema: type: string style: form explode: false 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 Verify that height units not listed in the metadata will generate an error message Validate that the height-units parameter complies with the syntax described in /req/edr/height-units-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources for the requested parameters were included in the result set Validate that the parameter-name parameter complies with the syntax described in /req/edr/parameter-name-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the geometry of the resources returned are valid for the requested coordinate reference system Verify that all crs values defined in the collections metadata are supported by the collection Verify that all crs values not defined in the collections metadata will generate a HTTP 400 error Validate that the crs parameter complies with the syntax described in /req/edr/REQ_rc-crs-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the response is returned in the requested data format Verify that all output format values defined in the collections metadata are supported by the collection Validate that the f parameter complies with the syntax described in /req/edr/REQ_rc-f-response . 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 Issue an HTTP GET request to the URL {root}/collections/{collectionId}/instances Validate that a document was returned with a status code 200 Validate the contents of the returned document using test /conf/instances/rc-md-success . 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 Validate that all response documents comply with /req/core/rc-collection-info-links Validate the collections content for all supported media types using the resources and tests identified in Table B.2 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 For every Instance of a Collection described in the Collections content, issue an HTTP GET request to the URL /collections/{collectionId}/instances/{instanceId} where {collectionId} is the id property for the collection and {instanceId} is the id property for the instance. Validate that an Instance of a Collection was returned with a status code 200 Validate the contents of the returned document using test /conf/instances/src-md-success . 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 No query parameters are specified Validate that a GeoJSON document was returned with a status code 200 containing at least a list of features one for each location supported by the collection. 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 Check that invalid locationId values return an error message Validate that a document was returned with a status code 404. 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 Test with valid query parameters Validate that a document was returned with a status code 200. Repeat these tests using the following parameter tests: Parameters Parameter /req/edr/REQ_rc-parameter-name-definition Response /req/edr/parameter-name-response DateTime Parameter /req/core/datetime-definition Response /req/core/datetime-response 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources that have a temporal geometry that intersects the temporal information in the datetime parameter were included in the result set. Verify that all resources in the collection that are not associated with a temporal geometry are included in the result set. Validate that the datetime parameter complies with the syntax described in /req/core/datetime-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that only resources for the requested parameters were included in the result set Validate that the parameter-name parameter complies with the syntax described in /req/edr/parameter-name-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the geometry of the resources returned are valid for the requested coordinate reference system Verify that all crs values defined in the collections metadata are supported by the collection Verify that all crs values not defined in the collections metadata will generate a HTTP 400 error Validate that the crs parameter complies with the syntax described in /req/edr/REQ_rc-crs-response . 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 in: query required: false schema: type: string style: form explode: false 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 Verify that the response is returned in the requested data format Verify that all output format values defined in the collections metadata are supported by the collection Validate that the f parameter complies with the syntax described in /req/edr/REQ_rc-f-response . 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: Lower left corner, coordinate axis 1 Lower left corner, coordinate axis 2 Upper right corner, coordinate axis 1 Upper right corner, coordinate axis 2 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 negative sign before a duration value (i.e. -PT10M) infers that the time start starts at the specified duration before the time value assigned to the parameter value . So if the measurement had a time value of 2020-04-05T14:30Z and a measurementType duration of -PT10M the value is representative of the period 2020-04-05T14:20Z/2020-04-05T14:30Z ; if the measurement had a time value of 2020-04-05T14:30Z and a measurementType duration of PT10M the value is representative of the period 2020-04-05T14:30Z/2020-04-05T14:40Z 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: YAML OpenAPI document 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