Opened 15 years ago
Closed 15 years ago
#241 closed defect (fixed)
GEOSBuffer produces an invalid geometry
Reported by: | pleroux | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 3.1.1 |
Component: | Default | Version: | 3.0.0 |
Severity: | Unassigned | Keywords: | |
Cc: |
Description
Here's a a valid polygon for which the GEOSBuffer function produces an invalid geometry.
At the beginning, I didn't test the returned geometry but only wrote it in WKT format (and it "worked"). I tested different values for dist (1 (m) and 2) and, with 1, it is obvious than the result is not valid (a big hole of the poygon disappears and two small polygons are created). With 2, it "seems" good and the obvious error obtained with 1 don't occur any more.
Even if they are not valid, I think they're interesting to investigate
>>> from shapely.wkb import loads >>> polygon = loads(open('polygon.hexwkb').readline().rstrip().decode('hex')) >>> polygon.is_valid True >>> buffer_1 = polygon.buffer(1.) >>> buffer_1.is_valid False >>> buffer_2 = polygon.buffer(2.) >>> buffer_2.is_valid False >>> print >> open('buffer_1.hexwkb','w'), buffer_1.wkb.encode('hex') >>> print >> open('buffer_2.hexwkb','w'), buffer_2.wkb.encode('hex')
On MacOSX, libgeos 3.0.0, with an equivalent code in C, the problem occurs too.
Attachments (1)
Change History (5)
by , 15 years ago
Attachment: | polygon.hexwkb added |
---|
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Please test r2504 or later. If the problem persist try providing an XML test case.
comment:3 by , 15 years ago
With r2509, the problem doesn't persist any more. "is_valid" attribute is True for the two buffers (see example code above) and, visually, the big hole that disappeared with older releases is correctly handled now.
comment:4 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
buffer_1.hexwkb and buffer_2.hexwkb, even zipped, are too big to be loaded