<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;">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">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 <pramsey@cleverelephant.ca> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; 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 <marco@boeringa.demon.nl> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div><p>Thanks Paul,</p><p>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.</p><p>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.</p><p>Marco<br>
</p>
<div class="moz-cite-prefix">Op 7-11-2023 om 19:02 schreef Paul
Ramsey:<br>
</div>
<blockquote type="cite" cite="mid:F9FD9E45-7416-49F7-8F84-55D360B19333@cleverelephant.ca">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<br>
<div><br>
<blockquote type="cite">
<div>On Nov 6, 2023, at 3:39 PM, Paul Ramsey
<a class="moz-txt-link-rfc2396E" href="mailto:pramsey@cleverelephant.ca"><pramsey@cleverelephant.ca></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br>
<div><br>
<blockquote type="cite">
<div>On Nov 6, 2023, at 3:33 PM, Marco Boeringa
<a class="moz-txt-link-rfc2396E" href="mailto:marco@boeringa.demon.nl"><marco@boeringa.demon.nl></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div><p>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?</p><p>Marco</p>
</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" moz-do-not-send="true" class="moz-txt-link-freetext">https://postgis.net/docs/ST_ReducePrecision.html</a></div>
<div><a href="https://postgis.net/docs/ST_SnapToGrid.html" moz-do-not-send="true" class="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" moz-do-not-send="true" class="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" moz-do-not-send="true" class="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="overflow-wrap: break-word; -webkit-nbsp-mode: space; 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></body></html>