Change BOX3D to be SRID and dimension aware

[robe]

Discussion here

​http://www.postgis.org/pipermail/postgis-devel/2011-November/016216.html

To be followed up after float to double #1328.

As a consequence of this change, the following also needs to be done for backward compatibility.

box3d_extent will be deprecated and possibly removed, though I think that might break some apps removing it. I have one to test that theory.

deprecate box2d (possibly get rid of it). I think there is too much code out there that relies on box2d that getting rid of it is a pipe dream the moment. So we might want to deprecate it now, remove it from the docs, and encourage people to not use it in a non-violent demonstration of disapproval.

1) ST_Extent returns box3d just like ST_3DExtent currently does. 2) Both ST_3DExtent and ST_Extent be changed to strip the SRID of the improved box3d type by default, with an optional argument — keep_srid (defaulted to false) for those like strk who really want it and want to override the behavior to make it true.

All this stuff better not push out the release time beyond our slated February 2012 or I'll be steaming mad (at least mad for a week).

[strk]

See #103 for a common use case (setSRID on box3d dropping Z)

[strk]

If it's just for me that we have to make this change I'll need to double check my priorities

Seriously my whole idea here was to simplify BOXes for use with BOX oriented operations, since we have a few. Mostly extent and operators and indices.

The idea is to make it transparent for client code that goes:

  CREATE INDEX mytable_spatial_index on mytable (<somecolumn>);
  SELECT * FROM mytable WHERE <somecolumn> && ST_MakeEnvelope(...);
  SELECT * FROM mytable WHERE <somecolumn> && ST_SetSRID'BOX(...)'; -- legacy

The above with <somecolumn> possibly being of type GEOMETRY or GEOGRAPHY or RASTER or TOPOGEOMETRY.

Did anyone already research on this topic and has conclusions about it ? Or I'd spend some time on it.

[strk]

We're too close to a release to do anything like this. The whole box/envelope discussion needs to be postponed to 2.1, or even future.

[strk]

So back to this issue. I'd want a real "box" type which can hold SRID and any number of dimensions. It can be float or double I don't really care at this very moment, but it's a way to easily handle a rectangle, get its width and height, grow it or shrink it, expand to include a point or another box etc…

It could be the only type on which indices and bounding-box based operators are defined and would have an implicit cast from all types (raster, geometry, geography, TopoGeometry) to take advantage of those indices and operators.

A good next step will likely be a wiki page, to link here.

[robe]

I don't think this is going to happen anytime soon. punt.

[strk]

Stumbled upon this one while thinking I needed a BOXND to find extent of an 4D table… To be honest we could get away with all these boxes by using a two-points LINESTRING. It would embed SRID and dimension flags.

Only it would be slightly larger in size than a simple box, and have less semantic associated with it. How would you feel about an ST_NDExtent() returning geometry ? Doesn't it sound too loose ?

[strk]

Related, PostgreSQL 9.2 introduced "range types": ​http://www.postgresql.org/docs/9.2/static/rangetypes.html

Boxes in any dimensions could be encoded as array of ranges. There would be no SRID awareness though…

[robe]

Milestone renamed