[GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results

[Hamish]

Maciek Sieczka via RT wrote:
>
> I have revisited this bug and I think I know why you, after your
> fixes, were able to produce correct buffers using my 'ditches' vector,
> while I was still obtaining errors (though somewhat different than at
> the beginning, before your fixes).
> 
> step-by-step:
> 
> 1. unpack the bzipped testing location I have sent you
> 
> 2. enter the location - don't touch anything yet!
> 
> 3. v.buffer input=ditches output=buf1 type=area buffer=1
> 
> 4. display 'buf1'; you should see the wrong buffer around the parcel
> that has cat 1205 in the 'ditches' vector - as I did

Nope, I still get correct output the first time.

g.region ditches_buf
d.vect buf1
d.vect ditches col=blue cats=1205
d.vect ditches col=red cats=1203
d.vect ditches col=yellow cats=1204

maybe it has to do with the 1203,1204 ?

can you isolate the problem with:

g.region ditches_buf
v.in.region problem_box
v.select ain=ditches bin=problem_box out=problem_areas
v.out.ascii format=standard in=problem_areas
v.in.ascii
v.buffer

?
e.g. is there a single boundary line between 1203,1204 or two (slightly
not touching) boundary lines?  "v.clean tool=rmdupl"


> 5. now, open 'ditches' in v.digit, pan to where cat 1205 is and
> disjoin it's boundary, and the snap the vertiices back as they were
> originally
>
> 6. v.buffer input=ditches output=buf1_new type=area buffer=1
> 
> 'buf1_new' is OK! - although the command in point 3. and 5. is
> identical, and although the input data haven't changed a bit - only
> one vertex was moved, but snapped back to it's original position
> immadietly.
> 
> I have no idea why it is like that. Hamish, can you reproduce that?

no..

> Does this explain how the same data worked for you but not for me?
> 
> Strange. The input vector in both cases is virtually the same, in both
> it is topologicall, error free (according to v.build, v.clean and
> visuall inspection in v.digit). But somehow, moving one vertex
> slightly and snapping it back "fixes" the vector so that v.buffer can
> handle it OK.
> 
> 'ditches' was hand digitised by me in QGIS 0.74, few months ago.

maybe it is a FP epsilon problem, which is slightly different machine to
machine + compiler to compiler? e.g. 123.4000000000002 vs 123.4.

You mention no errors with these, but did you try running v.buffer with
the output of v.build and v.clean or just see there was no error reported?

does the error survive v.out.ascii form=standard + v.in.ascii form=standard?

I see in the buffering output there are 7 areas without centroids, but I
wonder if these are just "islands" (holes) within areas?


Hamish