Solved the issue #82 about crss and extents.

core/standard/clause_12_map_paramCRS.adoc

@@ -20,7 +20,9 @@ A successful GET response is described in the core class (http://www.opengis.net
 
 include::requirements/crs/REQ_crs-definition.adoc[]
 
-NOTE: For clarification: The default CRS of the BBOX is CRS84 and the default CRS of the map is native or storage CRS
+See how you can find out the storage CRS for the collection and the dataset in <<rc_geoDataResourceMaps>> and <<rc_datasetMaps>> respectively.
+
+NOTE: The default CRS of the BBOX is CRS84 but the default CRS of the map is storage CRS
 
 ==== Response
 

core/standard/clause_15_map_originDataset.adoc

@@ -22,21 +22,42 @@ The landing page provides links to start exploring the resources offered by the
 
 The root of the API represents a dataset that will be exposed in different ways by the API.
 
-The root can be modified or complemented by other resources creating new endpoints indirectly giving access to the modified or complemented dataset. Other OGC API family standards will define this mechanisms. Examples of standards doing that are:
+The root can be modified or complemented by other resources creating new endpoints indirectly giving access to the modified or complemented dataset. Other OGC API family standards will define this mechanism. Examples of standards doing that are:
 
 * OGC API - Styles defines how to complement a geospatial resource by adding a style to it. The new resources is an overlap of the dataset and the resource
 
 include::requirements/dataset/REQ_landingpage.adoc[]
 
-In the landing page, in JSON format, the links follow the link schema defined in the OGC API - Common or in OGC API - Features v1. Below you can find an example fragment of the response to an OGC API - Maps landing page showing the link to root tiles.
+In the landing page, in JSON format, the links follow the link schema defined in the OGC API - Common or in OGC API - Features v1. Below you can find an example fragment of the response to an OGC API - Maps landing page showing the link to the dataset map.
 
-[[landingPageTilesRoot]]
-.API Landing Page fragment that advertises dataset maps. The same links could be added to a room style description.
+include::requirements/dataset/REQ_desc-extent.adoc[]
+
+include::requirements/dataset/REQ_desc-crs.adoc[]
+
+include::recommendations/dataset/REC_storage-epoch.adoc[]
+
+
+[[landingPageMap]]
+.API Landing Page fragment that advertises the dataset map.
 =================
 [source,JSON]
 ----
 {
-  links: [
+  "title": "Dataset of the city of Bonn",
+  "description": "Dataset containing collections such as buildings",
+  "attribution": "OpenStreetMap",
+  "extent": {
+    ...
+  },
+  "crs": ["EPSG:32631", "EPSG:23031", "EPSG:4326"],
+  "storageCrs": "EPSG:32631",
+  "storageCrsExtent": {
+    "spatial" : {
+         "bbox" : [ [ 47736, 4421022, 797736, 4734022 ] ]
+    }
+  },
+  "storageCrsCoordinateEpoch": 2022.3,
+  "links": [
     ...,
     {
       "href": "http://data.example.org/map",

core/standard/clause_16_map_originGeodata.adoc

@@ -29,6 +29,10 @@ include::requirements/geodata/REQ_desc-links.adoc[]
 
 include::recommendations/geodata/PER_desc-links.adoc[]
 
+include::requirements/geodata/REQ_desc-crs.adoc[]
+
+include::recommendations/geodata/REC_storage-epoch.adoc[]
+
 .Fragment of a collection with a links array with one item of the array pointing to a map.
 =================
 [source,JSON]
@@ -39,7 +43,15 @@ include::recommendations/geodata/PER_desc-links.adoc[]
   "attribution": "OpenStreetMap",
   "extent": {
     ...
-  }
+  },
+  "crs": ["EPSG:32631", "EPSG:23031", "EPSG:4326"],
+  "storageCrs": "EPSG:32631",
+  "storageCrsExtent": {
+    "spatial" : {
+         "bbox" : [ [ 47736, 4421022, 797736, 4734022 ] ]
+    }
+  },
+  "storageCrsCoordinateEpoch": 2022.3,
   "links": [
     ...
     {

core/standard/clause_7_map_core.adoc

@@ -57,6 +57,8 @@ The response of a GET request to a map resource will be a map representing the g
 
 include::requirements/core/REQ_map-response.adoc[]
 
+See how you can find out the storage CRS for the collection and the dataset in <<rc_geoDataResourceMaps>> and <<rc_datasetMaps>> respectively.
+
 include::recommendations/core/REC_content-crs.adoc[]
 
 A successful response to a HTTP GET map 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 requirements classes applicable to some common formats in <<rc_data_encodings>>

core/standard/recommendations/dataset/REC_storage-epoch.adoc

@@ -0,0 +1,6 @@
+[[rec_dataset_storage-epoch]]
+[width="90%",cols="2,6a"]
+|===
+^|*Recommendation {counter:rec-id}* |*/rec/dataset/storage-epoch*
+^|A |If the dataset is available more efficiently using a particular CRS (exposed in the storageCrs parameter) that is a dynamic coordinate reference system, the property storageCrsCoordinateEpoch in the landing page of the dataset SHOULD provide the epoch of that CRS.
+|===

core/standard/recommendations/geodata/REC_storage-epoch.adoc

@@ -0,0 +1,6 @@
+[[rec_geodata_storage-epoch]]
+[width="90%",cols="2,6a"]
+|===
+^|*Recommendation {counter:rec-id}* |*/rec/geodata/storage-epoch*
+^|A |If the collection is available more efficiently using a particular CRS (exposed in the storageCrs parameter) that is a dynamic coordinate reference system, the property storageCrsCoordinateEpoch in the collection object of the geospatial collection SHOULD provide the epoch of that CRS.
+|===

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

@@ -3,8 +3,9 @@
 |===
 ^|*Requirement {counter:req-id}* |*/req/core/map-response*
 ^|A |A successful execution of a map operation SHALL be a response with a HTTP status code 200.
-^|B |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.
-^|D |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.
-^|E |The body of a response of a successful operation SHALL contain a map in the negotiated format.
+^|B |The map response SHALL be in the storage CRS specified in the collection description, or CRS84 if none is specified, unless overridden by a specific query parameter (see <<rc_crs>>).
+^|C |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.
+^|D |The headers of the response SHALL include a "Content-Bbox" header with the actual geospatial boundary of the rendered map.
+^|E |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.
+^|F |The body of a response of a successful operation SHALL contain a map in the negotiated format.
 |===

core/standard/requirements/crs/REQ_crs-definition.adoc

@@ -15,5 +15,4 @@
     example: http://www.opengis.net/def/crs/OGC/1.3/CRS84
 ----
 ^|B |The CRS value SHALL be one of the values supported by the collection (or collections). If the list of supported CRS is not present, support for only http://www.opengis.net/def/crs/OGC/1.3/CRS84 SHALL be assumed.
-^|C |If this parameter is not specified, the native/storage CRS in the collection description will be used as a default.
 |===

core/standard/requirements/dataset/REQ_desc-crs.adoc

@@ -0,0 +1,9 @@
+[[req_dataset_desc-crs]]
+[width="90%",cols="2,6a"]
+|===
+^|*Requirement {counter:req-id}* |*/req/dataset/desc-crs*
+^|A |The crs property in the landing page of a dataset SHALL contain the identifiers for the list of CRSs supported by the server for dataset as a whole.
+^|B |If the storageCrs is not CRS84, a storageCrs property in the landing page of the dataset SHALL be the identifier for the dataset as a whole.
+^|C |If the dataset is available more efficiently (e.g. it is stored in the server in that CRS) using a particular CRS that is not CRS84, a storageCrs property in the landing page of the dataset SHALL be the identifier for that CRS.
+^|D |If a storageCrs property is used and that is not CRS84, an extent SHALL be provided in a storageCrsExtent property following the same schema as the extent property.
+|===

core/standard/requirements/dataset/REQ_desc-extent.adoc

@@ -0,0 +1,8 @@
+[[req_dataset_desc-extent]]
+[width="90%",cols="2,6a"]
+|===
+^|*Requirement {counter:req-id}* |*/req/dataset/desc-extent*
+^|A |An extent CRS SHALL be provided in a "extent" property following the same schema as the "extent" property for the collection (see OGC API - Common: Part 2).
+|===
+
+NOTE: The spatial bounding box is provided in CRS84 for Earthly data.

core/standard/requirements/geodata/REQ_desc-crs.adoc

@@ -0,0 +1,9 @@
+[[req_geodata_desc-crs]]
+[width="90%",cols="2,6a"]
+|===
+^|*Requirement {counter:req-id}* |*/req/geodata/desc-crs*
+^|A |The crs property in the collection object of a geospatial collection SHALL contain the identifiers for the list of CRSs supported by the server for that collection.
+^|B |If the storageCrs is not CRS84, a storageCrs property in the collection object of a geospatial collection SHALL be the identifier for the server storage CRS for that collection.
+^|C |If the collection is available more efficiently (e.g. it is stored in the server in that CRS) using a particular CRS that is not CRS84, a storageCrs property in the collection object of a geospatial collection SHALL be the identifier for that CRS.
+^|D |If a storageCrs property is used and that is not CRS84, an extent SHALL be provided in a storageCrsExtent property following the same schema as the extent property.
+|===