Issue #87 fixed. Conformance simplified

core/standard/clause_10_map_paramScaling.adoc

@@ -9,30 +9,6 @@ include::requirements/requirements_class_scaling.adoc[]
 
 This extension describes how to scale a map by specifying a set of parameters that will define its size (width and height) in pixels of a displaying device that indirectly defines que scale of the map.
 
-=== Declaration of conformance classes
-
-To support "generic" clients that want to access multiple OGC API standards and extensions - and not "just" a specific API / server, the API has to declare the requirements classes it implements and conforms to.
-
-==== Response
-
-The conformance page mainly consists of a list of links. OGC API - Common already requires some links.
-
-include::requirements/scaling/REQ_conformance-success.adoc[]
-
-In the conformance page (typically in JSON format) the links follow the link schema defined in the OGC API - Common. The following is an example fragment of the response of an implementation of the OGC API - Maps draft specification with the maps extension conformance information page.
-
-[[ConformancePageMapsMaps]]
-.Conformance Information Page fragment
-=================
-[source,JSON]
-{
-  "conformsTo": [
-    "http://www.opengis.net/spec/ogcapi-maps-1/1.0/req/core",
-    "http://www.opengis.net/spec/ogcapi-maps-2/1.0/req/scaling"
-  ]
-}
-=================
-
 === Map resource
 The _OGC API - Maps - Part 1: Core_ defines the map resource. The core also defines a minimum set of metadata to enable a client application to formulate a map request.
 

core/standard/clause_11_map_paramSpatialPartition.adoc

@@ -9,32 +9,6 @@ include::requirements/requirements_class_spatial-partitioning.adoc[]
 
 This extension describes how to subset a map by specifying a bounding box (in a CRS). Another way to subset a map is provided by another requirements class is to make it accessible as tiles.
 
-=== Declaration of conformance classes
-
-To support "generic" clients that want to access multiple OGC API standards and extensions - and not "just" a specific API / server, the API has to declare the requirements classes it implements and conforms to.
-
-==== Response
-
-The conformance page mainly consists of a list of links. OGC API - Common already requires some links.
-
-include::requirements/bbox/REQ_conformance-success.adoc[]
-
-In the conformance page (typically in JSON format) the links follow the link schema defined in the OGC API - Common. The following is an example fragment of the response of an implementation of the OGC API – Maps draft specification with the maps extension conformance information page.
-
-[[ConformancePageMapsSpatialPartitioning]]
-.Conformance Information Page fragment
-=================
-[source,JSON]
-{
-  "conformsTo": [
-    "http://www.opengis.net/spec/ogcapi-common-1/1.0/req/core",
-    "http://www.opengis.net/spec/ogcapi-common-2/1.0/req/collections",
-    "http://www.opengis.net/spec/ogcapi-maps-1/1.0/req/core"
-    "http://www.opengis.net/spec/ogcapi-maps-2/1.0/req/bbox"
-  ]
-}
-=================
-
 === Map resource
 The _OGC API - Maps - Part 1: Core_ defines the map resource. The core also defines a minimum set of metadata to enable a client application to formulate a map request.
 
@@ -71,6 +45,9 @@ include::requirements/bbox/REQ_map-success.adoc[]
 
 Normally, the content partially outside the map bounding box will be clipped at the extent of the bounding box. This can be done efficiently when map subsets are in raster format (e.g. map tiles). However, maps containing features in vector format may not clip features that are partially outside to ensure continuity of features or for performance.
 
+include::recommendation/bbox/PER_map-outside-bounds.adoc[]
+
+
 ==== Error conditions
 
 A general summary of the HTTP status codes can be found in http://www.opengis.net/doc/IS/ogcapi-features-1/1.0[OGC API - Features - Part 1: Core, version 1.0] as well as in OGC API - Common.

core/standard/clause_15_map_originDataset.adoc

@@ -55,29 +55,6 @@ In the landing page, in JSON format, the links follow the link schema defined in
 ----
 =================
 
