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

GRASS GIS GRASS GIS developer
1

Hi Hamish,

Thanks for working on this bug!

I have tried your recent patch you sent.

It improves things a bit, but doesn't solve the bug yet. See the
attached screndumps. These are xcf files, so you extract the v.buffer
syntax used from them.

As you can see the 4m (buf4.xcf) buffer of my ditches looks kindoff
better - there is no single bulge now, but a buffered ditch. The
problems are that the buffer width is not 4m as declared, but circa 1m
and there is a half-bulge on the left side and some artifact at the
top-left.

In case of the 1m buffer (buf1.xcf) there is no change at all when
compared to the previous result.

If you still have the sample Grass location (vbuffer_bugs) I sent you
please try reproducing these.

Maciek

(attachments)

v_buffer_hamishfixes.tar.bz2 (10.6 KB)

2

Maciej Sieczka wrote:

I have tried your recent patch you sent.

It improves things a bit, but doesn't solve the bug yet. See the
attached screndumps. These are xcf files, so you extract the v.buffer
syntax used from them.

As you can see the 4m (buf4.xcf) buffer of my ditches looks kindoff
better - there is no single bulge now, but a buffered ditch. The
problems are that the buffer width is not 4m as declared, but circa 1m
and there is a half-bulge on the left side and some artifact at the
top-left.

In case of the 1m buffer (buf1.xcf) there is no change at all when
compared to the previous result.

If you still have the sample Grass location (vbuffer_bugs) I sent you
please try reproducing these.

patch applied to 6.3-cvs and 6.2 branch.

square_rot_buf30 is fixed.
ditch_1188 is fixed.

1 and 4m buffer around ditches seem to work fine for me, but they did
before the patch. (?) (command taken from "v.info -h ditches_buf1")

I still see the "holes get filled" bug in my own data though,
(v.buffer in=roads bufcol="LANE_COUNT")

so that one's still open.

I seem to remeber Radim commenting on this a long time ago, here we go,
complete with screenshots:
  http://grass.itc.it/pipermail/grass-dev/2005-November/020133.html
  http://grass.itc.it/pipermail/grass-dev/2005-November/020136.html
  http://thread.gmane.org/gmane.comp.gis.grass.devel/9506

This is probably the same bug in v.buffer as you see and nothing to do
with buffcol= (??).

Ahh, I've got you now Obi Wan, the interior-fill bug happens when there
is an interior dangle in my road network ... and I've isolated it to a
vector made up of 10 polylines.

can you try buffering your ditches after
  v.clean tool=rmdangle thresh=[big]
?

I don't understand why you consistently get the error, and I
don't, using the same* dataset. [*] are we really using the same data?

md5sum vbuffer_bugs.tar.bz2
d229fb3e5724acb7bf6314d940fc4def vbuffer_bugs.tar.bz2

Hamish

3

Hamish wrote:

patch applied to 6.3-cvs and 6.2 branch.

square_rot_buf30 is fixed.

Confirmed. Great!

ditch_1188 is fixed.

Confirmed. Yay.

1 and 4m buffer around ditches seem to work fine for me, but they did
before the patch. (?) (command taken from "v.info -h ditches_buf1")

I still see the "holes get filled" bug in my own data though,
(v.buffer in=roads bufcol="LANE_COUNT")

so that one's still open.

I seem to remeber Radim commenting on this a long time ago, here we go,
complete with screenshots:
  http://grass.itc.it/pipermail/grass-dev/2005-November/020133.html
  http://grass.itc.it/pipermail/grass-dev/2005-November/020136.html
  http://thread.gmane.org/gmane.comp.gis.grass.devel/9506

This is probably the same bug in v.buffer as you see and nothing to do
with buffcol= (??).

Ahh, I've got you now Obi Wan, the interior-fill bug happens when there
is an interior dangle in my road network ... and I've isolated it to a
vector made up of 10 polylines.

