[postgis-devel] About BOXES

[Paul Ramsey]

On Fri, Nov 25, 2011 at 8:18 AM, Sandro Santilli <strk at keybit.net> wrote:
> Today we have multiple boxes:
>
>  BOX3D

The original box.

>  BOX3D_EXTENT

A box Mark had to add to get backward-compatible behaviour while
exposing a true double-precision extent aggregate.

>  BOX2D

The old index key float box, no longer required.

>  BOX2Df

A new index key float box, required but not for use by mortals. (Has
no input functions or output functions.)

And you missed

GIDX

A new multi-dimensional index key float box, required but not for use
by mortals.

> Do we really need all of them ? What for ?

We don't need any of them except the index keys.

> Can we get rid of them all ? Why not ?

There are use cases for boxes, so keeping one makes sense. There are
also uses of boxes embedded in client code, as you note index queries
were documented against a 'BOX3D' example for a very long time, even
when the index ops themselves were happening in GEOMETRY.

The case for BOX3D is that it's a known external interface. The case
against it is that it has no SRID. We could upgrade the backend
storage for BOX3D to support SRID and enrich the text representation
with the "SRID=999;" hack. That would have the advantage of not adding
yet more boxes, and the disadvantage of keeping the odd "BOX3D" name
for what might sometimes be a 2D and sometimes a 4D box.

P.

> Note that my need is still just as simple as selecting all the
> TopoGeometry objects that fall in the map viewport. And I know
> such operation I want performed on bounding boxes. And I know
> I'd like the interface to be as transparent as it was back in
> 2002:
>
>  A && 'BOX3D(90900 190900, 100100 200100)'::box3d
>
> Only with A which is now a TopoGeometry (or, incidentally, a Raster
> or a Geography).
>
> I'm dreaming of a setup in which all the bounding-box-oriented
> operators are actually defined on a bounding-box-type (be it BOX3D
> to be backward compatible since 2002 or a new shiny type being an
> evolution of that one) and all our types (geometry,geography,raster,
> topogeometry) would define implicit casts to that new type...
>
>
> [1] http://hub.qgis.org/projects/quantum-gis/repository/revisions/41de1a0045eff44a4fc81b1d02458fa32223666b
> [2] http://web.archive.org/web/20021213153604/http://postgis.refractions.net/docs/x534.html#AEN538
>
> --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
>