[postgis-devel] Changing ST_Expand(geometry) to return LINESTRING

[Sandro Santilli]

On Thu, Feb 26, 2015 at 09:43:09AM +0000, Komяpa wrote:
> A linestring as result will break some assumptions:
> 
> ST_Covers(ST_Expand(geom, 0), geom) == true - you're expanding geometry, so
> it should cover the original, right?

Uhm, expanding a point would still hold the assumption, but you're right
it would be broken by expanding a line or a polygon.

On the other hand the assumption is already broken in 3D, but
we don't have a function to show that...

> IMHO, BOX is more favourable. But Box won't keep SRID of geometry, which is
> now the only reason to use ST_Expand(geom,0) over ST_Extent(geom)...

Box won't even keep all dimension (there's no 4D box).
That's why I was suggesting to get a new BOX type, either
as geometry subtype or as a postgresql type.

--strk;

> чт, 26 февр. 2015 г. в 12:30, Sandro Santilli <strk at keybit.net>:
> 
> > I was looking for a way to expand a 4D point to use the resulting
> > "nd-box"  in an ND overlap query (&&&) and found the closest function
> > to do that being ST_Expand(geometry).
> >
> > That function reurns a geometry of type POLYGON, but I'm thinking..
> > what's the POLYGON representation for a 3D or 4D box ?
> > Having 5 vertices makes it completely arbitrary where to put
> > the MIN and the MAX values of each ordinate.
> >
> > Wouldn't it be less confusing to return a 2-vertices LINESTRING
> > instead ?
> >
> > As noted in http://trac.osgeo.org/postgis/ticket/1329
> > a 2-vertices LINESTRING might be the closest thing to
> > an even less confusing "BOXND" type. It has a direction
> > (contrary to a MULTIPOINT) that makes it clear what the
> > min and max are (first and last points).
> >
> > Or would you prefer to have a new "BOX" geometry type  ?
> > Or even a new "BOXND" PostgreSQL type ?
> >
> > --strk;