[GRASS-dev] Re: [bug #2765] (grass) v.buffer bug??
tutey at o2.pl
Sun Oct 8 10:27:16 EDT 2006
> 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 tried with tresh=1000. Nothing was modified (Removed dangles: 0
removed lines: 0).
> 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
Yes, we are using the same:
$ shoofi at sorbus:~/tmp$ md5sum vbuffer_bugs.tar.bz2
Very strange. Maybe it has something to do with the compiler used?
$ gcc -v
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
Or locale? I'm from Poland, where we use "," instead of "." for decimal
point delimiter. But how that would impact v.buffer I don't know - just
trying to think of *something*.
Does v.buffer depend on anything that could differ between your and my
system? I'm on Ubuntu Dapper 6.06, kernel 2.6.15-27-686. What is yours?
More information about the grass-dev