Opened 3 years ago
Closed 3 years ago
#1022 closed defect (fixed)
Buffering a specific closed linestring erroneously produces polygon without hole.
Reported by: | uclaros | Owned by: | |
---|---|---|---|
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)
Change History (7)
by , 3 years ago
Attachment: | Buffer from geometry postgis 3.1.png added |
---|
comment:1 by , 3 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 , 3 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.
Buffer wit hthe missing hole in the polygon