[postgis-devel] About BOXES

[Sandro Santilli]

On Fri, Nov 25, 2011 at 08:39:48AM -0800, Paul Ramsey wrote:
> On Fri, Nov 25, 2011 at 8:18 AM, Sandro Santilli <strk at keybit.net> wrote:

> > 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.

Another idea:

 1) keep BOX3D but deprecate it
    (have it raise WARNING messages on canonical input...)
 2) add a new type to which BOX3D implicitly cast
    ( and returned by ST_Srid(BOX3D) )

This could solve the name issue.
Then:

 3) drop all the other boxes (save gidx, being internal)
 4) have st_extent return the new type

And maybe, if entusiasm gets you:

 5) have bbox-oriented operators be defined on the new type
 6) provide implicit casts from each type to the new bbox type
 7) drop loads of operators duplication

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html