Skip to content
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

Wrong coordinates order when mapping Point in SRID 4326 to GeoJSON #107

Open
thefat32 opened this issue Jul 25, 2022 · 2 comments
Open

Wrong coordinates order when mapping Point in SRID 4326 to GeoJSON #107

thefat32 opened this issue Jul 25, 2022 · 2 comments
Labels
STJ Applies to NetTopologySuite.IO.GeoJSON4STJ

Comments

@thefat32
Copy link

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

        services.AddControllers().AddJsonOptions(options => {
               options.JsonSerializerOptions.Converters.Add(new GeoJsonConverterFactory());
           });

I'm using System.Text.Json implemetation

@airbreather airbreather added the STJ Applies to NetTopologySuite.IO.GeoJSON4STJ label Jul 25, 2022
@airbreather
Copy link
Member

Wrong coordinates order

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?

@thefat32
Copy link
Author

Yes of course! Having a mechanism to use my own logic to determine the coordinates order would be great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
STJ Applies to NetTopologySuite.IO.GeoJSON4STJ
Projects
None yet
Development

No branches or pull requests

2 participants