You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On the GeoJSON side of things, per RFC 7946 3.1.1 (emphasis mine):
A position is an array of numbers. There MUST be two or more
elements. The first two elements are longitude and latitude, or
easting and northing, precisely in that order and using decimal
numbers. Altitude or elevation MAY be included as an optional third
element.
On the "how your geometries are defined" side of things, depending on how NetTopologySuite/NetTopologySuite#314 works out (warning: that's been around for a while, don't hold your breath), that might give us room to do something different, but as things stand right now, the geometries themselves don't currently carry enough information for us to be able to confidently say that we need to say whether or not to change the order of the coordinates in order to comply with the spec.
It's not even as simple as "if SRID is 4326, then reverse; else, don't", because in my experience, the incorrect behavior discussed in https://gis.stackexchange.com/a/293900/37546 seems to be present more often than not, at least in the systems and data sets that I've worked with over the past decade or so.
I suppose we could consider adding an extension point where you could plug in your own logic to transform the Geometry that we would serialize with a different one, and vice-versa. Would that solve this issue for you?
When mapping a NTS Point with SRID 4326 to GeoJSON the coordinates remains in same order, but SRID 4326 is Lat/Long and GeoJSON is Long/Lat
Is there any config to the serializer to properly transform between GeoJSON and SRID 4326 ?
My Startup code is
I'm using System.Text.Json implemetation
The text was updated successfully, but these errors were encountered: