Opened 2 years ago

Closed 2 years ago

#1022 closed defect (fixed)

Buffering a specific closed linestring erroneously produces polygon without hole.

Reported by: uclaros Owned by: geos-devel@…
Priority: major Milestone:
Component: Default Version: 3.8.0
Severity: Unassigned Keywords:
Cc:

Description

Applying a buffer of 1m on the following linestring

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

produces a polygon without a hole, only outer ring. If any of the three almost-aligned nodes is moved, the expected result is returned: a polygon with a hole (one outer ring, one inner ring).

Found on QGIS and confirmed on shapely with geos 3.8.0

Attachments (1)

Buffer from geometry postgis 3.1.png (134.1 KB ) - added by jgrocha 2 years ago.
Buffer wit hthe missing hole in the polygon

Download all attachments as: .zip

Change History (7)

by jgrocha, 2 years ago

Buffer wit hthe missing hole in the polygon

comment:1 by jgrocha, 2 years ago

Confirmed using Postgis with GEOS 3.8.0-CAPI-1.13.1

SQL to reproduce the bug:

CREATE TABLE public.tpoly (
	id serial NOT NULL,
	geom geometry(POLYGON, 3857) not null,
	CONSTRAINT tpoly_pkey PRIMARY KEY (id)
);

CREATE TABLE public.tline (
	id serial NOT NULL,
	geom geometry(LINESTRING, 3857) not null,
	CONSTRAINT tline_pkey PRIMARY KEY (id)
);

insert into public.tline (geom)
values (ST_GeomFromText('LineString (278601.0234000000054948 4295292.71929999999701977, 278598.71919999999227002 4295290.49340000003576279, 278589.06283691781572998 4295303.48101469129323959, 278605.49300000001676381 4295297.03689999971538782, 278601.0234000000054948 4295292.71929999999701977)',3857));

insert into public.tpoly (geom)
select st_buffer(geom,1, 'quad_segs=0') from public.tline where id = 1;

The resulting buffer is attached.

comment:2 by Mike Taves, 2 years ago

Confirmed, with same behavior with JTS 1.14. And for the record, the input geometry is valid and simple.

The test can be simplified using a default buffer (without parameters).

What makes this bug interesting is that it is depends on the buffer distance, since most other values produce the expected result. And it's not just 1.0.

Here is a simple shapely example that checks 50 buffer distances between 0.1 and 2.0

import numpy as np
from shapely import wkt

g = wkt.loads('LineString (278601.0234000000054948 4295292.71929999999701977, 278598.71919999999227002 4295290.49340000003576279, 278589.06283691781572998 4295303.48101469129323959, 278605.49300000001676381 4295297.03689999971538782, 278601.0234000000054948 4295292.71929999999701977)')
for b in np.linspace(0.1, 2.0, num=50):
    if len(g.buffer(b).interiors) == 0:
        print(b)

shows these buffer distances

0.6428571428571428
0.9918367346938776
1.263265306122449
1.379591836734694

so 8% failure rate.

comment:3 by mdavis, 2 years ago

Logged as JTS 523

comment:4 by mdavis, 2 years ago

Fixed in JTS by PR 525

comment:5 by Paul Ramsey <pramsey@…>, 2 years ago

In 061656e/git:

Buffering a specific closed linestring erroneously produces polygon without hole. References #1022

comment:6 by Paul Ramsey <pramsey@…>, 2 years ago

Resolution: fixed
Status: newclosed

In 56b19e0/git:

Buffering a specific closed linestring erroneously produces polygon without hole. Closes #1022

Note: See TracTickets for help on using tickets.