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

[Andreas_Lange_via_RT]

Hamish (and All),

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

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? 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.

Maciek

-------------------------------------------- Managed by Request Tracker

[H_B]

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

[Maciej_Sieczka2]

Hamish wrote:

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.

... and I still can't :|. Just extracted the very same package I just
sent you, done

$ v.buffer input=ditches output=ditches_buf1b type=area buffer=1

and the ditches_buf1 has the same artifact it had so far. When I "edit"
it the input vector ditches the way I described in previous email - the
buffer is created OK. Shoot me.

g.region ditches_buf

Which one is that?

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 ?

Don't think so. Even when I removed them centroids and their boundaries
altogether, the problem was still there - see the output of 'v.buffer
input=ditches output=ditches_buf1b type=area buffer=1' for such a case [1].

can you isolate the problem with:

g.region ditches_buf

Which one is that? It's not there in the package I sent you.

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"

Done that before, to no avail.

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..

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.

Would that mean v.buffer is supposed to work on some Linuces and not on
the other? That would be a nightmare.

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?

Sure, I tried many ways for cleaing the data and feeding it into
v.buffer. But only manually moving the vertex and snapping it back helps.

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

Yes it does:

$ v.out.ascii ditches format=standard | v.in.ascii format=standard
out=ditches2
$ v.buffer input=ditches2 output=ditches2_buf1 type=area buffer=1

Same old bug... [2].

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

Yes, they are islands.

The point might propably be about the boundaries of the problematic
area being recognized as snapped on your machine, while being
recognized as disjointed on my machine. That'd be nuts tough. Please
watch the swf at [3], where I present step-by-step the two runs of
v.buffer on the problematic dataset - before and after the required
"edit", including how the "edit" looks like. I'm just moving vertex of
a topologically clean boundary a bit and snapping it back. Strange...

Best,
Maciek

[1]1203_1204_removed.png
[2]after_through_asc.png
[3]http://kufaya.googlepages.com/buffer_boundary_issue.html

(attachments)

[H_B]

Maciej Sieczka wrote:

> g.region ditches_buf

Which one is that? It's not there in the package I sent you.

It is the saved region:

$ cat vbuffer_bugs/vbuffer_bugs/windows/ditches_buf
proj: 1
zone: 33
north: 5678240
south: 5677910
east: 600860
west: 600570
cols: 29
rows: 33
e-w resol: 10
n-s resol: 10
top: 1
bottom: 0
cols3: 33
rows3: 31
depths: 1
e-w resol3: 8.78787879
n-s resol3: 10.64516129
t-b resol: 1

> can you isolate the problem with:

..

> v.select ain=ditches bin=problem_box out=problem_areas
> v.out.ascii format=standard in=problem_areas

..

Done that before, to no avail.

clearer: if you can extract it to a few simple areas & export with
v.out.ascii it is easier to follow step by step in the debugger. Also
you can post that to the bug's history and others can try without
needing you to send them the 1mb location download- more data points.

>> '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.

Would that mean v.buffer is supposed to work on some Linuces and not
on the other? That would be a nightmare.

I don't know. It is just a guess of why our two systems would be
different. I am testing with a Pent4 32bit debian/stable machine.
Is yours 64bit? v.buffer will try and do the same calculation, but the
computer may give a slightly different results. That will happen with
any 32bit and 64bit system doing FP math, with any program. It would be
a v.buffer bug if e.g. if it tests FP1==FP2 when it should test
"fabs(FP2-FP1) <= EPSILON"

The point might propably be about the boundaries of the problematic
area being recognized as snapped on your machine, while being
recognized as disjointed on my machine. That'd be nuts tough.

does "d.what.vect -f" (or without -f check area size) show the original
as a closed area?

Please watch the swf at [3], where I present step-by-step the two runs
of v.buffer on the problematic dataset - before and after the required
"edit", including how the "edit" looks like. I'm just moving vertex of
a topologically clean boundary a bit and snapping it back. Strange...

sorry, I don't have flash installed. But I trust you are honest and we
have tried the same commands

Hamish