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