Merge pull request #146 from opengeospatial/20221206_update

Fix of minor non-normative issues

core/standard/20-057.adoc

@@ -7,9 +7,9 @@
 :draft: 3.0
 :external-id: http://www.opengis.net/doc/{doc-type}/{standard}/{m.n}
 :docnumber: 20-057
-:received-date: 2029-03-30
-:issued-date: 2029-03-30
-:published-date: 2029-03-30
+:received-date: 2022-06-15
+:issued-date: 2022-08-26
+:published-date: 2022-11-10
 :fullname: Joan Masó
 :fullname_2: Jérôme Jacovella-St-Louis
 :docsubtype: Interface

core/standard/abstract_tests/netcdf/ATS_geo.adoc

@@ -18,6 +18,6 @@ test-purpose:: Validate NetCDF consistency of the georeference
 test-method::
 +
 --
-1. Validate that the NetCDF encoding incorporates georeference, this information is consistent with the TileMatrixSet, TileMatrix, TileRow and TileCol
+1. Validate that the NetCDF encoding incorporates a georeference, this information is consistent with the TileMatrixSet, TileMatrix, TileRow and TileCol
 --
 ====

core/standard/abstract_tests/tiff/ATS_geotiff.adoc

@@ -19,6 +19,6 @@ test-purpose:: Validate GeoTIFF consistency of the georeference
 test-method::
 +
 --
-1. If the TIFF encoding incorporates GeoTIFF georeference, validate that this information is consistent with the TileMatrixSet, TileMatrix, TileRow and TileCol
+1. If the TIFF encoding incorporates a GeoTIFF georeference, validate that this information is consistent with the TileMatrixSet, TileMatrix, TileRow and TileCol
 --
 ====

core/standard/abstract_tests/tileset/ATS_tileset-description.adoc

@@ -7,7 +7,7 @@
 ^|Requirement |/req/tileset/description
 ^|Test Method |1. Validate that the tileset endpoint SHALL support negotiating an application/json response. In this case, a successful response of a HTTP GET for a specific tileset is encoded following the data model and JSON schema for tileset metadata, as defined by the 2D Tile Matrix Set and Tileset Metadata standard 2.0.
 
-2. If the tileset endpoint also support negotiating an application/xml response,  validate that a successful response of a HTTP GET for a specific tileset is encoded following the data model and XML schema for tileset metadata, as defined by the 2D Tile Matrix Set and Tileset Metadata standard 2.0.
+2. If the tileset endpoint also supports negotiating an application/xml response,  validate that a successful response of a HTTP GET for a specific tileset is encoded following the data model and XML schema for tileset metadata, as defined by the 2D Tile Matrix Set and Tileset Metadata standard 2.0.
 
 3. If the tileset uses a TileMatrixSet registered in a TileMatrixSet registry (e.g. OGC NA), validate that the `tileMatrixSetURI` property links to the registered TileMatrixSet (e.g. `http://www.opengis.net/def/tilematrixset/{tileMatrixSet}`).
 
@@ -35,7 +35,7 @@ test-method::
 --
 1. Validate that the tileset endpoint SHALL support negotiation for an application/json response. In this case, a successful response of a HTTP GET for a specific tileset is encoded following the data model and JSON schema for tileset metadata, as defined by the 2D Tile Matrix Set and Tileset Metadata standard 2.0.
 
-2. If the tileset endpoint also support negotiation for an application/xml response,  validate that a successful response of a HTTP GET for a specific tileset is encoded following the data model and XML schema for tileset metadata, as defined by the 2D Tile Matrix Set and Tileset Metadata standard 2.0.
+2. If the tileset endpoint also supports negotiation for an application/xml response,  validate that a successful response of a HTTP GET for a specific tileset is encoded following the data model and XML schema for tileset metadata, as defined by the 2D Tile Matrix Set and Tileset Metadata standard 2.0.
 
 3. If the tileset uses a TileMatrixSet registered in a TileMatrixSet register that is published through an accessible registry (e.g. the OGC TileMatrixSet register), validate that the `tileMatrixSetURI` property links to the registered TileMatrixSet (e.g. `http://www.opengis.net/def/tilematrixset/{tileMatrixSet}`).
 

core/standard/abstract_tests/tilesets-list/ATS_tileset-links.adoc

@@ -29,7 +29,7 @@ test-purpose:: Validate that the content of a tileset list
 test-method::
 +
 --
