From f1c2b0941ef73260dedee9cf18bff5def13f792d Mon Sep 17 00:00:00 2001 From: Linda van den Brink Date: Thu, 30 Mar 2023 17:32:51 +0200 Subject: [PATCH] update snapshot geo module --- API-strategie-extensies/snapshot-modgeo.html | 440 ++++++++++++++----- 1 file changed, 318 insertions(+), 122 deletions(-) diff --git a/API-strategie-extensies/snapshot-modgeo.html b/API-strategie-extensies/snapshot-modgeo.html index a594cff4..22a8e1df 100644 --- a/API-strategie-extensies/snapshot-modgeo.html +++ b/API-strategie-extensies/snapshot-modgeo.html @@ -546,8 +546,8 @@ "postProcess": [ null ], - "publishISODate": "2023-03-27T22:00:00.000Z", - "generatedSubtitle": "Werkversie 27 maart 2023" + "publishISODate": "2023-03-29T22:00:00.000Z", + "generatedSubtitle": "Werkversie 29 maart 2023" } -
+

API Design rules Module: Geospatial

Geonovum Handreiking
- Werkversie

+ Werkversie
This version:
https://geonovum.github.io/KP-APIs/API-strategie-mod-geo/
Latest published version:
https://docs.geostandaarden.nl/api/API-Strategie-mod-geo/
@@ -730,7 +730,7 @@

Geonovum Handreiking

-

Abstract

The API strategy consists of a core — a generic set of rules for all government APIs — and various modules that only pertain to a specific application. See API Strategie for a list of all parts of the API Strategy.

This document describes the Geospatial module, containing rules for geospatial content and functions in APIs.

+

Abstract

The API strategy consists of a core — a generic set of rules for all government APIs — and various modules that only pertain to a specific application. See API Strategie for a list of all parts of the API Strategy.

This document describes the Geospatial module, containing rules for geospatial content and functions in APIs.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current Geonovum publications and the latest revision of this document can be found via https://www.geonovum.nl/geo-standaarden/alle-standaarden(in Dutch).

@@ -744,7 +744,7 @@

Geonovum Handreiking
-

In dit document zijn wijzigingen naar aanleiding van een deel van de consultatiereacties doorgevoerd. Nog niet alle consultatiereacties zijn verwerkt.

+

@@ -753,22 +753,59 @@

Geonovum Handreiking

Geospatial data is more specific in that it is explicitly located relative to the Earth.

Geospatial data is 'special' data in the sense that it typically indicates the location of things using geometry. This geometry allows geospatial functions such as 'find only the things located within this area' but also requires specific ways of handling. There are international regulations and standards for geospatial data that need to be taken into account in certain cases.

castle features shown on map with bounding box
Figure 1 The red bounding box acts as a filter to find only the castles located within this area
-

The Geospatial Module provides rules for the structuring of geospatial payloads and for functions in APIs to handle geospatial data.

In the geospatial module the abbreviation RD is used. RD refers to the "Stelsel van de Rijksdriehoeksmeting", this is the equivalent of EPSG code 28992 and EPSG name Amersfoort / RD New.

+

The Geospatial Module provides rules for the structuring of geospatial payloads and for functions in APIs to handle geospatial data.

Note

2. Request and response

Providing requested resources is the essence of any API. This also applies to REST APIs that handle geospatial data. There are, however, some specific aspects when dealing with geospatial data in REST APIs. The most important aspects are described in this chapter:

  • how to encode geometries in APIs
  • how to supply a spatial filter in the call (request)
  • how to return results of a spatial search
    • -

When requesting information, for example about cadastral parcels, users do not necessarily require the geometry, even if they used a spatial filter. A name or parcel ID may be sufficient.

Note

2.2 Call (requests)

A simple spatial filter can be supplied as a bounding box. This is a common way of filtering spatial data and can be supplied as a parameter. We adopt the OGC API Features [ogcapi-features-1] bounding box parameter:

+

API-GEO-1: Supply a simple spatial filter as a bounding box parameter

Support the OGC API Features part 1 bbox query parameter in conformance to the standard.

    GET /api/v1/buildings?bbox=5.4,52.1,5.5,53.2

Note that if a resource contains multiple geometries, it is up to the provider to decide if a single or multiple geometries are returned and that the provider shall clearly document this behavior. @@ -789,13 +826,13 @@

