[postgis-users] ST_Intersects behaviour with 3D Polygon and Linestring

[Paul Ramsey]

ST_Relate ignores all the Z coordinates. So if you want to see what the
reasoning is, just strip them away. Results for invalid inputs are not
guaranteed to have any meaning.

P.

On Mon, Dec 12, 2016 at 6:33 AM, Felix Kunde <felix-kunde at gmx.de> wrote:

> Hi everybody,
>
> I have a general question about the behaviour with 2D lines intersecting
> 3D polygons. In my example I want to filter walls of a building which are
> crossed by a shortest line between address point and street geometry. When
> regarded in 2D most 3D polygons are invalid, of course. Those polygons
> which have "too few points" in 2D (e.g. a rectangle of 5 points) do not
> return any intersection with a crossing linestring. My question is: How is
> this polygon then handled internally because functions like ST_Relate still
> return a result and not an exception.
>
> SELECT ST_Relate('POLYGON Z ((0 1 1,2 1 1,2 1 2,0 1 2,0 1
> 1))'::geometry,'LINESTRING (1 0,1 3)'::geometry);
> -- returns FFFFFF102 = disjoint, even though the geometries overlap in 2D
> space
>
> When there are more points, a self-intersection is reported as expected.
> But, PostGIS' topology functions can still operate on these invalid
> polygons and return TRUE on intersection.
>
> SELECT ST_Relate('POLYGON Z ((0 1 1,2 1 1,2.1 1 1,2.1 1 2,2 1 2,0 1 2,0 1
> 1))'::geometry,'LINESTRING (1 0,1 3)'::geometry);
> -- returns 1F20F0102
>
> One trick is to extract the exteroir ring of the polygons to get around
> the "too few points" issue. They I get the result I want. But I thought it
> might be an interesting question, if the described behaviour is really
> consistent.
>
> Kind regards
> Felix
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20161212/3c16bc3b/attachment.html>