GeoJSON says that all coordinates must be longitude/latitude or X/Y. This means the GeoJSON spec takes precedence over the crs.

see: https://www.rfc-editor.org/rfc/rfc7946.html#appendix-A.1

GeoJSON says that all coordinates must be longitude/latitude or X/Y. This means the GeoJSON spec takes precedence over the crs.

Yep, that"s correct, I wrote that in the original post. That is why I am suggesting when the WKT string specifies coordinates in latitude/longitude order, they should be swapped when writing out to GeoJSON.

I was checking the spec for eWKB, to see if the logic of swapping the Latitude/Longitude order based on SRID is the same as for WKT.

Its not completely clear, but it looks like WKB is like GeoJSON, the first two coordinates are always specified to be X-Y (Longitude-Latitude), so unlike WKT, they never need swapping when writing to GeoJSON.

@ashleysommer Could you provide some context about your use case? This discussion so far is about data and specifications, and I think it would be helpful to understand your use case more concretely.

However, even if we add geometry["meta"]["srid"]=4326 to the GeoJSON output, the geojson spec states that all geometries with a "longitude" and "latitude" component will always be in "longitude, latitude" order, so geomet emits an INVALID GeoJSON chunk:

I see your point, but I wouldn"t agree that"s invalid GeoJSON. There"s a discussion about why we introduced the "meta" extension to the GeoJSON output: #28. The big challenge with converting between different data types is the fact that not all specifications (WKT/WKB/EWKT/EWKB/GeoJSON, etc.) are completely "lossless". GeoJSON doesn"t have any aware of SRIDs. Even the various the WK specs are ambiguous in places. We figured the least we could do is add some hints to the output.

Yep, that"s correct, I wrote that in the original post. That is why I am suggesting when the WKT string specifies coordinates in latitude/longitude order, they should be swapped when writing out to GeoJSON.

This is an interesting idea. I do theoretically like the idea of intelligently reading the SRID and ordering coordinates of converted output accordingly. I think the main challenge there is finding good specs for all the different reference systems and adding special handling for all of them. That would be the thorough way to do it, but it"s a lot of work. I am, however, wary of introducing something which could cause problems.

I was checking the spec for eWKB, to see if the logic of swapping the Latitude/Longitude order based on SRID is the same as for WKT.
Its not completely clear, but it looks like WKB is like GeoJSON, the first two coordinates are always specified to be X-Y (Longitude-Latitude), so unlike WKT, they never need swapping when writing to GeoJSON.

It makes sense that a binary protocol would standard the order of coordinate components.

@ashleysommer Do you have a references to the WGS84 specification where the coordinate ordering is defined? Just so I can deep-dive on this a bit more.

In any case, I would be cautious to implement this change, because from what I can see, all of the WK specs standardize on XY(Z) ordering. GeoJSON is the same. In my view, this is about encoding values in 2d/3d space, which different from how those coordinates are represented or displayed in a given spatial reference system.

@larsbutler
Our use case is for the RDFLib project, we are implementing a GeoSPARQL to GeoJSON converter.
Serialized GeoSPARQL geometries are similar to eWKT, they are a wkt string with a CRS identifier attached.
Similarly, GeoSPARQL operates in the same manner to eWKT with regard to the axis ordering; if no CRS is provided, it assumes CRS84 and it uses lon-lat ordering. If a EPSG code is given, it uses the axis ordering from the EPSG spec (lat-lon).

That means when we convert a GeoSPARQL string with an EPSG crs and lat-lon axis-ordering to a GeoJSON document, we need to add the meta.srid string and reverse the axis ordering to maintain a standard compliant GeoJSON document.

I see your point, but I wouldn"t agree that"s invalid GeoJSON.

I"ve taken a look at a variety of industry-standard open-source GeoJSON parsers (in QGIS, in Postgres, in GDAL, in Shapely, and others) and all parse the coordinates in lon-lat order as-per the GeoJSON spec, regardless of any crs property or meta.srid property.

Subsequently, when taking a GeoJSON document produced by GeoMet with the meta.srid field populated and coordinates in lat-lon order, the document fails to load, or loads bogus geometry, in all applications I tested.

Therefore, GeoJSON documents with lat-lon ordering are invalid for all intents and purposes.

Do you have a references to the WGS84 specification where the coordinate ordering is defined? Just so I can deep-dive on this a bit more.

The official WGS84 spec is here: https://www.unoosa.org/pdf/icg/2012/template/WGS_84.pdf
But it is a bit hard to parse, and it doesn"t actually specify the order which the axes are serialized, because that is the reference spec, not a concrete implementation.

The best way I"ve found to lookup concrete specs with axis-order is on the espg.io website, eg https://epsg.io/4326
scroll down to "export" and choose "OGC WKT 2", this will give you everything you need to know how to implement that CRS in WKT, notably it includes axis ordering.

I do theoretically like the idea of intelligently reading the SRID and ordering coordinates of converted output accordingly. I think the main challenge there is finding good specs for all the different reference systems and adding special handling for all of them.

Thats what I thought too, until I dug a bit deeper and found that the EPSG organisation has a standard of following Y-X ordering on all of their CRS definitions, so that means on latitude/longitude axis CRS"s the order is always latitude-longitude.

I have a fork of geomet with a quick-and-dirty attempt at implementing conditionally reversing axis order for all geometries based on the CRS. In my code the logic is to flip the coordinates if the incoming geometry is in any EPSG-defined CRS, and don"t flip it if CRS is OGC:CRS84 or CRS is not given. I don"t know if there are any other CRS defined in the OGC namespace (but if there are, I bet they are all lon-lat order), and I don"t know if there are any other agencies that publish CRSs that a user would be referencing.

In any case, I would be cautious to implement this change, because from what I can see, all of the WK specs standardize on XY(Z) ordering. GeoJSON is the same. In my view, this is about encoding values in 2d/3d space, which different from how those coordinates are represented or displayed in a given spatial reference system.

I agree, WKT, WKB, eWKB, and GeoJSON all follow the same axis ordering, that makes it easy to simply declare that is the standard. However we cannot ignore eWKT and GeoSPARQL that are the two outliers. Both of these include in their respective spec documents the instruction to reverse the axis order when declaring a EPSG code that uses lat-lon ordering (all of them), and it is specifically the case of converting those formats into valid GeoJSON that we"re trying to achieve.