ST_AsGeoJSON in POSTGIS-2.5 different than ST_AsGeoJSON in POSTGIS-3.0

[maheshpusala]

facing issue as getting different JSON ouput when i am running ST_AsGeoJSON in POSTGIS-2.5 and ST_AsGeoJSON in POSTGIS-3.0, due to this in 2.5 when i am validating on returned geojson it is giving valid boundary, in 3.0 when i am validating on returned geojson it is giving self intersection error

please check and let me know anything i want update from my side, please find server , postgis version details

POSTGRES 12.5 POSTGIS 3.0

POSTGRES 11.6 POSTGIS 3.0

[maheshpusala]

Replying to maheshpusala:

facing issue as getting different JSON ouput when i am running ST_AsGeoJSON in POSTGIS-2.5 and ST_AsGeoJSON in POSTGIS-3.0, due to this in 2.5 when i am validating on returned geojson it is giving valid boundary, in 3.0 when i am validating on returned geojson it is giving self intersection error

please check and let me know anything i want update from my side, please find server , postgis version details

POSTGRES 12.5 POSTGIS 3.0

POSTGRES 11.6 POSTGIS 2.5

[robe]

Can you please provide some examples?

[maheshpusala]

attached required examples to debug further 1) oroginal WKT 2) postgis 2.5 converted geojson 3) postgis 3.0 converted geojson

[mdavis]

This is due to the output coordinates being rounded off slightly in 3.0.

For example, in 2.9 there is a coordinate

-93.1687103416383 41.8543515079768

In 3.0 this is output as:

 -93.168710342 41.854351508

This rounding is enough to cause the two polygons containing this point to become adjacent and hence invalid.

Is there a different default precision set in 3.0 GeoJSON output?

[mdavis]

Actually it might be that with the improvements to floating-point output in 3.0 the ST_AsGeoJSON default for precision (9 decimal digits) is now working (whereas before it was just outputting full precision).

This is effectively a regression. Also, it shows how having an output precision less than "full" can cause unexpected loss of data. Most other text output functions use precision=15 as their default. We should consider changing ST_AsGeoJSON to use this valud as well.

[Algunenano]

Actually it might be that with the improvements to floating-point output in 3.0

One correction, the improvements to floating point output were introduced in 3.1. The problem here comes from the change from a default 15 decimal digits to 9 which predates that change.

In any case, ST_AsGeoJSON has an option to set the number of decimal digits to however many you need and 15 decimal digits does not guarantee full precision output either. The good thing about 3.1 is that you can see a ask for a huge number of decimal digits and you'll only get significant ones (way less).

[mdavis]

Replying to Algunenano:

Thanks for the clarification.

In any case, ST_AsGeoJSON has an option to set the number of decimal digits to however many you need

True, but that requires a code change by the user.

15 decimal digits does not guarantee full precision output either.

No, but it should make topology collapse errors much less likely.

[pramsey]

Milestone renamed

[robe]

In prep for 3.1.3 release

[pramsey]

As noted, if you want more precision, you can have it. We deliberately reduced output precision of GeoJSON because the pointless extra volume of precision has knock-on in things like data extracts and feeding web clients. It's a choose-your-poison situation and poison we have chosen is the occasional dimensional collapse.