Buffer of closed LineString fails to have hole for some distance values

[dr-jts]

Original bug report: GEOS 1022

Computing buffer with distance = 1 of closed LineString below produces a polygon with no hole, which is incorrect.

LineString (278601.0234000000054948 4295292.71929999999701977, 278598.71919999999227002 4295290.49340000003576279, 278589.06283691781572998 4295303.48101469129323959, 278605.49300000001676381 4295297.03689999971538782, 278601.0234000000054948 4295292.71929999999701977)

Furthermore, the following distance values also produce polygons with no holes:

0.6428571428571428
0.9918367346938776
1.263265306122449
1.379591836734694

[dr-jts]

The reason for this failure is that the generated buffer curve linework is failing to be noded correctly. It's surprising this hasn't shown up as a failure long before now. The incorrect noding is occurring in the overlapping fillet arcs generated at each end of the linestring. This is due to the variation that occurs as a result of generating nearly-coincident segments in the arc for each of the line end segments.

Polygons do not suffer from this problem, since the code does not generate end arcs for the rings of polygons. My speculation is that it is rare to have buffer inputs consisting of closed linestrings with nearly-parallel end segments.

The good news is that this issue can be solved simply by generating buffer curves for closed linestrings in the same way as polygon rings. In fact, the recent issue #518 proposes doing exactly this.

[dr-jts]

Fixed by #525