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

[Rémi Cura]

Hey,
you can just use another srid with translated points to reduce the number
of (useless) digits.
You can even just create the index on the translation function so you don't
duplicate your data.
(ex : CREATE INDEX ON your_table USING
gist(st_translate(geom,0,0,-1388534400)))


If you don't want to do this, you could try creativ custom solutions,
but in all case you couldn't use no more the &&& syntax, and would have to
use indexes over function instead
(or maybe postgres RULES )

Cheers,
Rémi-C


2014-06-13 18:13 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca>:

> 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
>
>
> _______________________________________________
> 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/c1882afa/attachment.html>