<div dir="ltr"><div>There's now a pull request to address this:<br></div><div><br></div><div><a href="https://github.com/postgis/postgis/pull/92" target="_blank">https://github.com/postgis/postgis/pull/92</a><br></div><div><br></div><div>The only places in the regression suite where a BOX3D->geometry cast is executed are places where a (user-input) BOX3D literal is explicitly cast to a geometry.  So, there shouldn't be a performance hit or ill effect of having the BOX3D->geometry cast produce a PolyhedralSurface, as Even suggests.</div><div><br></div><div>Any objections to this?</div><div><br></div><div>Dan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 8:02 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le jeudi 18 février 2016 10:49:52, Sandro Santilli a écrit :<br>
> On Thu, Feb 18, 2016 at 10:03:54AM +0100, Rémi Cura wrote:<br>
> > Is there any way to perform &&& in all 3 dimensions?<br>
><br>
> Our boxes are all broken.<br>
> There should be somewhere a wiki page or ticker or something about<br>
> options to improve the situation. IIRC it boiled down to:<br>
><br>
>  1) Have a BOX geometry type (like LINESTRING/POINT/POLYGON)<br>
>  2) Expose a GBOX postgresql type (like BOX2D, BOX3D)<br>
><br>
> Recently, I've started using 2-vertices linestrings to simulate<br>
> the equivalent of a "BOX geometry type". It is the value returned<br>
> by <a href="http://postgis.net/docs/ST_BoundingDiagonal.html" rel="noreferrer" target="_blank">http://postgis.net/docs/ST_BoundingDiagonal.html</a><br>
><br>
> You can easily create such object via ST_MakeLine:<br>
> <a href="http://postgis.net/docs/ST_MakeLine.html" rel="noreferrer" target="_blank">http://postgis.net/docs/ST_MakeLine.html</a><br>
><br>
> It will support SRID and all supported dimensions.<br>
><br>
> Changing the BOX3D->Geometry cast ? I'm all for it, and I'd have<br>
> it return a "bounding diagonal" too...<br>
<br>
</span>Naively, I would rather have expected a BOX3D to be converted as a<br>
PolyhedralSurface, but there might be implications in doing so.<br>
<span class="im HOEnZb"><br>
><br>
> --strk;<br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
<br>
</span><span class="im HOEnZb">--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/postgis-devel</a></div></div></blockquote></div><br></div>