[postgis-devel] BOX3D strange behaviour
dbaston at gmail.com
Fri Feb 26 03:41:04 PST 2016
There's now a pull request to address this:
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
Any objections to this?
On Thu, Feb 18, 2016 at 8:02 AM, Even Rouault <even.rouault at spatialys.com>
> Le jeudi 18 février 2016 10:49:52, Sandro Santilli a écrit :
> > On Thu, Feb 18, 2016 at 10:03:54AM +0100, Rémi Cura wrote:
> > > Is there any way to perform &&& in all 3 dimensions?
> > Our boxes are all broken.
> > There should be somewhere a wiki page or ticker or something about
> > options to improve the situation. IIRC it boiled down to:
> > 1) Have a BOX geometry type (like LINESTRING/POINT/POLYGON)
> > 2) Expose a GBOX postgresql type (like BOX2D, BOX3D)
> > Recently, I've started using 2-vertices linestrings to simulate
> > the equivalent of a "BOX geometry type". It is the value returned
> > by http://postgis.net/docs/ST_BoundingDiagonal.html
> > You can easily create such object via ST_MakeLine:
> > http://postgis.net/docs/ST_MakeLine.html
> > It will support SRID and all supported dimensions.
> > Changing the BOX3D->Geometry cast ? I'm all for it, and I'd have
> > it return a "bounding diagonal" too...
> Naively, I would rather have expected a BOX3D to be converted as a
> PolyhedralSurface, but there might be implications in doing so.
> > --strk;
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/postgis-devel
> Spatialys - Geospatial professional services
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgis-devel