<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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>
</body>
</html>