Intersection between two valid geometries yelds an invalid one

[strk]

This actually happens with test geometries we already have in the testsuite, just didn't notice up to now. The geoms are 5th case in robustness.xml

[strk]

Interesting enough, the following tests also fail with invalid return from Intersection:

tests/stmlf/stmlf-cases-20061020.xml: case1: test1 tests/stmlf/stmlf-cases-20061020.xml: case20: test1 tests/stmlf/stmlf-cases-20061020.xml: case24: test1 tests/stmlf/stmlf-cases-20061020.xml: case25: test1

[strk]

For the record: refusing an invalid result from the CommonBitsOp policy thus passing the ball to SnapOp fixes all the stmlf* cases but still triggers an exception on this one.

At closer look, the SnapOp for this one fails because snapping one of the geometries makes it invalid (self-intersection). Computed snap tolerance is 1.1831999999e-07 The two geometries are almost identical, snapping makes a spike collapse to a line.

[strk]

Good (?) news: JTS fails with this as well. The testcase is in GEOS repository appropriately tweaked in format to be supported by JTS. Message from JTSTestRunner:

=====  Test Runner  -  JTS Topology Suite (Version 1.12.0 alpha)  =====
Reading test file /usr/src/geos/trunk/tests/xmltester/tests/bug375.xml
Running tests...

Case bug375.xml - #1 (7): http://trac.osgeo.org/geos/ticket/375
Test Threw Exception (a intersection b)     com.vividsolutions.jts.geom.TopologyException: found non-noded intersection between LINESTRING ( 5417154.92 5658376.37, 5417155.18955743 5658376.89699992 ) and LINESTRING ( 5417155.1895573465 5658376.896999757, 5417155.814 5658378.111 ) [ (5417155.189557428, 5658376.896999915, NaN) ]


1 cases with 3 tests  --  2 passed, 0 failed, 1 threw exceptions

[strk]

Of course I'm talking about the result when refusing the invalid result from COmmonBitsOp.. which gets closer to becoming the default IMHO

[strk]

Let's close this as a wontfix being known to fail in JTS too. In it's current incarnation the test is now in failure/TestOverlay.xml