The following table summarizes results of running the tests in [attachment: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 [[BR]]
(b) GEOS 3.3.2SVN r3528 / 3.4.0SVN r3527 on a 64bit system [[BR]]
(c) JTS rev.480 [[BR]]
(d) symDiffArea frac: 0.00970281 tolerated 0.001 [[BR]]
(e) symDiffArea frac: 0.0731868 tolerated 0.001 [[BR]]
(f) symDiffArea frac: 0.0704188 tolerated 0.001 [[BR]]
(g) symDiffArea frac: 0.0429171 tolerated 0.001 [[BR]]
(h) Expected result is of type Polygon; obtained result is of type MultiPolygon [[BR]]




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


= 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 [source:trunk/src/noding/SegmentNodeList.cpp#L259 SegmentNodeList.createSplitEdge] refusing (in GEOS) to produce 1-vertex SegmentString.
 1. scale=1e1
  * GEOS computes 52 edges
  *  JTS computes 53 edges
  * Result don't change dropping the additional check in [source:trunk/src/noding/SegmentNodeList.cpp#L259 SegmentNodeList.createSplitEdge]
 1. scale=1e5
  * GEOS computes 19 edges
  *  JTS computes 20 edges
  * Result don't change dropping the additional check in [source:trunk/src/noding/SegmentNodeList.cpp#L259 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 [attachment:ScaledNoderTest.java]

= Resources =

diffnoding.gz contains the offsetcurve produced by both GEOS and JTS with reduction scale 1e5 and distance 1.01 against input. [[BR]]
The curve, passed to [source:trunk/src/operation/buffer/BufferBuilder.cpp#L507 BufferBuilder::computeNodedEdges], results in edges with a differently computed _depth_ between JTS and GEOS.