[postgis-devel] About BOXES

[Paul Ramsey]

Getting into representations, good...

On Fri, Nov 25, 2011 at 12:43 PM, Sandro Santilli <strk at keybit.net> wrote:
> On Fri, Nov 25, 2011 at 11:20:30AM -0800, Paul Ramsey wrote:
> 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

I prefer this one, and with optional spacing (as in the SQL/MM parser)
so that we could have

BOX (4 6,57 40);SRID=4326
BOX Z (4 6 0,57 40 0);SRID=4326
BOX M (4 6 0,57 40 0);SRID=4326
BOX ZM (4 6 0 0,57 40 0 0);SRID=4326

Now, you sure about putting the SRID at the back, unlike the geometry WKT?

> Meaning parsers for ST_3DExtent are more likely to fail.

It's so new, I'm guessing we can afford this risk.

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

The problem with ST_Extent() returning a box2d was that it was a
float-backed type, so the coordinates were rounded out and not exact.
box3d_extent was a hack to avoid the rounding while retaining a
box2d-style text representation. Since box2d is no longer used as an
index key, it can be redefined to be double-backed, and st_extent
could return box2d again. But it looks like we can get most of what we
need with your proposal above, the only downside being that the text
representation of the 'bbox' type will be 'BOX()' and not 'BBOX()'.

P.


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