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

[Dylan Beaudette]

On Tuesday 30 January 2007 13:48, Maciej Sieczka wrote:
> 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
>

Hi Maciek,

I just tried it with a fairly recent CVS build and got the same result that 
you did (i.e. the bad one).

Cheers,


-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341