Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#984 closed defect (fixed)

Buffering a polygon inwards (eroding) results in a bizarre geometry error.

Reported by: jpmaterial Owned by: strk
Priority: major Milestone:
Component: Core Version: main
Severity: Significant Keywords:
Cc:

Description

When offsetting a certain polygon by 0.75, the outline changes randomly. I'm using GEOS via the Shapely Python library where I also first reported this bug: https://github.com/Toblerity/Shapely/issues/767 . They told me to report it here. The polygon (and a Shapely-based repro script) is available in hex WKB from my test_data github repository: https://github.com/jpmaterial/test_data/tree/master/Shapely/767

My GEOS version is reported as 3.7.1 in conda, I'm assuming this is the master.

Attachments (5)

outer_1567062696_8.wkb (7.6 KB ) - added by jpmaterial 3 years ago.
The polygon in question
63924404-80de0200-ca48-11e9-8940-8d3638ca23d9.png (13.9 KB ) - added by jpmaterial 3 years ago.
Illustration of the error in question
jts_master_result.png (20.8 KB ) - added by dbaston 3 years ago.
geos-3.1.0-buffer.png (72.8 KB ) - added by strk 2 years ago.
GEOS master (3.1.0dev) result of the operation
issue-geos-984.xml (30.2 KB ) - added by strk 2 years ago.
XML tester, with WKB input

Download all attachments as: .zip

Change History (13)

by jpmaterial, 3 years ago

Attachment: outer_1567062696_8.wkb added

The polygon in question

by jpmaterial, 3 years ago

Illustration of the error in question

by dbaston, 3 years ago

Attachment: jts_master_result.png added

comment:1 by dbaston, 3 years ago

Looks ok in JTS master, so must be unique to GEOS.

Do you mean "randomly" as in you get a different result each time your run the operation? Or do you mean that the output is unexpected?

comment:2 by jpmaterial, 3 years ago

Summary: Buffering a polygon inwards (eroding) results in a random geometry error.Buffering a polygon inwards (eroding) results in a bizarre geometry error.

More precise title. The result is actually deterministic.

comment:3 by strk, 2 years ago

Daniel: did you produce an XML test for feeding the test to JTS ? As I did create one, with the geometry in WKT format, and get a good result in GEOS master as well. I'm attaching the test. jpmaterial: do you confirm you get a good result with current GEOS master ? Chances are the WKT representation is loosing some precision which hides the problem

comment:4 by strk, 2 years ago

Well I used the WKB input and the result is still good to me. I'm attaching the XML and the PNG image of the result.

by strk, 2 years ago

Attachment: geos-3.1.0-buffer.png added

GEOS master (3.1.0dev) result of the operation

comment:5 by strk, 2 years ago

Sorry, I was wrong, I did NOT use the WKB. Still trying to convert to HEXWKB ...

comment:6 by strk, 2 years ago

Ok, now I did test with HEXWKB and it still works. I'm attaching the XML test

by strk, 2 years ago

Attachment: issue-geos-984.xml added

XML tester, with WKB input

comment:7 by strk, 2 years ago

Resolution: fixed
Status: newclosed

It looks like the issue is fixed, although I'm not sure in which version it was fixed...

comment:8 by uclaros, 2 years ago

Could be related to / fixed with: https://trac.osgeo.org/geos/ticket/1022

Note: See TracTickets for help on using tickets.