[postgis-devel] GBOXF

[Sandro Santilli]

On Thu, Dec 01, 2011 at 10:46:25AM +0000, Mark Cave-Ayland wrote:

> What is more concerning is that at the moment we will always be
> introducing error into geometry bounding box comparisons that are
> used as part of an index scan, because we need to inflate the box
> upon conversion from double to float. So at the moment the only way
> to guarantee consistent results is to use floats for all internal
> arithmetic - otherwise we will have cases where sequential scans and
> index scans can return different results.

Note that using floats for all math might not be the same
as using doubles and then inflate-to-float as the former
may result in a box which doesn't fully enclose a geometry
in double precision space. 

I know we're doing math in double and inflate-to-float 
when we extract keys for the index. Ensuring to always
do such thing for other uses should give us a consistent 
behavior. Not easy to test/enforce but theoretically
viable. Ticket #1324 is aimed at helping with that:
http://trac.osgeo.org/postgis/ticket/1324

Of course if that's what we decide to do, then we should
stick with that ("boxes are float") which means neither
ST_Extent return nor any new BBOX type should expose
anything which falls on the double precision grid, as
that would expose the risk to get back to inconsistency.

--strk; 

  ,------o-. 
  |   __/  |    Sign the pledge for PostGIS-2.0 Topology !
  |  / 2.0 |    http://www.pledgebank.com/postgistopology
  `-o------'