v.buffer native failures

[marisn]

GRASS native buffering methods are known to fail. Here is a test data for "no cap" case producing some strange output.

v.in.ascii -n in=- out=test_line format=standard << EOF
L 4
 3 4
 6 4
 7 3
 7 2
EOF
v.buffer input=test_line output=test_butt distance=2 -c

Related bugs (those might not be duplicates!): #2531 #1244 #1231 #90

[marisn]

And here is test case for ordinary (round cap) buffer failure:

v.in.ascii -n in=- out=test_line2 format=standard << EOF
L 4
 6 4
 7 3
 7 2
 8 1
EOF
v.buffer input=test_line2 output=test_buff2 distance=2

[marisn]

It also fails in case when a line forms a closed loop (line is buffered only from one side!):

v.in.ascii -n in=- out=test_loop format=standard << EOF
L 9
 2 2
 2 8
 6 7
 3 7
 3 3
 7 3
 7 6
 8 2
 2 2
EOF
v.buffer input=test_loop output=loop_buf distance=0.2
v.buffer input=test_loop output=loop_sharp distance=0.2 -s

[martinl]

Milestone renamed

[mmetz]

This is a long known issue and the reason why v.buffer uses GEOS buffering. GRASS native buffering will probably not be fixed because GEOS buffering is working, thus closing as won't fix.