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

[Maris Nartiss]

Hi Maciej,

I imported both ascii snippets with v.in.ascii -n format=standard and
they looked like same. Created buffer with size=1 and type=area.
Results where same as in my previous tests. For first ascii snippet, I
got shrinked vector area (like removed vector from inside of area)
plus the mystic circle in middle. Second one - good order - worked as
expected - I got correct buffer.

It seems, that v.buffer expects some features to be in right
order(tm). Next thing to find is it v.buffer specific or it's a design
failure in V_lib. As I wrote already, v.* code is a bit more complex
than I can understand - no help form me, just testing.

I will recompile my GRASS too with -g CFLAG and repeat test. If result
will differ, I will report.

Maris.

2007/2/7, Maciej Sieczka <tutey at o2.pl>:
> Maris,
>
> Maris Nartiss wrote:
> > 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.
>
> I suppose this last thing might matter. Please note that the following
> ASCII vector is buffered bad (it's the one you have already tested, the
> infamous ditch_1205):
>
> 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
>
> While it's slightly different version (same coordinates, but a
> different order of vertices - it's well visible in meld/kdif/xdiff) is
> buffered fine.
>
> 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
> B  4
>  600727.68682251 5677973.32091602
>  600739.16582305 5678137.49568095
>  600736.32863997 5678140.4618269
>  600730.63832718 5678056.67823368
>
> Can you try that?
>
> > 2007/2/5, Hamish <hamish_nospam at yahoo.com>:
>
> >> 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.
>
> I will try that tomorrow anyway. Who knows.
>
> Maciek
>