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

[Maciej Sieczka]

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