<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Hi,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I’m afraid there’s not much we can do about it, you’re just representing more precision than the 32-bit index bounding boxes can hold. On the plus side, you’re getting a false positive, not a false negative, so you can always filter finally with a double precision function like 3ddistance</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">P</div> <div id="bloop_sign_1402675956336478976" class="bloop_sign"><div><br></div><span style="font-family:helvetica,arial;font-size:13px"></span>-- <br>Paul Ramsey<br>http://cleverelephant.ca<div>http://postgis.net</div></div> <br><p style="color:#000;">On June 13, 2014 at 7:35:27 AM, Marios Vodas (<a href="mailto:mvodas@outlook.com">mvodas@outlook.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div class="hmmessage"><div></div><div>
<title></title>
<div dir="ltr">Dear PostGIS hackers,<br>
<br>
I would like to highlight an issue I discovered while I was trying
to use &&& operator with 3D linestrings. The problem is
that when comparing two geometries with &&&
operator precision is lost if a dimension
contains big numbers as coordinates, so the operator returns
true instead of false and vice versa. This might be due to rounding
but I think it should be fixed since the precision is lost only
within the execution of &&& and not when the
coordinates are given as input to construct the geometry object;
meaning I can see the correct number when use ST_AsText() on the
linestring geometry but these numbers are not respected.<br>
<br>
Here is an example that illustrates this situation: SELECT
ST_MakeLine(ST_MakePoint(1,1,1388534401),
ST_MakePoint(3,3,1388534403)) &&&
ST_MakeLine(ST_MakePoint(1,1,1388534404),
ST_MakePoint(3,3,1388534405));<br>
It returns true instead of false!<br>
<br>
Maybe the error is due to a cast to a 32-bit floating point, e.g.:
SELECT 1388534404::real::integer;<br>
<br>
Marios Vodas<br></div>
_______________________________________________
<br>postgis-devel mailing list
<br>postgis-devel@lists.osgeo.org
<br>http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</div></div></span></blockquote></body></html>