<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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>
</p>
<div class="moz-cite-prefix">Op 7-11-2023 om 20:31 schreef Paul
Ramsey:<br>
</div>
<blockquote type="cite"
cite="mid:1F2603A4-7ABC-40ED-84C0-F5DDE08BD165@cleverelephant.ca">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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"
moz-do-not-send="true" class="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
<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;">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
<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>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" moz-do-not-send="true"><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"
moz-do-not-send="true"><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>
</blockquote>
</body>
</html>