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. The data in bufrob4.wkt is rounded to the precision grid of 1e-5.

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​

Actually the above runs aren't expected to be meaningful as MCIndexSnapRounder is expected to receive input already rounded to the given precision grid, which in our case would be 1e-5. Passing that scale to the noder gives 178 edges with both GEOS and JTS.

ScaledNoder

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​

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.