CRS in GeoJSON

[afeliachi]

The property "crs" is not supported anymore in GeoJSON as it has been removed from the specs (see appendix-B.1).
As it is specified in section 4 the expected coordinate reference system is CRS84 (WGS 84 with the axis order long-lat). This should be taken into account when converting from GML. We find this very limiting. Although it says that

where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.

it is not helpful at all. This triggers a big issue because there no prior arrangement with data consumers since there's no normative way to specify the crs, and the existing GeoJSON library doesn't understand other CRS than CRS84. I am not sure that a coordinates conversion to CRS84 in appschema is a viable solution or is even possible. What do you think we should do in this case?

[KathiSchleidt]

on the one hand not that worried, as in our example we currently have: "crs": null For reality, I'm starting to wonder if the following wouldn't be a sane way forward:

• Leave the GeoJSON coords in WGS84 regardless, but don't see these as exact coordinates, just a ballpark for dots-on-the-map (kinda like the old bounding box or envelope stuff)
• Then provide the real precision coordinates with CRS using GeoSparql

While the downside is the redundancy and possible conflict/contradiction, the upside is the best of both worlds, quick dots on maps with generic browsers, while providing the full info for where its required

Thoughts?

[afeliachi]

on the one hand not that worried, as in our example we currently have: "crs": null

• Leave the GeoJSON coords in WGS84 regardless, but don't see these as exact coordinates, just a ballpark for dots-on-the-map (kinda like the old bounding box or envelope stuff)

Indeed in our case the "crs" is null, but actually the coordinates (as specified in the gml) are expressed in WGS84. The coordinates order in this case must be inverted in the GeoJSON in ordrer to be correct (ballpark) geometry.

• Then provide the real precision coordinates with CRS using GeoSparql

While the downside is the redundancy and possible conflict/contradiction, the upside is the best of both worlds, quick dots on maps with generic browsers, while providing the full info for where its required

I see what you want say here. This joins the discussion we had in ELFIE about preview Geometrie VS Detailed Geometries. I truly believe that having a GeoSparql geometries is the perfect solution when working with other JSON-LD based representation. But I think that anyone specifically requesting (and familiar with) GeoJSON would not expect or understand anything other than a GeoJSON encoded geometry. From a consumer point of view, is a hybrid representation an acceptable thing, especially for geometries? Or maybe a larger question is when a JSON file stops from being a GeoJSON and starts being something else?

[KathiSchleidt]

In an ideal world, sure, we'd want something different, but we're not in an ideal world, neither us on the provision end, nor the consumers. Ideal consumers would know what they want, and understand what they're getting. Using this Solomonic split, I believe that

• the smart users will probably notice the GeoSparql at some point and start thinking, maybe even using
• the other users will not care either way, be happy with a dot somewhere on the map and get on with it.

We won't be able to force the stupid ones to do the right thing (one never can ;) ), but we can enable the smart ones to do it if they like to (and maybe over time inspire some of the others to do it right also)

Is such a compromise possible? anything else in LD that would break Geo?

[afeliachi]

Totally agree with you. This is why I never manged to like GeoJSON. Sure it narrows things for developers since it's straightforward and much less complicated that the heavy machinery of the XML world, but by being a (almost) schema-less semantic-less model, it is making the data really dumb. This is why I thinks pushing GeoSparql into GeoJSON won't help that much. This is actually why we advocated for a JSON-LD representation in the first place (I believe). It would be a more suitable solution for "smarter" users ;), whether the geometries are encoded as geosparql wkt, schema.org geometries or others.

[sgrellet]

We had a short email discussion about GeoJSON-LD with OGC ELFIE members last week. Can one of you summarize here the main conclusions about why GeoJSON-LD was also a no go ?

[afeliachi]

The conclusion was that a valid GeoJSON having a geometry other than a point cannot be a valid JSON-LD. The GeoJSON-LD context provides sums up the specs of GeoJSON except for the geometry representation since it doesn't solve the nested array problem. Any hybrid writing would whether make it an invalid GeoJSON or an invalid JSON-LD.

[KathiSchleidt]

Since WFS3 is pushing us towards GeoJSON, couldn't we find some sort of agreement that the GeoJSON geometry is just a representative point (ballpark dot on a map), while the true geo comes under the GeoSparql bit?

[sgrellet]

I'd go for CRS84 with the geometry as-is (no ballpark one) otherwise it won't make sense when setting up WFS3 for polylines or (multi)Polygon represented features. For example, what point to take to represent the Loire river geom ? I know it would force on the data provider side to have in PostGIS another geometry column forced at CRS84. But this would validate the 'GeoJSON contract'. And we'll provide more 'acceptable' in the JSON-LD using GeoSparql

[KathiSchleidt]

But, if you insist on adding polylines/gons, then to my understanding, you can kiss JSON-LD goodbye :( Thus my approach was keeping the GeoJSON Geometry limited to a representative point (& not breaking JSON-LD), while providing the true polyXXX in the GeoSparql Fear you'll have to set a priority:

• Full Geo in the GeoJSON
• JSON-LD

what's it to be?

[afeliachi]

In my understanding we are going for both distinct representations. Isn't it?

[KathiSchleidt]

But in my understanding, if we go for PolyStuff in GeoJSON, we break JSON-LD (feel like we're going around in circles here, what am I missing?)

[afeliachi]

In my understanding both distinct representation GeoJSON and JSON-LD could be asked through content negotiation. If someone is asking fo "application/json" they would get the GoeJSON, if they're asking for "application/json+ld" they would get the JSON-LD representation.

[KathiSchleidt]

that would be ideal, have GeoSolutions agreed?

[afeliachi]

Ok I see we misunderstood each ether :)
This was our final conclusion (@sgrellet can confirm). We agreed that GeoJSON-LD wouldn't work and thus we must separate both representations. I am currently working on the expected JSON-LD output file. Should commit it this afternoon.

[sgrellet]

I confirm

[afeliachi]

If I may go back to the main issue here about the crs being fixed for GeoJSON as CRS84. After discussion with @sgrellet we think that the solution would be to provide in the source data an additional geometry column with CRS84 coordinates, to avoid any on-the-fly coordinates transformation. GeoJSON should take into account this geometry only. Thoughts?

[aaime]

Hi, sharing my 2 cents on the matter.

The WFS3 specification will likely contain a way to handle CRS in GeoJSON in the CRS extension. The upside, it means that it's not our duty to solve this, the downside, there is no control on the timing. The current very early draft of the CRS extension mentions the GeoJSON previous agreement though, see https://github.com/opengeospatial/WFS_FES/tree/master/extensions/crs and in particular https://github.com/opengeospatial/WFS_FES/blob/master/extensions/crs/requirements/REQ_geojson.adoc

About the reprojection, sorry, the main geometry must be in CRS84, as per specification, unless the CRS extension is used, a secondary attribute might be in the native CRS instead.

[sgrellet]

Thanks Andrea So conclusion is:

• provide in the source data an additional geometry column with CRS84 coordinates, to avoid any on-the-fly coordinates transformation
• other projection system will be used either in the JSON-LD and (at a later time using the CRS extension approach)

[sgrellet]

sample GeoJSON file 'target_borehole_wfs3_output.json' edited accordingly (crs:null removed and point coordinates in the relevant order)