[GRASS-dev] Re: [GRASS GIS] #699: v.buffer2 segfault: in Vect_get_isle_points() (was: v.buffer segfault: in Vect_get_isle_points())

[GRASS GIS]

#699: v.buffer2 segfault:  in Vect_get_isle_points()
----------------------+-----------------------------------------------------
  Reporter:  neteler  |       Owner:  grass-dev@…              
      Type:  defect   |      Status:  closed                   
  Priority:  normal   |   Milestone:  7.0.0                    
 Component:  Vector   |     Version:  6.4.0 RCs                
Resolution:  fixed    |    Keywords:  v.buffer                 
  Platform:  All      |         Cpu:  All                      
----------------------+-----------------------------------------------------
Changes (by mmetz):

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


Comment:

 Replying to [comment:23 hamish]:
 > Hi,
 >
 > I am really thankful for the progress, and have no objection, but before
 these plans are enacted and issues closed & forgotten about, I would think
 it to be a good idea to revisit the original ML threads re. reasons that
 v.buffer2 was written in the first place.
 >
 > http://intevation.de/rt/webrt?serial_num=2765
 >
 I tested the ascii vectors in this ticket, including the ditches_1205, all
 work fine, all troubles mentioned in this long thread seem to be solved.

 Unfortunately, the test data polygonmap and frame are no longer available,
 but then it seems that the ascii vectors available in the ticket where
 mainly used for testing and debugging.

 > I think there's another report focusing on v.parallel- I would check if
 the "inside corner" problem which was present in both (1) and (2) versions
 is indeed now fixed.

 Some tickets related to v.buffer/v.parallel/v.buffer2/v.parallel2 (it's
 not always clear which version is meant) are listed in comment 17 of this
 ticket, and solved for v.buffer/v.parallel, see comment 17. That includes
 the "inside corner" bug.

 >
 > I'm having trouble accessing the 2008 Summer of Code application, due I
 think to the recent re-vamp of the SoC website. But fwiw,
 {{{
 > 2008 Summer of Code
 > Reimplement And Add Features to Buffer Generation Module in GRASS
 > by Rosen Ivanov Matev, mentored by Wolf Bergenheim
 > http://thread.gmane.org/gmane.comp.gis.grass.devel/27534/
 > http://code.google.com/soc/2008/osgeo/about.html
 }}}
 >
 The ideas and concepts mentioned in these threads are surely convincing,
 but it really is a pity that Rosen Matev does not responds to these
 tickets. I fixed what I could for v.buffer2/v.parallel2, and would have
 preferred to get these working, but I reached a dead end. That is why I
 decided to go for the original version of Radim. If Rosen Matev would fix
 the library functions, I could fix the modules.
 >
 > but back to the old RT bug tracker bug #2765 re v.buffer1.. I think it
 is important to read through all that report before (re)activating; here's
 one snippet:
 {{{
 > [Apr 29 2007]
 > 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
 >
 > [...]
 >
 > http://bambi.otago.ac.nz/hamish/grass/bugs/bug2765.png
 > http://bambi.otago.ac.nz/hamish/grass/bugs/bug2765_zoom.png
 }}}
 >
 Have you tested? Buffering ditch_1205 works fine for me.

 I still opt for reactivating old v.buffer/v.parallel (already done for 6.5
 in r45837), but keeping the code for v.buffer2/v.parallel2 in the hope
 that this gets fixed at some stage, or used for some new
 v.buffer3/v.parallel3.

 I am closing this ticket because the two segfaults reported here related
 exclusively to v.buffer2 and not v.buffer, and I fixed these for
 v.buffer2. I would recommend a new ticket for further discussion of
 v.buffer/v.parallel vs. v.buffer2/v.parallel2.

 Markus M

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/699#comment:25>
GRASS GIS <http://grass.osgeo.org>