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

GRASS GIS GRASS GIS developer
1

hamish_nospam@yahoo.com wrote (Mon, Sep 11 2006 04:14:07):

Maciek:

square_rot

Notice this is not a square of four corners!

Why the "!", actually?

If you zoom in you find it contains 229 vertices, i.e. this is r.to.vect
output with steps at the grid resolution. So not as easy to debug by hand

OK. But this doesn't mean buffering it should be buggy, right?

ditches

I couldn't recreate your buff=1 and 4 errors- buffering works fine for
me there.

I'm wondering why, because I can perfecetly reproduce the bug at any time with
exactly the data I sent you.

Are you absolutely sure that the output of following v.buffer commands:

v.buffer input=ditches output=ditches_buf1 type=area buffer=1
v.buffer input=ditches output=ditches_buf4 type=area buffer=4

looks all OK after you zoom to region 'ditches_buf' included in my sample dataset?

For me it's obvious that the output is plain wrong.

Maciek

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

2

this bug's URL: http://intevation.de/rt/webrt?serial_num=2765

> Maciek:
>> square_rot

> Notice this is not a square of four corners!

Why the "!", actually?

> If you zoom in you find it contains 229 vertices, i.e. this is
> r.to.vect output with steps at the grid resolution. So not as easy
> to debug by hand

OK. But this doesn't mean buffering it should be buggy, right?

This is significant as the bug appears on a complex polygon, not a
simple 4 vertex square as it appeared on first look.

>> ditches

> I couldn't recreate your buff=1 and 4 errors- buffering works fine
> for me there.

I'm wondering why, because I can perfecetly reproduce the bug at any
time with exactly the data I sent you.

Are you absolutely sure that the output of following v.buffer
commands:

v.buffer input=ditches output=ditches_buf1 type=area buffer=1
v.buffer input=ditches output=ditches_buf4 type=area buffer=4

looks all OK after you zoom to region 'ditches_buf' included in my
sample dataset?

For me it's obvious that the output is plain wrong.

attached is a screenshot of the original vector in "aqua" on top of the
1 and 4 meter buffers I've just created.

looking at "v.info -h" I see that I did load it into v.digit to have a
look at the topology. I've tried again with a fresh copy of the mapset,
same (good) results. I don't know why it would be different- but for me
that works.

But it doesn't matter -- I was looking for a simple example of it going
wrong and I think I've found one:

Can you try buffering this simple polygon and see if it works correctly
for you? (I used a 10m buffer) If we can fix the bug causing that,
maybe your area filling bug will go away too.
("v.in.ascii -n format=standard")

B 26
600039.02641686 5678405.3999173
600077.97320276 5678399.62882899
600086.74267773 5678396.53372018
600165.15210099 5678369.45151806
600169.2571522 5678367.86458082
600321.12416744 5678313.92598028
600329.91897615 5678321.23595115
600333.66876785 5678318.50222813
600324.59956919 5678312.02422909
600321.23100969 5678310.98774925
600167.57287245 5678364.49602132
600085.45304905 5678392.66483416
600077.19942555 5678396.27579444
600036.44715953 5678401.36982765
600030.38590477 5678402.27256772
600010.78354895 5678405.62560227
599996.21074494 5678408.39830396
599987.18334424 5678410.71963557
599979.96142368 5678412.00926424
599968.01258083 5678413.77867984
599954.94262744 5678414.84644733
599949.52618701 5678419.48911054
599968.61269136 5678418.4574076
599998.40311369 5678411.75133851
600001.62800241 5678411.19452149
600039.02641686 5678405.3999173
C 1 1
600232.43677669 5678342.9534263
1 1188

Hamish

(attachments)

ditches014.png

3

Hamish wrote:

Maciek wrote:

Are you absolutely sure that the output of following v.buffer
commands:

v.buffer input=ditches output=ditches_buf1 type=area buffer=1
v.buffer input=ditches output=ditches_buf4 type=area buffer=4

looks all OK after you zoom to region 'ditches_buf' included in my
sample dataset?

For me it's obvious that the output is plain wrong.

