wfs3-experiments

CRS support in OGC API Features

The core of the API specification only supports WGS84. Work has been done already on an extension to support different CRSses. In this document we collect results on experiments with different CRSses.

CRS Extension OGC API Features

For NL we need RijksDriehoekstelsel as CRS, because some data is mandated by law to provide geometry in that CRS. Othwerise OGC API Features may not be a good option to access some (formal) data.

Sample implementations

Sample requests including CRS, BBOX and BBOX-CRS

All items

Request to get all items:

https://www.ldproxy.nrw.de/topographie/collections/ax_bahnverkehr/items?f=json

Output in other CRS

The same, but CRS: EPSG:28992 as output in GeoJSON (NOTE: in the HTTP request the parameter value for http://www.opengis.net/def/crs/EPSG/0/28992 needs to be URI encoded, so becomes: http%3A%2F%2Fwww.opengis.net%2Fdef%2Fcrs%2FEPSG%2F0%2F28992):

https://www.ldproxy.nrw.de/topographie/collections/ax_bahnverkehr/items?f=json&crs=http://www.opengis.net/def/crs/EPSG/0/28992

The output contains the CRS information encoded in GeoJSON (TODO: is the crs notation valid?):

...
"timeStamp": "2019-06-05T11:12:35Z",
"crs": "http://www.opengis.net/def/crs/EPSG/0/28992",
"features": [
...

Request in a bbox CRS other than WGS84

To retrieve data in another bbox CRS than WGS84, the following 2 parameters must be added to a request:

Example request, returns 2 items in the bbox (collection consists of 97 items): https://www.ldproxy.nrw.de/topographie/collections/ax_bahnverkehr/items?f=json&crs=http://www.opengis.net/def/crs/EPSG/0/28992&bbox=237692,269652,237802,269900&bbox-crs=http://www.opengis.net/def/crs/EPSG/0/28992

Samples for BGT

TODO

Possible issues and discussion points

How to deal with alternate links in the /collections/{collectionId}/ if multiple CRSes (and multiple encodings) are supported? Should every combination of CRS and encoding have a separate alternate link? Should there be no alternate links for CRSes? For transparency and discoverability of an API one could argue that there should be an alternate link for all combinations, but this may lead to too much combinations (possibly deterring developers)

Alternatives for CRS parameters in request and response: use HTTP headers

The Dutch API strategy describes a different apporach to request data in a specific CRS. Dutch API Strategy on CRS negotiation (in Dutch)

Disadvantage: clients need to be aware of Accept-Crs header

TODO : create a client that can handle the Accept-Crs header

Notation of CRS in GeoJSON

The old specification, describes a mechanism to include crs information in GeoJSON encoded data. See https://geojson.org/geojson-spec.html#named-crs.