[postgis-devel] BOX3D strange behaviour

Regina Obe lr at pcorp.us
Fri Feb 26 16:53:09 PST 2016

+1 for making BOX3D cast to geometry = PolyhedralSurface. That's way more useful to me than any other coercion and seems like the most logical representation of a box3d.

Paul said it had no effect on the index operators (as they don't rely on any to geometry casting).  That would be my only concern with not just having it do the non-ambiguous right thing.

This would of course be a breaking change so can't be done until 2.3.


-----Original Message-----
From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Sandro Santilli
Sent: Friday, February 26, 2016 10:34 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] BOX3D strange behaviour

On Fri, Feb 26, 2016 at 06:41:04AM -0500, Daniel Baston wrote:
> There's now a pull request to address this:
> https://github.com/postgis/postgis/pull/92
> 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.
> Any objections to this?

I think it'd still count as an API break as clients expecting a POLYGON would not get one. Hard to anticipate how offending such change could be, but should be threated as an API break, if done.

I wonder if it makes sense to keep improving BOX3D rather than deprecating it in favor of something different.

postgis-devel mailing list
postgis-devel at lists.osgeo.org

More information about the postgis-devel mailing list