SymDifference between two valid geometries return an _invalid_ geometry [JTS fails too]

[strk]

Geometry A:

010300000001000000080000000000000087523A41000000402C62524100000000B0523A41000000C01E6252410000000084523A41000000C023625241858C4F2488523A4151F8EEAC2562524111A0F52288523A414F50F3AC25625241D59FF52288523A414F50F3AC25625241000000007F523A4100000080256252410000000087523A41000000402C625241

Geometry B:

01030000000100000004000000A871502388523A4158FEF2AC2562524100A0F52288523A414F50F3AC2562524111A0F52288523A414F50F3AC25625241A871502388523A4158FEF2AC25625241

They are both valid, but when running SymDifference against them the result is invalid.

[strk]

The inputs are a larger polygon (first) and a very narrow polygon almost collapsed to a line which intersects with the former.

Areas:

     839.745285423078
 3.86746841149477e-14

Overlay with original input fails: TopologyException: found non-noded intersection between LINESTRING (1.72506e+06 4.81909e+06, 1.72506e+06 4.81909e+06) and LINESTRING (1.72506e+06 4.81909e+06, 1.72506e+06 4.81909e+06) at 1725064.1365604463 4819094.70235069

Common-bits remover result is refused due to invalidity of the output.

Snap heuristic is accepted no matter invalidity of the output. Invalidity is (in both cases): Self-intersection at or near point 1725064.1365604463 4819094.70235069 (1725064.1365604463499 4819094.7023506900296)

I guess it'd make more sense to throw a TopologyException on invalid output.. but that's really something that shouldn't happen.

[strk]

I've tested JTS which also fails. Not easy to tell because JTS testrunner doesn't check output for validity, but it succeeds in returning the invalid geometry as result.

[strk]

See also #838

[strk]

This issue is reported to be fixed by the fix for #838 too: ​https://github.com/locationtech/jts/issues/107#issuecomment-361962900

[robe]

Milestone renamed

[dbaston]

Added test confirming fix in cd3af0d40a9ab78fddf16abf29bd4d7bce099868/git