How to test

  • Validate that a response with status code 200 is returned.
  • Verify that only features that have a spatial geometry that intersects the bounding box are returned as part of the result set.
    • -
    Note
    Note
    -

    API-GEO-3: Place results of a global spatial query in the relevant geometric context

    +

    However, until the filtering module is written, the geospatial module retains rule API-GEO-2 about dealing with results of a global spatial query. This rule may be moved to the filtering module at a later stage.

    +
    +

    API-GEO-2: Place results of a global spatial query in the relevant geometric context

    In case of a global query /api/v1/_search, results should be placed in the relevant geometric context, because results from different collections, i.e. different sets of resources of the same type, are retrieved. Express the name of the collection to which the results belong in the singular form using the property type. For example:

      // POST /api/v1/_search:
   {
@@ -829,14 +866,14 @@ 
    How to test
    
 
  • Issue an HTTP GET request to the API.
    • 
 
  • Validate that the returned document contains the expected type property for each member.
    • 
 
-

    2.3 Result (response)

    In case a REST API shall comply to the OGC API Features specification, e.g. for usage in GIS applications, the following applies.

    -

    API-GEO-1: Support GeoJSON for geospatial APIs

    -

    For representing 2D geometric information in an API, use the convention for describing geometry as defined in the GeoJSON format [rfc7946]. Support GeoJSON as described in OGC API Features Requirements class 8.3 [ogcapi-features-1]. -

    -Example: feature -
      {
-    "type": "Feature",
-    "id": "0308100000022041",
+

    In case a REST API shall comply to the OGC API Features specification for creating, updating and deleting a resource, the following applies.

    +

    API-GEO-3: Support GeoJSON in geospatial API requests

    +

    For representing geometric information in an API request, use the convention for describing geometry as defined in the GeoJSON format [rfc7946]. Support GeoJSON as described in OGC API Features part 4, but note that this standard is still in development.

    +Example: POST feature +
      POST /collections/gebouwen/items   HTTP/1.1
+  Content-Type: application/geo+json
+  {
+    "type": "Feature",
     "geometry":  {
       "type": "Point",
       "coordinates": [5.2795,52.1933]
@@ -844,22 +881,17 @@ 
    How to test
    
     "properties": {
       "naam": "Paleis Soestdijk",
       ...
-    },
-    "links": [
-    {
-      "self": ""
-    } 
-    ]
+    }
   }
    - -

    Example: feature collection

    -
      {
-    "type": "FeatureCollection",
+Example: POST feature collection
+
      POST /collections   HTTP/1.1
+  Content-Type: application/geo+json
+  {
+    "type": "FeatureCollection",
     "features": [
     {
       "type": "Feature",
-      "id": "0308100000022041",
       "geometry":  {
         "type": "Point",
         "coordinates": [5.2795,52.1933]
@@ -867,33 +899,131 @@ 
    How to test
    
       "properties": {
         "naam": "Paleis Soestdijk",
         ...
-      },
-      "links": [
+      }
+    }]
+  }  
+  
    
+
    How to test
    
+
      
+
    • Create a new resource that includes feature content (i.e. coordinates) using the HTTP POST method with request media type application/geo+json in the Content-Type header.
      • 
+
    • Validate that a response with status code 201 (Created) is returned.
      • 
+
    • Validate that the response includes the Location header with the URI of the newly added resource.
+
    
+

    In case a REST API does not have to comply to the OGC API Features specification, e.g. for usage in administrative applications, the REST API shall use the JSON data format. If a resource contains geometry, that geometry shall be embedded as a GeoJSON Geometry object within the resource. The media type application/json must be supported. This may also apply to other media types application/*+json, however this depends on the media type specification. If the media type specification prescribes that resource information must be embedded in a JSON structure defined in the media specification, then the media type should not be supported while it is impossible to comply to that specification with the method described below. The media type application/geo+json should not be supported while the resource does not comply to the GeoJSON specification, i.e. the request resource does not embed a feature or feature collection. +A template for the definition of the schemas for the GeoJSON Geometry object in the requests in OpenAPI definitions is available: geometryGeoJSON.yaml. +In case a collection of resources is embedded in the request resource, the name of the array containing the resources should be the plural of the resource name.

    +

    API-GEO-4: Embed GeoJSON Geometry object as part of the JSON resource in API requests

    +

    When a JSON (application/json) request contains a geometry, represent it in the same way as the Geometry object of GeoJSON.

    +Example: POST resource containing geometry +
      POST /collections/gebouwen/items   HTTP/1.1
+  Content-Type: application/json
+  {
+    "naam": "Paleis Soestdijk",
+    "geometrie": {
+      "type": "Point",
+      "coordinates": [5.2795,52.1933]
+    }
+  }
+
    +Example: POST resource containing geometry collection +
      POST /collections/gebouwen/items   HTTP/1.1
+  Content-Type: application/json
+  {
+    "naam": "Paleis Soestdijk",
+    "geometrie": {
+      "type": "GeometryCollection",
+      "geometries": [
+        {
+          "type": "Point",
+          "coordinates": [5.2795,52.1933]
+        }
+      ]
+    }
+  }
+
    +

    How to test

    +
      +
    • Create a new resource that includes geometry of GeoJSON Geometry object type using the HTTP POST method with request media type application/json in the Content-Type header.
      • +
    • Validate that a response with status code 201 (Created) is returned.
      • +
    • Validate that the response includes the Location header with the URI of the newly added resource. +
    +

    2.3 Result (response)

    In case a REST API shall comply to the OGC API Features specification, e.g. for usage in GIS applications, the following applies.

    +

    API-GEO-5: Support GeoJSON in geospatial API responses

    +

    For representing 2D geometric information in an API response, use the convention for describing geometry as defined in the GeoJSON format [rfc7946]. Support GeoJSON as described in OGC API Features Requirements class 8.3 [ogcapi-features-1]. +

    +Example: feature +
      Request:
+  // GET /collections/gebouwen/items/0308100000022041   HTTP 1.1
+  // Content-type: application/geo+json
+
+
+
+  Response:
+  {
+    "type": "Feature",
+    "id": "0308100000022041",
+    "geometry":  {
+      "type": "Point",
+      "coordinates": [5.2795,52.1933]
+    },
+    "properties": {
+      "naam": "Paleis Soestdijk",
+      ...
+    },
+    "links": [
       {
-        "self": ""
+        "self": "/collections/gebouwen/items/0308100000022041"
       } 
-      ]
-    }],
-    "timeStamp" : "2023-02-22T10:32:23Z",
+    ]
+  }

    +

    Example: feature collection

    +
      Request:
+  // GET /collections/gebouwen   HTTP 1.1
+  // Content-type: application/geo+json
+
+  Response:
+  {
+    "type": "FeatureCollection",
+    "features": [
+      {
+        "type": "Feature",
+        "id": "0308100000022041",
+        "geometry":  {
+          "type": "Point",
+          "coordinates": [5.2795,52.1933]
+        },
+        "properties": {
+          "naam": "Paleis Soestdijk",
+          ...
+        },
+        "links": [
+          {
+            "self": "/collections/gebouwen/0308100000022041"
+          } 
+        ]
+      },
+      {
+      }
+    ],
+    "timeStamp" : "2023-02-22T10:32:23Z",
     "numberMatched" : "0308100000022041",
     "numberReturned" : "1",
     "links": [
-    {
-      "self": ""
-    } ,
-    {
-      "next": ""
-    } ,
+      {
+        "self": "/collections/gebouwen"
+      },
+      {
+        "next": ""
+      }
     ]
-  }
-
    + }

    Note that:

    • The resources' properties (e.g. naam) are passed in the properties object. Depending on the implemented filter capabilities the properties object may contain all or a selection of the resources' properties.
      • -
    • The OGC API Fearures specification provides the possibility to add an array of links to a feature and feature collection, which may contain a self link and in case of a feature collection may contain navigation links.

      -

      How to test

      +
    • The OGC API Features specification provides the possibility to add an array of links to a feature and feature collection, which may contain a self link and in case of a feature collection may contain navigation links.

      +

      How to test

      Test case 1:

      @@ -930,70 +1060,92 @@

      How to test

    • Validate that Content-Type header contains application/json
    • Validate that the returned document is a JSON document.
    -

    In case a REST API does not have to comply to the OGC API Features specification, e.g. for usage in administrative applications, the REST API shall use the JSON data format. If resources contain geometry, the geometry shall be returned as a GeoJSON Geometry object embedded in the resource. The media type application/json must be supported. The media type application/geo+json should not be supported while the resource does not comply to the GeoJSON specification, i.e. the response does not return a feature or feature collection. -A template for the definition of the schemas for the GeoJSON Geometry object in the responses in OpenAPI definitions are available geometryGeoJSON.yaml. -In case a collection of resources is returned, the name of the array containing the resources should be the plural of the resource name.

    -

    API-GEO-4: Embed GeoJSON Geometry object as part of the JSON resource

    +

    In case a REST API does not have to comply to the OGC API Features specification, e.g. for usage in administrative applications, the REST API shall use the JSON data format. If resources contain geometry, the geometry shall be returned as a GeoJSON Geometry object embedded in the resource. The media type application/json must be supported. This may also apply to other media types application/*+json, however this depends on the media type specification. If the media type specification prescribes that resource information must be embedded in a JSON structure defined in the media type specification, then the media type should not be supported while it is impossible to comply to that specification with the method described below. The media type application/geo+json should not be supported while the resource does not comply to the GeoJSON specification, i.e. the response does not return a feature or feature collection. +A template for the definition of the schemas for the GeoJSON Geometry object in the responses in OpenAPI definitions is available: geometryGeoJSON.yaml. +In case a collection of resources is returned, the name of the array containing the resources should be the plural of the resource name.

    +

    API-GEO-6: Embed GeoJSON Geometry object as part of the JSON resource in API responses

    When a JSON (application/json) response contains a geometry, represent it in the same way as the Geometry object of GeoJSON.

    Example: resource containing geometry

    -
      {
-    "identificatie": "0308100000022041",
+
      Request:
+  // GET /gebouwen/0308100000022041   HTTP 1.1
+  // Content-type: application/hal+json
+
+  Response:
+  {
+    "identificatie": "0308100000022041",
     "naam": "Paleis Soestdijk",
     "geometrie":  {
       "type": "Point",
       "coordinates": [5.2795,52.1933]
     },
     ...,
-    "_links": {
+    "_links": {
       {
-        "self": ""
+        "self": "/gebouwen/0308100000022041"
       }
     }
   }
    
 
 
    Example: resource containing geometry collection
    
-
      {
-    "identificatie": "0308100000022041",
+
      Request:
+  // GET /gebouwen/0308100000022041   HTTP 1.1
+  // Content-type: application/hal+json
+
+  Response:
+  {
+    "identificatie": "0308100000022041",
     "naam": "Paleis Soestdijk",
     "geometrie": {
       "type": "GeometryCollection",
       "geometries": [
-        "type": "Point"
-        "coordinates": [5.2795,52.1933]
+        {
+          "type": "Point"
+          "coordinates": [5.2795,52.1933]
+        },
+        {
+          "type": "Polygon"
+          "coordinates" : [...]
+        }
       ]
     },
     ...,
-    "_links": {
+    "_links": {
       {
-        "self": ""
+        "self": "/gebouwen/0308100000022041"
       }
     }
   }
    
 
 
    Example: collection of resources containing geometry
    
-
      {
-    "<plural of resource name>": [
-    {
-      "identificatie": "0308100000022041",
-      "naam": "Paleis Soestdijk",
-      "geometrie":  {
-        "type": "Point",
-        "coordinates": [5.2795,52.1933]
-      }
-      ...
-      "_links": {
-        {
-          "self": ""
+
      Request:
+  // GET /gebouwen   HTTP 1.1
+  // Content-type: application/hal+json
+
+  Response:
+  {
+    "gebouwen": [
+      {
+        "identificatie": "0308100000022041",
+        "naam": "Paleis Soestdijk",
+        "geometrie":  {
+          "type": "Point",
+          "coordinates": [5.2795,52.1933]
+        }
+        ...
+        "_links": {
+          {
+            "self": "/gebouwen/0308100000022041"
+          }
         }
       }
-    } ],
-    "_links": {
+    ],
+    "_links": {
       {
-        "self": ""
+        "self": "/gebouwen"
       },
       {
-        "next": ""
+        "next": ""
       }
     }
   }
    
@@ -1001,8 +1153,8 @@ 
    How to test
    
 Note that:
 
 
      
-
    • The resource and resource collection may be [HAL] resources and therefore may contain a _links object. The _links object should contain a self link and in case of a collection also navigation links (e.g. first, next prev, last).
      
-
      How to test
      
+
    • The resource and resource collection may be [HAL] resources and therefore may contain a _links object. The _links object should contain a self link and in case of a collection also navigation links (e.g. first, next prev, last). In such cases the application/hal+json media type may be used.
      
+
      How to test
      
 
      
 Test case 1:
 
      
@@ -1063,42 +1215,52 @@ 
      How to test

    3. Coordinate Reference System (CRS)

    A Coordinate Reference System (CRS) or Spatial Reference System (SRS) is a framework to measure locations on the earth surface as coordinates. Geometries consist of coordinates. To be able to measure the geometry's coordinates on the earth surface a CRS is required in conjunction with the coordinates.

    CRSs are uniquely identified by means of a Spatial Reference System Identifier (SRID). -SRIDs may refer to different standards, for example EPSG Geodetic Parameter Dataset or Open Geospatial Consortium (OGC).

    CRSs may be grouped into ensemble CRSs. The CRSs that are part of an ensemble CRS are called ensemble member CRSs or member CRSs. When exchanging geometry an ensemble member CRS shall be used instead of an ensemble CRS when known and if accurate data is required. When transforming geometry from one CRS to another, use an ensemble member CRS (instead of an ensemble CRS) as input and output of coordinate transformation, when known and if accurate data is required.

    For a detailed description of CRSs see [hr-crs].

    3.1 CRS discovery

    A client shall be able to determine a list of CRSs supported by an API.

    -

    API-GEO-5: Provide a list of all CRSs that are supported by the API

    +SRIDs may refer to different standards, for example EPSG Geodetic Parameter Dataset or Open Geospatial Consortium (OGC).

    CRSs may be grouped into ensemble CRSs. The CRSs that are part of an ensemble CRS are called ensemble member CRSs or member CRSs. When exchanging geometry an ensemble member CRS shall be used instead of an ensemble CRS when known and if accurate data is required. When transforming geometry from one CRS to another, use an ensemble member CRS (instead of an ensemble CRS) as input and output of coordinate transformation, when known and if accurate data is required.

    For a detailed description of CRSs see [hr-crs].

    3.1 CRS discovery

    A client shall be able to determine a list of CRSs supported by an API.

    +

    API-GEO-7: Provide a list of all CRSs that are supported by the API

    +

    If a REST API shall comply to the OGC API Features specification then the API must provide an endpoint to determine a list of supported CRSs.

      // GET /api/v1/collections:
    -

    How to test

    +

    How to test

    • Issue an HTTP GET request to the /collections endpoint of the API.
    • 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 the CRS URIs return a GML document with an epsg:CommonMetadata element (xmlns:epsg="urn:x-ogp:spec:schema-xsd:EPSG:1.0:dataset
      • +
    • Validate that the CRS URIs return a GML document with an epsg:CommonMetadata element (xmlns:epsg="urn:x-ogp:spec:schema-xsd:EPSG:1.0:dataset).
      • +
    +

    If a REST API does not have to comply to the OGC API Features specification, e.g. when the API is used for administrative purposes, then the API shall also provide an endpoint to determine the supported CRSs.

    +
      // GET /api/v1/crss:
    +

    How to test

    +
      +
    • Issue an HTTP GET request to the /crss endpoint of the API.
      • +
    • Validate that the returned document contains an object with a crs property.
      • +
    • Validate that the crs property contains an array with CRS references in the form of URIs.
      • +
    • Validate that the CRS URIs return a GML document with an epsg:CommonMetadata element (xmlns:epsg="urn:x-ogp:spec:schema-xsd:EPSG:1.0:dataset).

    According to OGC API Features - part 1 - 7.13. Feature collections an OGC API Features API shall provide a GET operation on the /collections endpoint which returns a collections object.

    OGC API Features - part 2 - Coordinate Reference Systems by Reference [ogcapi-features-2] describes how to support different CRSs in your geospatial API. According to OGC API Features - part 2 - 6.2 Discovery and in particular Global list of CRS identifiers, a collections object provided by the API's /collections endpoint may contain a global list of supported CRSs by means of the crs property. This global CRS list applies to all feature collections delivered by the API, unless otherwise stated at a feature collection.

    Each feature collection mentioned within the collections list may also contain a crs property if the set of supported CRSs differs from the global CRS list. -If a feature collection supports exactly the same CRSs as mentioned in the global CRS list, then the crs property may be omitted.

    If a feature collection supports additional CRSs compared to the global CRS list in the collections object, then a reference to the global CRS list #/crs may be added in the feature collection object and the URIs of the additional CRSs are added to the CRS list in the crs property of the feature collection.

    If a feature collection supports a different set of CRSs than the set defined in the global CRS list, then a reference to the global CRS list is omitted and only the URIs of the supported CRSs are added to the CRS list in the crs property of the feature collection.

    For clients, it may be helpful to know the CRS identifier that may be used to retrieve features from that collection without the need to apply a CRS transformation.

    -

    API-GEO-6: Make known in which CRS the geospatial data is stored by specifying the property storageCrs in the collection object.

    +If a feature collection supports exactly the same CRSs as mentioned in the global CRS list, then the crs property may be omitted.

    If a feature collection supports additional CRSs compared to the global CRS list in the collections object, then a reference to the global CRS list #/crs may be added in the feature collection object and the URIs of the additional CRSs are added to the CRS list in the crs property of the feature collection.

    If a feature collection supports a different set of CRSs than the set defined in the global CRS list, then a reference to the global CRS list is omitted and only the URIs of the supported CRSs are added to the CRS list in the crs property of the feature collection.

    For clients, it may be helpful to know the CRS identifier that may be used to retrieve features from that collection without the need to apply a CRS transformation. If all features in a feature collection are stored using a particular CRS, the property storageCRS shall be used to specify this CRS, in accordance with OGC API Features - part 2 - 6.2.2 Storage CRS. The value of this property shall be one of the CRSs supported by the API and advertised in the CRS list as stated in requirement 4 of OGC API Features - part 2 - 6.2.2 Storage CRS. If relevant, the epoch should also be specified, using the storageCRSCoordinateEpoch property. For an explanation of the use of epochs with CRS, see the CRS Guidelines [hr-crs].

    +

    API-GEO-8: Make known in which CRS the geospatial data is stored by specifying the property storageCrs in the collection object.

    The value of this property shall be one of the CRSs the API supports.

    -

    How to test

    +

    How to test

    • Issue an HTTP GET request to each collection in the /collections endpoint of the API.
    • Validate that each returned collection contains the storageCRS property.
    • Validate that the value of the storageCRS property is one of the URIs from the list of supported CRSs.
    -

    If all features in a feature collection are stored using a particular CRS, the property storageCRS shall be used to specify this CRS, in accordance with OGC API Features - part 2 - 6.2.2 Storage CRS. The value of this property shall be one of the CRSs supported by the API and advertised in the CRS list as stated in requirement 4 of OGC API Features - part 2 - 6.2.2 Storage CRS. If relevant, the epoch should also be specified, using the storageCRSCoordinateEpoch property. For an explanation of the use of epochs with CRS, see the CRS Guidelines [hr-crs].

    3.2 CRS negotiation

    The default CRS for GeoJSON and for OGC API Features is WGS 84 with coordinate order longitude-latitude, also referred to as "CRS84". This refers to an ensemble of global CRSs that can be applied world-wide. Due to the datum and the tectonic displacements it is not accurate enough for local coordinate reference systems like ETRS89 (EPSG:4258, European), or RD (EPSG:28992, Dutch). For more information about coordinate reference systems, read the Geonovum guidelines on CRS [hr-crs].

    Note: Convention

    3.2 CRS negotiation

    The default CRS for GeoJSON and for OGC API Features is WGS 84 with coordinate order longitude-latitude, also referred to as "CRS84". This refers to an ensemble of global CRSs that can be applied world-wide. Due to the datum and the tectonic displacements it is not accurate enough for local coordinate reference systems like ETRS89 (EPSG:4258, European), or RD (EPSG:28992, Dutch). For more information about coordinate reference systems, read the Geonovum guidelines on CRS [hr-crs].

    Note: Convention

    Since most client-side mapping libraries use WGS 84 longitude-latitude (CRS84), the W3C/OGC Spatial Data on the Web working group recommends to use this as the default coordinate reference system. The API strategy caters for this supporting not only ETRS89 and RD, but also CRS84.

    The default CRS, i.e. the CRS which is assumed when not specified by either the API or the client, is CRS84, in line with GeoJSON and OGC API Features.

    -

    API-GEO-7: Use CRS84 as the default coordinate reference system (CRS). Support CRS84 in line with OGC API Features Requirement 10. +

    Since most client-side mapping libraries use WGS 84 longitude-latitude (CRS84), the W3C/OGC Spatial Data on the Web working group recommends to use this as the default coordinate reference system. The API strategy caters for this supporting not only ETRS89 and RD, but also CRS84.

    The default CRS, i.e. the CRS which is assumed when not specified by either the API or the client, is CRS84, in line with GeoJSON and OGC API Features.

    +

    API-GEO-9: Use CRS84 as the default coordinate reference system (CRS). Support CRS84 in line with OGC API Features Requirement 10.

    The implication of this is, that if no CRS is explicitly included in the request, CRS84 is assumed. This rule also applies if the request uses POST.

    -

    How to test

    +

    How to test

    • Issue an HTTP GET request to retrieve some spatial data from the API without specifying a coordinate reference system.
    • Validate that the response includes a Content-Crs header with the URI for CRS84 or CRS84h.
    • Validate the retrieved spatial data using the CRS84 reference system (for 2D geometries) or the CRS84h reference system (for 3D geometries).
    -

    In addition, support for ETRS89 and/or RD is required.

    -

    API-GEO-8: Use ETRS89 and/or RD when required, as these are the preferred coordinate reference systems (CRS) for Dutch geospatial data. Follow the Dutch Guideline for the use of CRSs [hr-crs].

    +

    In addition, support for ETRS89 and/or RD is required.

    +

    API-GEO-10: Use ETRS89 and/or RD when required, as these are the preferred coordinate reference systems (CRS) for Dutch geospatial data. Follow the Dutch Guideline for the use of CRSs [hr-crs].

    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.

    -

    How to test

    +

    How to test

    • Issue an HTTP GET request to retrieve some spatial data from the API, specifying ETRS89 and/or RD as coordinate reference system.
    • Validate that the response includes a Content-Crs header with the URI for the requested CRS.
      • @@ -1117,58 +1279,58 @@

      How to test

    • Use an ensemble member CRS (instead of an ensemble CRS) for exchanging geometry, when known.
    • Use an ensemble member CRS (instead of an ensemble CRS) as output of coordinate transformation, when known.
    • APIs shall support and advertise both ensemble CRSs and ensemble member CRSs if geometry is exchanged and the CRS for the geometry is an ensemble member CRS.
      • -
    • under certain conditions WGS 84 can be made equal to e.g. ETRS89, this is called a nultransformation, see [hr-crs]. If a nultransformation is used to realize WGS 84, then the CRS (e.g. ETRS89) that is used to realize WGS 84 shall be supported and advertised by an API.
      • -
    -

    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]. If a nultransformation is used to realize WGS 84, then the CRS (e.g. ETRS89) that is used to realize WGS 84 shall be supported and advertised by an API.
    • +
    +

    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:

      @@ -1250,6 +1412,12 @@

      How to test

      + + + + + + @@ -1279,7 +1447,9 @@

      How to test

      -
      Name http://www.opengis.net/def/crs/EPSG/9.9.1/7930
      ETRF2000 - LatLonEHt3DEuropeanhttp://www.opengis.net/def/crs/EPSG/9.9.1/7931
      ITRF2014 - LatLon 2D Global Global http://www.opengis.net/def/crs/EPSG/9.9.1/3857
      Note: CRS support and GeoJSON

    These requirements should be met when an API serves features for an INSPIRE dataset.

    -

    A. Appendix

    A.1 Old CRS negotiation method

    An 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 rules

    This 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 queries

    Note

    A 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.

      // POST /api/v1/panden/_zoek with request body:
+  {
+    "_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:

      // POST /api/v1/panden/_zoek with request body:
+  {
+    "_geo": {
+      "contains": {
+        "type": "Point",
+        "coordinates": [5.9623762, 52.2118093]
+      }
+    },
+    "status": "Actief"
+  }
+

    A.2 Old CRS negotiation method

    Note

    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.

    @@ -1350,7 +1546,7 @@

    How to test

    -
    HTTP header 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.