#994: v.buffer creating wrong buffer around polygon edges.
-------------------------+--------------------------------------------------
Reporter: mlechner | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: 6.4.0 RCs
Keywords: v.buffer | Platform: Linux
Cpu: Unspecified |
-------------------------+--------------------------------------------------
v.buffer is creating wrong results around some edges.[[BR]]
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[[BR]]
blue= spearfish rstrct_areas; green=v.buffer result; brown = correct
buffer using fTools in QGIS buffering corresponding shapefile
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.
> 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.
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?
> 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..
Replying to [comment:4 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.
Replying to [comment:6 mmetz]:
> Replying to [comment:4 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?
