final edits before publication

standard/requirements/edr/query_type/corridor.adoc

@@ -104,7 +104,7 @@ a| **corridor-height**
 
 * <<req_edr_corridor-height-definition,definition>> 
 
-* <<req_edr_corridor-height-response,rules>> |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
+* <<req_edr_corridor-height-response,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
  a| * `corridor-height=100`
 a| **height-units**
 

standard/sections/clause_0_front_material.adoc

@@ -41,17 +41,18 @@ 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 <<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 *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 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. 
 
 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 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 <<common-paths>>. 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 <<common-paths>>. This document extends that foundation to define the EDR API.
 
 [#common-paths,reftext='{table-caption} {counter:table-num}']
 .Overview of Resources

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 <<position-definition,position>>

standard/sections/clause_9_general.adoc

@@ -157,11 +157,11 @@ content:
 [[security]]
 === Security considerations
 
-The <<OGC19-072,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.
+The http://www.opengis.net/doc/IS/ogcapi-edr-1/1.1[OGC API - EDR] Standard is an extension of <<OGC19-072,OGC API - Common - Part 1: Core>>. The <<OGC19-072,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 <<req_oas30_security,Requirement /req/oas30/security>> 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),