Merge branch 'master' into Update-URLs

.github/workflows/build-openapi-bundle.yml

@@ -13,11 +13,11 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: Setup npm
-      uses: actions/setup-node@v2
+      uses: actions/setup-node@v4
     - name: Install dependencies
       run: npm install -g @apidevtools/swagger-cli
     - name: Checkout
-      uses: actions/checkout@v2
+      uses: actions/checkout@master
       with:
         fetch-depth: 0
     - name: Generate OpenAPI bundle

.github/workflows/test-build-openapi-bundle.yml

@@ -13,11 +13,11 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: Setup npm
-      uses: actions/setup-node@v2
+      uses: actions/setup-node@v4
     - name: Install dependencies
       run: npm install -g @apidevtools/swagger-cli
     - name: Checkout
-      uses: actions/checkout@v2
+      uses: actions/checkout@master
       with:
         repository: ${{ github.event.pull_request.head.repo.full_name }}
         ref: ${{ github.event.pull_request.head.ref }}

LICENSE

@@ -0,0 +1,11 @@
+Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
+
+If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
+
+THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
+
+THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
+
+This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
+
+Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

core/standard/openapi/parameters/core/cube-bbox.yaml

@@ -0,0 +1,32 @@
+name: bbox
+in: query
+description: |-
+  Only features that have a geometry that intersects the bounding box are selected.
+  The 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
+
+  For WGS 84 longitude/latitude the values are in most cases the sequence of
+  minimum longitude, minimum latitude, maximum longitude and maximum latitude.
+  However, in cases where the box spans the antimeridian the first value
+  (west-most box edge) is larger than the third value (east-most box edge).
+  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.
+required: true
+schema:
+  oneOf:
+    - items:
+        type: number
+      type: array
+      minItems: 4
+      maxItems: 4
+    - items:
+        type: number
+      type: array
+      minItems: 6
+      maxItems: 6
+style: form
+explode: false

core/standard/openapi/paths/queries/cube.yaml

@@ -7,7 +7,7 @@ get:
   operationId: GetDataForCube
   parameters:
     - $ref: ../../parameters/collections/collectionId.yaml
-    - $ref: ../../parameters/core/bbox.yaml
+    - $ref: ../../parameters/core/cube-bbox.yaml
     - $ref: ../../parameters/core/cube-z.yaml
     - $ref: https://beta.schemas.opengis.net/ogcapi/common/part2/0.1/collections/openapi/parameters/datetime.yaml
     - $ref: ../../parameters/core/parameter-name.yaml

core/standard/requirements/edr/query_type/item.adoc

@@ -30,7 +30,7 @@ a| **bbox**
 
 * <<req_core_rc-bbox-definition,definition>> 
 
-* <<req_core_rc-bbox-response,rules>>|String|**Yes** a| The coordinates are defined by a BBOX string. Only data that has a geometry that intersects the <<area-definition,area>> defined by the <<req_core_rc-bbox-definition,bbox>>
+* <<req_core_rc-bbox-response,rules>>|String|**No** a| The coordinates are defined by a BBOX string. Only data that has a geometry that intersects the <<area-definition,area>> defined by the <<req_core_rc-bbox-definition,bbox>>
 are selected.
 
 * Lower left corner, coordinate axis 1

core/standard/sections/clause_0_front_material.adoc

@@ -41,7 +41,7 @@ All questions regarding this submission should be directed to the editor or the
 [abstract]
 == 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 <<rc_core-section,Core Requirements Class>>.
+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 *Radius*, *Area* or *Cube*, along a *Trajectory* or through a *Corridor*, from a predefined *Location* or as an existing data *Item*. 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 <<rc_core-section,Core Requirements Class>>.
 
 The goals of the EDR Application Programming Interface (API) that is specified by this standard are to:
 
@@ -50,7 +50,9 @@ The goals of the EDR Application Programming Interface (API) that is specified b
 
 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-definition,Position>>, <<area-definition,Area>>, <<cube-definition,Cube>>, <<trajectory-definition,Trajectory>> or <<corridor-definition,Corridor>> - can be thought of as discrete sampling geometries, conceptually consistent with the feature of interest in the https://www.ogc.org/standards/sos[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 https://www.ogc.org/standards/wcs[Web Coverage Service (WCS)] standard. In contrast to SOS and WCS, the EDR API is fully consistent with the patterns of the https://ogcapi.ogc.org/[OGC API] family of standards and aims to provide a single set of simple-to-use query patterns. Use cases for EDR range from real or virtual time-series observation retrievals, to sub-setting 4-dimensional data cubes along user-supplied sampling geometries. These query patterns do not attempt to satisfy the full scope of either SOS or WCS, but instead provide useful building blocks to enable the composition of APIs that satisfy a wide range of geospatial data use cases. By defining a small set of query patterns (and no requirement to implement all of them), the EDR API should help to simplify the design of systems (as they can be performance tuned for the supported queries) making it easier to build robust and scalable infrastructures.
