Opened 3 years ago

Closed 2 years ago

#3448 closed defect (wontfix)

v.buffer native failures

Reported by: marisn Owned by: grass-dev@…
Priority: normal Milestone: 7.6.0
Component: Vector Version: unspecified
Keywords: v.buffer v.parallel Cc:
CPU: Unspecified Platform: Unspecified

Description

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

Change History (4)

comment:1 Changed 3 years ago by 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

comment:2 Changed 3 years ago by marisn

Summary: v.buffer -c native failurev.buffer native failures

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

comment:3 Changed 3 years ago by martinl

Milestone: 7.5.07.6.0

Milestone renamed

comment:4 Changed 2 years ago by mmetz

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.