Hi all,
I was palying a bit with bug-trigering vector and You can see results
in attachments - setting buffer to 10m will give different buffer top,
setting buffer to 1 m will return more annoying result and stopping
buffer process before clean is visible in third image.
I also looked in v.buffer code, but my C skeelz are too lame to
undrstand it, but I noticed lot of comments with "TODO" and "Should
work like this". Also there is some stuff relaying on asumption, thath
some stuff is listed clockwise or counterclockwise, etc.
Also I was not able to create buffers for boundary, centroid. They are
listed in v.buffer man page but I do not see any code related to them
in v.buffer.
Hope more info will help,
Maris.
2007/2/5, Hamish <hamish_nospam@yahoo.com>:
> > 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.
Maciej wrote:
> 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.
>
> Hamish,
> 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
B 4
600727.68682251 5677973.32091602
600739.16582305 5678137.49568095
600736.32863997 5678140.4618269
600730.63832718 5678056.67823368
B 2
600730.63832718 5678056.67823368
600725.02385533 5677974.01131491
C 1 1
600730.04890192 5678035.56666655
1 1205
B 2
600727.68682251 5677973.32091602
600725.02385533 5677974.01131491
EOF
# 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:
"
v.buffer
--------
Completely rewrite if possible or at least fix the bug which is
probably in clean_parallel() in lib/vector/Vlib/buffer.c.
"
Hamish
[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]
(attachments)