-=== Declaration of conformance classes
-
-==== Response
-
-The conformance page mainly consists of a list of links. OGC API - Common already requires some links.
-
-include::requirements/dataset/REQ_conformance-success.adoc[]
-
-In the conformance page (typically in JSON format) the links follow the link schema defined in the OGC API - Common. The following is an example fragment of the response of an OGC API - Maps conformance information page
-
-[[ConformancePageMapsCollection]]
-.Conformance Information Page fragment
-=================
-[source,JSON]
-{
-  "conformsTo": [
-    "http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
-    "http://www.opengis.net/spec/ogcapi-maps-1/1.0/conf/core"
-    "http://www.opengis.net/spec/ogcapi-maps-1/1.0/conf/dataset"
-  ]
-}
-=================
-
 === Dataset maps
 The maps core defines a `map` resource that is associated with an operation that contains the necessary information to later formulate a map request. Nevertheless, the core does not does not specify how to retrieve a map resource description. This section offers one possible path to do that from the dataset represented by the API.
 

core/standard/clause_16_map_originGeodata.adoc

@@ -14,30 +14,6 @@ include::recommendations/geodata/REC_api-common.adoc[]
 
 This building block stays flexible and does not require to implement OWS Common, allowing for other API architectures outside the OGC API framework to adopt it. However, a server under the OGC APIs is expected to implement OGC API Common. If so, in practice, this means that the landing page and the conformance page follow OGC API - Common core and collections requirement classes will be used. Temporarily, it is also possible to combine this building block with OGC API features v1 that is not tied to OWS Common.
 
-=== Declaration of conformance classes
-To support "generic" clients that want to access multiple OGC API standards and extensions - and not "just" a specific API / server, the API has to declare the conformance classes it implements and conforms to.
-
-==== Response
-The conformance page mainly consists of a list of links.
-
-include::requirements/geodata/REQ_conformance-success.adoc[]
-
-If the server declares also conformity to OGC API - Common or to OGC API - Features v1, then it has to consider the OGC API - Common requirements for declaring conformance, i.e. the use of a the conformance page. In the JSON format the conformance page is an array of links following the link schema defined in the OGC API - Common or in OGC API - Features v1. Below is an example fragment of a conformance information page of an API conformant to OGC API - Common and OGC API - Maps.the ones at the endpoint  defined by OGC API - Common or OGC API - Features 1.0.
-
-[[ConformancePageMapsGeoData]]
-.Conformance Information Page fragment
-=================
-[source,JSON]
-{
-  "conformsTo": [
-    "http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
-    "http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections",
-    "http://www.opengis.net/spec/ogcapi-maps-1/1.0/conf/core"
-    "http://www.opengis.net/spec/ogcapi-maps-1/1.0/conf/geodata"
-  ]
-}
-=================
-
 === Geospatial data resources
 This standard does not specify how geospatial resources are exposed in the API and if they have the possibility to be retrievable as geospatial data (e.g. feature items). This standard expect that other OGC API family standards will define how to expose these geospatial resources. Examples of standards that can expose geospatial resources are:
 

core/standard/clause_7_map_core.adoc

@@ -7,9 +7,9 @@
 
 include::requirements/requirements_class_core.adoc[]
 
-This core specifies a map resource: a resource that represents the geospatial data as a rendered map. The map resource, as defined in this core retrieves a generic map as a graphical representation of the data in the API. With only the core, the representation is not constrained almost in any way by the client, so the server is free to return a total or a partial representation of the resource of an arbitrary size. Extensions to this core will add query parameters to personalize the server behavior to the client needs. Some of those extension will define specifying parameters that will determine the map resolution (width, height, bounding  box and CRS). In addition, another extension will define how a map endpoint can be retrieved as tiles by applying the OGC API - Tiles.
+This core specifies a map resource: a resource that represents the geospatial data as a rendered map. The map resource, as defined in this core retrieves a generic map as a graphical representation of the data in the API. With only the core, the representation is not constrained almost in any way by the client, so the server is free to return a total or a partial representation of the resource of an arbitrary size. Extensions to this core will add query parameters to personalize the server behavior to the client needs. These extensions will define specifying parameters that will allow for the client to define the map size and resolution of the map (width, height, bounding  box and CRS). In addition, an orthogonal extension will define how a map endpoint can be retrieved as tiles by applying the OGC API - Tiles.
 