attached is a screenshot of the original vector in "aqua" on top of the
1 and 4 meter buffers I've just created.

Wow, this looks OK indeed. Look at my buf_bugs.png screenshot of the
same area - red is 4m buffer, green is 1m buffer. Both are all wrong.
I wonder how such a difference between your and my results is possible.

But it doesn't matter -- I was looking for a simple example of it going
wrong and I think I've found one:

Can you try buffering this simple polygon and see if it works correctly
for you? (I used a 10m buffer) If we can fix the bug causing that,
maybe your area filling bug will go away too.

I tried. You can see the result of buffering at 10m on the attached
screendumps:

hamish_area.png - your input area
hamish_area_buf10.png - 10m buffer
hamish_area_both.png - both, overlayed

The 10m buffer is wrong. I'm curious if you obtain *the same* wrong buffer.

Maciek

(attachments)

buf_bugs.png
hamish_area.png
hamish_area_buf10.png
hamish_area_both.png

4

Maciej Sieczka wrote:

Wow, this looks OK indeed. Look at my buf_bugs.png screenshot of the
same area - red is 4m buffer, green is 1m buffer. Both are all wrong.
I wonder how such a difference between your and my results is
possible.

Unless "ditches" is slightly different, I don't know. The 4m buffer blob
seems to me to be the same disease as the lump in "my" area.

maybe try v.build.polyline?

> But it doesn't matter -- I was looking for a simple example of it
> going wrong and I think I've found one:

> Can you try buffering this simple polygon and see if it works
> correctly for you? (I used a 10m buffer) If we can fix the bug
> causing that, maybe your area filling bug will go away too.

I tried. You can see the result of buffering at 10m on the attached
screendumps:

hamish_area.png - your input area
hamish_area_buf10.png - 10m buffer
hamish_area_both.png - both, overlayed

The 10m buffer is wrong. I'm curious if you obtain *the same* wrong
buffer.

I get identical results, which is reassuring. (this is cat #1188 or so
from the 'ditches' map)

Hamish

5

Hamish wrote:

Maciej Sieczka wrote:

Wow, this looks OK indeed. Look at my buf_bugs.png screenshot of the
same area - red is 4m buffer, green is 1m buffer. Both are all wrong.
I wonder how such a difference between your and my results is
possible.

Unless "ditches" is slightly different, I don't know.

My "ditches" is *identical* to what I sent you. Very strange.

The 4m buffer blob
seems to me to be the same disease as the lump in "my" area.

maybe try v.build.polyline?

v.build.polylines is buggy, especially for closed lines like area
boundaries:

http://intevation.de/rt/webrt?serial_num=4249
http://intevation.de/rt/webrt?serial_num=4247

and I avoid using it - not to screw my data.

But it doesn't matter -- I was looking for a simple example of it
going wrong and I think I've found one:
Can you try buffering this simple polygon and see if it works
correctly for you? (I used a 10m buffer) If we can fix the bug
causing that, maybe your area filling bug will go away too.

I tried. You can see the result of buffering at 10m on the attached
screendumps:

hamish_area.png - your input area
hamish_area_buf10.png - 10m buffer
hamish_area_both.png - both, overlayed

The 10m buffer is wrong. I'm curious if you obtain *the same* wrong
buffer.

I get identical results, which is reassuring. (this is cat #1188 or so
from the 'ditches' map)

Some good news! Do you maybe have an idea how to fix that?

Maciek

6

Maciej Sieczka wrote:

> I get identical results, which is reassuring. (this is cat #1188 or
> so from the 'ditches' map)

Some good news! Do you maybe have an idea how to fix that?

The loop processing segments sa and sb in clean_parrallel() wraps back
to the first segment, and the bug resets the number of points based on
the last segment seen (ie sa back to "0"), not the maximum number of
points added to the output group. (see debug output in bug history)

(clean_parallel() is in lib/vector/Vlib/buffer.c)

Hopefully that is enough of a clue for someone to find a solution. I
won't have any time to work on it for the next week or two, but would
like to see this fixed and tested for the 6.2.0 release.

Hamish