Hamish wrote:
Düster Horst wrote:
When I buffer the attached line layer with 250 mapunits I get an
unsiutable result. Take a look of the buffer_error.png image. You will
see that the line at the mean right wasn't buffered correct. To
reproduce this behavior I attach the original line layer.GRASS-6.1.0
This is a known bug, see the BUGS section in the v.buffer help page.
Work-around 1: make a buffer half the size, then buffer the result a
second time.
That is (too)often not a solution. v.buffer is buggy in an
unpredictable way.
See the attached screendumps.
ditches.png is a dump of my vector 'ditches'. It is an all OK vector,
1-2m wide, topologically clean areas, each with categories and
attributes. See how it is buffered in 2 next cases (metric projection):
ditches_buf_1m.png is an output of:
v.buffer input=ditches output=ditches_buf_1m type=area buffer=1
ditches_buf_4m.png is an output of:
v.buffer input=ditches output=ditches_buf_4m type=area buffer=4
Work-around 2: v.to.rast, r.buffer, r.to.vect
Luckily this works as supposed to, but is not always appropriate. Take
this case of mine for example - creating a nice 1m or 0.5m raster
buffer around my 'ditches' takes going down to an extremely high
resolution=long processing time, and no matter how high the res the
result is never as good as it could be with v.buffer bug-free.
Not only buffering areas is buggy. Buffering lines is as much
unpredictable. See:
http://www.biol.uni.wroc.pl/sieczka/udostepnione/grass/corrupted_buffer_of_a_line.png
(background for this dump is explained in
http://intevation.de/rt/webrt?serial_num=2765)
Stating the obvious, no reliable buffering for vectors in Grass is a
dramatic problem.
Maciek
(attachments)
