[postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

Marco Boeringa marco at boeringa.demon.nl
Tue Nov 7 11:16:55 PST 2023


Thanks Paul,

But is there a more definitive solution in PostGIS / PROJ on the horizon 
in terms of future development? No one expects a perfectly valid 
geometry that just happens to hit the projection boundary of WGS1984 to 
come out garbled by doing a transform and back-transform to the original 
CRS. I realize there may be technical challenges here, but this will 
undoubtedly keep coming up many times in the future, and likely has in 
the past, by other confused non-expert users of PostGIS if nothing 
changes. It is really counter-intuitive to need to use stuff like 
ST_SnapToGrid, ST_ReducePrecision or ST_WrapX to "fix" something that 
goes right for 99.999% of all other data. It also makes any needed code 
more convoluted.

Yes, well, I know, storing data in WGS 1984 geometry may not be best 
practice with this kind of globe spanning data, but it works for most 
cases and I already cast to geography a lot to do stuff where geography 
is really needed.

Marco

Op 7-11-2023 om 19:02 schreef Paul Ramsey:
>
>
>> On Nov 6, 2023, at 3:39 PM, Paul Ramsey <pramsey at cleverelephant.ca> 
>> wrote:
>>
>>
>>
>>> On Nov 6, 2023, at 3:33 PM, Marco Boeringa <marco at boeringa.demon.nl> 
>>> wrote:
>>>
>>> Well, yes indeed that is what is happening, 180 came out of the 
>>> reprojection steps as -180. Full output geometry below. Is there any 
>>> way to prevent this behavior?
>>>
>>> Marco
>>>
>>
>> Not really… Either snap to grid or reduce precision
>>
>> https://postgis.net/docs/ST_ReducePrecision.html
>> https://postgis.net/docs/ST_SnapToGrid.html
>>
>> will get you back onto the dividing line (note that it is 
>> at -180.00000000000014), but that won’t help in flipping -180 to 180. 
>> For your particular case, applying
>>
>> https://postgis.net/docs/ST_ShiftLongitude.html
>>
>> will fix it, I think, though not in generality
>
> I think using
>
> https://postgis.net/docs/ST_WrapX.html
>
> would allow a more general purpose solution. At least one you have 
> more control over.
>
> P
>
>>
>> P
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20231107/f16525ef/attachment.htm>


More information about the postgis-users mailing list