[postgis-devel] GBOXF

[Mark Cave-Ayland]

On 30/11/11 13:02, Sandro Santilli wrote:

>> Actually while you mention it, I can also see how GROUP BY could be
>> an issue with points in the same way as two points very close
>> together could potentially be considered as one.
>
> Right. But I still don't see an issue with it, as it's semantically
> the same as two completely different lines having the same bounding
> box. It's like 10 being 5+5 but also 4+6.
>
> More concerning were two _equal_ geometries being considered not equal
> because the bounding box of one of them was computed using doubles
> and the other was rounded to floats:
> http://trac.osgeo.org/postgis/ticket/1273
>
> I think the contract here is: bounding box of a geometry is the minimum
> bounding box that can enclose a geometry expressible with the given
> numeric precision. It's been floats so far (since 1.x ?).
>
> I think this is what we're debating: if it should be floats or doubles.
> Having a mix of the two representations scaries me a little bit (see
> the bug above).

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.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs