[GRASS-user] Re: v.buffer creates artefact - bug?
hamish_nospam at yahoo.com
Mon Feb 5 04:47:43 EST 2007
> > Hamish said it was not reproducible on his "Debian/Sarge, gcc 3.3.5,
> > linux 2.4.27-3-686 on a P4".
> > Maybe GCC version makes the difference? I'll try GCC 3 when
> > possible.
> So I did, gcc 3.3.6 on Ubunutu 6.06 32bit Pentium M. No good. Exactly
> the same bug crops out as with gcc 4.03.
> Are you still not able to reproduce this? You might be holding the key
> to a fix.
AFAIR, we were able to isolate it to this polygon shape:
# (working in Spearfish)
GRASS> v.in.ascii out=ditch_1205 form=standard -n << EOF
C 1 1
# and then:
GRASS> v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
GRASS> v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4
Doing this with current CVS both ditch_1205_b1 and ditch_1205_b4 look
totally normal for me. So I still can't recreate it. shrug.
This probably isn't it, but I use CFLAGS="-g" to compile in debug info,
which I think has the side effect of initing all memory to 0's which
changes the expression of some memory bugs.
-note there is another extant bug in v.buffer I do know the cause of-
(but not a solution)
If you have lines shaped like an "E" or an "M", the resulatant buffered
area has a good chance of placing the new area's centroid very close to
a line feature. One of the "is it real" tests v.buffer/main.c does is
to check the distance from a centroid to the line feature, and in this
case the line pokes into the middle of the area so the distance will be
very small and the test returns incorrect results.
Also note that Radim often suggested that v.buffer should be rewritten
from scratch-- doc/vector/TODO:
Completely rewrite if possible or at least fix the bug which is
probably in clean_parallel() in lib/vector/Vlib/buffer.c.
[I've little spare time to keep up with the mailing lists right now, so
sorry for any delayed/missed responses; be sure bug #2765 gets updated if
you find a good clue]
More information about the grass-user