[GRASS-dev] Re: [bug #2765] (grass) v.buffer bug??

Hamish hamish_nospam at yahoo.com
Sun Oct 8 07:21:49 EDT 2006

Maciej Sieczka wrote:
> I have tried your recent patch you sent.
> It improves things a bit, but doesn't solve the bug yet. See the
> attached screndumps. These are xcf files, so you extract the v.buffer
> syntax used from them.
> As you can see the 4m (buf4.xcf) buffer of my ditches looks kindoff
> better - there is no single bulge now, but a buffered ditch. The
> problems are that the buffer width is not 4m as declared, but circa 1m
> and there is a half-bulge on the left side and some artifact at the
> top-left.
> In case of the 1m buffer (buf1.xcf) there is no change at all when
> compared to the previous result.
> If you still have the sample Grass location (vbuffer_bugs) I sent you
> please try reproducing these.

patch applied to 6.3-cvs and 6.2 branch.

square_rot_buf30 is fixed.
ditch_1188 is fixed.

1 and 4m buffer around ditches seem to work fine for me, but they did
before the patch. (?)  (command taken from "v.info -h ditches_buf1")

I still see the "holes get filled" bug in my own data though,
 (v.buffer in=roads bufcol="LANE_COUNT")

so that one's still open.

I seem to remeber Radim commenting on this a long time ago, here we go,
complete with screenshots:

This is probably the same bug in v.buffer as you see and nothing to do
with buffcol= (??).

Ahh, I've got you now Obi Wan, the interior-fill bug happens when there
is an interior dangle in my road network ... and I've isolated it to a
vector made up of 10 polylines.

can you try buffering your ditches after
  v.clean tool=rmdangle thresh=[big]

I don't understand why you consistently get the error, and I
don't, using the same* dataset.  [*] are we really using the same data?

md5sum vbuffer_bugs.tar.bz2
d229fb3e5724acb7bf6314d940fc4def  vbuffer_bugs.tar.bz2


More information about the grass-dev mailing list