<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">If you nudged it first, the -180s might end up back where they below.<div><br></div><div>P<br><div><br><blockquote type="cite"><div>On Nov 7, 2023, at 11:57 AM, Brent Wood <Brent.Wood@niwa.co.nz> wrote:</div><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;">Hi guys,</div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;"><br></div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;">What happens if the dataset is converted to 0-360 with ST_ShiftLongitude() then back again to +-180?</div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;"><br></div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;">I'd expect that to come up with the +-180 standardised on one or the other, rather than having a dataset with both.<br></div><div class="elementToProof" style="caret-color: rgb(0, 0, 0); font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;"><br></div><div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;">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...)<br></div><div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;"><br></div><div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt;"><br></div><div id="Signature"><div><div></div><div></div><div name="divtagdefaultwrapper" style="font-family: Calibri, Arial, Helvetica, sans-serif; margin: 0px;"><div class="BodyFragment"><div class="PlainText">Brent Wood<br><br>Principal Technician, Fisheries<br>NIWA<br>DDI: +64 (4) 3860529</div></div></div></div></div></div><div id="appendonsend" style="caret-color: rgb(0, 0, 0); font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"></div><hr tabindex="-1" style="caret-color: rgb(0, 0, 0); font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline-block; width: 830.046875px;"><span style="caret-color: rgb(0, 0, 0); font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;"></span><div id="divRplyFwdMsg" dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><font face="Calibri, sans-serif" style="font-size: 11pt;"><b>From:</b><span class="Apple-converted-space"> </span>postgis-users <postgis-users-bounces@lists.osgeo.org> on behalf of Paul Ramsey via postgis-users <postgis-users@lists.osgeo.org><br><b>Sent:</b><span class="Apple-converted-space"> </span>Wednesday, November 8, 2023 08:39<br><b>To:</b><span class="Apple-converted-space"> </span>Marco Boeringa <marco@boeringa.demon.nl><br><b>Cc:</b><span class="Apple-converted-space"> </span>Paul Ramsey <pramsey@cleverelephant.ca>; PostGIS Users Discussion <postgis-users@lists.osgeo.org><br><b>Subject:</b><span class="Apple-converted-space"> </span>Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon</font><div> </div></div><div style="caret-color: rgb(0, 0, 0); font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; line-break: after-white-space;">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.<br><div><br><blockquote type="cite"><div>On Nov 7, 2023, at 11:36 AM, Marco Boeringa <marco@boeringa.demon.nl> wrote:</div><br class="x_Apple-interchange-newline"><div><div><div style="margin-top: 0px; margin-bottom: 0px;">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.<br></div><div class="x_moz-cite-prefix">Op 7-11-2023 om 20:31 schreef Paul Ramsey:<br></div><blockquote type="cite">All that said…<div><br></div><div>It would be possible to “fix” this, but it’s a scary black box. </div><div>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)</div><div><br></div><div><a href="https://github.com/postgis/postgis/blob/42f04a29effdd9e8280c7aba17420ba306fc73f4/liblwgeom/lwgeodetic.c#L3351" originalsrc="https://github.com/postgis/postgis/blob/42f04a29effdd9e8280c7aba17420ba306fc73f4/liblwgeom/lwgeodetic.c#L3351" shash="fM6/XtP1vd/cDcZtDvR0c6LF5wU+l2bjVgy/NVL12+k3aKwOO+/yUa4wsMZwUrD6ZkMtUA/DtUJDJGL9yEe3unCudTPpWKCLFZ+JQ3UbNz+Yccxc/JRYro3eJspgwtdfRkw1l/iHoTkABTkHqaPLukjBnhvyTgHfljFR2eZTFj0=" class="x_moz-txt-link-freetext">https://github.com/postgis/postgis/blob/42f04a29effdd9e8280c7aba17420ba306fc73f4/liblwgeom/lwgeodetic.c#L3351</a></div><div><br></div><div>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.</div><div><br></div><div>P.<br><div><br><blockquote type="cite"><div>On Nov 7, 2023, at 11:22 AM, Paul Ramsey<span class="Apple-converted-space"> </span><a class="x_moz-txt-link-rfc2396E" href="mailto:pramsey@cleverelephant.ca"><pramsey@cleverelephant.ca></a><span class="Apple-converted-space"> </span>wrote:</div><br class="x_Apple-interchange-newline"><div><div style="line-break: after-white-space;">Nope.<div><br></div><div>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! :) </div><div><br></div><div>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.</div><div><br></div><div>ATB,</div><div><br></div><div>P<br><div><br><blockquote type="cite"><div>On Nov 7, 2023, at 11:16 AM, Marco Boeringa<span class="Apple-converted-space"> </span><a class="x_moz-txt-link-rfc2396E" href="mailto:marco@boeringa.demon.nl"><marco@boeringa.demon.nl></a><span class="Apple-converted-space"> </span>wrote:</div><br class="x_Apple-interchange-newline"><div><div><div style="margin-top: 0px; margin-bottom: 0px;">Thanks Paul,</div><div style="margin-top: 0px; margin-bottom: 0px;">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.</div><div style="margin-top: 0px; margin-bottom: 0px;">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.</div><div style="margin-top: 0px; margin-bottom: 0px;">Marco<br></div><div class="x_moz-cite-prefix">Op 7-11-2023 om 19:02 schreef Paul Ramsey:<br></div><blockquote type="cite"><br><div><br><blockquote type="cite"><div>On Nov 6, 2023, at 3:39 PM, Paul Ramsey<span class="Apple-converted-space"> </span><a class="x_moz-txt-link-rfc2396E" href="mailto:pramsey@cleverelephant.ca"><pramsey@cleverelephant.ca></a><span class="Apple-converted-space"> </span>wrote:</div><br class="x_Apple-interchange-newline"><div><div style="line-break: after-white-space;"><br><div><br><blockquote type="cite"><div>On Nov 6, 2023, at 3:33 PM, Marco Boeringa<span class="Apple-converted-space"> </span><a class="x_moz-txt-link-rfc2396E" href="mailto:marco@boeringa.demon.nl"><marco@boeringa.demon.nl></a><span class="Apple-converted-space"> </span>wrote:</div><br class="x_Apple-interchange-newline"><div><div><div style="margin-top: 0px; margin-bottom: 0px;">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?</div><div style="margin-top: 0px; margin-bottom: 0px;">Marco</div></div></div></blockquote><br></div><div>Not really… Either snap to grid or reduce precision</div><div><br></div><div><a href="https://postgis.net/docs/ST_ReducePrecision.html" originalsrc="https://postgis.net/docs/ST_ReducePrecision.html" shash="jd4xt7uG8941CVIU74ol9Q8Uab8G+2GrRucLdMe6DKfWXyFGyHOdES/KUuFdlB3sLqwtHfkzwFk8fZqUpSYZo+XIaeNjwjC1fRUcDRls3M59vh662v8WIzjZPZowWiWDAp/6b/CJAZmo5s/2kbkoMwiYbntEZdMkX7ALjuZVtb4=" class="x_moz-txt-link-freetext">https://postgis.net/docs/ST_ReducePrecision.html</a></div><div><a href="https://postgis.net/docs/ST_SnapToGrid.html" originalsrc="https://postgis.net/docs/ST_SnapToGrid.html" shash="QLZeETAWPNhic6TldvI0jIwVUbubmjKpytvTpxSVtixqmoXHDxqq3UoMjR3xPOsqDmVA6bykg2f72qkLX1Keq/mJbjwt1LTy9jFYXPE145yyQFEBeGKpGRdd0KK7V9lEeWFOzgcbOq5BwVesKKfehU2T5tNjwrfmwF3nM8aLl2c=" class="x_moz-txt-link-freetext">https://postgis.net/docs/ST_SnapToGrid.html</a></div><div><br></div><div>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</div><div><br></div><div><a href="https://postgis.net/docs/ST_ShiftLongitude.html" originalsrc="https://postgis.net/docs/ST_ShiftLongitude.html" shash="JRfgKRpTdFoDINdyD5iYEdMcUgx97Ei69QiobHRG258md13aGZ5pGSDys788xiZb0SL/Cs7yLBvXIOXr9YY5vTO7Kw6LCLGfpqJDippLiLrpwbaM+bUEE1UHeqkF7DyG/u1A1AtyOUH4LucwCAOmtWZGEssp2Qp9niNUDopWEuk=" class="x_moz-txt-link-freetext">https://postgis.net/docs/ST_ShiftLongitude.html</a></div><div><br></div><div>will fix it, I think, though not in generality</div></div></div></blockquote><div><br></div><div>I think using </div><div><br></div><div><a href="https://postgis.net/docs/ST_WrapX.html" originalsrc="https://postgis.net/docs/ST_WrapX.html" shash="iUTLNzPoi9ISwpZNB8IoXEaZvXryDCPTGgLhxDc8+jZ9rS0y06p3zEFHlHjlI02sIBEKJj7+i5ZiFr7IlGCON2/TkRv1TqfWYaQoXQISjLf1yxLJaCuocuFjvyRQDuuRdAnc+0gu0bT74n18hZsHSkP0LpeZY+6B2N+DjvTEdEg=" class="x_moz-txt-link-freetext">https://postgis.net/docs/ST_WrapX.html</a></div><div><br></div><div>would allow a more general purpose solution. At least one you have more control over.</div><div><br></div><div>P</div><br><blockquote type="cite"><div><div style="line-break: after-white-space;"><div><br></div><div>P</div></div></div></blockquote></div><br></blockquote></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div></blockquote></div></div></blockquote></div><br></div><table cellspacing="20" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; width: 600px; font-size: 8pt; font-family: Arial;"><tbody><tr><td><a href="https://www.niwa.co.nz/"><img src="https://www.niwa.co.nz/static/niwa-2018-horizontal-180.png"></a></td><td><span>Brent Wood<span class="Apple-converted-space"> </span><br><font color="#1793d2">Principal Technician - GIS and Spatial Data Management</font><br><font color="#1793d2">Programme Leader - Environmental Information Delivery</font><br>+64-4-386-0529<br><br>National Institute of Water & Atmospheric Research Ltd (NIWA)<br>301 Evans Bay Parade Hataitai Wellington New Zealand<br><b>Connect with NIWA:</b><span class="Apple-converted-space"> </span><a href="https://www.niwa.co.nz/">niwa.co.nz</a><span class="Apple-converted-space"> </span><a href="https://www.facebook.com/nzniwa">Facebook</a><span class="Apple-converted-space"> </span><a href="https://www.linkedin.com/company/niwa">LinkedIn</a><span class="Apple-converted-space"> </span><a href="https://twitter.com/niwa_nz">Twitter</a><span class="Apple-converted-space"> </span><a href="https://www.instagram.com/niwa_science">Instagram</a><span class="Apple-converted-space"> </span><a href="https://www.youtube.com/channel/UCJ-j3MLMg1H59Ak2UaNLL3A">YouTube</a></span><table style="width: 500px;"><tbody></tbody></table></td></tr></tbody></table><font face="Arial" size="1" style="caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">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.<span class="Apple-converted-space"> </span><br>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.</font></div></blockquote></div><br></div></body></html>