From e937806b8d29472c7fb8f1184a67554dfb686485 Mon Sep 17 00:00:00 2001 From: Gobe Hobona Date: Fri, 14 Jul 2023 16:37:56 +0100 Subject: [PATCH] final edits before publication --- standard/requirements/edr/query_type/corridor.adoc | 2 +- standard/sections/clause_0_front_material.adoc | 7 ++++--- standard/sections/clause_8_queries.adoc | 2 +- standard/sections/clause_9_general.adoc | 4 ++-- 4 files changed, 8 insertions(+), 7 deletions(-) diff --git a/standard/requirements/edr/query_type/corridor.adoc b/standard/requirements/edr/query_type/corridor.adoc index 2a464861..e0ae9a24 100644 --- a/standard/requirements/edr/query_type/corridor.adoc +++ b/standard/requirements/edr/query_type/corridor.adoc @@ -104,7 +104,7 @@ a| **corridor-height** * <> -* <> |String |*Yes*| The height value represents the whole height of the corridor where the trajectory supplied in the coords query parameter is the centre point of the corridor +* <> |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 a| * `corridor-height=100` a| **height-units** diff --git a/standard/sections/clause_0_front_material.adoc b/standard/sections/clause_0_front_material.adoc index 19286c17..275c5718 100644 --- a/standard/sections/clause_0_front_material.adoc +++ b/standard/sections/clause_0_front_material.adoc @@ -41,9 +41,10 @@ All questions regarding this submission should be directed to the editor or the [abstract] == Abstract -The OGC Environmental Data Retrieval (EDR) Application Programming Interface (API) 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 <>. +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 <>. + +The goals of the EDR Application Programming Interface (API) that is specified by this standard are to: -The goals of the EDR API are to: 1. Make it easier to access a wide range of data through a uniform, well-defined simple Web interface; 2. To achieve data reduction to just the data needed by the user or client while hiding much of the data storage complexity. @@ -51,7 +52,7 @@ A major use case for the EDR API is to retrieve small subsets from large collect The EDR API query patterns - <>, <>, <>, <> or <> - 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. -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 <>. This document extends that foundation to define the Environmental Data Retrieval API. +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 <>. This document extends that foundation to define the EDR API. [#common-paths,reftext='{table-caption} {counter:table-num}'] .Overview of Resources diff --git a/standard/sections/clause_8_queries.adoc b/standard/sections/clause_8_queries.adoc index cc8ee46d..fce76688 100644 --- a/standard/sections/clause_8_queries.adoc +++ b/standard/sections/clause_8_queries.adoc @@ -50,7 +50,7 @@ The OGC API — Common standard does not define any information resource typ [#query-resource-table,reftext='{table-caption} {counter:table-num}'] .Query Types -[width="90%",cols="2,1,4",options="header"] +[width="90%",cols=",,",options="header"] |=== ^|**Path Template** ^|**Query Type** ^|**Description** |/collections/{collectionId}/position | Position | Return data for the requested <> diff --git a/standard/sections/clause_9_general.adoc b/standard/sections/clause_9_general.adoc index 777df3fb..5b83480a 100644 --- a/standard/sections/clause_9_general.adoc +++ b/standard/sections/clause_9_general.adoc @@ -157,11 +157,11 @@ content: [[security]] === Security considerations -The <> Standard does not mandate any specific security controls. However, the Standard was constructed so that security controls can be added without impacting conformance. +The http://www.opengis.net/doc/IS/ogcapi-edr-1/1.1[OGC API - EDR] Standard is an extension of <>. The <> Standard does not mandate any specific security controls. However, the Standard was constructed so that security controls can be added without impacting conformance. Apply <> for OpenAPI 3.0 Security support. -The OpenAPI specification currently supports the following link:https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#security-scheme-object[security schemes]: +The OpenAPI specification, which is used by the http://www.opengis.net/doc/IS/ogcapi-edr-1/1.1[OGC API - EDR] Standard, currently supports the following link:https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#security-scheme-object[security schemes]: * HTTP authentication, * an API key (either as a header or as a query parameter),