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

Paul Ramsey pramsey at cleverelephant.ca
Fri Jun 13 09:13:39 PDT 2014

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

Paul Ramsey

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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20140613/010508c7/attachment.html>

More information about the postgis-devel mailing list