-A map resource can be obtained from a non map resource by adding `/map` the resource. The core does not specify the resources where `/map` can be applied. However, we can list common places in and API where maps can be obtained in following table. Additional conformance classes will better define these possibilities.
+A map resource can be obtained from a non map resource by adding `/map` to the resource URI. The core does not specify which resources `/map` can be applied. However, a list of common places in the API where maps can be obtained is present in the following table as a recommendation. Additional conformance classes will better define these possibilities.
 
 [#Common-map-resources-in-the-api,reftext='{table-caption} {counter:table-num}']
 .Common map resources in an geospatial API
@@ -22,30 +22,7 @@ A map resource can be obtained from a non map resource by adding `/map` the reso
 |/collections/{collectionId}/styles/{styleId}/map | A map representing `collectionId` in the `styleId` style
 |===
 
-NOTE: There is no mandatory dependency of this core on OGC API - Commons. This allows for non-OGC APIs to implement this core without the need to comply to the OGC API common structure (landing page, conformance, API description). It expected that main implementations will specify a dependency on OGC API - Commons in their conformance page.
-
-=== Declaration of conformance classes
-To support "generic" clients that want to access multiple OGC API standards and extensions - and not "just" a specific API / server, the API has to declare the conformance classes it implements and conforms to.
-
-==== Response
-The conformance page mainly consists of a list of links.
-
-include::requirements/core/REQ_conformance-success.adoc[]
-
-If the server declares also conformity to OGC API - Common - Part 1: Core or to OGC API - Features - Part 1: Core, then it has to consider the OGC API requirements for declaring conformance, i.e. the use of a the conformance page. In the JSON format the conformance page is an array of links following the link schema defined in the OGC API - Common - Part 1: Core or in OGC API - Features - Part 1: Core. Below is an example fragment of a conformance information page of an API conformant to OGC API - Common and OGC API - Maps.
-
-[[ConformancePageMapsCore]]
-.Conformance Information Page fragment
-=================
-[source,JSON]
-{
-  "conformsTo": [
-    "http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
-    "http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections",
-    "http://www.opengis.net/spec/ogcapi-maps-1/1.0/conf/core"
-  ]
-}
-=================
+NOTE: There is no mandatory dependency of this core on OGC API - Commons. This allows for non-OGC APIs to implement this core without the need to comply to the OGC API common structure (landing page, conformance, API description). However, it expected that many implementations will specify a dependency on OGC API - Commons in their conformance page.
 
 === Map resource
 
@@ -60,6 +37,8 @@ include::recommendations/core/PER_map-op.adoc[]
 
 NOTE: The desired encoding is selected using HTTP content negotiation. In addition the parameters specified by the core, other parameters should be added.
 
+NOTE: HTTP content negotiation replaces the FORMAT= parameters in WMS. However, for convenience, some implementations can implement a f= parameter for circumstances where content negotiation is not possible or available (e.g. testing the API in a web browser by using a URL)
+
 ==== Parameters transparent and bgcolor
 These parameters indicate how the absence of data will be represented in the map and allow for the map to be overlaid with other maps without completely obscuring the lower layers. The parameter `transparent` is maintained for backwards compatibility; the use of the 'alpha channel' in `bgcolor` is recommended instead.
 
@@ -76,7 +55,7 @@ The response of a GET request to a map resource will be a map representing the g
 
 include::requirements/core/REQ_map-response.adoc[]
 
-A successful response to a map GET operation will be consistent with the media type of resource requested. This draft specification does not impose any media type or file format and map responses may be in JPEG, PNG or other appropriate format (including vector based formats such as KML or SVG). It is also possible to respond an HTML page with the image embedded and, eventually, with additional controls.
+A successful response to a map GET operation will be consistent with the media type of resource requested. This draft specification does not impose any media type or file format and map responses may be in JPEG, PNG or other appropriate format (including vector based formats such as KML or SVG). It is also possible to respond an HTML page with the image embedded and, eventually, with additional controls. This standard provides some conformance classes applicable to some common formats in <<rc_data_encodings>>
 
 == Requirement Class "Map Metadata"
 === Overview
@@ -250,3 +229,26 @@ If the API has a OpenAPI document describing the schema for the response, the fo
 }
 ----
 =================
+
+=== Declaration of conformance classes
+To support "generic" clients that want to access multiple OGC API standards and extensions - and not "just" a specific API / server, the API has to declare the conformance classes it implements and conforms to.
+
+==== Response
+The conformance page mainly consists of a list of links.
+
+include::requirements/core/REQ_conformance-success.adoc[]
+
+If the server declares also conformity to OGC API - Common - Part 1: Core or to OGC API - Features - Part 1: Core, then it has to consider the OGC API requirements for declaring conformance, i.e. the use of a the conformance page. In the JSON format the conformance page is an array of links following the link schema defined in the OGC API - Common - Part 1: Core or in OGC API - Features - Part 1: Core. Below is an example fragment of a conformance information page of an API conformant to OGC API - Common and OGC API - Maps.
+
+[[ConformancePageMapsCore]]
+.Conformance Information Page fragment
+=================
+[source,JSON]
+{
+  "conformsTo": [
+    "http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
+    "http://www.opengis.net/spec/ogcapi-common-2/1.0/conf/collections",
+    "http://www.opengis.net/spec/ogcapi-maps-1/1.0/conf/core"
+  ]
+}
+=================