can you try buffering your ditches after
  v.clean tool=rmdangle thresh=[big]

I tried with tresh=1000. Nothing was modified (Removed dangles: 0
removed lines: 0).

I don't understand why you consistently get the error, and I
don't, using the same* dataset. [*] are we really using the same data?

md5sum vbuffer_bugs.tar.bz2
d229fb3e5724acb7bf6314d940fc4def vbuffer_bugs.tar.bz2

Yes, we are using the same:
$ shoofi@sorbus:~/tmp$ md5sum vbuffer_bugs.tar.bz2
d229fb3e5724acb7bf6314d940fc4def vbuffer_bugs.tar.bz2

Very strange. Maybe it has something to do with the compiler used?

$ gcc -v
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

Or locale? I'm from Poland, where we use "," instead of "." for decimal
point delimiter. But how that would impact v.buffer I don't know - just
trying to think of *something*.

Does v.buffer depend on anything that could differ between your and my
system? I'm on Ubuntu Dapper 6.06, kernel 2.6.15-27-686. What is yours?

Maciek

4

Hamish wrote:
> I still see the "holes get filled" bug in my own data though,

..

> Ahh, I've got you now Obi Wan, the interior-fill bug happens when
> there is an interior dangle in my road network ... and I've isolated
> it to a vector made up of 10 polylines.

attached are instructions for recreating the bug with a simplified set
of lines which trigger it. ("v.clean tool=prune" worked well!)

Things start to go wrong in Vect_break_lines(): the island (hole) in the
middle of the area (test with d.what.vect) becomes an area, so then
area_in_buffer() loops through it as a real overlapping area. Then the
island's centroid is nearer to a boundary than the buffer distance,
which lets it pass the test. Perhaps area_in_buffer() could test cw vs
ccw side of polygon to solve this?

I get the same results if I stop v.buffer with debug=buffer and run
"v.clean tool=break".

also in the Vect_break_lines() step it goes from 8 boundaries to 167,
so I can't later pass a stored buffer value for each of the 8 buffers to
the area_in_buffer() test (but this may not be important if it knows
that the island isn't an area in the first place). It's still a bug that
the dynamic buffer size area_in_buffer() uses the last buffer &
tolerance loaded for post-processing, as I've noted in the source.

> I don't understand why you consistently get the error, and I
> don't, using the same* dataset.

..

Very strange. Maybe it has something to do with the compiler used?

$ gcc -v
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

Or locale? I'm from Poland, where we use "," instead of "." for
decimal point delimiter. But how that would impact v.buffer I don't
know - just trying to think of *something*.

Does v.buffer depend on anything that could differ between your and my
system? I'm on Ubuntu Dapper 6.06, kernel 2.6.15-27-686. What is
yours?

No idea. I'm using Debian/Sarge, gcc 3.3.5, linux 2.4.27-3-686 on a P4.

Can you try running
  v.buffer ditches buffer=4 debug=buffer
? and have a look at the output with d.vect and d.what.vect ?
maybe some clues/hope there.

Hamish

(attachments)

vbuf_fill_bug.txt (2.3 KB)

5

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

just to recap on the current status of the bug:

if you buffer a polygon which contains a interior dangle that is near
the middle of the area, one of the cleaning steps* makes a mistake and
thinks the temporary island centroid is within the buffered polygon.
This happens when the distance to the (exterior) centroid is within the
buffer distance to the dangle's new buffered boundary.
(see attached pic)

[*] area_in_buffer() {first test} in vector/v.buffer/main.c

in hind sight I think Vect_break_lines() is working correctly. The
original unbroken boundaries are on top of each other, but do not
"touch", so interior area has a path out. After breaking lines at
intersections the map is "flat" and there is no way out. (think
"flatten layers" in gimp)

buffer distance in the cleaning step when using bufcol= param is also
buggy. (only uses the last buffer value loaded)

Hamish

(attachments)

vbuff_fill_bug.png