[postgis-devel] GBOXF

[Paul Ramsey]

OK, so it sounds like the way forward is to basically keep what we
have now, which is a double GBOX, but with care taken that we populate
it it with float-rounded versions of the bounds, so that
demand-generated boxes match cached boxes. This will need to be
documented, but if we move to doing bbox access via an accessor
instead of directly referencing the object the number of pain points
should go down hopefully.

I will move forward with new bbox work on the above basis, and abandon
the doublebox experiment.

P.

On Mon, Nov 28, 2011 at 9:45 AM, Olivier Courtin
<olivier.courtin at oslandia.com> wrote:
>
> On Nov 28, 2011, at 6:38 PM, Paul Ramsey wrote:
>
> Olivier,
> Since the cached double box experiment seems to be getting dropped due
> to the performance loss, we're getting back to "what do we do with
> cached float boxes". Sandro wants to make sure the boxes attached to
> our LWGEOM instance are always consistent, which is hard when
> sometimes they are double (off calculated values) and sometimes float
> (off cached values).
>
>
> I agree with Sandro consistency concern.
>
> One way to ensure consistency would be to make
> the GBOX actually be float (GBOXF). I recall you were very happy to
> have GBOX replace BOX2FLOAT4. Was that because GBOX is higher
> dimensional or because it is double based, or both?
>
>
> Both in fact,
>
> As double bbox are really convenient as our datas are double based.
>
> I want to know, so
> I can decide whether it's OK to replace GBOX with a GBOXF.
>
>
>
> --
> Olivier
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>