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 <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/postgis-users
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/postgis-users
