Number of buffered points not always a multiple of quadSegs

[Mike Taves]

Using Buffer with quadrantSegments, it is expected that the number of unique points is quadrantSegments * 4. However, for some quadrantSegments there is an extra point that is a near duplicate of the last.

For example quadrantSegments = 13, using either Shapely or PostGIS:

-- PostGIS
SELECT ST_AsText(ST_Buffer(ST_MakePoint(0, 0), 1.0, 13));
# Shapely
from shapely.geometry import Point
Point(0, 0).buffer(1.0, 13).wkt

results with 53 unique points (or 54 with repeat last) POLYGON((1 0,...,1 1.44557759859665e-14,1 0)), where the second last is within machine epsilon distance of the last coordinate. This example for quadrantSegments = 13 should have 52 unique points, or 53 points for a closed polygon.

This is not an isolated case for quadrantSegments = 13; same also for: 13, 15, 16, 17, 20, 22, 25, 26, 28, 31, 32, 38, 39, 42, 43, 45, 46, 47, 49, 50, 51, 53, 54, 56, 57, 62, 64, 67, 68, 71, 75, 76, 78, 81, 83, 84, 85, 89, 90, ...

It seems there are no issues with JTS on this issue.

[Mike Taves]

I should note that this was tested with several versions of GEOS, including 1.5.0, and on 64-bit Linux and Windows.

[Mike Taves]

Replying to mwtoews:

including 1.5.0

I mean GEOS 3.5.0-CAPI-1.9.0 r4084

[robe]

Does the issue exist on all versions of GEOS you tested with? Which version e.g. GEOS 3.4.2 did you test?

[Mike Taves]

Yes "3.4.2-CAPI-1.8.2 r3924" too, on Windows x64. I'm moving the milestone off for the next major release, unless this is an easy fix.

[strk]

Ticket retargeted after milestone closed

[Mike Taves]

See ​https://github.com/libgeos/geos/pull/282

[mdavis]

This is also a problem in JTS. Now fixed by ​JTS PR 526.

[pramsey]

Should be fixed in GEOS at Should be fixed at 7732d9b6339e4b75b567cc0f5e33d753c5a9f528

[pramsey]

Also backed-ported into 3.8 stable.

[Regina Obe <lr@…>]

In 23e07a5/git:

More missing cstdint headers
Closes #990, References #743