[postgis-devel] Vive Doublebox

[Paul Ramsey]

On Thu, Dec 8, 2011 at 5:31 AM, Sandro Santilli <strk at keybit.net> wrote:

> Could you list the advantages of having a cached box based on doubles
> rather than float ? So far you only mentioned avoiding the coordinate
> drifts during cast-to-box, but as cast-to-box would mostly serve the
> purpose of using && over it, and && being still based on float I don't
> see that drift as representing any problem.

The lwgeom->bbox would exactly match the cached box in the serialized
form. So there would be no need for care to ensure consistent bounding
box semantics, it would always be consistent.

ST_Extent would be implementable as a quick scan of the bbox cache
rather than a full read of all coordinates.

The bounding boxes people get from shapes with "obvious" bounds (eg
'LINESTRING(0 0, 1 1)') would match their expectations, diminishing
user surprise. (Actually, it is possible to get this behaviour without
doublebox, but ensuring that the casts to box types always do a full
scan of the coordinates to generate a box.

The code for handling lwgeom->bbox won't have interesting-to-explain
contextual behavior around populating the bbox (ie, when parsing text,
round the generated box out to float before returning, but when
generating an extent for casting or st_extent returns, leave it at
double precision).

> Should we list all functions dealing with boxes and expecting full
> precision ? I think ST_Extent is one of them. Is that correct ?
> It'd help to have a full list and for each item evaluate how important
> using double precision would be.

I think I'm done with this topic. The current situation is ugly, and
I'd be happiest if our contract was my original one (I'll guarantee
you the lwgeom->bbox bounds the shape it surrounds but nothing else,
certainly not that you always get the same one for a given shape).

P.

>
> --strk;
>
>  ,------o-.
>  |   __/  |    Thank you for PostGIS-2.0 Topology !
>  |  / 2.0 |    http://www.pledgebank.com/postgistopology
>  `-o------'
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel