v.buffer2 creating wrong buffer around polygon edges.

[mlechner]

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

[mlechner]

screenshot of buffer_bug described in ticket

[hamish]

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

[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

[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

[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?

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

[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

[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

[mmetz]

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