[postgis-devel] lwgeom_calculate_bbox

[Paul Ramsey]

The confusion is exacerbated by the fact that we have two
implementations of all this stuff floating around right now in the
middle of serialization change. Also, a certainly level of uncertainty
about how much backward compatibility to maintain. Simple fact of
life: there are user-accessible box2d, and box3d types available in
order versions. There's also a postgresql built-in 'box' type. The
box3d_extent type was added to provide a double-based return to fix
the problem of extent() not returning the true extents, while
retaining backward compatibility. To this mix I add two more types
(not user accessible, but defined for the purpose of index keys,
'gidx' (multi-dimensional key) and 'box2df' (2d float key, but in a
more dimensionally expandable order (xmin,xmax,ymin,ymax) than the
existing box2d key (xmin,ymin,xmax,ymax).

Could you sketch out what the heck raster is doing with boxes, and
whether it's actually required or was just a mind-jump ("i need a box,
hey, here's a box type!") during development.

Paul

On Sun, Mar 20, 2011 at 10:43 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Sun, Mar 20, 2011 at 06:18:09PM +0100, Sandro Santilli wrote:
>
>> If we're going to drop the BOX2D
>> type, how else would we go with fetching a cached BOX ?
>
> Crawling trough source history (thanks git!), I see that
> a box3d_extent type was introduced around March 2009:
>
> So we now have box2d, box3d and box3d_extent.
> But NONE of them we define operators on :!
>
> Seems time to make a plan, if there isn't one already, so
> that 2.0 comes with a single such type, to have all boundable
> types converge to for the sake of using a single set of
> operators and indices.
>
> --strk;
>
>  ()   Free GIS & Flash consultant/developer
>  /\   http://strk.keybit.net/services.html
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>