The following table summarizes results of running the tests in buffer-tests.zip​

dist	GEOS 3.3.0 + patch	GEOS (b) OLD reduc stratg	GEOS (b) NEW reduc stratg	JTS (c)
0.35	Same output as 3.2.0	ok on 1st attempt, no reduction	ok on 1st attempt, no reduction	ok on 1st attempt, no reduction
0.75	Same output as 3.2.0	ok on 1st reduction (1e10)	ok on 1st reduction (1e5)	ok on 1st reduction (1e5)
1.01	Same output as 3.2.0	ok on 2nd reduction (1e9)	fail on 5th reduction (1e1) (d)	ok on 1st reduction (1e5)
1.1 (a)	Same output as 3.2.0	ok on 2nd reduction (1e9)	ok on 1st reduction (1e5)	ok on 1st reduction (1e5)
1.5	Half incorrect (i)	ok on 2nd reduction (1e9)	fail on 6th reduction (1e0) (e)	ok on 1st reduction (1e5)
2	Incorrect output(ii)	fail on 11th reduction (1e0) (f)	fail on 6th reduction (1e0) (f)	ok on 1st reduction (1e5)
5	Incorrect output(ii)	fail on 11th reduction (1e0) (g)	fail on 6th reduction (1e0) (g)	ok on 1st reduction (1e5)
10	Incorrect output(ii)	fail on 12th reduction (1e-1)(h)	fail on 7th reduction (1e-1)(h)	ok on 1st reduction (1e5)

(a) aka TestBufferJagged.xml
(b) GEOS 3.3.2SVN r3528 / 3.4.0SVN r3527 on a 64bit system
(c) JTS rev.480
(d) symDiffArea frac: 0.00970281 tolerated 0.001
(e) symDiffArea frac: 0.0731868 tolerated 0.001
(f) symDiffArea frac: 0.0704188 tolerated 0.001
(g) symDiffArea frac: 0.0429171 tolerated 0.001
(h) Expected result is of type Polygon; obtained result is of type MultiPolygon

(i) Same as GEOS 3.2.0 in xmltester. Incorrect in GEOS 3.3.0 client -- same problem as (ii).
(ii) Output seems to have lost way too much precision.

MCIndexSnapRounder

Comparing operations of MCIndexSnapRounder against bufrob4.wkt noding.

After the fix to HotPixel in r3528 there are still differences in the number of coordinates found for each noded edge.

1. scale=1e2
   • GEOS computes 25 edges 3 of which composed by 3 vertices and 22 of 2 vertices.
   • JTS computes 25 edges 3 of which composed by 3 vertices, 3 by 1 vertex and 19 by 2.
   • The LineString generated using all the points, according to Equals, is the same. The difference is in SegmentNodeList.createSplitEdge​ refusing (in GEOS) to produce 1-vertex SegmentString.
2. scale=1e1
   • GEOS computes 52 edges
   • JTS computes 53 edges
   • Result don't change dropping the additional check in SegmentNodeList.createSplitEdge​
3. scale=1e5
   • GEOS computes 19 edges
   • JTS computes 20 edges
   • Result don't change dropping the additional check in SegmentNodeList.createSplitEdge​

ScaledNoder

NOTE this is valid as of before r3528, should be rechecked now. Focus is on MCIndexSnapRounder now.

Having detected a difference in noding I've produced a testcase to read a geometry and perform noding on its linework. The JTS version is ScaledNoderTest.java​

The image below shows difference between GEOS (yellow) and JTS (cyan) noding results with bufrob4.wkt​ input.

There are two nodes in both version, only JTS is anchoring the line going down to the node on the left while GEOS is anchoring it to the node on the right. It's interesting to note that the input (red line) is closer to GEOS result, not JTS. Also it is to be noted that the horizontal segment is a duplicated edge in JTS which then results in one edge more than the GEOS counterpart.

Resources

diffnoding.gz contains the offsetcurve produced by both GEOS and JTS with reduction scale 1e5 and distance 1.01 against input.
The curve, passed to BufferBuilder::computeNodedEdges​, results in edges with a differently computed _depth_ between JTS and GEOS.