+The EDR API query patterns - <<position-definition,Position>>, <<radius-definition,radius>>, <<area-definition,Area>>, <<cube-definition,Cube>>, <<trajectory-definition,Trajectory>>, <<corridor-definition,Corridor>> or <<location-definition, Location>>  - can be thought of as discrete sampling geometries, conceptually consistent with the feature of interest in the https://www.ogc.org/standards/sos[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 http://www.ogc.org/standards/wcs[Web Coverage Service (WCS)] standard. In contrast to SOS and WCS, the EDR API is fully consistent with the patterns of the https://ogcapi.ogc.org/[OGC API] family of standards and aims to provide a single set of simple-to-use query patterns. Use cases for EDR range from real or virtual time-series observation retrievals, to sub-setting 4-dimensional data cubes along user-supplied sampling geometries. These query patterns do not attempt to satisfy the full scope of either SOS or WCS, but instead provide useful building blocks to enable the composition of APIs that satisfy a wide range of geospatial data use cases. By defining a small set of query patterns (and no requirement to implement all of them), the EDR API should help to simplify the design of systems (as they can be performance tuned for the supported queries) making it easier to build robust and scalable infrastructures.
+
+The EDR API *Item* query pattern provides a way of discovering and retrieving existing data objects available from the service. 
 
 With the OGC API family of standards, the OGC community has extended its suite of standards to include Resource Oriented Architectures and Web Application Programming Interfaces (APIs). These standards are based on a shared foundation, specified in https://ogcapi.ogc.org/common[OGC API-Common], which defines the resources and access paths that are supported by all OGC APIs. The resources are listed in <<common-paths>>. This document extends that foundation to define the EDR API.
 

ogc-web-api-guidelines/OGC API EDR Checklist V1.1.md

@@ -8,28 +8,28 @@ See an example in the [OGC API - Common - Part 1: Core Standard](https://docs.og
 
 | # | Principle | Discussion
 | -- | -- | --
-|	1	|	Don’t reinvent	|	
-|	2	|	Keep it simple and intuitive	|	
-|	3	|	Use well-known resource types	|	
-|	4	|	Construct consistent URIs	|	
-|	5	|	Use HTTP methods consistent with RFC 7231	|	
-|	6	|	Put selection criteria behind the ‘?’	|	
-|	7	|	Error handling and use of HTTP status codes	|	
-|	8	|	Use explicit list of HTTP status codes	|	
-|	9	|	Use of HTTP header	|	
-|	10	|	Allow flexible content negotiation	|	
-|	11	|	Pagination	|	
-|	12	|	Processing resources	|	
-|	13	|	Support metadata	|	
-|	14	|	Consider your security needs	|	
-|	15	|	API description	|	
-|	16	|	Use well-known identifiers	|	
-|	17	|	Use explicit relations	|	
-|	18	|	Support W3C cross-origin resource sharing	|	
-|	19	|	Resource encodings	|	
-|	20	|	Good APIs are testable from the beginning	|	
-|	21	|	Specify whether operations are safe and/or idempotent	|	
-|	22	|	Make resources discoverable	|	
-|	23	|	Make default behavior explicit	|	
+|	1	|	Don’t reinvent	|	Adopts concepts from OGC API - Common (landing page, conformance, collections, datetime query parameter) and OGC API - Features (`/collections/{collectionId}/items`) and uses WKT and ISO8601 for most syntax
+|	2	|	Keep it simple and intuitive	| Allows for minimal compliant implementation (1 query type) - provides interaction with minimal domain knowledge - provide query types as convenience / shortcuts to common subsetting patterns
+|	3	|	Use well-known resource types	|	Provides a resource agnostic and inclusive API - CoverageJSON resource type is `application/vnd.cov+json`. Another type may be registered with IANA if appropriate
+|	4	|	Construct consistent URIs	|	Adopts collection of resources principle  - `/collections/{collectionId}/items`  - `/collections/{collectionId}/{queryType}`
+|	5	|	Use HTTP methods consistent with RFC 7231	| Implements resource-based HTTP `GET` and `POST` methods. HTTP `POST` helps with URL truncation and security of sending sensitive data. Future work may add support for HTTP `OPTIONS`, required for CORS/preflight
+|	6	|	Put selection criteria behind the ‘?’	| Provides query parameter support in order to further subset a given resource/query type
+|	7	|	Error handling and use of HTTP status codes	| Provides exception schema (code and description) as well as the appropriate HTTP status codes
+|	8	|	Use explicit list of HTTP status codes	| 200, 202, 204, 304, 308, 400, 401, 403, 404, 405, 406, 413, 500 (see Table 6)
+|	9	|	Use of HTTP header	| Allows for Link headers
+|	10	|	Allow flexible content negotiation	| Currently not addressed
+|	11	|	Pagination	| Eliminates pagination given the design patterns of the query types to provide succinct results from discrete sampling
+|	12	|	Processing resources	| Not applicable
+|	13	|	Support metadata	| Provides `service-desc` and `service-doc` link relations - provides metadata via extended Collections model
+|	14	|	Consider your security needs	| Supports HTTPS (See 6.6) and RFC2818 - it is recommended to explicitly NOT support HTTP, addressing privacy issues and insecure communication. It is recommended that HTTP `POST` is used as an additional security mechanism
+|	15	|	API description	| Supports OpenAPI for API documentation
+|	16	|	Use well-known identifiers	| Provides media types and link relations that are based on IANA and extended per the OGC Definitions Server
+|	17	|	Use explicit relations	| The primary function is query and a single response. Links to associated resources describing the query response are explicit
+|	18	|	Support W3C cross-origin resource sharing	| CORS is supported (See 10.4)
+|	19	|	Resource encodings	| Supports JSON, GeoJSON, HTML and CoverageJSON
+|	20	|	Good APIs are testable from the beginning	| Demonstrates this via the EDR ETS - enables standard programming libraries in implementing standard HTTP request/response, headers and well-known media types and design patterns
+|	21	|	Specify whether operations are safe and/or idempotent	| Provides both safe and idempotent operations via HTTP `GET` and `POST`
+|	22	|	Make resources discoverable	| Implements common OGC API link relations
+|	23	|	Make default behavior explicit	| Collection metadata provides the ability for link relations via URL templates along with explanations of templated variables  - example: https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/blob/master/candidate-standard/examples/collections_metadata_JSON_1.adoc