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

Marco Boeringa marco at boeringa.demon.nl
Wed Nov 8 04:30:46 PST 2023 

Paul,

Do you want me to log an issue for this in the PostGIS OSGeo issue 
tracker, including the reproducible case I already posted in the mails?

Marco

Op 7-11-2023 om 20:58 schreef Paul Ramsey:
> If you nudged it first, the -180s might end up back where they below.
>
> P
>
>> On Nov 7, 2023, at 11:57 AM, Brent Wood <Brent.Wood at niwa.co.nz> wrote:
>>
>> Hi guys,
>>
>> What happens if the dataset is converted to 0-360 with 
>> ST_ShiftLongitude() then back again to +-180?
>>
>> I'd expect that to come up with the +-180 standardised on one or the 
>> other, rather than having a dataset with both.
>>
>> It is a shame that more recent versions of proj don't support 0-360 
>> longitudes, as that would fix the issue in the Ross Sea (but only by 
>> moving it 180deg...)
>>
>>
>> Brent Wood
>>
>> Principal Technician, Fisheries
>> NIWA
>> DDI:  +64 (4) 3860529
>> ------------------------------------------------------------------------
>> *From:*postgis-users <postgis-users-bounces at lists.osgeo.org> on 
>> behalf of Paul Ramsey via postgis-users <postgis-users at lists.osgeo.org>
>> *Sent:*Wednesday, November 8, 2023 08:39
>> *To:*Marco Boeringa <marco at boeringa.demon.nl>
>> *Cc:*Paul Ramsey <pramsey at cleverelephant.ca>; PostGIS Users 
>> Discussion <postgis-users at lists.osgeo.org>
>> *Subject:*Re: [postgis-users] Failing ST_Transform with Ross Ice 
>> Shelf polygon
>> Hm, the current logic of the nudge would probably still not help your 
>> case, since your problem is both the coordinate being slightly out of 
>> bounds and also the change in sign. The nudge would move 
>> -180.0000000004 to -180, but it wouldn’t flip the sign.
>>
>>> On Nov 7, 2023, at 11:36 AM, Marco Boeringa 
>>> <marco at boeringa.demon.nl> wrote:
>>>
>>> Sounds interesting. I think many users of PostGIS would be really 
>>> glad to see something like this implemented if it could reasonably 
>>> be done. Haven't tried the double cast via geography yet, but seems 
>>> fun thing to check and see the result.
>>> Op 7-11-2023 om 20:31 schreef Paul Ramsey:
>>>> All that said…
>>>>
>>>> It would be possible to “fix” this, but it’s a scary black box.
>>>> We already nudge geodetics back into place when casting from 
>>>> geometry to geography (interesting workaround, take your 
>>>> reprojected result and do a ::geography::geometry on it)
>>>>
>>>> https://github.com/postgis/postgis/blob/42f04a29effdd9e8280c7aba17420ba306fc73f4/liblwgeom/lwgeodetic.c#L3351 
>>>> <https://github.com/postgis/postgis/blob/42f04a29effdd9e8280c7aba17420ba306fc73f4/liblwgeom/lwgeodetic.c#L3351>
>>>>
>>>> For systems that we know are geodetics (and with modern proj we 
>>>> generally know that) we could apply the nudge to the outputs. It 
>>>> would make things slower (more logic) but it would only change 
>>>> those cases where the coordinates are in fact out of bounds by a 
>>>> very small amount.
>>>>
>>>> P.
>>>>
>>>>> On Nov 7, 2023, at 11:22 AM, Paul 
>>>>> Ramsey<pramsey at cleverelephant.ca> 
>>>>> <mailto:pramsey at cleverelephant.ca>wrote:
>>>>>
>>>>> Nope.
>>>>>
>>>>> It can be quite reasonably argued that the answer is correct, and 
>>>>> the problem is treating EPSG:4326 (a geodetic coordinate system 
>>>>> with angular units) as if it was a planar system with cartesian 
>>>>> units (spoiler: it is not that). In angular units, -180.0000000004 
>>>>> is ridiculously close to 180.0. You aren’t complaining about the 
>>>>> other coordinates, like where 175.123456789 is coming through as 
>>>>> 175.123456788. Why not? It’s the same error! :)
>>>>>
>>>>> I don’t know what it is about the math going through that fun CRS 
>>>>> that is causing roundoff or even if it’s particularly large (I 
>>>>> don’t think it is), but it is not at all unique to that system. 
>>>>> You can generate data that is progressively offset from the 
>>>>> original data doing nothing more exotic than going back and forth 
>>>>> from WGS83 to UTM over and over and over.
>>>>>
>>>>> ATB,
>>>>>
>>>>> P
>>>>>
>>>>>> On Nov 7, 2023, at 11:16 AM, Marco 
>>>>>> Boeringa<marco at boeringa.demon.nl> 
>>>>>> <mailto:marco at boeringa.demon.nl>wrote:
>>>>>>
>>>>>> 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> 
>>>>>>>> <mailto:pramsey at cleverelephant.ca>wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Nov 6, 2023, at 3:33 PM, Marco 
>>>>>>>>> Boeringa<marco at boeringa.demon.nl> 
>>>>>>>>> <mailto: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_ReducePrecision.html>
>>>>>>>> https://postgis.net/docs/ST_SnapToGrid.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 
>>>>>>>> <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 
>>>>>>> <https://postgis.net/docs/ST_WrapX.html>
>>>>>>>
>>>>>>> would allow a more general purpose solution. At least one you 
>>>>>>> have more control over.
>>>>>>>
>>>>>>> P
>>>>>>>
>>>>>>>>
>>>>>>>> P
>>>>>>>
>>>>>
>>>>
>>
>> <https://www.niwa.co.nz/> 	Brent Wood
>> Principal Technician - GIS and Spatial Data Management
>> Programme Leader - Environmental Information Delivery
>> +64-4-386-0529
>>
>> National Institute of Water & Atmospheric Research Ltd (NIWA)
>> 301 Evans Bay Parade Hataitai Wellington New Zealand
>> *Connect with NIWA:*niwa.co.nz <https://www.niwa.co.nz/>Facebook 
>> <https://www.facebook.com/nzniwa>LinkedIn 
>> <https://www.linkedin.com/company/niwa>Twitter 
>> <https://twitter.com/niwa_nz>Instagram 
>> <https://www.instagram.com/niwa_science>YouTube 
>> <https://www.youtube.com/channel/UCJ-j3MLMg1H59Ak2UaNLL3A>
>>
>> To ensure compliance with legal requirements and to maintain cyber 
>> security standards, NIWA's IT systems are subject to ongoing 
>> monitoring, activity logging and auditing. This monitoring and 
>> auditing service may be provided by third parties. Such third parties 
>> can access information transmitted to, processed by and stored on 
>> NIWA's IT systems.
>> Note: This email is intended solely for the use of the addressee and 
>> may contain information that is confidential or subject to legal 
>> professional privilege. If you receive this email in error please 
>> immediately notify the sender and delete the email.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20231108/1f78d7e3/attachment.htm>

More information about the postgis-users mailing list