[GRASS-dev] Re: [bug #2765] (grass) v.buffer bug??
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
> 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?
More information about the grass-dev