What now of the ETRS:89 requirement for data services?

[nmtoken]

Review Feedback

Now that GeoJSON has been published as an Alternative Encoding that Shall satisfy all IR requirements for a data set, should the advice now change for any encoding with respect the requirement to use ETRS89?

Effectively that if the same caveat applies there is no requirement to use ETRS89?

Encoding rule

ref: https://github.com/INSPIRE-MIF/2017.2/blob/master/GeoJSON/geojson-encoding-rule.md

NOTE As INSPIRE mandates the use of the European Terrestrial Reference System 1989 (ETRS89, see Requirement 1) for the areas within the geographical scope of ETRS89 and both CRS84 and ETRS89 use the GRS 80 ellipsoid (although with minor enhancements), we shall assume CRS84 to be equivalent to ETRS89. If, for any dataset, this assumption would be problematic, then GeoJSON cannot serve as an alternative encoding rule for that dataset.

Issues encountered

If, for any dataset, this assumption would be problematic, then GeoJSON cannot serve as an alternative encoding rule for that dataset.

How will it be possible to validate whether the CRS used in the GeoJSON encoding (or indeed other encoding that doesn't use ETRS89 ) is valid for the data set?

Future plans

Other comments

Alternative Coordinate Reference System support

While the required Coordinate Reference System for any data encoded in GeoJSON is CRS84, a client may request delivery of a data set using a different projected reference system, as per the mechanism described in Requirement 8 in the WFS 3.0 draft specification.

An INSPIRE Download service delivering data encoded in GeoJSON shall be able to deliver projected geometries if a client requests these explicitly, at least for the spatial reference systems documented in section 6.3. of the data specifications that fall within the scope of this encodign specification. When delivering data that is not in CRS 84, the GeoJSON data should include the crs member as defined in the deprecated (Draft 6 of the GeoJSON specification)

Note encodign above is a typo in the document

To me it is odd to create some new guidance that relies on on a deprecated methodology (which applies as well to the WFS 3.0 spec as well) far better to use a new encoding like perhaps CoverageJSON. That aside though, I'm not sure what this section implies.

Is the intention to cover the base that you could specify an ETRS89 crs with the deprecated crs member (an example of this might be nice), or something else?

[michellutz]

From the provider point of view: If you want (for whatever reason) to share your data in some other CRS than CRS84, you shall include the crs member as specified in the deprecated (Draft 6 of the GeoJSON specification). While deprecated, this is still widely supported in client software (e.g. QGIS).

From the user point of view: if you receive GeoJSON with a crs member, you shall interpret the coordinates in that CRS. If the GeoJSON does not have a crs member, then you shall assume CRS84.

We agree that an example for this would be useful.

[michellutz]

P.S. we noted that the latest OGC-API Features no longer seems to include a requirement as referred to from the GeoJSON encoding rule:

While the required Coordinate Reference System for any data encoded in GeoJSON is CRS84, a client may request delivery of a data set using a different projected reference system, as per the mechanism described in Requirement 8 in the WFS 3.0 draft specification.

So this reference should be updated or reworded.

[nmtoken]

That's for GeoJSON, but what about other formats, say GML, CovJSON, GeoTIFF, coming from other services not just WFS.

If CRS:84 can be considered as an alternate CRS for ETRS:89 (assuming accuracy isn't affected), then doesn't this apply to any INSPIRE service and any format?

[nmtoken]

However the OGC API - Features - Part 1: Core does have:

OGC API Features provides API building blocks to create, modify and query features on the Web. OGC API Features is comprised of multiple parts, each of them is a separate standard. This part, the "Core", specifies the core capabilities and is restricted to fetching features where geometries are represented in the coordinate reference system WGS 84 with axis order longitude/latitude.

Or CRS:84 as we know it

[thorsten-reitz]

I changed the wording of the refernece to WFS 3.0. Do I understand you right that we should add an example for request and response for a different CRS than the default to the section as well?

[nmtoken]

@thorsten-reitz not sure if that comment is to me or to Michel. The reason I raised this question/issue, was for clarification of status now for encodings other than GeoJSON and their use of CRS:84 as an alternate CRS, rather than the current requirement for a CRS using ETRS:89. It's an Alternative Encoding question not a question about how to use other CRS in GeoJSON.

So, I'm not sure what to advise on what to add to the document examples.

Core OGC API - Features (was WFS 3.0) only has support for CRS:84 as a CRS but has no default encoding, so a WFS 3.0 service could serve up a GML response in CRS:84; one assumes that this would still be INSPIRE compliant.

[nmtoken]

Should I ask the original question again? my issue, seems to have been conflated with an other issue which you have closed

[thorsten-reitz]

@nmtoken we can reopen this one, it closed automatically on merging the PR.

[thorsten-reitz]

@nmtoken However, I am not yet sure how to proceed on the issue in the scope of the GeoJSON encoding :).

[nmtoken]

@thorsten-reitz the scope of 2017.2 isn't just GeoJSON,