[GRASS-user] v.buffer creates artefact - bug?

[Maciej Sieczka]

Markus Neteler wrote:
> Wolfgang Qual wrote on 01/30/2007 11:18 AM:

>> I am using GRASS 6.1 CVS and created a buffer around a line theme
>> using the buffcol and buffer option. The result can be loaded into
>> QGIS and it looks good, except some strange points (artefacts?). I
>> could provide a screenshot of this (is there a place on the Wiki for
>> this purpose?).

> after offlist communication with Wolfgang this is most likely a QGIS/QT
> rendering bug as already known from: http://svn.qgis.org/trac/ticket/83

v.buffer was fixed a lot in last months, mainly by Hamish. Many thanks
to him! And it works mostly OK these days. I'm saying almost - because
there is still a strange error that I can reproduce always and Hamish
cannot, although we are using exactly same data. We asked GRASS Folks
to try to reproduce that too, but there was no feedback. So let me ask
you All again:

1. Grab the location:
http://kufaya.googlepages.com/vbuffer_issue.tar.bz2

There is only one vector 'ditch_1205' in mapset 'ditch'. Please buffer
it with:
v.buffer in=ditch_1205 out=ditch_1205_buf4 type=area buffer=4

2. Please drop a line in this thread whether your output looks like
this (OK, Hamish's case):
http://kufaya.googlepages.com/ditch_1205_edt_b4.png

or this (bad, my case):
http://kufaya.googlepages.com/ditch_1205_b4.png

With any thoughts on what is going on here.

This will maybe give us some hint why on Earth exactly the same
command, same v.buffer version and same input data yield different
results for me and Hamish.

For me, in order to achieve the same result as Hamish does, I have to
edit the 'ditch_1205' in v.digit, by disconnecting the snapped boundary
and connecting it back, like:

http://kufaya.googlepages.com/ditch_1205_edt1.png
http://kufaya.googlepages.com/ditch_1205_edt2.png
http://kufaya.googlepages.com/ditch_1205_edt3.png

This is nuts, because before and after the "edit" the vector remains
topologicaly clean and perfectly the same, *besides* the order in which
boundaries are listed, if you look at the output of 'v.out.ascii
ditch_1205_edt form=standard' before and after v.digit "session" as
outlined on the 3 pics above. And the strangest thing is that Hamish
doesn't need to do this edit for v.buffer to work properly, while I do.

Please look into the http://intevation.de/rt/webrt?serial_num=2765 for
details, the message on Sun, Nov 26 2006 22:38:08 especialy.

Maciek