[GRASS-dev] [GRASS GIS] #3448: v.buffer -c native failure

GDAL · November 18, 2017, 1:35pm

#3448: v.buffer -c native failure
---------------------------------+-------------------------
Reporter: marisn | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.5.0
Component: Vector | Version: unspecified
Keywords: v.buffer v.parallel | CPU: Unspecified
Platform: Unspecified |
---------------------------------+-------------------------
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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3448>
GRASS GIS <https://grass.osgeo.org>

GDAL · November 18, 2017, 2:24pm

#3448: v.buffer -c native failure
--------------------------+---------------------------------
  Reporter: marisn | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 7.5.0
Component: Vector | Version: unspecified
Resolution: | Keywords: v.buffer v.parallel
       CPU: Unspecified | Platform: Unspecified
--------------------------+---------------------------------

Comment (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
}}}

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3448#comment:1>
GRASS GIS <https://grass.osgeo.org>

GDAL · November 18, 2017, 3:14pm

#3448: v.buffer native failures
--------------------------+---------------------------------
  Reporter: marisn | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 7.5.0
Component: Vector | Version: unspecified
Resolution: | Keywords: v.buffer v.parallel
       CPU: Unspecified | Platform: Unspecified
--------------------------+---------------------------------

Comment (by 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
}}}

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3448#comment:2>
GRASS GIS <https://grass.osgeo.org>

GDAL · August 22, 2018, 8:06pm

#3448: v.buffer native failures
--------------------------+---------------------------------
  Reporter: marisn | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.6.0
Component: Vector | Version: unspecified
Resolution: wontfix | Keywords: v.buffer v.parallel
       CPU: Unspecified | Platform: Unspecified
--------------------------+---------------------------------
Changes (by mmetz):

* status: new => closed
* resolution: => wontfix

Comment:

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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3448#comment:4>
GRASS GIS <https://grass.osgeo.org>

Blumentrath_Stefan1 · August 23, 2018, 11:39am

Hi Marcus,

I am not too familiar with C and the like so I might confuse some things here...

I noticed that using .buffer() in PyGRASS gives a lot of "using native format" output.

So I looked it up and it seems to be using native buffering (Vect_area_buffer2):
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/vector/geometry.py#L1654

And Vect_area_buffer2 is the non-geos buffering, right?
https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.buffer/main.c#L564

So, should then PyGRASS be changed/fixed to use geos buffering too?
Shall I open a ticket?

Cheers,
Stefan

-----Original Message-----
From: grass-dev <grass-dev-bounces@lists.osgeo.org> On Behalf Of GRASS GIS
Sent: onsdag 22. august 2018 22:07
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures

#3448: v.buffer native failures
--------------------------+---------------------------------
  Reporter: marisn | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 7.6.0
Component: Vector | Version: unspecified
Resolution: wontfix | Keywords: v.buffer v.parallel
       CPU: Unspecified | Platform: Unspecified
--------------------------+---------------------------------
Changes (by mmetz):

* status: new => closed
* resolution: => wontfix

Comment:

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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3448#comment:4>
GRASS GIS <https://grass.osgeo.org>

Markus_Metz · August 23, 2018, 3:20pm

On Thu, Aug 23, 2018 at 1:39 PM Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:

Hi Marcus,

I am not too familiar with C and the like so I might confuse some things here…

I noticed that using .buffer() in PyGRASS gives a lot of “using native format” output.

this “using native format” refers to the format of newly created vector maps (could also be OGR via v.external.out)

So I looked it up and it seems to be using native buffering (Vect_area_buffer2):

https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/vector/geometry.py#L1654

And Vect_area_buffer2 is the non-geos buffering, right?
https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.buffer/main.c#L564

So, should then PyGRASS be changed/fixed to use geos buffering too?

all vector buffering functions in the vector libs are GRASS native functions, only the module v.buffer uses GEOS buffering. That means you should use v.buffer instead of vector library functions.

Shall I open a ticket?

yes please, pygrass should use the module v.buffer, or GEOS functions

Markus M

Cheers,
Stefan

-----Original Message-----
From: grass-dev <grass-dev-bounces@lists.osgeo.org> On Behalf Of GRASS GIS
Sent: onsdag 22. august 2018 22:07
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures

#3448: v.buffer native failures
--------------------------±--------------------------------
Reporter: marisn | Owner: grass-dev@…
Type: defect | Status: closed
Priority: normal | Milestone: 7.6.0
Component: Vector | Version: unspecified
Resolution: wontfix | Keywords: v.buffer v.parallel
CPU: Unspecified | Platform: Unspecified
--------------------------±--------------------------------
Changes (by mmetz):

status: new => closed

resolution: => wontfix

Comment:

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.

–
Ticket URL: <https://trac.osgeo.org/grass/ticket/3448#comment:4>
GRASS GIS <https://grass.osgeo.org>

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Blumentrath_Stefan1 · August 23, 2018, 6:46pm

Thanks for the explanation.

Ticket created…

···