fixing issues #45 #15 #100 #98 and #102

core/standard/clause_11_map_paramSpatialSubsetting.adoc

@@ -55,6 +55,10 @@ include::requirements/subsetting/REQ_subset-coordinates.adoc[]
 
 include::recommendations/subsetting/REC_subset-crs-axis-names.adoc[]
 
+==== CURIE permission
+
+include::recommendations/subsetting/PER_subset-crs-curie.adoc[]
+
 === Response
 
 A successful GET response is described in the core class (http://www.opengis.net/spec/ogcapi-maps-1/1.0/req/core).

core/standard/clause_12_map_paramCRS.adoc

@@ -24,6 +24,8 @@ See how you can find out the storage CRS for the collection and the dataset in <
 
 NOTE: The default CRS of the BBOX is CRS84 but the default CRS of the map is storage CRS
 
+include::recommendations/crs/PER_crs-crs-curie.adoc[]
+
 ==== Response
 
 include::requirements/crs/REQ_map-success.adoc[]

core/standard/clause_16_map_originGeodata.adoc

@@ -44,8 +44,8 @@ include::recommendations/geodata/REC_storage-epoch.adoc[]
   "extent": {
     ...
   },
-  "crs": ["EPSG:32631", "EPSG:23031", "EPSG:4326"],
-  "storageCrs": "EPSG:32631",
+  "crs": ["[EPSG:32631]", "[EPSG:23031]", "[EPSG:4326]"],
+  "storageCrs": "[EPSG:32631]",
   "storageCrsExtent": {
     "spatial" : {
          "bbox" : [ [ 47736, 4421022, 797736, 4734022 ] ]

core/standard/clause_2_conformance.adoc

@@ -174,7 +174,7 @@ This standard does not mandate a specific encoding or format for representing ma
 * <<rc_png,PNG>> (http://www.opengis.net/spec/ogcapi-maps-1/1.0/req/png)
 * <<rc_jpeg,JPEG>> (http://www.opengis.net/spec/ogcapi-maps-1/1.0/req/jpeg)
 * <<rc_tiff,TIFF>> (http://www.opengis.net/spec/ogcapi-maps-1/1.0/req/tiff)
-* <<rc_svg,TIFF>> (http://www.opengis.net/spec/ogcapi-maps-1/1.0/req/svg)
+* <<rc_svg,SVG>> (http://www.opengis.net/spec/ogcapi-maps-1/1.0/req/svg)
 * <<rc_html,HTML>> (http://www.opengis.net/spec/ogcapi-maps-1/1.0/req/html)
 
 All these conformance classes act as building blocks that should be implemented in combination with other more fundamental conformance classes that provide support for Web API discovery, conformity and Web API formal definition (e.g., OpenAPI). Possible alternatives for these fundamental conformance classes are _OGC API - Common Part 1: Core_, _OGC API - Features Part 1: Core_ or any other non-OGC classes that provide this functionality.

core/standard/clause_6_overview.adoc

@@ -155,7 +155,10 @@ It is foreseen that future parts will specify other extensions, such as how to g
 Other standards or extensions of standards may also provide mechanisms (e.g., additional query parameters) to deal with additional dimensions such as elevation, or more advanced temporal capabilities than what is defined in this standard's _datetime_ conformance class.
 
 ==== Dynamic and scalable map viewers
-The concept of a map as an image more that 20 years ago as part of the OGC Web Map Service. At that time, the web was only 11 years old, most HTML pages were static and JavaScript was a rudimentary programing language capable to control user entries in an HTML form and not much more. In that environment, having a service capable of creating a PNG that could be embedded as a HTML page by using an IMG tag provide the first approach to static maps on the web. At that time, the web was only 11 years old, most HTML pages were static and JavaScript was a rudimentary programing language capable to control user entries in an HTML form and not much more. By replacing the source (SRC) of the IMG tag programmatically with JavaScript, as a reaction of some user actions, provided the first approach to dynamic maps. GetFeatureInfo added a limited capability for queryable maps. However, users are now used to move around the map by frequently doing zoom and pan operations. If the server is not providing a very fast response, the user experience is not fluid and the map is not dynamic enough. One possible approach to solve this is divide the view port in tiles and request them separately. Since tiles follow a tile matrix pattern, they can be pre-rendered in the server and cached in the Internet. For implementing fast dynamic maps, this OGC API should be combined with the OGC API - Tiles.
+The concept of a map as an image more that 20 years ago as part of the OGC Web Map Service. At that time, the web was only 11 years old, most HTML pages were static and JavaScript was a rudimentary programing language capable to control user entries in an HTML form and not much more. In that environment, having a service capable of creating a PNG that could be embedded as a HTML page by using an IMG tag provide the first approach to static maps on the web.  Replacing the source (SRC) of the IMG tag programmatically with JavaScript, as a reaction of some user actions, provided the first approach to dynamic maps. GetFeatureInfo added a limited capability for queryable maps. However, users are now used to move around the map by frequently doing zoom and pan operations. If the server is not providing a very fast response, the user experience is not fluid and the map is not responsive enough. One possible approach to solve this, is divide the viewport in tiles and request them separately. Since tiles follow a tile matrix pattern, they can be pre-rendered in the server or cached in the Internet. For implementing fast dynamic maps, this OGC API should be combined with the OGC API - Tiles.
+
+==== Client side maps versus server side maps
+This standard deals with maps that are generated by the server. The client can present them with no modification. Currently, even the smallest rendering device support hardware rendering (a.k.a. the transformation from geometries to pixels can be done by the GPU). Transmitting geometries from the server commonly requires less bandwidth than transmitting the render map from the server and offers more flexibility in the client side to personalize the portrayal style. Because of this, it is expected that OGC API - Maps use cases will focus more on static maps as well as print cartography, whereas as OGC API - Tiles with raw data (e.g., Vector and Coverage Tiles) will be better suited for dynamic maps.
 
 ==== No equivalent to GetFeatureInfo as part of this document
 The GetFeatureInfo operation in the OGC Web Map Service gives the capability to clients to implement some simple level of user interaction to the map. In essence the user will focus on a point in the map (e.g. by clicking on it) and the client will request the server some textual information related to the elements represented in that point of the map (a functionality sometimes called "query by location"). If the elements represented in the map are simple features, the result should be related to their properties (attributes). If the map represents a coverage, the result should report the value of the coverage in that position (eventually, if the coverage is multidimensional, it could be a e.g. time series graphic or a vertical profile). The format of the actual response was left at the discretion of the server.

core/standard/clause_7_map_core.adoc

@@ -39,7 +39,7 @@ A map resource may be retrieved as a map subset or a tile subsets. Retrieving th
 
 NOTE: The desired encoding is selected using HTTP content negotiation. In addition to 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 embbed in a HTML IMG SRC tag)
+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 embed in a HTML IMG SRC tag)
 
 === 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.

core/standard/clause_7b_map_paramsCartographicLayout.adoc

@@ -63,14 +63,15 @@ include::requirements/requirements_class_cartographic-layout-grid-crs.adoc[]
 
 include::requirements/cartographic-layout/REQ_grid-crs-definition.adoc[]
 
-NOTE: A graticule is a network of lines on a map that delineate the geographic expressed as lines of equal latitude or longitude (a.k.a. meridians and parallels). A graticule can be added to a map by requesting a lat/long CRS (such as CRS:84). If the CRS of the map is the same as the one requested by this parameter, the grid will appear as a set of vertical and horizontal strait lines. In other CRSs, meridians a parallels may result in curbed lines.
+NOTE: A graticule is a network of lines on a map that delineate the geographic expressed as lines of equal latitude or longitude (a.k.a. meridians and parallels). A graticule can be added to a map by requesting a lat/long CRS (such as CRS:84). If the CRS of the map is the same as the one requested by this parameter, the grid will appear as a set of vertical and horizontal straight lines. In other CRSs, meridians a parallels may result in curved lines.
 
-NOTE: A CRS grid is a network of lines on a map that delineate the CRS coordinates expressed as lines of equal X or Y. If the CRS of the map is the same as the one requested by this parameter, the results in a set of vertical and horizontal strait lines.
+NOTE: A CRS grid is a network of lines on a map that delineate the CRS coordinates expressed as lines of equal X or Y. If the CRS of the map is the same as the one requested by this parameter, the results in a set of vertical and horizontal straight lines.
 
-NOTE: Commonly only one or two CRS values will be provided in this list (e.g. one graticule and another in the CRS of the projection). In some areas where there is two or more official CRS projections, three CRSs could be needed in the list. Adding more that three CRSs in the NOTE: A CRS grid is a network of lines on a map that delineate the CRS coordinates expressed as lines of equal X or Y. If the CRS of the map is the same as the one requested by this parameter, the results in a set of vertical and horizontal strait lines.
-list is expected to results in a very confusing presentation with too many lines.
+NOTE: Commonly only one or two CRS values will be provided in this list (e.g. one graticule and another in the CRS of the projection). In some areas where there is two or more official CRS projections, three CRSs could be needed in the list. Adding more that three CRSs in the list is expected to result in a confusing presentation with too many lines.
 
 NOTE: It is possibly that graticules and CRS grids are presented in a different thickness and colors that contrast better with the map. It is also possible that a grid has more than one color or thickness to emphasize different densities of the grid. An alternative or complementary style could be the use of margins and rulers showing coordinate numbers. All these variations are at the discretion of the server and cannot be controlled from the client using this conformance class.
 
+include::recommendations/cartographic-layout/PER_carto-layout-crs-curie.adoc[]
+
 ==== Response
 A successful GET response is described in the core class (http://www.opengis.net/spec/ogcapi-maps-1/1.0/conf/core). Some of these cartographic layout elements can be interpreted and executed in different ways by the server. In some cases the server can decide that some elements are inappropriate or there is no space to add them. The standard does not impose any extra requirements on the response.

core/standard/recommendations/cartographic-layout/PER_carto-layout-crs-curie.adoc

@@ -0,0 +1,8 @@
+[[per_cartographic-layout_crs-curie]]
+[width="90%",cols="2,6a"]
+|===
+^|*Permission {counter:per-id}* |*/per/cartographic-layout/crs-curie*
+^|A |The implementation MAY support un-safe CURIE without square brackets.
+|===
+
+NOTE: This makes the notation compatible with WMS.

core/standard/recommendations/crs/PER_crs-crs-curie.adoc

@@ -0,0 +1,8 @@
+[[per_crs_crs-curie]]
+[width="90%",cols="2,6a"]
+|===
+^|*Permission {counter:per-id}* |*/per/crs/crs-curie*
+^|A |The implementation MAY support un-safe CURIE without square brackets.
+|===
+
+NOTE: This makes the notation compatible with WMS.

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

@@ -2,5 +2,5 @@
 [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.
+^|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

@@ -2,5 +2,5 @@
 [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.
+^|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/recommendations/subsetting/PER_subset-crs-curie.adoc

@@ -0,0 +1,8 @@
+[[per_subset_crs-curie]]
+[width="90%",cols="2,6a"]
+|===
+^|*Permission {counter:per-id}* |*/per/subsetting/crs-curie*
+^|A |For the bbox-crs and subset-crs query parameters, the implementation MAY support un-safe CURIE without square brackets.
+|===
+
+NOTE: This makes the notation compatible with WMS.

core/standard/requirements/cartographic-layout/REQ_grid-crs-definition.adoc

@@ -16,6 +16,10 @@
     items:
       type: string
 ----
-^|B |Each name in the comma separated list in the value of the `grid-crss` SHALL be interpreted as a CRS name. For each CRS in the list, if the CRS coordinates are lat/long the server shall interpret the request for a graticule and otherwise the server shall interpret the request of a CRS grid.
-^|C |The absence of the parameter `grid-crss` SHALL be interpreted as "neither CRS grid nor graticule in the map".
+^|B |Each name in the comma separated list in the value of the `grid-crss` SHALL be interpreted as a CRS. For each CRS in the list, if the CRS coordinates are lat/long the server shall interpret the request for a graticule and otherwise the server shall interpret the request of a CRS grid.
+^|B |The implementation SHALL support any of the CRSs listed in the collection (or collections) description. If the list of supported CRS is not present, only http://www.opengis.net/def/crs/OGC/1.3/CRS84 SHALL be supported.
+^|C |The implementation SHALL support CRS expressed as URIs or as safe CURIEs.
+^|D |The absence of the parameter `grid-crss` SHALL be interpreted as "neither CRS grid nor graticule in the map".
 |===
+
+NOTE: A CURIE {authority}[-{objectType}]:{id} would map to the following OGC URI: http://www.opengis.net/def/{objectType}/{authority}/0/{id}. If -{objectType} is missing, the default object type is crs.

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

@@ -8,11 +8,14 @@
   crs:
     name: crs
     in: query
-    description: A URI of the coordinate reference system of the map response. A list of all supported CRS values can be found under the collection metadata.
+    description: A coordinate reference system of the map response. A list of all supported CRS values can be found under the collection metadata.
     required: false
     schema:
       type: string
     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.
+^|B |The implementation SHALL support any of the CRSs listed in the collection (or collections) description. If the list of supported CRS is not present, only http://www.opengis.net/def/crs/OGC/1.3/CRS84 SHALL be supported.
+^|C |The implementation SHALL support CRS expressed as URIs or as safe CURIEs.
 |===
+
+NOTE: A CURIE {authority}[-{objectType}]:{id} would map to the following OGC URI: http://www.opengis.net/def/{objectType}/{authority}/0/{id}. If -{objectType} is missing, the default object type is crs.

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

@@ -2,8 +2,10 @@
 [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.
+^|A |The `crs` property in the landing page of a dataset SHALL contain URI or safe CURIEs for the list of CRSs supported by the dataset as a whole.
+^|B |If the storage CRS is not http://www.opengis.net/def/crs/OGC/1.3/CRS84, a `storageCrs` property in the landing page of a dataset  SHALL be the URI or the safe CURIEs for the server storage CRS 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 http://www.opengis.net/def/crs/OGC/1.3/CRS84, a `storageCrs` property in the landing page of a dataset SHALL be the identifier for that CRS.
+^|D |If a `storageCrs` property is used and that is not http://www.opengis.net/def/crs/OGC/1.3/CRS84, an extent SHALL be provided in a `storageCrsExtent` property following the same schema as the extent property.
 |===
+
+NOTE: A CURIE {authority}[-{objectType}]:{id} would map to the following OGC URI: http://www.opengis.net/def/{objectType}/{authority}/0/{id}. If -{objectType} is missing, the default object type is crs.

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

@@ -2,8 +2,10 @@
 [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.
+^|A |The `crs` property in the collection object of a geospatial collection SHALL contain URI or safe CURIEs for the list of CRSs supported by the server for that collection.
+^|B |If the storage CRS is not http://www.opengis.net/def/crs/OGC/1.3/CRS84, a `storageCrs` property in the collection object of a geospatial collection SHALL be the URI or the safe CURIEs 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 http://www.opengis.net/def/crs/OGC/1.3/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 http://www.opengis.net/def/crs/OGC/1.3/CRS84, an extent SHALL be provided in a `storageCrsExtent` property following the same schema as the extent property.
 |===
+
+NOTE: A CURIE {authority}[-{objectType}]:{id} would map to the following OGC URI: http://www.opengis.net/def/{objectType}/{authority}/0/{id}. If -{objectType} is missing, the default object type is crs.