<div dir="ltr">A linestring as result will break some assumptions:<br><br><div>ST_Covers(ST_Expand(geom, 0), geom) == true - you're expanding geometry, so it should cover the original, right?<br><div><br></div><div>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)...</div></div></div><br><div class="gmail_quote">чт, 26 февр. 2015 г. в 12:30, Sandro Santilli <<a href="mailto:strk@keybit.net">strk@keybit.net</a>>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was looking for a way to expand a 4D point to use the resulting<br>
"nd-box"  in an ND overlap query (&&&) and found the closest function<br>
to do that being ST_Expand(geometry).<br>
<br>
That function reurns a geometry of type POLYGON, but I'm thinking..<br>
what's the POLYGON representation for a 3D or 4D box ?<br>
Having 5 vertices makes it completely arbitrary where to put<br>
the MIN and the MAX values of each ordinate.<br>
<br>
Wouldn't it be less confusing to return a 2-vertices LINESTRING<br>
instead ?<br>
<br>
As noted in <a href="http://trac.osgeo.org/postgis/ticket/1329" target="_blank">http://trac.osgeo.org/postgis/<u></u>ticket/1329</a><br>
a 2-vertices LINESTRING might be the closest thing to<br>
an even less confusing "BOXND" type. It has a direction<br>
(contrary to a MULTIPOINT) that makes it clear what the<br>
min and max are (first and last points).<br>
<br>
Or would you prefer to have a new "BOX" geometry type  ?<br>
Or even a new "BOXND" PostgreSQL type ?<br>
<br>
--strk;<br>
______________________________<u></u>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-<u></u>bin/mailman/listinfo/postgis-<u></u>devel</a><br>
</blockquote></div>