[GRASS-dev] Re: v.buffer creates artefact - bug?

[Maris Nartiss]

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 at 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]
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vbuffer_issue_10m.png
Type: image/png
Size: 14688 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070205/fe7a9ba7/vbuffer_issue_10m.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vbuffer_issue_1m.png
Type: image/png
Size: 13546 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070205/fe7a9ba7/vbuffer_issue_1m.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vbuffer_issue_4m_clean.png
Type: image/png
Size: 12641 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20070205/fe7a9ba7/vbuffer_issue_4m_clean.png