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

[Hamish]

Hi,

WRT bug #2765, v.buffer errors--
  https://intevation.de/rt/webrt?display=History&serial_num=2765


example of vector shape that doesn't get buffered correctly:

GRASS> v.in.ascii out=ditch_1205 form=standard -n << EOF
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
EOF

# and then:
GRASS> v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
GRASS> v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4

 

I now have a machine where it fails for me, so some more debug info
to share:

The problem is in lib/vector/Vlib/buffer.c  clean_parallel()
(no big surprise there)

Vect_line_buffer() calls Vect_line_parallel() for side 1, 

Vect_line_parallel() calls parallel_line() then clean_parallel(),

clean_parallel() creates a centroid in the buffered area, then tests to
see if the new centroid is in the ORIGINAL (smaller) area. In some
cases, the centroid will be within the buffered area, but outside the
original area.

here's a picture and zoom:
  http://bambi.otago.ac.nz/hamish/grass/bugs/bug2765.png
  http://bambi.otago.ac.nz/hamish/grass/bugs/bug2765_zoom.png

since the point is outside the area, that section of the buffer is
thrown away and we get a bad result.
[in point_in_buf()  (sd=15.140885 <= d=16.000000) so it returns 1]

actually the erring function is not called point_in_polygon(), it is
called point_in_buf():
	/* is loop in buffer ? */
	if ( point_in_buf( origPoints, px, py, d )  ){

but it is testing vs. origPoints (original shape to be buffered) not
the to-be-cleaned buffer area ??? so not doing "point_in_buf" at all.

I am not sure how to fix that.


see also the note by me in the bug report dated Tue, Oct 10 2006.

other notes:
 * v.build.polylines on the original shape fixes it (this time)
 * buffer distance in the cleaning step when using bufcol= param is
   also buggy. (only uses the last buffer size value loaded)



Hamish