BOX3D strange behaviour

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Paul Ramsey
Something strange, I would imagine, but I'm no 3d expert :)

On Fri, Feb 26, 2016 at 3:45 PM, Komяpa <[hidden email]> wrote:

> When performong ST_3DIntersection(geom, box3d), will approach with line do
> the thing that's awaited from it clipping geometry by the box, or make
> strange multipoint/multilinestring/EMPTY intersection? :)
>
> пт, 26 февр. 2016 г. в 17:34, Paul Ramsey <[hidden email]>:
>>
>> Codacil to this: a linestring involves an lwline and a pointarray, a
>> multipoint involves a multipoint, 2 x point, 2 x pointarray, so
>> there's a minor efficiency in sticking w/ the line.
>>
>> On Thu, Feb 18, 2016 at 1:27 PM, Rémi Cura <[hidden email]> wrote:
>> > Exactly,
>> > in the end it's just 2 points.
>> > I personally would prefer to keep it as 2 points,
>> > because I feel a line is semantically more different,
>> > but it amounts to the same thing in the end.
>> >
>> > Cheers,
>> > Rémi-C
>> >
>> > 2016-02-18 11:36 GMT+01:00 Sandro Santilli <[hidden email]>:
>> >>
>> >> On Thu, Feb 18, 2016 at 11:02:49AM +0100, Rémi Cura wrote:
>> >> > Using Even trick saves me about 25% time.
>> >> > Good !
>> >>
>> >> Right, it's the same approach of the "BoundingDiagonal",
>> >> only he does it with a 2-members multipoint rather than
>> >> with a 2-vertices linestring.
>> >>
>> >> --strk;
>> >> _______________________________________________
>> >> postgis-devel mailing list
>> >> [hidden email]
>> >> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>> >
>> >
>> >
>> > _______________________________________________
>> > postgis-devel mailing list
>> > [hidden email]
>> > http://lists.osgeo.org/mailman/listinfo/postgis-devel
>> _______________________________________________
>> postgis-devel mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Sandro Santilli-2
In reply to this post by Daniel Baston
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.

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
Reply | Threaded
Open this post in threaded view
|

Re: BOX3D strange behaviour

Regina Obe
+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.

Thanks,
Regina



-----Original Message-----
From: postgis-devel [mailto:[hidden email]] On Behalf Of Sandro Santilli
Sent: Friday, February 26, 2016 10:34 AM
To: PostGIS Development Discussion <[hidden email]>
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.

--strk;
_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel


_______________________________________________
postgis-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-devel
12