[postgis-devel] About BOXES

[Sandro Santilli]

On Fri, Nov 25, 2011 at 11:20:30AM -0800, Paul Ramsey wrote:
> On Fri, Nov 25, 2011 at 11:18 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
> >>> Backward compatiblity issue: what does ST_Extent() return? The problem
> >>> is if people are parsing the output, they expect whatever it returns
> >>> to have a text representation of 'BOX()' (the old box2d
> >>> representation).
> 
> Oh, hai, I have the answer to my question: because box2d is no longer
> *used* anywhere, I can re-define it as a double type, and st_extent
> can go back to using box2d as a return type, and the old syntax can
> remain.

ST_Extent returns box3d_extent.
ST_3DExtent returns box3d.

I think they should both return the new type BBOX with 2 or 3 dimensions
depending on what was requested.

box3d_extent looks like this:
 BOX(4 6,57 40)

box3d looks like this:
 BOX3D(4 6 0,57 40 0)

We could have our new BBOX type do something like this:
 BOX(4 6,57 40);SRID=4326
 BOX3D(4 6 0,57 40 0);SRID=4326
 BOX4D(4 6 0 0,57 40 0 0);SRID=4326
 BOXM(4 6 0,57 40 0);SRID=4326

The first two are meant to be backward compatible,
the latter tries to build on the former. Alternatively:
 BOX(4 6,57 40);SRID=4326
 BOXZ(4 6 0,57 40 0);SRID=4326
 BOXM(4 6 0,57 40 0);SRID=4326
 BOXZM(4 6 0 0,57 40 0 0);SRID=4326

Meaning parsers for ST_3DExtent are more likely to fail.

Among all of this, I don't get your "re-define box2d" idea.

--strk; 

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