Opened 9 years ago

Closed 8 years ago

#994 closed defect (fixed)

v.buffer2 creating wrong buffer around polygon edges.

Reported by: mlechner Owned by: grass-dev@…
Priority: critical Milestone: 6.4.1
Component: Vector Version: 6.4.0 RCs
Keywords: v.buffer2 Cc: rmatev
CPU: Unspecified Platform: Linux

Description

v.buffer is creating wrong results around some edges.
try spearfish60: v.buffer input=rstrct_areas@PERMANENT output=rstr_buffered type=point,line,area layer=1 distance=1000 angle=0 scale=1.0 tolerance=0.01

see http://www.marcolechner.de/buffer_bug.png (selfsigned certificate from uni-freiburg.de to accept) or attached file
blue= spearfish rstrct_areas; green=v.buffer result; brown = correct buffer using fTools in QGIS buffering corresponding shapefile

Attachments (2)

buffer_bug.png (7.2 KB) - added by mlechner 9 years ago.
screenshot of buffer_bug described in ticket
vbuffer.png (15.1 KB) - added by hellik 8 years ago.

Download all attachments as: .zip

Change History (10)

Changed 9 years ago by mlechner

Attachment: buffer_bug.png added

screenshot of buffer_bug described in ticket

comment:1 Changed 9 years ago by hamish

Cc: rmatev added

yeah, this one has been around for ages. see also its very close relative bug #90, AIU it's the same bug in the cleaning code for areas. and there is Markus M's comments in #699 too.

the ditches area given midway through RT bug # 2765 is better now though, but I'm not sure about the example at the end of the old report. (note that bug was for the first grass6 v.buffer module)

http://intevation.de/rt/webrt?serial_num=2765

thanks for pointing out the simple test case. I can reproduce it on 32bit linux with current grass 6.5svn.

btw I've been sitting on an area I've got that makes the main cleaning steps place centroids wrong; I'll file that as another bug.

Hamish

comment:2 Changed 9 years ago by hamish

but I'm not sure about the example at the end of the old report.

that's another thin-area one which was fixed by the v.buffer2 replacement.

taking a hint from RT# 2765 I tried v.build.polylines on rstrct_areas and reran the test. interestingly the buffer comes out completely empty! (ah that is because cats are *completely* lost from centroids in that process!?.

moving the centroids of the 2 small NW polygons into their respective middles with v.digit didn't help. after assigning centroids in the v.build.polylines output map it still breaks but a bit differently. this time the big area looks ok.

we can simplify it back to a single 4 sided rectangle:

v.extract in=rstrct_areas out=rstrct_areas_cat4 list=4
v.buffer in=rstrct_areas_cat4 out=rstrct_areas_cat4_buf1000 dist=1000

which is:

B  5
 598239.59422707 4917334.78591833
 598255.01958824 4916224.77709862
 599657.47540894 4916247.27752886
 599645.08933166 4917345.07553359
 598239.59422707 4917334.78591833
C  1 1
 598825.31    4916714.37  
 1     4         

that NW corner fails even with distance=20, which makes me posture that it is an acute angle thing and not to do with the centroid.

Hamish

comment:3 Changed 9 years ago by hamish

ah..., moving the begin/end corner to the SW makes the SW corner buffer fail. so it's failing to join up the polygon / connecting lon=180E,W wrap style problem?

v.in.ascii out=rstarea4_rot form=standard -n << EOF
B  5
 598255.01958824 4916224.77709862
 599657.47540894 4916247.27752886
 599645.08933166 4917345.07553359
 598239.59422707 4917334.78591833
 598255.01958824 4916224.77709862
C  1 1
 598825.31    4916714.37  
 1     4 
EOF

Hamish

comment:4 Changed 9 years ago by hamish

Priority: majorcritical

ah..., moving the begin/end corner to the SW makes the SW corner buffer fail. so it's failing to join up the polygon / connecting lon=180E,W wrap style problem?

promoting this to priority="critical" in the hope that we can fix it before 6.4.0. Vector buffering is a bit of a core GIS function, so it would be good to have it working correctly..

Hamish

comment:5 Changed 9 years ago by hamish

Milestone: 6.4.06.4.1

comment:6 in reply to:  4 ; Changed 8 years ago by mmetz

Replying to hamish:

promoting this to priority="critical" in the hope that we can fix it before 6.4.0. Vector buffering is a bit of a core GIS function, so it would be good to have it working correctly..

A bit late for 6.4.0, hopefully fixed in r45198, r45200r, r45201 (6.4.1, 6.5, 7.0). It's now working for areas on Linux, I suspect different bugs on Mac and/or Windows.

Markus M

Changed 8 years ago by hellik

Attachment: vbuffer.png added

comment:7 in reply to:  6 Changed 8 years ago by hellik

Replying to mmetz:

Replying to hamish:

promoting this to priority="critical" in the hope that we can fix it before 6.4.0. Vector buffering is a bit of a core GIS function, so it would be good to have it working correctly..

A bit late for 6.4.0, hopefully fixed in r45198, r45200r, r45201 (6.4.1, 6.5, 7.0). It's now working for areas on Linux, I suspect different bugs on Mac and/or Windows.

Markus M

tested example above with WinGRASS-6.4.SVN-r45671-1-Setup.exe in winvista32. it seems to work (see attached screenshot). closing the ticket?

Helmut

comment:8 Changed 8 years ago by mmetz

Keywords: v.buffer2 added; v.buffer removed
Resolution: fixed
Status: newclosed
Summary: v.buffer creating wrong buffer around polygon edges.v.buffer2 creating wrong buffer around polygon edges.

Applied to v.buffer2 (fixed here), not v.buffer. Closing ticket.

Note: See TracTickets for help on using tickets.