GeoJSON's CRS does not meet INSPIRE requirements

[michellutz]

GeoJSON (RFC 7946) only supports one projection (effectively urn:ogc:def:crs:OGC::CRS84), while INSPIRE requires projections based on ETRS89?

The best summary is probably http://docs.opengeospatial.org/guides/16-122r1.html section (5.3. OGC needs that GeoJSON does not cover). So for INSPIRE GeoJSON we will need to Extend GeoJSON for geometry but not using the geometry type, as per example "Example of GeoJSON file describing a protected area also in EPSG:25831 (coordinates are dummy)."

{ "type": "FeatureCollection", 
  "features": [{ 
      "type": "Feature", 
      "geometry": { 
         "type": "MultiPolygon", 
         "coordinates": [ [[[102.0, 2.0], [103.0, 2.0], [103.0, 3.0], [102.0, 3.0], [102.0, 2.0]]], [[[100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]], [[100.2, 0.2], [100.8, 0.2], [100.8, 0.8], [100.2, 0.8], [100.2, 0.2]]] ] }, 
       "id": "http://www.ecopotential.org/sierranevada", 
       "bbox": [100.0, 0.0, 103.0, 3.0], 
       "bboxCRS": { 
         "bbox": [500100.0, 4600000.0, 500103.0, 4600003.0], 
         "crs": "http://www.opengis.net/def/crs/EPSG/0/25831", } 
       "properties": { 
           "geometryCRS": { 
             "type": "MultiPolygon", 
             "crs": "http://www.opengis.net/def/crs/EPSG/0/25831", 
             "coordinates": [ [[[500102.0, 4600002.0], [500103.0, 4600002.0], [500103.0, 4600003.0], [500102.0, 4600003.0], [500102.0, 4600002.0]]], [[[500100.0, 4600000.0], [500101.0, 4600000.0], [500101.0, 4600001.0], [500100.0, 4600001.0], [500000.0, 4600000.0]], [[500100.2, 4600000.2], [500100.8, 4600000.2], [500100.8, 4600000.8], [500100.2, 4600000.8], [500100.2, 4600000.2]]] ] },
           "name": "Sierra Nevada", 
           "ecosystemType": "Mountain",
           "ecosystemService": ["turism", "biodiversity reserve"], 
           "elevationRange": [860, 3482], 
           "figureOfProtection": "National park" } } }

[cportele]

We have discussed this in the WFS 3.0 work and take a simpler approach than in the OGC T12 ER.

The Core will be restricted to http://www.opengis.net/def/crs/OGC/1.3/CRS84, but additional CRS can be supported using an extension to explicitly request data in another CRS (using a query parameter crs). In the case of GeoJSON the "prior arrangement" clause of the GeoJSON RFC is used. This works fine in a number of clients.

I see no benefit or value in putting geometry in GeoJSON anywhere else than in geometry.

WFS 3.0 Links:

• Original issue from March 2018
• WFS 3.0 Part 2: Support for coordinate reference systems - DRAFT, Asciidoc files

Here is an example of a response to a request with crs=http://www.opengis.net/def/crs/EPSG/0/25832:

{
  "type" : "Feature",
  "links" : [ ... ],
  "crs" : "http://www.opengis.net/def/crs/EPSG/0/25832",
  "id" : "DENW19AL0000geMFFL",
  "geometry" : {
    "type" : "MultiPolygon",
    "coordinates" : [ [ [ [ 479999.035, 5704476.907 ], [ 480026.067, 5704474.951 ], [ 480032.21, 5704539.222 ], [ 480006.464, 5704541.635 ], [ 480005.023, 5704534.615 ], [ 480002.632, 5704511.571 ], [ 480002.124, 5704506.676 ], [ 479999.035, 5704476.907 ] ] ] ]
  },
  "properties" : {
    "aktualit" : "2017-04-26",
    "flaeche" : 1739.0,
    "flstkennz" : "05297001600193______",
    ...
  }
}

The additional crs member in the feature was part of the first version of GeoJSON, but removed in the RFC. It is a valid extension though and documents the prior arrangement.

That said, for many applications http://www.opengis.net/def/crs/OGC/1.3/CRS84 will be sufficient. Many servers supporting multiple CRSs convert between WGS84 and ETRS89 one-to-one anyhow. For those use cases that need a higher accuracy and want to use GeoJSON the prior arrangement clause and more precise conversions can be used.

[PalmJanssen]

We are aware of this problem and the discussion. In applications though the only one crs (WGS) option is not workable and quick solutions are needed, developed and implemented.

From a Dutch application I know that they add a Content-Crs header to specify the CRS. Equally an Accept-Crs header is created to specify an accepted Crs for data acceptance.

[nmtoken]

The first issue is not whether http://www.opengis.net/def/crs/OGC/1.3/CRS84 is sufficient or not for most applications, its the fact that http://www.opengis.net/def/crs/OGC/1.3/CRS84 is not an INSPIRE compliant CRS, so to be compliant with the law (as it currently stands) there must be a way of having some ETRS89 geometry.

[nmtoken]

From a WFS point of view we can have some CRS request parameter doesn't really matter whether it's HTTP or some other protocol header information or some URL request param, or indeed from some param in a (hypermedia) document, that gets an extended GeoJSON file, with the appropriate geometry... the issue is then how the downloaded GeoJSON is recognized by other applications outside of the web environment as having a different geometry

[nmtoken]

The additional crs member in the feature was part of the first version of GeoJSON, but removed in the RFC. It is a valid extension though and documents the prior arrangement.

My understanding from the http://docs.opengeospatial.org/guides/16-122r1.html document is that it is not valid, (section 5.3)

The geometries cannot be extended to other types.

and

GeoJSON cannot be used in the following use cases:

...

When there is a need to communicate features that need to be represented in other CRS that CRS84, such as the combination of UTM/ETRS89.

and section 5.3.2

Sometimes it could be necessary to distribute your data in other CRSs that are not CRS84. As long as you are not doing this in the "geometry" part of the GeoJSON, you are allowed to do this. You can even reuse the geometry object in the properties section, knowing that they will be not considered by pure GeoJSON parsers.

[cportele]

That OGC document describes one way - and is incorrect in some statements.

The GeoJSON specification is clear that "alternative coordinate reference systems can be used without risk of data being misinterpreted, where all involved parties have a prior arrangement". See section 4.

This is not about extending the geometries to other types as long as only the existing types like Point, LineString, Polygon are used.

And the extension section 6 is clear that additional members like a crs member are valid extensions.

[nmtoken]

OK, but really for INSPIRE, and OGC we should formally define an extension, which should include changing the mime type (perhaps by adding a subtype).

[nmtoken]

I've been thinking about this from a service orientated view point, but is it correct that the ETRS89 restriction for European coverage only applies to Network services?

For example the following issue suggests that dataset metadata doesn't need to specify ETRS89

ref: https://github.com/inspire-eu-validation/ets-repository/issues/135

So a direct link to GeoJSON from a dataset metadata record would be allowable...