core/standard/clause_8_map_tilesetsList.adoc

@@ -11,33 +11,6 @@ This extension describes how to subset a map by making it accessible as tiles. A
 
 NOTE: The concept of map tiles substitutes the WMTS 1.0 concept of tiles. Tiles can be data tiles (e.g. vector tiles) or map tiles (tiles that are rendered using an style)
 
-=== Declaration of conformance classes
-
-To support "generic" clients that want to access multiple OGC API standards and extensions - and not "just" a specific API / server, the API has to declare the requirements classes it implements and conforms to.
-
-==== Response
-
-The conformance page mainly consists of a list of links.
-
-include::requirements/tilesets/REQ_conformance-success.adoc[]
-
-If the server declares also conformity to OGC API - Common or to http://www.opengis.net/doc/IS/ogcapi-features-1/1.0[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 the conformance page. In the JSON format the conformance page is an array of links following the link schema defined in the OGC API - Common or in http://www.opengis.net/doc/IS/ogcapi-features-1/1.0[OGC API - Features - Part 1: Core, version 1.0]. Below is an example fragment of a conformance information page of an API conformant to OGC API - Common and OGC API - Tiles.
-
-[[ConformancePageMapTileSets]]
-.Conformance Information Page fragment
-=================
-[source,JSON]
-{
-  "conformsTo": [
-    "http://www.opengis.net/spec/ogcapi-common-1/1.0/conf/core",
-    "http://www.opengis.net/spec/ogcapi-tiles-1/1.0/conf/tileset"
-    "http://www.opengis.net/spec/ogcapi-tiles-1/1.0/conf/tilesets-list"
-    "http://www.opengis.net/spec/ogcapi-maps-1/1.0/conf/core",
-    "http://www.opengis.net/spec/ogcapi-maps-2/1.0/conf/tilesets"
-  ]
-}
-=================
-
 === Map
 This standard does not specify how maps are exposed in the API. Refer to the _OGC API - Maps - Part 1: Core_, classes dataset or geodata for examples on how to generate maps.
 

core/standard/recommendations/bbox/PER_map-outside-bounds.adoc

@@ -0,0 +1,6 @@
+[[per_bbox_map-op]]
+[width="90%",cols="2,6a"]
+|===
+^|*Permission {counter:per-id}* |*/per/bbox/map-op*
+^|A |When the requested subset is outside the bounds of the requested CRS the server MAY limit the Content-Bbox to the valid values in the CRS.
+|===

core/standard/requirements/core/REQ_conformance-success.adoc

@@ -2,5 +2,5 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Requirement {counter:req-id}* |*/req/core/conformance-success*
-^|A |If the API has a mechanism to advertise conformance classes, the API SHALL advertise the maps core conformance class with a link to  http://www.opengis.net/spec/ogcapi-maps-1/1.0/conf/core.
+^|A ||If the API instance has a mechanism to advertise conformance classes, the list of conformance classes SHALL include the ones defined in this standard and listed in <<table_conformance_urls>> that are supported by this API instance.
 |===

core/standard/requirements/core/REQ_map-response.adoc

@@ -2,6 +2,8 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Requirement {counter:req-id}* |*/req/core/map-response*
-^|A |A successful execution of a map operation SHALL be reported as a response with a HTTP status code 200.
-^|B |The content of a response of a successful operation SHALL be a map format
+^|A |A successful execution of a map operation SHALL be a response with a HTTP status code 200.
+^|B |The headers of the response should include a "Content-Crs" header. The headers SHALL include the "Content-Crs" header with the URI of the CRS used to render the map except if the content is in the http://www.opengis.net/def/crs/OGC/1.3/CRS84 CRS.
+^|C |The headers of the response SHALL include a "Content-Bbox" header with the actual geospatial boundary of the rendered map. The server should honor the subset request if it is present. The Content-Bbox coordinates SHALL be in response CRS (indicated in the "Content-Crs" or CRS84 if it is not present) and SHALL honor the CRS coordinates order.
+^|D |The body of a response of a successful operation SHALL contain a map format
 |===