General usage of the European ETRS89 coordinate reference system (CRS) or RD/NAP is preferred, but is not the default CRS. Hence, one of these CRSs has to be explicitly included in each request when one of these CRSs is desired in the response or used in a request.
-
API-GEO-9 : When the API provides data in an ensemble CRS like WGS 84 or ETRS89 while it is known to what ensemble member CRS the data actually refers, this ensemble member should also be one of the CRSs supported by the API and advertised in the CRS list. E.g. when 2D data is transformed from RD with RDNAPTRANS not only EPSG:4258 should be supported but also EPSG::9067.
-
How to test
+
Under certain conditions WGS 84 can be made equal to e.g. ETRS89, this is called a nultransformation, see [hr-crs
+
+
API-GEO-11 : When the API provides data in an ensemble CRS like WGS 84 or ETRS89 while it is known to what ensemble member CRS the data actually refers, this ensemble member should also be one of the CRSs supported by the API and advertised in the CRS list. E.g. when 2D data is transformed from RD with RDNAPTRANS not only EPSG:4258 should be supported but also EPSG:9067.
+
How to test
Issue an HTTP GET request to the /collections endpoint.
Validate that the returned document contains a collections object with the crs property.
Validate that the crs property contains an array with CRS references in the form of URIs.
Validate that when the crs property contains a URL for a ensemble CRS like ETRS89 (EPSG:4258), it also contains a URL for a ensemble member CRS like ETRF2000 (EPSG:9067).
-
The CRS can be specified for request and response individually using parameters or headers.
-
API-GEO-10 : Support passing the coordinate reference system (CRS) of the geometry in the request as a query parameter
+
The CRS can be specified for request and response individually using parameters or headers.
+
API-GEO-12 : Support passing the coordinate reference system (CRS) of the geometry in the request as a query parameter
Support the OGC API Features part 2 bbox-crs parameter in conformance to the standard.
-
If a bounding box or geospatial filter is sent to the server without these parameters, the default CRS, CRS84, is assumed as specified in API-GEO-7 .
-
If an invalid value, i.e. a CRS which is not in the list of supported CRSs, is given for one of these parameters, the server responds with an HTTP status code `400`.
+
If a bounding box or geospatial filter is sent to the server without these parameters, the default CRS, CRS84, is assumed as specified in API-GEO-9 .
+
If an invalid value, i.e. a CRS which is not in the list of supported CRSs, is given for one of these parameters, the server responds with an HTTP status code 400.
Additionally, if other types of geospatial filters are supported in the API besides bbox:
Support the OGC API Features part 3 filter-crs parameter in conformance to the standard.
-
How to test
+
How to test
Issue an HTTP GET request to the API, including the bbox parameter AND the bbox-crs parameter.
Validate that a document was returned with a status code 200.
Verify that the response includes a Content-Crs http header with the URI of the requested CRS identifier.
Perform the same test for the filter-crs parameter, if the server supports other types of geospatial filters.
-
In an API that supports the creation and/or updating of items, POST, PUT or PATCH requests with geospatial content in the body may be sent by a client to the server. In that case, it is necessary to indicate the CRS used, unless CRS84, the default CRS, is used.
-
API-GEO-11 : When HTTP POST, PUT and/or PATCH requests are supported, pass the coordinate reference system (CRS) of geometry in the request body as a header
+
In an API that supports the creation and/or updating of items, POST, PUT or PATCH requests with geospatial content in the body may be sent by a client to the server. In that case, it is necessary to indicate the CRS used, unless CRS84, the default CRS, is used.
+
API-GEO-13 : When HTTP POST, PUT and/or PATCH requests are supported, pass the coordinate reference system (CRS) of geometry in the request body as a header
Support the OGC API Features part 4 Content-Crs header in conformance to the standard.
-
Alternatively, if the feature representation supports expressing CRS information for each feature / geometry, the information can also be included in the feature representation. If no CRS is asserted, the default CRS, CRS84, is assumed, as stated in API-GEO-7 .
-
How to test
+
Alternatively, if the feature representation supports expressing CRS information for each feature / geometry, the information can also be included in the feature representation. If no CRS is asserted, the default CRS, CRS84, is assumed, as stated in API-GEO-9 .
+
How to test
In a request (i.e. when creating or updating an item on the server):
Issue an HTTP POST request to the API with spatial data in the request body, including the Content-Crs header with the value of the CRS identifier for the spatial data in the body.
Verify that a document was returned with status code 201 in case a new item was created, or with status code 200.
Repeat with a similar test voor PUT and/or PATCH if the server supports these.
-
-
API-GEO-12 : Support passing the desired coordinate reference system (CRS) of the geometry in the response as a query parameter
+
+
API-GEO-14 : Support passing the desired coordinate reference system (CRS) of the geometry in the response as a query parameter
Support the OGC API Features part 2 crs parameter in conformance to the standard.
-
How to test
+
How to test
Issue an HTTP GET request to the API, including the crs parameter.
Verify that the response has the status code 200, and includes a Content-Crs http header with the value of the requested CRS identifier.
-
-
API-GEO-13 : Assert the coordinate reference system (CRS) used in the response using a header
+
+
API-GEO-15 : Assert the coordinate reference system (CRS) used in the response using a header
Support the OGC API Features part 2 Content-Crs header in conformance to the standard.
-
How to test
+
How to test
Issue an HTTP GET request to the API, requesting spatial data.
Verify that the response includes the Content-Crs header with the URI of the requested CRS identifier if explicitly requested, or with the value http://www.opengis.net/def/crs/OGC/1.3/CRS84 if no CRS was explicitly requested.
@@ -1204,7 +1366,7 @@ How to test
Geometry filter in request, geometry in response
The client indicates the CRS of the geometry filter in the request using bbox-crs or filter-crs as in the previous scenario, and requests a specific CRS for the geometries in the response using the crs parameter. The server indicates the geometry CRS in response using the Content-Crs header.
-Use the following URIs to specify the CRS:
Below is a list of the most commonly used CRSs in the Netherlands:
Note : CRS support and GeoJSON
+For a more extensive overview of CRSs see: https://docs.geostandaarden.nl/crs/crs/#bijlage-a-crs-overzicht-tabel .
+Note that the URI of each CRS contains a version number and that new versions may be released in future.
+Before using a URI verify if newer versions are available and use the latest version.
Note : CRS support and GeoJSON
Officially, WGS 84 longitude-latitude (CRS84) is the only CRS allowed in GeoJSON. However, GeoJSON does state that using another CRS is allowed, if this is agreed between provider and consumer of the data. The API functionality described above, to negotiate the CRS between client and server, can be viewed as such an agreement. Many GIS clients can deal with GeoJSON in other CRS than CRS84.
In addition, the Geonovum CRS guidelines [hr-crs how ETRS89 can be treated as equal to CRS84 under certain circumstances .
@@ -1294,7 +1464,33 @@ How to test
describing encoding metadata links These requirements should be met when an API serves features for an INSPIRE dataset.
- A. AppendixA.1 Old CRS negotiation methodAn older method of specifying CRS in the headers of requests is described in this appendix. It was part of the first version of the "Geospatial Extension" which was never ratified. APIs that already support this old header method can add support for the current parameter method (see CRS negotiation ) while still supporting the header method for a certain period. Supporting both the new method (using parameters) and the old (using headers) is trivial.
If a client specifies CRS using a parameter AND in the header, the parameter takes precedence and the CRS in the header is ignored.
What follows is the original description of the rule in the old Geospatial Extension.
Rule : Pass the coordinate reference system (CRS) of the request and the response in the headers
The coordinate reference system (CRS) for both the request and the response are passed as part of the request headers and response headers. In case this header is missing, send the HTTP status code 412 Precondition Failed.
The following headers are purely meant for negotiation between the client and the server. Depending on the application, the request not only contains geometries but also specific meta data, e.g. the original realization including the collection date.
Request and response may be based on another coordinate reference system. This applies the HTTP-mechanism for content negotiation. The CRS of the geometry in the request (request body) is specified using the header Content-Crs.
+ A. Appendix - deprecated rulesThis appendix contains some of the rules that were described in the first version of the "Geospatial Extension", which was never officially adopted as a standard. Only those rules that are still relevant in some situations or do not have a good replacement in the current Geospatial model are retained here. They are shown here only as information.
A.1 POST endpoint for geospatial queriesA spatial filter can be complex and large. It is best practice to supply complex queries in the body, not in the request URI. Since GET may not have a payload (although supported by some clients) use a POST request to a separate endpoint. For example, a GEO query to all panden where the geometry in the field _geo (there may be multiple geometry fields) contains a GeoJSON object (in this case a Point, so one coordinate pair):
Deprecated rule (was: API-36) : Provide a POST endpoint for geo queries
Spatial queries are sent in a POST to a dedicated endpoint.
+ {
+ "_geo" : {
+ "contains" : {
+ "type" : "Point" ,
+ "coordinates" : [5.9623762 , 52.2118093 ]
+ }
+ }
+ }
+ Other geospatial operators like intersects or within can be used as well.
Deprecated rule (was: API-37) : Support mixed queries at POST endpoints
The POST endpoint is preferably set up as a generic query endpoint to support combined queries:
+ {
+ "_geo" : {
+ "contains" : {
+ "type" : "Point" ,
+ "coordinates" : [5.9623762 , 52.2118093 ]
+ }
+ },
+ "status" : "Actief"
+ }
+ A.2 Old CRS negotiation methodNote
An older method of specifying CRS in the headers of requests was part of the first version of the "Geospatial Extension" which was never officially adopted as a standard. APIs that already support this old header method can add support for the current parameter method (see CRS negotiation ) while still supporting the header method for a certain period. Supporting both the new method (using parameters) and the old (using headers) is trivial.
+
+If a client specifies CRS using a parameter AND in the header, the parameter takes precedence and the CRS in the header is ignored.
+What follows is the original description of the rule in the old Geospatial Extension.
+ Deprecated rule (was: API-40) : Pass the coordinate reference system (CRS) of the request and the response in the headers
The coordinate reference system (CRS) for both the request and the response are passed as part of the request headers and response headers. In case this header is missing, send the HTTP status code 412 Precondition Failed.
The following headers are purely meant for negotiation between the client and the server. Depending on the application, the request not only contains geometries but also specific meta data, e.g. the original realization including the collection date.
Request and response may be based on another coordinate reference system. This applies the HTTP-mechanism for content negotiation. The CRS of the geometry in the request (request body) is specified using the header Content-Crs.
HTTP header
@@ -1350,7 +1546,7 @@ How to test
EPSG:28992
RD, Dutch
-
Rule : Use content negotiation to serve different CRSs
The CRS for the geometry in the response body is defined using the Accept-Crs header. In case the API does not support the requested CRS, send the HTTP status code 406 Not Acceptable.
Deprecated rule (was: API-41) : Use content negotiation to serve different CRSs
The CRS for the geometry in the response body is defined using the Accept-Crs header. In case the API does not support the requested CRS, send the HTTP status code 406 Not Acceptable.
