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

[GRASS GIS]

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

Comment(by mmetz):

 Replying to [comment:18 hamish]:
 > I'm super glad of the progress here. Before we go much further I think
 it would be a good idea to go back to the mailing list archives (and
 private emails) and re-read the threads discussing the specific issues
 which lead to the creation of v.buffer2/v.parallel2 in the first place,
 and revisit them to see if those issues are now addressed. Radim's vector
 TODO list talked about it as well.
 >
 > I just want to be sure we're betting on the right horse and aren't going
 to run back into the same previously discovered fatal flaws that we've
 forgotten about.
 >
 The most serious bug I am aware of was that cleaning would not work with
 the buffer column option, i.e. if different lines/areas are buffered with
 different distances. This has been fixed in v.buffer2, but the
 implementation in vbuffer2 is both using lots of memory and is very slow.
 The new v.buffer (r45833) uses much less memory and is much faster. The
 entire nc_spm railroad map is now buffered in less than 2 minutes (see
 also comment 16). There are still some special cases where the results of
 v.buffer/v.parallel can be improved, but their results are IMHO far better
 than v.buffer2/v.parallel2.

 > I've been meaning to do this dig myself for some weeks as I remember
 bits of it, but time has been against me lately.
 >
 > mmetz:
 > > Umh, and v.buffer is up to 10x faster and easier to maintain than
 > > v.buffer2...
 >
 > short of anything truly fatal in the original reasons for writing
 v.buffer2, that statement is rather hard to argue with.
 >
 Unfortunately, everything became a bit more complicated in order to
 support a buffer column with individual buffering distances and in order
 to handle some special cases.

 Markus M

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