Version 13 (modified by 12 years ago) ( diff ) | ,
---|
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 r3523 / 3.4.0SVN r3524 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.
Noding
The image below shows difference between GEOS (yellow) and JTS (cyan) noding results with bufrob3_5 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.
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.
Further reducing the input and the applied code I got to bufrob3.wkt giving a different number of noded edges between JTS (333) and GEOS (330). This is when using ScaledNoder with scale of 1e5 and underlying MCIndexSnapRounder noder.
I'm also attaching the JTS unit test which I'm using to compare GEOS/JTS runs. The test reads WKT from a file.
Attachments (7)
-
diffnoding.wkt.gz
(24.6 KB
) - added by 12 years ago.
offsetcurve produced by both JTS and GEOS when buffering input by 1.01 distance. GEOS and JTS compute edges depth differently starting from this same input.
-
bufrob3.wkt
(7.8 KB
) - added by 12 years ago.
Using ScaledNoder with scale=1e5 nodes this with edges: JTS 333, GEOS 330
-
bufrob3_5.wkt
(3.0 KB
) - added by 12 years ago.
further simplification: 147 edges with JTS, 146 with GEOS
-
buffer-tests.zip
(63.3 KB
) - added by 12 years ago.
All buffer tests, with correct expected results
-
bufrob3_5_5.wkt
(3.8 KB
) - added by 12 years ago.
Version of bufrob3_5 with all coordinates snapped to a 1e-5 grid
-
ScaledNoderTest.java
(5.5 KB
) - added by 12 years ago.
Updated version of ScaledNoderTest for JTS, supports both WKT and HexWKB in input
-
bufrob4.wkt
(821 bytes
) - added by 12 years ago.
14 edges with JTS, 13 with GEOS -- input snapped to 1e-5
Download all attachments as: .zip