[postgis-devel] Precision loss issue with &&& operator

[Paul Ramsey]

Hi,
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
P

-- 
Paul Ramsey
http://cleverelephant.ca
http://postgis.net

On June 13, 2014 at 7:35:27 AM, Marios Vodas (mvodas at outlook.com) wrote:

Dear PostGIS hackers,
 
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.
 
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));
It returns true instead of false!
 
Maybe the error is due to a cast to a 32-bit floating point, e.g.: SELECT 1388534404::real::integer;
 
Marios Vodas
_______________________________________________  
postgis-devel mailing list  
postgis-devel at lists.osgeo.org  
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20140613/010508c7/attachment.html>