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

Fri Sep 27 09:11:53 PDT 2013

another food for thought :
ST_SymDifference produces polygon with no area (ie lines), and polygon with
self intersecting boundary.

First image shows result of a buffer and SYmDifference based processing
Second image : I moved manually things to expose errors, I added no points.

It surely is a precision issue I'll try to solve with snapping.

Yet all the geometries passes ST_IsValid, but are invalid for QGIS

Cheers,
Rémi-C

2013/9/27 Rémi Cura <remi.cura at gmail.com>

> 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/3d5e4dae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after_recursive_buffer_and_symdifference__geometrical_errors_exposed.jpg
Type: image/jpeg
Size: 108076 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20130927/3d5e4dae/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after_recursive_buffer_and_symdifference.jpg
Type: image/jpeg
Size: 58660 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20130927/3d5e4dae/attachment-0001.jpg>