<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Paul,</p>
<p>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?</p>
<p>Marco<br>
</p>
<div class="moz-cite-prefix">Op 7-11-2023 om 20:58 schreef Paul
Ramsey:<br>
</div>
<blockquote type="cite"
cite="mid:A72AD5D8-4550-4DC4-8AB7-0C2A52235443@cleverelephant.ca">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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
<a class="moz-txt-link-rfc2396E" href="mailto:Brent.Wood@niwa.co.nz"><Brent.Wood@niwa.co.nz></a> 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 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>
<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
style="font-size: 11pt;" face="Calibri, sans-serif"><b>From:</b><span
class="Apple-converted-space"> </span>postgis-users
<a class="moz-txt-link-rfc2396E" href="mailto:postgis-users-bounces@lists.osgeo.org"><postgis-users-bounces@lists.osgeo.org></a> on
behalf of Paul Ramsey via postgis-users
<a class="moz-txt-link-rfc2396E" href="mailto:postgis-users@lists.osgeo.org"><postgis-users@lists.osgeo.org></a><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 <a class="moz-txt-link-rfc2396E" href="mailto:marco@boeringa.demon.nl"><marco@boeringa.demon.nl></a><br>
<b>Cc:</b><span class="Apple-converted-space"> </span>Paul
Ramsey <a class="moz-txt-link-rfc2396E" href="mailto:pramsey@cleverelephant.ca"><pramsey@cleverelephant.ca></a>; PostGIS
Users Discussion <a class="moz-txt-link-rfc2396E" href="mailto:postgis-users@lists.osgeo.org"><postgis-users@lists.osgeo.org></a><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
<a class="moz-txt-link-rfc2396E" href="mailto:marco@boeringa.demon.nl"><marco@boeringa.demon.nl></a> 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 moz-txt-link-freetext"
moz-do-not-send="true">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" moz-do-not-send="true"><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" moz-do-not-send="true"><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" moz-do-not-send="true"><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" moz-do-not-send="true"><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 moz-txt-link-freetext"
moz-do-not-send="true">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 moz-txt-link-freetext"
moz-do-not-send="true">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 moz-txt-link-freetext"
moz-do-not-send="true">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 moz-txt-link-freetext"
moz-do-not-send="true">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
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;"
cellspacing="20">
<tbody>
<tr>
<td><a href="https://www.niwa.co.nz/"
moz-do-not-send="true"><img
src="https://www.niwa.co.nz/static/niwa-2018-horizontal-180.png"
moz-do-not-send="true"></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/"
moz-do-not-send="true">niwa.co.nz</a><span
class="Apple-converted-space"> </span><a
href="https://www.facebook.com/nzniwa"
moz-do-not-send="true">Facebook</a><span
class="Apple-converted-space"> </span><a
href="https://www.linkedin.com/company/niwa"
moz-do-not-send="true">LinkedIn</a><span
class="Apple-converted-space"> </span><a
href="https://twitter.com/niwa_nz"
moz-do-not-send="true">Twitter</a><span
class="Apple-converted-space"> </span><a
href="https://www.instagram.com/niwa_science"
moz-do-not-send="true">Instagram</a><span
class="Apple-converted-space"> </span><a
href="https://www.youtube.com/channel/UCJ-j3MLMg1H59Ak2UaNLL3A"
moz-do-not-send="true">YouTube</a></span>
<table style="width: 500px;">
<tbody>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<font
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;"
size="1" face="Arial">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>
</blockquote>
</body>
</html>