-1. Validate that the API SHALL supports a GET operation on a `.../tiles` path returning a list of available tilesets
+1. Validate that the API supports a GET operation on a `.../tiles` path returning a list of available tilesets
 
 2. Validate that a successful response of a HTTP GET consists of a list of available tilesets each element containing a subset of the tileset metadata (as defined by the 2D Tile Matrix Set and Metadata standard), consisting of: `dataType, `crs`, a link to the tileset (with rel: self), a link to the TileMatrixSet defintion (with rel: `http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme`) and `tileMatrixSetURI` (if the TMS is available in a registry).
 

core/standard/annex_history.adoc

@@ -15,4 +15,5 @@
 |2022-09-12 |1.0.0 draft 2 |G. Hobona |all |Conversion to metanorma
 |2022-09-15 |1.0.0 |J. Maso & J. St-Louis |several |Initial version 1.0
 |2022-10-24 |1.0.0 |G. Hobona |several |OGC Staff editorial review
+|2022-12-05 |1.0.0 |C. Reed, J. Maso, J. St-Louis & G. Hobona |multiple |This release of version 1.0 fixes minor non-normative issues that were in the 2022-11-10 release of version 1.0
 |===

core/standard/api_modules/datetime/requirements/REQ_rc-datetime-response.adoc

@@ -12,7 +12,6 @@
 ====
 [%metadata]
 identifier:: /req/collections/rc-datetime-response
-description:: For each UML class defined or referenced in the Relief Package:
 part:: If the `datetime` parameter is provided by the client and supported by the server, then only resources that have a temporal geometry that intersects the temporal information in the `datetime` parameter SHALL be part of the result set. If a resource has multiple temporal properties, it is the decision of the server whether only a single temporal property is used to determine the extent or all relevant temporal properties.
 part:: The ``datetime`` parameter SHALL match all resources in the collection that are not associated with a temporal geometry.
 ====

core/standard/clause_0_front_material.adoc

@@ -13,11 +13,11 @@ Recipients of this document are requested to submit, with their comments, notifi
 [abstract]
 == Abstract
 
-_OGC API — Tiles_ Standard defines building blocks for implementing Web APIs that support the retrieval of tiled geospatial information.
-A Web API is an [.underline]#application programming interface# for either a [.underline]#web server# or a [.underline]#web browser# [Wikipedia, 2022].
-The OGC suite of Web APIs is an extensible framework for building HTTP based services that can be accessed in different applications on different platforms such as the Web, desktop, mobile, etc.
-_OGC API — Tiles_ Standard specifies how different forms/types of geospatial resources are supported, such as tiles of vector features ("vector tiles"), coverages, and maps (or imagery). Although OGC API - Tiles can be used independently, the building blocks can be combined with other OGC API Standards for additional capabilities or increased interoperability for specific types of data.
-The _OGC API — Tiles_ references the OGC Two-Dimensional Tile Matrix Set (TMS) and Tileset Metadata Standard [OGC 17-083r4].
+The _OGC API — Tiles_ Standard defines building blocks for implementing Web APIs that support the retrieval of tiled geospatial information. A Web API is an [.underline]#application programming interface# for either a [.underline]#web server# or a [.underline]#web browser# [Wikipedia, 2022].
+
+The OGC suite of Web API standards is an extensible framework for building HTTP based services that can be accessed in different applications on different platforms such as the Web, desktop, mobile, etc.
+The _OGC API — Tiles_ Standard specifies how different forms/types of geospatial resources are supported, such as tiles of vector features ("vector tiles"), coverages, and maps (or imagery). Although OGC API - Tiles can be used independently, the building blocks can be combined with other OGC API Standards for additional capabilities or increased interoperability for specific types of data.
+The _OGC API — Tiles_ Standard references the _OGC Two-Dimensional Tile Matrix Set (TMS) and Tile Set Metadata_ Standard [OGC 17-083r4].
 That Standard defines logical models and encodings for specifying tile matrix sets and describing tile sets.
 A tile matrix set is a tiling scheme that enables an application to partition and index space based on a set of regular grids defined for multiple scales in a Coordinate Reference System (CRS).
 

core/standard/clause_10_tile_datasetTileSets.adoc

@@ -14,7 +14,7 @@ Combined with the Requirements Class "Collections Selection" (<<rc_collections-s
 If an OGC based Web API offers several geospatial data resources for a dataset, that API may limit the number of collections that can be retrieved together, and/or provide a limited subset of the collections by default.
 
 === General
-This Requirements Class describes how to serve tilesets for a dataset provided as Web API instance implementing  _OGC API - Common - Part 1_ requirement classes or https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0] as an alternative.
+This Requirements Class describes how to serve tilesets for a dataset provided as a Web API instance implementing  _OGC API - Common - Part 1_ requirements classes or https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0] as an alternative.
 
 === Web API Landing Page
 
@@ -28,7 +28,7 @@ In the landing page, in JSON format, the links follow the link schema defined in
 The example below shows a fragment of the response to an _OGC API - Tiles_ landing page showing links to dataset tilesets.
 
 [[landingPageTilesRoot]]
-.Web API Landing Page fragment that advertises dataset tilesets.
+.Web API Landing Page fragment that advertises dataset tilesets
 =================
 [source,JSON]
 ----
@@ -71,7 +71,7 @@ The Requirements Class "Core" (<<rc_tiles_core>>) defines how to retrieve a sing
 
 ==== Response
 The response is expected to represent the entire dataset.
-In a Web API based server providing access to a complex dataset formed by several geospatial data resources, it can be useful to select specific sub-resources of interest when requesting data from this dataset.
+In a server providing access through a Web API to a complex dataset formed by several geospatial data resources, it can be useful to select specific sub-resources of interest when requesting data from this dataset.
 This can be achieved with the use of the Requirements Class "Collections Selection" (<<rc_collections-selection>>) or as an automatic decision by the server.
 
 include::recommendations/dataset-tilesets/REC_geodata-selection.adoc[]

core/standard/clause_11_tile_geoDataTileSets.adoc

@@ -7,30 +7,30 @@
 
 include::requirements/requirements_class_geodata-tilesets.adoc[]
 
-The GeoData Tilesets Requirements Class assumes assumes that data is organized into one or more geospatial data resources
-(e.g., the "collections" http://docs.ogc.org/DRAFTS/20-024.html[OGC API - Common - Part 2: Geospatial data]).
+The GeoData Tilesets Requirements Class assumes that data is organized into one or more geospatial data resources
+(e.g., the "collections" http://docs.ogc.org/DRAFTS/20-024.html[OGC API - Common - Part 2: Geospatial Data]).
 Geospatial data resources are referenced using URIs.
 
 The GeoData Tilesets Class defines how to specify link(s) to one or more list(s) of tilesets containing a representation of this geospatial data resource (path). This Class is used in conjunction with <<rc_tileSets-list>> that specifies the response to this GET request.
 
 === General
 include::recommendations/geodata-tilesets/REC_api-common.adoc[]
 
-This Requirements Class depends on _OGC API - Part 2: Geospatial data_, but stays flexible and does not require implementation of OGC API - Common - Part 1. This 
+This Requirements Class depends on _OGC API - Common - Part 2: Geospatial Data_, but stays flexible and does not require implementation of _OGC API - Common - Part 1_. This
 allows for other Web API architectures outside the OGC API framework to adopt this Class.
-However, a server implementing other OGC APIs is expected to implement OGC API - Common - Part 1.
-In practice, this means that the landing page and the conformance page follow OGC API - Common core requirement classes when used.
-Combining this building block with https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0] instead of _OGC API - Common - Part 2 is also possible.
+However, a server implementing other OGC APIs is expected to implement _OGC API - Common - Part 1_.
+In practice, this means that the landing page and the conformance page follow _OGC API - Common_ core requirements classes when used.
+Combining this building block with https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0] instead of _OGC API - Common - Part 2_ is also possible.
 
 === Geospatial data resources
-This Standard does not specify how geospatial data resources are exposed in a Web API based server that implements OGC APIs and whether they can be retrieved as geospatial data (e.g., feature items). For example, https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0] includes the definition of collections and each collection is available in the `/collections/{collectionId}` path. OGC API - Common will provide a similar mechanism. Other paths in the Web API could also give access to geospatial data resources.
+This Standard does not specify how geospatial data resources are exposed in a server that implements OGC APIs and whether they can be retrieved as geospatial data (e.g., feature items). For example, https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0] includes the definition of collections and each collection is available in the `/collections/{collectionId}` path. OGC API - Common will provide a similar mechanism. Other paths in the Web API could also give access to geospatial data resources.
 
 NOTE: The concept of geospatial data resource path replaces the concept of "layer" found in WMTS 1.0 but is intended to result in a better integration between data visualization and data access.
 
 include::requirements/geodata-tilesets/REQ_desc-links.adoc[]
 
-For example, an implementation of the https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core] returns a list of links that include geospatial resource aspects for each geospatial data resource in the `/collections/{collectionId}` path.
-_OGC API - Common - Part 2: Geospatial data_ provides a similar mechanism.
+For example, an implementation of the https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core] Standard returns a list of links that include geospatial resource aspects for each geospatial data resource in the `/collections/{collectionId}` path.
+_OGC API - Common - Part 2: Geospatial Data_ provides a similar mechanism.
 In the JSON response, the `links` array is where links to lists of tilesets must be added.
 
 .Fragment of a collection with a links array including two items pointing to lists of tilesets (one for vector tiles and one for map tiles).

core/standard/clause_12_tile_collectionsSelection.adoc

@@ -8,15 +8,15 @@ include::requirements/requirements_class_collections-selection.adoc[]
 
 [[rm_collections-selection]]
 
-In a Web API based server providing access to a complex dataset formed by several geospatial data resources, selecting specific sub-resources of interest when requesting data from this dataset can be useful.
+In a server providing access through a Web API to a complex dataset formed by several geospatial data resources, selecting specific sub-resources of interest when requesting data from this dataset can be useful.
 This requirements class defines how to include a query parameter when requesting a resource (e.g., dataset tiles) to specify which geospatial data resources (a.k.a. collections) should be used to generate the response.
 
 This Requirements Class can be implemented e.g. in conjunction with the Requirements Class "Dataset Tilesets" (<<rc_datasetTileSets>>) or in conjunction with an equivalent requirements class from _OGC API - Maps_.
 
 === Operation
 
-By default, the geospatial data resources to be included in the dataset tiles responses are unspecified but should represent the entire dataset. 
-This Class adds a mechanism to select the geospatial data resources to be used to generate the derived resources (e.g., maps or tiles). 
+By default, the geospatial data resources to be included in the dataset tiles responses are unspecified but should represent the entire dataset.
+This Class adds a mechanism to select the geospatial data resources to be used to generate the derived resources (e.g., maps or tiles).
 In practice this enables the capability to generate resources involving more than one geospatial data sub-resource.
 
 [[req_collections-selection_parameter-collections]]

core/standard/clause_16_tile_dataEncodings.adoc

@@ -32,7 +32,7 @@ include::requirements/png/REQ_content.adoc[]
 
 As above, selecting an encoding that can be natively interpreted by the web browser is fundamental. The JPEG format is one of the most popular formats on the World Wide Web and is defined by the ITU-T Recommendation T.81 and the ISO/IEC 10918-1 standard.
 
-The JPEG compression algorithm operates at its best on photographs and paintings with smooth variations of tone and color. JPEG is best used for color and grayscale still images, but not for binary images. JPEG is also the most common format used digital cameras to encode and store pictures. However, JPEG is not well suited for line drawings and other textual or iconic graphics, where the sharp contrasts between adjacent pixels can cause noticeable artifacts. Such images are better saved in a lossless graphics format such as PNG. Because JPEG is a lossy compression method, which reduces the image fidelity, it is inappropriate for exact reproduction of imaging data.
+The JPEG compression algorithm operates at its best on photographs and paintings with smooth variations of tone and color. JPEG is best used for color and grayscale still images, but not for binary images. JPEG is also the most common format used by digital cameras to encode and store pictures. However, JPEG is not well suited for line drawings and other textual or iconic graphics, where the sharp contrasts between adjacent pixels can cause noticeable artifacts. Such images are better saved in a lossless graphics format such as PNG. Because JPEG is a lossy compression method, which reduces the image fidelity, it is inappropriate for exact reproduction of imaging data.
 
 include::requirements/requirements_class_jpeg.adoc[]
 
@@ -56,7 +56,7 @@ include::requirements/tiff/REQ_geotiff.adoc[]
 [[rc_netcdf]]
 === Requirements Class "NetCDF"
 
-In the case of multidimensional regular grid tiles, as defined in Annex J of the 2D-TMS Standards [OGC 17-083r4], there is a need for a format that can store multidimensional data in a natural way. The NetCDF format is one of the most popular formats for scientific data that is able store multi-dimensional arrays of data values. NetCDF format is defined by the UCAR-Unidata community and standardized in the OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0 (OGC 10-090r3).
+In the case of multidimensional regular grid tiles, as defined in Annex J of the 2D TMS Standard [OGC 17-083r4], there is a need for a format that can store multidimensional data in a natural way. The NetCDF format is one of the most popular formats for scientific data that is able to store multi-dimensional arrays of data values. NetCDF format is defined by the UCAR-Unidata community and standardized in the OGC Network Common Data Form (NetCDF) Core Encoding Standard version 1.0 (OGC 10-090r3).
 
 include::requirements/requirements_class_netcdf.adoc[]