[postgis-devel] Float vs Double Box

[Nicklas Avén]

Hallo Brian

If I understand your slides correctly they are about polygons.

With polygons (and lines) we will have to live with that difference till
we make some new functionality that rechecks with distance against the
real geometry. 

To recheck and tell when enough distances is calculated to say for sure
that the n closest is found is no problem. The problem is, what to do
next. How to stop the query to gain the time saving from not calculating
all distances. 

There is also problematic not to get the needed syntax messy in the
function.


But what I (and Mark) is pointing at is the problem also if we are only
using points. The problem will very seldom have any practical impact
since it is rare to work with better precision than float data type
gives. But as far as I know there is no deliberate robustness weaknesses
before in PostGIS, and hopefully there is some way around introducing
them now.

/Nicklas 


On Thu, 2011-11-10 at 23:56 -0800, Brian Hamlin wrote:
> Hi Nicklas -
> 
>    did you see my slides, exploring the subtle difference in  
> st_distance(), <->  , <#>  ?
> 
> http://download.osgeo.org/postgis/knn_misc/
> 
> ==
> Brian Hamlin
> GeoCal
> OSGeo California Chapter
> 415-717-4462 cell
> 
> On Nov 10, 2011, at 11:47 PM, Nicklas Avén wrote:
> 
> >
> >> Or floats for every box, right ?
> >> That should be pretty consistent: box operations are floats,
> >> shape operations are double.
> >
> > No, there will still be problems.
> > Look at the example I posted yesterday. When it comes to ordering by
> > distance between bboxes you might get the wrong answer.
> >
> > So nearest neighbor calculations with knn will not be robust
> >
> > SELECT id, ST_Distance(a, b), a<->b FROM
> > (SELECT 1 id, 'POINT(300000 6000000)'::geometry a, 'POINT(300001.0
> > 6000001.4)'::geometry b
> > UNION ALL
> > SELECT 2 id, 'POINT(300000 6000000)'::geometry a, 'POINT(300001.1
> > 6000001.1)'::geometry b ) c
> > ORDER BY  a<->b
> >
> > Run it and look at the order of st_distance compared to the order  
> > of <->
> > Here it is of course without index use, but I guess the result is the
> > same with index.
> >
> > /Nicklas
> >
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>