dr-jts
Snapped difference result: Linestring or Empty?
The test of GEOS 350 in the TestOverlay-geos-350.xml file is an areaoverlay test. But GEOS has a test that actually includes the resultant. And the resultant is basically a line. When this "exact" test is run in GEOS using OverlayNG, the result is this:
../geos-git/tests/xmltester/tests/issue/issue-geos-350.xml: case1: test2: difference(A, B): failed. (0 ms)
Description: http://trac.osgeo.org/geos/ticket/350
Original data, fails at noding after snapping
Geometry A: MULTIPOLYGON (((-314775 2708, -336712 -2708, -348138 17051, -339224.934708 1637.62199313, -334393.819242 841.294460641, -332495.87988 -1667.08708709, -314775 2708)))
Geometry B: MULTIPOLYGON (((-357571.747025 -5762.12304965, -321742.91437 -4737.7456186, -324495.928716 19374.7701694, -357251.629078 17838.2040229, -357571.747025 -5762.12304965)))
Expected result: POLYGON ((-322378.688155 830.73441923, -322378.688155 830.73441923, -314775 2708, -322378.688155 830.73441923))
Obtained result: POLYGON EMPTY
The two shapes look like this.
The difference should be something, either a POLYGON with a very narrow base (the GEOS result using the old overlay engine) or snapped down to a LINESTRING. GEOS OverlayNG returns EMPTY, does JTS?
JTS returns POLYGON EMPTY as well for A.difference(B).
This is expected, since (currently and by design) polygon edges which collapse due to snapping are not included in the output. The rationale is that if the inputs were snapped prior to running the operation, those edges would disappear anyway. And it avoid having portions of polygons turn into lines, which might be "surprising" to subsequent processing.
So chalk this one up as a difference in semantics between OverlayNG and classic overlay. (Open to discussion, of course)
Yeah, a big proportion of the other failures in the XML suite are of this category. The outputs from the old overlay are GEOMETRYCOLLECTION(LINESTRING, POLYGON), and the outputs of the NG overlay are MULTIPOLYGON.
This does seem (in this case quite clearly) to violate the principle of least surprise though. It's surprising that the clear something outside of B turns into nothing in the difference result.
This does seem (in this case quite clearly) to violate the principle of least surprise though. It's surprising that the clear something outside of B turns into nothing in the difference result.
Sigh... I suppose so.
It may be a bit tricky to reintroduce output of collapsed edges, since I remember dropping this semantic made the coding easier. Will need some research to see.