-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GeoJSON's CRS does not meet INSPIRE requirements #9
Comments
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 I see no benefit or value in putting geometry in GeoJSON anywhere else than in WFS 3.0 Links:
Here is an example of a response to a request with
The additional 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. |
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. |
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. |
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 |
My understanding from the http://docs.opengeospatial.org/guides/16-122r1.html document is that it is not valid, (section 5.3)
and
and section 5.3.2
|
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 |
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). |
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: inspire-eu-validation/ets-repository#135 So a direct link to GeoJSON from a dataset metadata record would be allowable... |
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)."
The text was updated successfully, but these errors were encountered: