<div dir="ltr"><div><div><div><div>another food for thought :<br></div>ST_SymDifference produces polygon with no area (ie lines), and polygon with self intersecting boundary.<br><br></div><div>First image shows result of a buffer and SYmDifference based processing<br>
</div><div>Second image : I moved manually things to expose errors, I added no points.<br></div><div><br></div><div>It surely is a precision issue I'll try to solve with snapping.<br><br></div><div>Yet all the geometries passes ST_IsValid, but are invalid for QGIS<br>
</div>
<br></div>Cheers,<br></div>Rémi-C<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/27 Rémi Cura <span dir="ltr"><<a href="mailto:remi.cura@gmail.com" target="_blank">remi.cura@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hello Dev List,<br><br></div>this discussion is about a wrong behaviour (nonetheless ensuring valid (for postgis) output) of the function<br>
</div>ST_SymDifference.<br><br></div><div>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)<br>
</div><div><br></div><div>This problem is blocking as I don't see any workaround in complex cases (unless using ST_Split, which is not 3D enabled)<br></div><div><br></div>I found that this operation is done by GEOS , in the OverlayOp.cpp file :<br>
<div style="margin-left:40px"><font size="1">OverlayOp::computeOverlay</font><br></div><div><div><br></div><div>I don't understand where the problem come from .(My Cpp knowledge is not what I would like it to be)<br>
<br>
</div><div>Somebody knows where is the problem and how to correct it?<br></div><div><br></div><div>Cheers,<br><br>Rémi-C<br></div><div><div class="h5"><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/27 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Fri, Sep 27, 2013 at 04:15:10PM +0200, Rémi Cura wrote:<br>
<br>
> Output for line vs surface should be multipolygon, or poylgon with holes (<br>
> flat hole : the parts of the line inside the polygon), or multipolygon with<br>
> holes (flat holes : same).<br>
<br>
</div>Your multipolygon would be invalid (two elements of a multipolygon cannot<br>
have a linear intersection), but a GEOMETRYCOLLECTION containing two<br>
polygons could substitute it.<br>
<br>
On the other hand the "flat hole" is really impossible to represent with<br>
a valid geometry, I'm afraid, as it'd need a self-intersecting boundary.<br>
<div><br>
> Output for point vs surface should be polygon with holes (1 point hole :<br>
> point inside or on boundary of surface), or multipolygons with holes (1<br>
> point holes : same).<br>
<br>
</div>Same thing, would be an invalid ring.<br>
<div><br>
> I think there would be no problem to store this geometry in postgis ().<br>
<br>
</div>No, no problem to store it, but it'd wouldn't pass ST_IsValid.<br>
<div><br>
> Then output of SymDiff would be a SymDiff and not an union when points or<br>
> lines are involved with surfaces (Which makes output false, and anything<br>
> using it possibly false also).<br>
<br>
</div>Note that any overlay operation would throw an exception when given<br>
a geometry that doesn't pass ST_IsValid, so you couldn't check.<br>
<div><br>
> At the very least SymDiff should not add points to surface boundary where<br>
> it crossed line (what is the sense of it??).<br>
<br>
</div>That's indeed implementation specific, due to noding operation still<br>
being performed as the first step with every overlay.<br>
<div><br>
> Surely enough some output wouldn't be "valid", depending on your criteria<br>
> (quite sure QGis wouldn't like it). Yet it would be possible to warn about<br>
> invalid (for postgis) output and possibly deal with it.<br>
><br>
> Shall we switch to the dev list?<br>
<br>
</div>Yep, more appropriate, let's continue there.<br>
<br>
--strk;<br>
<div><div><br>
> Thanks for your time,<br>
><br>
> Rémi-C<br>
><br>
><br>
><br>
> 2013/9/27 Sandro Santilli <<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>><br>
><br>
> > Your ascii art doesn't render correctly with fixed font,<br>
> > unfortunately. Anyway I think I understood the issue.<br>
> ><br>
> > I belive the problem is with mix of dimensions.<br>
> > A line has 1 dimension only, by definition.<br>
> > If we had to make "space" to subtract the points that<br>
> > compose that line, how much space would those points take ?<br>
> > Points have even less dimension: 0...<br>
> ><br>
> > It's like subtracting points from an area and expecting<br>
> > to see holes in it. Does it sound ?<br>
> ><br>
> > --strk;<br>
> ><br>
> ><br>
> > On Fri, Sep 27, 2013 at 02:52:42PM +0200, Rémi Cura wrote:<br>
> > > hey,<br>
> > > I'm experiencing a strange behavior with ST_SymDifference<br>
> > > :<<a href="http://postgis.net/docs/manual-2.0/ST_SymDifference.html" target="_blank">http://postgis.net/docs/manual-2.0/ST_SymDifference.html</a>><br>
> > ><br>
> > > When doing symdiff of a line and a surface, I get the same surfaces with<br>
> > > added points on surfaces boundary (where line crossed surface).<br>
> > ><br>
> > > Example :<br>
> > > ___________<br>
> > > *├---------┤*<br>
> > > -------------------<br>
> > ><br>
> > > gives<br>
> > > ___________<br>
> > > *| |***<br>
> > > -------------------<br>
> > ><br>
> > > I read the SQL MM definition<br>
> > > (here<<a href="http://jtc1sc32.org/doc/N1101-1150/32N1107-WD13249-3--spatial.pdf" target="_blank">http://jtc1sc32.org/doc/N1101-1150/32N1107-WD13249-3--spatial.pdf</a><br>
> > >,<br>
> > > page 67-68-69), and I found no trace of behavior with line against<br>
> > > surfaces.<br>
> > ><br>
> > > Mathematically , if we take for definition the union without the<br>
> > > intersection, the result is false (no point on the line should be in the<br>
> > > result, yet they are).<br>
> > ><br>
> > > I was expecting as output one polygon each side of the line (ie 2<br>
> > polygons).<br>
> > ><br>
> > > I would appreciate any thoughts about this.<br>
> > > Cheers,<br>
> > ><br>
> > > Rémi-C<br>
> > > PS : I know I can use ST_Split or other tricks for the same result in<br>
> > this<br>
> > > simple case, but not so easily for trickier case.<br>
> > _______________________________________________<br>
> > postgis-users mailing list<br>
> > <a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
> > <a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>
<br>
> _______________________________________________<br>
> postgis-users mailing list<br>
> <a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users</a><br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
<br>
<a href="http://www.cartodb.com" target="_blank">http://www.cartodb.com</a> - Map, analyze and build applications with your data<br>
<br>
~~ <a href="http://strk.keybit.net" target="_blank">http://strk.keybit.net</a><br>
<br>
</font></span></blockquote></div><br></div></div></div></div></div></div>
</blockquote></div><br></div>