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

[Komяpa]

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?

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

чт, 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;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20150226/ce277da4/attachment.html>