diff --git a/core/standard/20-057.adoc b/core/standard/20-057.adoc index 4db945b0..8b8f3a80 100644 --- a/core/standard/20-057.adoc +++ b/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 diff --git a/core/standard/abstract_tests/netcdf/ATS_geo.adoc b/core/standard/abstract_tests/netcdf/ATS_geo.adoc index ff758c9e..9bc15930 100644 --- a/core/standard/abstract_tests/netcdf/ATS_geo.adoc +++ b/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 -- ==== diff --git a/core/standard/abstract_tests/tiff/ATS_geotiff.adoc b/core/standard/abstract_tests/tiff/ATS_geotiff.adoc index 5800feb6..7aa6edf5 100644 --- a/core/standard/abstract_tests/tiff/ATS_geotiff.adoc +++ b/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 -- ==== diff --git a/core/standard/abstract_tests/tileset/ATS_tileset-description.adoc b/core/standard/abstract_tests/tileset/ATS_tileset-description.adoc index 7c24b352..5970b368 100644 --- a/core/standard/abstract_tests/tileset/ATS_tileset-description.adoc +++ b/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}`). diff --git a/core/standard/abstract_tests/tilesets-list/ATS_tileset-links.adoc b/core/standard/abstract_tests/tilesets-list/ATS_tileset-links.adoc index 3b4db48e..fea0348f 100644 --- a/core/standard/abstract_tests/tilesets-list/ATS_tileset-links.adoc +++ b/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). diff --git a/core/standard/annex_history.adoc b/core/standard/annex_history.adoc index ecf738fc..334b76f2 100644 --- a/core/standard/annex_history.adoc +++ b/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 |=== diff --git a/core/standard/api_modules/datetime/requirements/REQ_rc-datetime-response.adoc b/core/standard/api_modules/datetime/requirements/REQ_rc-datetime-response.adoc index 838bf090..a098e1f7 100644 --- a/core/standard/api_modules/datetime/requirements/REQ_rc-datetime-response.adoc +++ b/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. ==== diff --git a/core/standard/clause_0_front_material.adoc b/core/standard/clause_0_front_material.adoc index 1313788e..a6b38dd1 100644 --- a/core/standard/clause_0_front_material.adoc +++ b/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). diff --git a/core/standard/clause_10_tile_datasetTileSets.adoc b/core/standard/clause_10_tile_datasetTileSets.adoc index f75b967c..ab4d3fed 100644 --- a/core/standard/clause_10_tile_datasetTileSets.adoc +++ b/core/standard/clause_10_tile_datasetTileSets.adoc @@ -14,7 +14,7 @@ Combined with the Requirements Class "Collections Selection" (<>) 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" (<>) or as an automatic decision by the server. include::recommendations/dataset-tilesets/REC_geodata-selection.adoc[] diff --git a/core/standard/clause_11_tile_geoDataTileSets.adoc b/core/standard/clause_11_tile_geoDataTileSets.adoc index 910a5df0..01a80cd7 100644 --- a/core/standard/clause_11_tile_geoDataTileSets.adoc +++ b/core/standard/clause_11_tile_geoDataTileSets.adoc @@ -7,8 +7,8 @@ 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 <> that specifies the response to this GET request. @@ -16,21 +16,21 @@ The GeoData Tilesets Class defines how to specify link(s) to one or more list(s) === 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). diff --git a/core/standard/clause_12_tile_collectionsSelection.adoc b/core/standard/clause_12_tile_collectionsSelection.adoc index a93ecc70..38671c00 100644 --- a/core/standard/clause_12_tile_collectionsSelection.adoc +++ b/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" (<>) 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]] diff --git a/core/standard/clause_16_tile_dataEncodings.adoc b/core/standard/clause_16_tile_dataEncodings.adoc index ae9a95f6..4f3ce241 100644 --- a/core/standard/clause_16_tile_dataEncodings.adoc +++ b/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[] diff --git a/core/standard/clause_1_scope.adoc b/core/standard/clause_1_scope.adoc index 5f4ce120..49471577 100644 --- a/core/standard/clause_1_scope.adoc +++ b/core/standard/clause_1_scope.adoc @@ -1,4 +1,4 @@ == Scope -The _OGC API — Tiles_ Standard specifies the behavior of Web APIs that provide access to tiles of one or more geospatial data resources (collections) that the Web API offers. This Standard defines how to discover which resources offered by the Web API can be retrieved as tiles, get metadata about the available tile sets (including according to which tile matrix set each tile set is partitioned and the limits of that tile set within a common potentially global tile matrix set) and how to request a tile. This Standard is sometimes referred as _Tiles API_. +The _OGC API — Tiles_ Standard specifies the behavior of Web APIs that provide access to tiles of one or more geospatial data resources (collections) that the Web API offers. This Standard defines how to discover which resources offered by the Web API can be retrieved as tiles, get metadata about the available tile sets (including according to which tile matrix set each tile set is partitioned and the limits of that tile set within a common potentially global tile matrix set) and how to request a tile. This Standard is sometimes referred to as the _Tiles API_. -The core conformance class is defined in a way that could be easily included in a web API, even if that API does not conform to the _OGC API - Common_ standard. A web API can combine some requirements classes of this OGC API Standard with those of other OGC API Standards (including _OGC API - Common_) to extend the scope of the Web API by adding functionality. +The core conformance class is defined in a way that could be easily included in a web API, even if that API does not conform to the _OGC API - Common_ Standard. A web API can combine some requirements classes of this OGC API Standard with those of other OGC API Standards (including _OGC API - Common_) to extend the scope of the Web API by adding functionality. diff --git a/core/standard/clause_2_conformance.adoc b/core/standard/clause_2_conformance.adoc index 8e65e038..864ce6cf 100644 --- a/core/standard/clause_2_conformance.adoc +++ b/core/standard/clause_2_conformance.adoc @@ -50,11 +50,11 @@ The _TileSets List_ Requirements Class defines a generic operation for retrievin *<>* (http://www.opengis.net/spec/ogcapi-tiles-1/1.0/req/dataset-tilesets) -The _Dataset Tilesets_ Requirements Class defines how to retrieve all tiles for a dataset that could potentially consists of multiple geospatial data resources. All implementation instances of the Tiles API must implement this Requirements Class if they are claiming to support *dataset* tiles following this _OGC API - Tiles Part 1: Core_ Standard. +The _Dataset Tilesets_ Requirements Class defines how to retrieve all tiles for a dataset that could potentially consist of multiple geospatial data resources. All implementation instances of the Tiles API must implement this Requirements Class if they are claiming to support *dataset* tiles following this _OGC API - Tiles - Part 1: Core_ Standard. Dataset tiles may combine content from multiple geospatial resources, regardless of whether those are available separately (as tiles or otherwise). [#table_resource_dataset_tileset,reftext='{table-caption} {counter:table-num}'] -.Overview of resource and common direct links that corresponds to the dataset tileset +.Overview of resource and common direct links that correspond to the dataset tileset [cols="33,66",options="header"] |=== |Resource name |**Common** path @@ -68,7 +68,7 @@ Dataset tiles may combine content from multiple geospatial resources, regardless The _GeoData TileSets_ Requirements Class supports the retrieval of tiles from a specific geospatial data resource. [#table_resource_geodata_tilesets,reftext='{table-caption} {counter:table-num}'] -.Overview of resource and common direct links that corresponds to the geospatial data resources tilesets +.Overview of resource and common direct links that correspond to the geospatial data resources tilesets [cols="33,66",options="header"] |=== |Resource name |Example of possible paths @@ -84,7 +84,7 @@ The _GeoData TileSets_ Requirements Class supports the retrieval of tiles from a The _Collections Selection_ Requirements Class supports the listing of specific geospatial data resources from which to retrieve tiles such as for use with data set tiles. [#table_resource_geodata_selection,reftext='{table-caption} {counter:table-num}'] -.Overview of resource and common direct links that corresponds to the geodata selection +.Overview of resource and common direct links that correspond to geodata selection [cols="33,66",options="header"] |=== |Resource name |Example of possible paths diff --git a/core/standard/clause_4_terms_and_definitions.adoc b/core/standard/clause_4_terms_and_definitions.adoc index e67a65ec..b2d9792e 100644 --- a/core/standard/clause_4_terms_and_definitions.adoc +++ b/core/standard/clause_4_terms_and_definitions.adoc @@ -18,7 +18,7 @@ For the purposes of this document, the following additional terms and definition ==== coverage tile -_tile_ that contains information, often in a gridded form, where the values represent observations or measurements as a count, or quantity using some unit of measure +_tile_ that contains information, often in a gridded form, where the values represent observations or measurements as a count, or quantity using some unit of measure. NOTE: Coverage tiles are generated in combination with _OGC API - Coverages_, and can also be generated by combining a subset (trim) and resampling operation. Usually, visualizing a coverage tile on a rendering device implies mapping those values to colors. @@ -28,14 +28,14 @@ a set of data, published or curated by a single agent, and available for access NOTE: A Web API implementing OGC API - Common often gives access to a single dataset which may be comprised of one or more _geospatial data resources_. ==== geospatial data resource -web accessible resource that consists of a set of geospatial data +web accessible resource that consists of a set of geospatial data. NOTE: In Web APIs implementing _OGC API - Common - Part 2: Geospatial Data_, geospatial data resources are referred to as collections and are defined in the _collections_ conformance class. NOTE: _geodata_ is sometimes used in this document as an abbreviation of _geospatial data_ ==== geospatial resource aspect -web accessible resource that represents a component of geospatial information (metadata, schemas...) or geospatial data accessed using a particular mechanism and data model (e.g., feature items, tiles, maps, coverages,...) of a more generic geospatial data resource (e.g., a collection) +web accessible resource that represents a component of geospatial information (metadata, schemas...) or geospatial data accessed using a particular mechanism and data model (e.g., feature items, tiles, maps, coverages,...) of a more generic geospatial data resource (e.g., a collection). NOTE: Not to be confused with a web accessible resource representation. While resource representations share the same path and are selected by format negotiation, geospatial aspects use different paths. Commonly a geospatial aspect is a subpath of a geospatial data resource. @@ -49,7 +49,7 @@ The landing page provides access to the root of a dataset. ==== map tile -_tile_ that contains information in a raster form where the values of cells are colors which can be readily displayed on rendering devices +_tile_ that contains information in a raster form where the values of cells are colors which can be readily displayed on rendering devices. NOTE: Map tiles are generated in combination with _OGC API - Maps_. @@ -72,7 +72,7 @@ NOTE: Tiles can contain a variety of data types, such as grid-based pictorial re ==== tile matrix -tiling grid in a given 2D coordinate reference system, associated to a specific scale and partitioning space into regular conterminous _tiles_, each of which being assigned a unique identifier +tiling grid in a given 2D coordinate reference system, associated to a specific scale and partitioning space into regular conterminous _tiles_, each of which being assigned a unique identifier. NOTE: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard @@ -87,20 +87,20 @@ NOTE: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metada ==== tile indexing scheme scheme to uniquely reference a _tile_ in a _tiling scheme_ by the use of a unique identifier (or set of identifiers), and reversely, which unique identifier (or unique set of identifiers) corresponds -to a space satisfying the geometric properties of a specific tile +to a space satisfying the geometric properties of a specific tile. NOTE: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard ==== tile set -a set of _tiles_ resulting from tiling data according to a particular _tiling scheme_ +a set of _tiles_ resulting from tiling data according to a particular _tiling scheme_. NOTE: From OGC 19-014r1: Core Tiling Conceptual and Logical Models for 2D Euclidean Space, but adapted to clarify that in the context of this document, a tile set refers specifically to a set of tiles containing data and following a common tiling scheme. ==== tiling scheme -scheme that defines how space is partitioned into individual _tiles_, potentially featuring multiple levels of detail (each tiling at a different granularity to reflect a different resolution or scale) +scheme that defines how space is partitioned into individual _tiles_, potentially featuring multiple levels of detail (each tiling at a different granularity to reflect a different resolution or scale). A tiling scheme defines the spatial reference system and the geometric properties of each tile defined by the scheme. Those properties include which space each tile occupies (the tile's spatial extent), as well as a tile coordinate origin if a particular corner of origin convention is established. @@ -118,20 +118,21 @@ metadata describing common properties defining a _tile set_, layers and styles u NOTE: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard -==== vector tile (a.k.a. tiled vector feature data) +==== vector tile +admitted:[tiled vector feature data] -tile that contains vector data that has been generalized (simplified) at the tile scale resolution and clipped by the tile boundaries +tile that contains vector data that has been generalized (simplified) at the tile scale resolution and clipped by the tile boundaries. NOTE: From OGC 17-083r4: OGC Two Dimensional Tile Matrix Set and Tile Set Metadata standard ==== Web API -API using an architectural style that is founded on the technologies of the Web [source: OGC API - Features - Part 1: Core] +API using an architectural style that is founded on the technologies of the Web. [source: OGC API - Features - Part 1: Core] NOTE: See link:https://www.w3.org/TR/dwbp/#APIHttpVerbs[Best Practice 24: Use Web Standards as the foundation of APIs] (W3C Data on the Web Best Practices) for more detail. ==== Web API based implementation -a server software that implements a Web API +a server software that implements a Web API. NOTE: The Web API based implementations mentioned in the context of this Standard declare conformity to at least one Conformance Class defined by this Standard. diff --git a/core/standard/clause_6_overview.adoc b/core/standard/clause_6_overview.adoc index 73f34b41..2ded37fd 100644 --- a/core/standard/clause_6_overview.adoc +++ b/core/standard/clause_6_overview.adoc @@ -2,18 +2,18 @@ == Overview === Introduction -The _OGC API — Tiles_ Standard defines building blocks that can be used in the implementation of Web API based servers and compatible clients to support the retrieval of tiled geospatial data that follow the structure defined in the https://docs.ogc.org/is/17-083r4/17-083r4.html[OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0] standard (OGC 17-083r4) (see <>), which is also known as the 2D TMS standard. This Standard assumes that the reader is familiar with the concepts in the OGC 17-083r4 This Standard, such as a tile, tile set, tile set metadata, tile matrix and tile matrix set. If that is not the case, reading the OGC 17-083r4 overview subsection is recommended. +The _OGC API — Tiles_ Standard defines building blocks that can be used in the implementation of Web API based servers and compatible clients to support the retrieval of tiled geospatial data that follow the structure defined in the https://docs.ogc.org/is/17-083r4/17-083r4.html[OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0] Standard (OGC 17-083r4) (see <>), which is also known as the 2D TMS Standard. The _OGC API — Tiles_ Standard assumes that the reader is familiar with the concepts in the OGC 17-083r4 Standard, such as a tile, tile set, tile set metadata, tile matrix and tile matrix set. If that is not the case, reading the OGC 17-083r4 overview subsection is recommended. Services and clients are encouraged to support as many of the TileMatrixSets defined in Annex D and E of the OGC 17-083r4 Standard as possible. Other TileMatrixSets defined in the http://www.opengis.net/def/tms[OGC TileMatrixSet register] for all geospatial data resources to maximize interoperability should be considered. However, support for any specific TileMatrixSet is not required. Tiles that share the same TileMatrixSet definition can be easily visualized together in a data integration client. -The OGC API - Tiles standard is an alternative to the OGC Web Map Tile Service (WMTS) standard <>. The fundamental concept TileMatrixSet has not changed from the one used in WMTS. Therefore tiles provided via a WMTS instance and the ones generated by an _OGC API — Tiles_ implementation instance that are based on the same TileMatrixSet can also be easily visualized and/or processed together. If the selected tile matrix set is the one called WebMercatorQuad (see OGC 17-083r4 Annex D.1), tiles are also compatible with the ones made available by some popular mass market approaches. +The OGC API - Tiles standard is an alternative to the OGC Web Map Tile Service (WMTS) Standard <>. The fundamental concept TileMatrixSet has not changed from the one used in WMTS. Therefore tiles provided via a WMTS instance and the ones generated by an _OGC API — Tiles_ implementation instance that are based on the same TileMatrixSet can also be easily visualized and/or processed together. If the selected tile matrix set is the one called WebMercatorQuad (see OGC 17-083r4 Annex D.1), tiles are also compatible with the ones made available by some popular mass market approaches. [#img_WebMercatorQuadZoom15,reftext='{figure-caption} {counter:figure-num}'] .Contiguous tiles from different services and APIs sharing same WebMercatorQuad tile matrix set and the tile matrix identified as 15 (sometimes called "zoom") image::images/WebMercatorQuadZoom15.png[width=800,align="center"] This Standard does not specify any requirement for the type of _geospatial data resource_ that could be delivered as tiles. -Provided that the geospatial data resources can be organized into tiles, any such resource can be supported regardless of whether they are maps, features data, +Provided that the geospatial data resources can be organized into tiles, any such resource can be supported regardless of whether they are maps, vector features, coverages, a resource that does not represent data per se (e.g., an annotation) and so forth. NOTE: The geospatial data resources (e.g., collections) replace the concept of layer in the OGC Web Map Service (WMS) <> and WMTS Standards. @@ -24,28 +24,28 @@ OGC API datasets (see <>) and collections (see <> as well as the W3C Best Practices for sharing Data on the Web <>. The bibliography lists several OGC Engineering Reports from initiatives that led to the development of OGC API — Tiles. Some of the Engineering Reports are from OGC Testbed initiatives <> <> , whereas others are from the OGC Vector Tiles Pilot <> <> <> <> <>. +OGC Web Service (OWS) standards have historically implemented a Remote-Procedure-Call-over-HTTP architectural style using Extensible Markup Language (XML) for payloads. This was the state-of-the-art in the late 1990s and early 2000s when some of the initial versions of OGC Web Services Standards were designed and documented. Their service oriented architectural style now has a competing resource-oriented Web API style. The WMTS 1.0 standard defines a resource-oriented architectural style but lacks a Web API definition. The _OGC API - Tiles_ Standard specifies a Web API that follows the architecture of the Web and in particular the W3C/OGC Best Practices for sharing Spatial Data on the Web <> as well as the W3C Best Practices for sharing Data on the Web <>. The bibliography lists several OGC Engineering Reports from initiatives that led to the development of OGC API — Tiles. Some of the Engineering Reports are from OGC Testbed initiatives <> <> , whereas others are from the OGC Vector Tiles Pilot <> <> <> <> <>. -This Standard defines the necessary elements to incorporate tile support into a Web API implementation. These elements can be incorporated in an API based on the _OGC API - Features - Part 1: Core_ or can be incorporated in a Web API implementation based on the _OGC API - Common - Part 1: Core_. Both of those Standards specify a kernel of a Web API approach to services that follows current resource-oriented architecture practices in the OGC. OGC API - Common provides the foundation upon which implementations of the OGC API Standards can be built. OGC API - Common can be integrated with this Standard and other resource-specific OGC API standards to build an Web API implementation. However, this Standard is also designed in a way that can extend OGC API - Common, but does not make OGC API - Common mandatory. As such this Standard can be reused as a building block in other APIs that do not follow the OGC API pattern. +This Standard defines the necessary elements to incorporate tile support into a Web API implementation. These elements can be incorporated in an API based on the _OGC API - Features - Part 1: Core_ or can be incorporated in a Web API implementation based on the _OGC API - Common - Part 1: Core_. Both of those Standards specify a kernel of a Web API approach to services that follows current resource-oriented architecture practices in the OGC. OGC API - Common provides the foundation upon which implementations of the OGC API Standards can be built. OGC API - Common can be integrated with this Standard and other resource-specific OGC API Standards to build a Web API implementation. However, this Standard is also designed in a way that can extend OGC API - Common, but does not make OGC API - Common mandatory. As such this Standard can be reused as a building block in other APIs that do not follow the OGC API pattern. Beside the general alignment with the architecture of the Web (e.g., consistency with HTTP/HTTPS, hypermedia controls), another goal for the suite of OGC API Standards is modularization. This goal has several facets: * Clear separation between core requirements and more advanced capabilities. This _OGC API - Tiles - Part 1: Core_ Standard defines the requirements that are relevant for anyone who wants to share or use Tiled Data at a fine-grained level. Additional capabilities that several communities are using today will be specified as extensions to this Standard. * Technologies that change more frequently are decoupled and specified in separate modules ("requirements classes" in OGC terminology). This enables, for example, the use/re-use of new encodings for spatial data or Web API definition (such as a new version of the OpenAPI description document). -* Modularization is not just about a single "service". OGC APIs provide building blocks that can be reused in Web APIs in general. In other words, a server supporting OGC API - Tiles Requirements should not be seen as a standalone service. Rather, the web API implementation should be viewed as a collection of Web API building blocks which together implement Tile capabilities. A corollary for this is that it should be possible to implement a Web API that concurrently conforms to conformance classes from the Features, Coverages, Maps, Tiles, and other future OGC API standards. +* Modularization is not just about a single "service". OGC APIs provide building blocks that can be reused in Web APIs in general. In other words, a server supporting OGC API - Tiles Requirements should not be seen as a standalone service. Rather, the web API implementation should be viewed as a collection of Web API building blocks which together implement Tile capabilities. A corollary for this is that it should be possible to implement a Web API that concurrently conforms to conformance classes from the Features, Coverages, Maps, Tiles, and other future OGC API Standards. The OGC APIs approach is intended to support two types of client developers: * Those that have never heard about the OGC. Developers should be able to create a client using the Web API definition without the need to adopt a specific OGC approach (they no longer need to read how to implement a GetCapabilities response document, allowing them to focus on the geospatial resource aspects). * Those that want to write a "generic" client that can access OGC APIs. In other words, they are not specific to a particular Web API. -As a result of following a RESTful approach, implementations of an OGC API is not backwards compatible with OWS implementations per se. However, a design goal is to define OGC APIs in a way that an OGC API interface can be mapped to or used as a façade to an existing OWS implementation (where appropriate). OGC APIs are intended to be simpler and more modern, but still an evolution from the previous versions and their implementations making the transition easy such as by initially implementing facades in front of the current OWS services. +As a result of following a RESTful approach, implementations of an OGC API are not backwards compatible with OWS implementations per se. However, a design goal is to define OGC APIs in a way that an OGC API interface can be mapped to or used as a façade to an existing OWS implementation (where appropriate). OGC APIs are intended to be simpler and more modern, but still an evolution from the previous versions and their implementations making the transition easy such as by initially implementing façades in front of the current OWS services. === Relationship to other OGC API standards @@ -81,28 +81,28 @@ As informative guidance implementations should consider the following aspects. Three different mechanisms are defined by this Standard to describe the domain of the dimensions of the tiles, including spatiotemporal axes as well as additional dimensions. In the Requirements Class "Tilesets List" (<>), the collection description inherited from _OGC API - Common - Part 2_ contains an `extent` property that can -describe both the spatial and temporal domain of the data. In addition, the _Unified Additional Dimensions_ common building block, used in the +describe both the spatial and temporal domains of the data. In addition, the _Unified Additional Dimensions_ common building block, used in the example OpenAPI definition, further specifies that additional dimensions shall be described in a similar way to the temporal dimension. An extra `grid` property in the example OpenAPI definition also allows specifying the resolution and the number of cells (for data organized as a regular grid) or a list of coordinates (for data organized as an irregular grid) along each dimension. -With the _TileSet_ conformance class, the tile set metadata allows to specify a spatial bounding box for tiles as a whole, as well as for each individual +With the _TileSet_ conformance class, the tileset metadata allows to specify a spatial bounding box for tiles as a whole, as well as for each individual collection of geospatial data represented or contained within the tiles (the _layers_). The resolution of these layers can also be specified by including the minimum and maximum cell size and equivalent scale denominators. The informative Annex J of the https://docs.ogc.org/is/17-083r4/17-083r4.html[OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0] standard -further extends this capability to describe the domain set by enhancing the schema to include bounds and resolution for additional dimensions as well being able to handle the specifics of unequal temporal units. The Annex J also includes provisions to describe tile matrix sets featuring additional dimensions which not only +further extends this capability to describe the domain set by enhancing the schema to include bounds and resolution for additional dimensions as well being able to handle the specifics of unequal temporal units. Annex J also includes provisions to describe tile matrix sets featuring additional dimensions which not only extend in other dimensions but can also define divisions and down sampling of these additional dimensions for lower resolution tile matrices. In addition to describing the bounds of the tileset dimensions, the Requirements Class "TileSet" (<>) also supports specifying limits in terms of identifiers for the minimum and maximum tile matrices, tile rows, and tile columns for which data is available. ==== Description of the observed or measured properties -The Requirements Class "TileSet" (<>), supports specifying the tile set metadata for the measured or observed properties for each +The Requirements Class "TileSet" (<>), supports specifying the tileset metadata for the measured or observed properties for each collection of geospatial data represented or contained within the tiles (the _layers_). For each of these properties, a JSON schema and semantic information can be described. This schema can be used to describe properties for feature collections or the range type of coverages. ==== Available formats and tile response expectations -The Tiles API Standard in Requirements classes for tile encodings (<>) defines six requirements classes for specific encodings for different types of tiled data. +The Tiles API Standard, in Requirements classes for tile encodings (<>), defines six requirements classes for specific encodings for different types of tiled data. Additional encodings can be supported using HTTP content negotiation, following conventions specific to those encodings. In this case requirements are expected to fall back to the closest encoding defined in Requirements classes for tile encodings (<>) (e.g., using the GeoTIFF and netCDF conformance class as a model for other coverage data, the JPEG and PNG classes for other map tiles encodings, and the Mapbox Vector Tiles or GeoJSON for other vector tiles encodings). @@ -111,7 +111,7 @@ using this standard, including 3D models either batched as a single mesh, or as ==== Limitations -Although implementations of the _OGC API — Tiles_ Standard can be used "stand-alone", other OGC API Standards or draft specifications may provide additional capabilities and specify additional normative requirements describing how to retrieve specific types of tiled content. This includes describing in greater detail the domain or the observed or measured properties within the tiled data. Conforming to these standards as well may enable greater interoperability. For example, for map tiles, this Standard does not define how a client requests a specific background color or whether tiles should be opaque or transparent expecting that the _OGC API — Maps_ will do so. +Although implementations of the _OGC API — Tiles_ Standard can be used "stand-alone", other OGC API Standards or draft specifications may provide additional capabilities and specify additional normative requirements describing how to retrieve specific types of tiled content. This includes describing in greater detail the domain, or the observed or measured properties within the tiled data. Conforming to these standards as well may enable greater interoperability. For example, for map tiles, this Standard does not define how a client requests a specific background color or whether tiles should be opaque or transparent expecting that the _OGC API — Maps_ will do so. === How to approach an implementation of an OGC API Standard @@ -131,7 +131,7 @@ For the second approach, implementations should consider Requirements Class "Ope There is yet a third way to approach an implementation of an OGC API Standard that relies on assuming a set of predefined paths and path templates. These predefined paths are used in many examples in this Standard and are presented together in <>. Many implementations of this Standard will provide a Web API definition document (e.g. OpenAPI) using this set of predefined paths and path templates to get necessary resources directly. -All this could mislead the reader into getting the false impression that the predefined paths are enforced. They are not. +All this could mislead the reader into getting the false impression that the predefined paths are enforced. They are not. Therefore, building a client that is assuming a predefined set of paths is risky. Even so, many API implementations will actually follow the predefined set of paths and the client using this approach could be successful on many occasions. Again, be aware that these paths are not required by this Standard. diff --git a/core/standard/clause_7_tile_core.adoc b/core/standard/clause_7_tile_core.adoc index f80f90e5..73d9ef30 100644 --- a/core/standard/clause_7_tile_core.adoc +++ b/core/standard/clause_7_tile_core.adoc @@ -7,7 +7,7 @@ include::requirements/requirements_class_core.adoc[] The Core Requirements Class is generically designed to describe an HTTP GET operation, as well as its response, to retrieve tiles from a tileset which can be described by the https://docs.ogc.org/is/17-083r4/17-083r4.html[OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0] standard. The Core introduces the idea of URI templates and variables associated with the TileMatrix, TileRow, and TileCol concepts defined in the https://docs.ogc.org/is/17-083r4/17-083r4.html[OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0] Standard but it does not prescribe a particular path or template form for the URL of those tiles. -The Core focuses on the individual tiles and does not describe the tileset as a whole. The implementer of a Web API should also implements support for tileset metadata in conjunction with the core requirements class as it provides important information to clients. This can be done by also implementing the Requirements Class "Tileset" (<>) or integrating within another API providing this capability through another mechanism. +The Core focuses on the individual tiles and does not describe the tileset as a whole. The implementer of a Web API should also implement support for tileset metadata in conjunction with the core requirements class as it provides important information to clients. This can be done by also implementing the Requirements Class "Tileset" (<>) or integrating within another API providing this capability through another mechanism. === A tile A tile resource is a geospatial resource presenting a fragment of a much bigger geospatial data resource that is spatially constrained at the boundaries of the selected tile in a tile matrix set. @@ -27,7 +27,7 @@ include::recommendations/core/REC_tc-op.adoc[] The desired encoding is selected by the client using HTTP content negotiation. If necessary, the client can determine the supported encodings, or more precisely the media types of the supported encodings, from the Web API definition, or from the conformance declaration (see <>). -The core of the OGC API - Tiles standard provides a mechanism to select and retrieve a tile in a TileMatrixSet that is agreed between the client and server. This Core Requirements Class does not discuss the details of how the client and service agree on which TileMatrixSet they use. +The core of the OGC API - Tiles Standard provides a mechanism to select and retrieve a tile in a TileMatrixSet that is agreed between the client and server. This Core Requirements Class does not discuss the details of how the client and service agree on which TileMatrixSet they use. ==== Parameter tileMatrix include::requirements/core/REQ_tc-tilematrix-definition.adoc[] @@ -83,7 +83,7 @@ The conformance declaration mainly consists of a list of links. include::requirements/core/REQ_tc-conformance-success.adoc[] -If the server also declares conformity to OGC API - Common - Part 1: Core or to https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0], then it has to consider the OGC API - Common requirements for declaring conformance, i.e. the use of a conformance declaration page. In the JSON format the conformance declaration page is an array of links following the link schema defined in the OGC API - Common or in https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0] standards. Below is an example fragment of a conformance a Web API declaration page conformant to OGC API - Common and OGC API - Tiles is shown. +If the server also declares conformity to OGC API - Common - Part 1: Core or to https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0], then it has to consider the OGC API - Common requirements for declaring conformance, i.e. the use of a conformance declaration page. In the JSON format the conformance declaration page is an array of links following the link schema defined in the OGC API - Common or in https://docs.ogc.org/is/17-069r4/17-069r4.html[OGC API - Features - Part 1: Core, version 1.0] standards. Below is an example fragment of a conformance declaration page conformant to OGC API - Common and OGC API - Tiles. [[ConformancePageTileset]] .Conformance Information Page fragment diff --git a/core/standard/clause_8_tile_tileSet.adoc b/core/standard/clause_8_tile_tileSet.adoc index 7bd5264d..e3363c56 100644 --- a/core/standard/clause_8_tile_tileSet.adoc +++ b/core/standard/clause_8_tile_tileSet.adoc @@ -33,7 +33,7 @@ Metadata may optionally also provide additional information, such as: - Attribution. A link to a definition of a TileMatrixSet is always required whether a custom TileMatrixSet or a registered TileMatrixSet is used. -Having the Web API hosts a local definition of each supported TileMatrixSet to ensure availability is recommended. +Having the Web API host a local definition of each supported TileMatrixSet to ensure availability is recommended. === Tileset resource A tileset consists of a set of tiles obtained by partitioning geospatial data according to a particular TileMatrixSet. @@ -186,7 +186,7 @@ An OGC API landing page provides links to start exploring the resources offered Using the JSON format, the landing page links follow the link schema defined in _OGC API - Common_. The following is an example fragment of the response to an OGC API - Tiles landing page. [[landingPageTilesTmxs]] -.Web API Landing Page fragment with links to TileMatrixSet descriptions. +.Web API Landing Page fragment with links to TileMatrixSet descriptions ================= [source,JSON] ---- @@ -212,7 +212,7 @@ Using the JSON format, the landing page links follow the link schema defined in ==== TileMatrixSets -An HTTP request to the TileMatrixSets endpoint retrieves a list of links to the descriptions of the tile matrix sets supported by the OGC Web API. They may be the TileMatrixSets defined in the Annex D and the Annex E of the https://docs.ogc.org/is/17-083r4/17-083r4.html[OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0] Standard or customized ones. The response follows the schema below. +An HTTP request to the TileMatrixSets endpoint retrieves a list of links to the descriptions of the tile matrix sets supported by the OGC Web API. They may be the TileMatrixSets defined in Annex D and Annex E of the https://docs.ogc.org/is/17-083r4/17-083r4.html[OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0] Standard, or in customized definitions. The response follows the schema below. [[TileMatrixSetsResponseSchema]] .Schema for the TileMatrixSets resource @@ -229,7 +229,7 @@ An HTTP request to the TileMatrixSets endpoint retrieves a list of links to the ================= [[TileMatrixSetsResponseCommonSchema]] -.Schema for id-link used to validate TileMatrixSets resource. +.Schema for id-link used to validate TileMatrixSets resource ================= [source,YAML] id-link: @@ -281,7 +281,7 @@ id-link: ==== TileMatrixSet -A HTTP GET request to a TileMatrixSet endpoint retrieves the full description of a tile matrix set supported by Web API based servers and client applications following the schema described in the https://docs.ogc.org/is/17-083r4/17-083r4.html[OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0] Standard. The response follows the TileMatrixSet schema. +An HTTP GET request to a TileMatrixSet endpoint retrieves the full description of a tile matrix set supported by Web API based servers and client applications following the schema described in the https://docs.ogc.org/is/17-083r4/17-083r4.html[OGC Two Dimensional Tile Matrix Set and Tile Set Metadata 2.0] Standard. The response follows the TileMatrixSet schema. [[TileMatrixSetResponseExample]] .Fragment of a TileMatrixSet resource example diff --git a/core/standard/clause_9_tile_tileSetsList.adoc b/core/standard/clause_9_tile_tileSetsList.adoc index 8523cf04..c8cb8005 100644 --- a/core/standard/clause_9_tile_tileSetsList.adoc +++ b/core/standard/clause_9_tile_tileSetsList.adoc @@ -7,7 +7,7 @@ include::requirements/requirements_class_tilesets-list.adoc[] -This class defines a resource called _tilesets list_ that provides a list of elements each one including a link to individual tileset resource and a small set of metadata. To obtain a complete definition of the Tileset you should follow the link to the Tileset (in application/json, you will retrieve a TileSetMetadata document; see <>). +This class defines a resource called _tilesets list_ that provides a list of elements, each one including a link to an individual tileset resource and a small set of metadata. To obtain a complete definition of the Tileset you should follow the link to the Tileset (in application/json, you will retrieve a TileSetMetadata document; see <>). Refer to the "Dataset Tilesets" (<>) and "GeoData Tilesets" <> requirements classes that describe two complementary mechanisms for associating tilesets lists with datasets and geospatial data resources, respectively. === Tilesets list diff --git a/core/standard/requirements/dataset-tilesets/REQ_landingpage.adoc b/core/standard/requirements/dataset-tilesets/REQ_landingpage.adoc index a0f24ae4..04eae474 100644 --- a/core/standard/requirements/dataset-tilesets/REQ_landingpage.adoc +++ b/core/standard/requirements/dataset-tilesets/REQ_landingpage.adoc @@ -11,5 +11,5 @@ ==== [%metadata] identifier:: /req/dataset-tilesets/landingpage -part:: If the API has a mechanism for exposing root resources (e.g., a landing page), the API SHALL advertise at least one URIs to retrieve tilesets list provided by this service with a link having a `rel` value: `http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector`, `http://www.opengis.net/def/rel/ogc/1.0/tilesets-map` or `http://www.opengis.net/def/rel/ogc/1.0/tilesets-coverage`. +part:: If the API has a mechanism for exposing root resources (e.g., a landing page), the API SHALL advertise at least one URI to retrieve a tilesets list provided by this service with a link having a `rel` value: `http://www.opengis.net/def/rel/ogc/1.0/tilesets-vector`, `http://www.opengis.net/def/rel/ogc/1.0/tilesets-map` or `http://www.opengis.net/def/rel/ogc/1.0/tilesets-coverage`. ==== diff --git a/core/standard/requirements/geojson/REQ_content.adoc b/core/standard/requirements/geojson/REQ_content.adoc index f73dc4f6..c26f77f3 100644 --- a/core/standard/requirements/geojson/REQ_content.adoc +++ b/core/standard/requirements/geojson/REQ_content.adoc @@ -14,7 +14,6 @@ [requirement,label="/req/geojson/content",identifier="/req/geojson/content"] ==== -For each UML class defined or referenced in the Relief Package: [.component,class=part] -- diff --git a/core/standard/requirements/netcdf/REQ_geo.adoc b/core/standard/requirements/netcdf/REQ_geo.adoc index 40fe19e3..0519aa98 100644 --- a/core/standard/requirements/netcdf/REQ_geo.adoc +++ b/core/standard/requirements/netcdf/REQ_geo.adoc @@ -11,5 +11,5 @@ ==== [%metadata] identifier:: /req/netcdf/geo -part:: If the NetCDF encoding incorporates georeference, this information SHALL be consistent with the TileMatrixSet, TileMatrix, TileRow and TileCol +part:: If the NetCDF encoding incorporates a georeference, this information SHALL be consistent with the TileMatrixSet, TileMatrix, TileRow and TileCol ==== diff --git a/core/standard/requirements/tiff/REQ_geotiff.adoc b/core/standard/requirements/tiff/REQ_geotiff.adoc index d87d7f87..9e605ea2 100644 --- a/core/standard/requirements/tiff/REQ_geotiff.adoc +++ b/core/standard/requirements/tiff/REQ_geotiff.adoc @@ -11,5 +11,5 @@ ==== [%metadata] identifier:: /req/tiff/geotiff -part:: If the TIFF encoding incorporates GeoTIFF georeference, this information SHALL be consistent with the TileMatrixSet, TileMatrix, TileRow and TileCol +part:: If the TIFF encoding incorporates a GeoTIFF georeference, this information SHALL be consistent with the TileMatrixSet, TileMatrix, TileRow and TileCol ==== diff --git a/core/standard/requirements/tileset/REQ_tileset-description.adoc b/core/standard/requirements/tileset/REQ_tileset-description.adoc index fdc699bc..e53f8612 100644 --- a/core/standard/requirements/tileset/REQ_tileset-description.adoc +++ b/core/standard/requirements/tileset/REQ_tileset-description.adoc @@ -19,11 +19,11 @@ ==== [%metadata] identifier:: /req/tileset/description -part:: The tileset endpoint SHALL support negotiation of an application/json response. In this case, a successful response of an HTTP GET for a specific tileset SHALL be encoded following the data model and JSON schema for tileset metadata, as defined by the 2D Tile Matrix Set and Tile Set Metadata standard 2.0. -part:: If the tileset endpoint also supports negotiation of an application/xml response, a successful response of an HTTP GET for a specific tileset SHALL be 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. +part:: The tileset endpoint SHALL support negotiation of an application/json response. In this case, a successful response of an HTTP GET for a specific tileset SHALL be encoded following the data model and JSON schema for tileset metadata, as defined by the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard 2.0. +part:: If the tileset endpoint also supports negotiation of an application/xml response, a successful response of an HTTP GET for a specific tileset SHALL be encoded following the data model and XML schema for tileset metadata, as defined by the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard 2.0. part:: If the tileset uses a TileMatrixSet registered in a TileMatrixSet register (e.g. that of the OGC), the `tileMatrixSetURI` property SHALL link to the registered TileMatrixSet (e.g. `http://www.opengis.net/def/tilematrixset/{tileMatrixSet}`). part:: The links property SHALL include a link to the TileMatrixSet definition with relation type `http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme` following the - https://schemas.opengis.net/tms/2.0/json/tileMatrixSet.json[tile matrix set schema], as defined by the 2D Tile Matrix Set and Tileset Metadata standard 2.0. + https://schemas.opengis.net/tms/2.0/json/tileMatrixSet.json[tile matrix set schema], as defined by the OGC Two Dimensional Tile Matrix Set and Tile Set Metadata Standard 2.0. part:: The tileset metadata SHALL include at least one templated link to individual tiles using the relation type `item`, and the template parameters `{tileMatrix}`, and `{tileRow}` and `{tileCol}`. Those variables are to be substituted by their respective valid values to obtain the URL to a tile. part:: If a tiles link template is specific to a particular format, the link SHALL contain the media type for that format in the `"type"` property. Otherwise, normal HTTP content type negotiation rules apply (`Accept:` header). diff --git a/core/standard/requirements/tilesets-list/REQ_tilesets-list_tileset-links.adoc b/core/standard/requirements/tilesets-list/REQ_tilesets-list_tileset-links.adoc index 2ed58180..2f6dd63b 100644 --- a/core/standard/requirements/tilesets-list/REQ_tilesets-list_tileset-links.adoc +++ b/core/standard/requirements/tilesets-list/REQ_tilesets-list_tileset-links.adoc @@ -7,7 +7,7 @@ identifier:: /req/tilesets-list/tileset-links part:: A successful response of an HTTP GET SHALL consist of an object with a property called `tilesets` which is a list of available tilesets, each element containing: `dataType`, `crs`, a `link` to the tileset (with rel: `self`), a `link` to the tileMatrixSet definition (with rel: `http://www.opengis.net/def/rel/ogc/1.0/tiling-scheme`) and `tileMatrixSetURI` (if the TMS is available in a register) (this is a subset of the tileset metadata; as defined by the 2D Tile Matrix Set and Tile Set Metadata standard). part:: Each element of that list SHALL include a `link` to a resource providing the full version of the _tileset metadata_, using link relation `self`. part:: The tileset-list endpoint SHALL support negotiation of an application/json response. In this case, a successful response of an HTTP GET SHALL be encoded following the JSON schema (that represents a subset of the TileSet Metadata in 2D Tile Matrix Set and Tile Set Metadata standard 2.0). - ++ [source,JSON] ---- {