<div dir="ltr"><div><div><div><div><div>Hey,<br></div>you can just use another srid with translated points to reduce the number of (useless) digits.<br></div><div>You can even just create the index on the translation function so you don't duplicate your data.<br>
</div><div>(ex : CREATE INDEX ON your_table USING gist(st_translate(geom,0,0,-1388534400)))<br><br></div><div><br></div>If you don't want to do this, you could try creativ custom solutions, <br></div>but in all case you couldn't use no more the &&& syntax, and would have to use indexes over function instead<br>
</div>(or maybe postgres RULES )<br><br></div>Cheers,<br>Rémi-C<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-13 18:13 GMT+02:00 Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
Hi,</div><div 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 style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">P</div> <div><div><br></div><span style="font-family:helvetica,arial;font-size:13px"></span>-- <br>Paul Ramsey<br><a href="http://cleverelephant.ca" target="_blank">http://cleverelephant.ca</a><div>
<a href="http://postgis.net" target="_blank">http://postgis.net</a></div></div><div><div class="h5"> <br><p style="color:#000">On June 13, 2014 at 7:35:27 AM, Marios Vodas (<a href="mailto:mvodas@outlook.com" target="_blank">mvodas@outlook.com</a>) wrote:</p>
</div></div><blockquote type="cite"><span><div><div></div><div><div><div class="h5">
<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></div></div>
_______________________________________________
<br>postgis-devel mailing list
<br><a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>
<br><a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a></div></div></span></blockquote></div><br>_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br></blockquote></div><br></div>