[postgis-devel] (Bug?) Strange Behavior with ST_SymDifference (line, surface)

[Rémi Cura]

Hello Dev List,

this discussion is about a wrong behaviour (nonetheless ensuring valid (for
postgis) output) of the function
ST_SymDifference.

In a nutshell : ST_SymDifference(line, surface) gives the same surface
(wrong mathematical result) with added points at former crossing of line
and surface (strange but doesn't mathematically affects result at least)

This problem is blocking as I don't see any workaround in complex cases
(unless using ST_Split, which is not 3D enabled)

I found that this operation is done by GEOS , in the OverlayOp.cpp file :
OverlayOp::computeOverlay

I don't understand where the problem come from .(My Cpp knowledge is not
what I would like it to be)

Somebody knows where is the problem and how to correct it?

Cheers,

Rémi-C


2013/9/27 Sandro Santilli <strk at keybit.net>

> On Fri, Sep 27, 2013 at 04:15:10PM +0200, Rémi Cura wrote:
>
> > Output for line vs surface should be multipolygon, or poylgon with holes
> (
> > flat hole : the parts of the line inside the polygon), or multipolygon
> with
> > holes (flat holes : same).
>
> Your multipolygon would be invalid (two elements of a multipolygon cannot
> have a linear intersection), but a GEOMETRYCOLLECTION containing two
> polygons could substitute it.
>
> On the other hand the "flat hole" is really impossible to represent with
> a valid geometry, I'm afraid, as it'd need a self-intersecting boundary.
>
> > Output for point vs surface should be polygon with holes (1 point hole :
> > point inside or on  boundary of surface), or multipolygons with holes (1
> > point holes : same).
>
> Same thing, would be an invalid ring.
>
> > I think there would be no problem to store this geometry in postgis ().
>
> No, no problem to store it, but it'd wouldn't pass ST_IsValid.
>
> > Then output of SymDiff would be a SymDiff and not an union when points or
> > lines are involved with surfaces (Which makes output false, and anything
> > using it possibly false also).
>
> Note that any overlay operation would throw an exception when given
> a geometry that doesn't pass ST_IsValid, so you couldn't check.
>
> > At the very least SymDiff should not add points to surface boundary where
> > it crossed line (what is the sense of it??).
>
> That's indeed implementation specific, due to noding operation still
> being performed as the first step with every overlay.
>
> > Surely enough some output wouldn't be "valid", depending on your criteria
> > (quite sure QGis wouldn't like it). Yet it would be possible to warn
> about
> > invalid (for postgis) output and possibly deal with it.
> >
> > Shall we switch to the dev list?
>
> Yep, more appropriate, let's continue there.
>
> --strk;
>
> > Thanks for your time,
> >
> > Rémi-C
> >
> >
> >
> > 2013/9/27 Sandro Santilli <strk at keybit.net>
> >
> > > Your ascii art doesn't render correctly with fixed font,
> > > unfortunately. Anyway I think I understood the issue.
> > >
> > > I belive the problem is with mix of dimensions.
> > > A line has 1 dimension only, by definition.
> > > If we had to make "space" to subtract the points that
> > > compose that line, how much space would those points take ?
> > > Points have even less dimension: 0...
> > >
> > > It's like subtracting points from an area and expecting
> > > to see holes in it. Does it sound ?
> > >
> > > --strk;
> > >
> > >
> > > On Fri, Sep 27, 2013 at 02:52:42PM +0200, Rémi Cura wrote:
> > > > hey,
> > > > I'm experiencing a strange behavior with ST_SymDifference
> > > > :<http://postgis.net/docs/manual-2.0/ST_SymDifference.html>
> > > >
> > > > When doing symdiff of a line and a surface, I get the same surfaces
> with
> > > > added points on surfaces boundary (where line crossed surface).
> > > >
> > > > Example :
> > > >   ___________
> > > > *├---------┤*
> > > >   -------------------
> > > >
> > > > gives
> > > >   ___________
> > > > *|             |***
> > > >   -------------------
> > > >
> > > > I read the SQL MM definition
> > > > (here<
> http://jtc1sc32.org/doc/N1101-1150/32N1107-WD13249-3--spatial.pdf
> > > ‎>,
> > > > page 67-68-69), and I found no trace of behavior with line against
> > > > surfaces.
> > > >
> > > > Mathematically , if we take for definition the union without the
> > > > intersection, the result is false (no point on the line should be in
> the
> > > > result, yet they are).
> > > >
> > > > I was expecting as output one polygon each side of the line (ie 2
> > > polygons).
> > > >
> > > > I would appreciate any thoughts about this.
> > > > Cheers,
> > > >
> > > > Rémi-C
> > > > PS : I know I can use ST_Split or other tricks for the same result in
> > > this
> > > > simple case, but not so easily for trickier case.
> > > _______________________________________________
> > > postgis-users mailing list
> > > postgis-users at lists.osgeo.org
> > > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at lists.osgeo.org
> > http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>
>
> --
>
>  http://www.cartodb.com - Map, analyze and build applications with your
> data
>
>                                        ~~ http://strk.keybit.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20130927/76b95faa/attachment.html>