[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 mlennert):

 Replying to [comment:15 mmetz]:
 > Replying to [comment:14 mlennert]:
 > >
 > > I can't remember what the issues were triggering the rewrite of
 v.buffer, but if you think you can solve these issues and that that the
 original v.buffer is much faster, you definitely have my +1.
 > >
 > I think the motivation was the dirty output of v.parallel and only
 halfway implemented support for a column with buffer distances unique for
 each feature.
 >
 > Unfortunately it was not as easy as I assumed, I had to modify the
 original vector lib functions, i.e. the disabled lib/vector/Vlib/buffer.c
 file in order to get clean results.
 >
 > For grass 6.5, r45437 fixes (for me) the issues mentioned in this ticket
 and in the tickets #90, #994, #1231, #1244.
 >
 > For testing purposes, I have used the vectors mentioned in these tickets
 with both v.buffer and v.parallel, that is vector/v.buffer and
 vector/v.parallel and not vector/v.buffer2 and vector/v.parallel2. All
 vectors were used as input with the settings given in the respective
 tickets and various variations of the distance and tolerance options in
 order to fix the original versions.
 >
 > Still outstanding is the fix for the bufcol option, but that is not that
 difficult (seriously). I can look at it once the current change has been
 approved.
 >
 > In order to test, you would need to get grass 6.5 r45437 and manually
 compile the two modules vector/v.buffer and vector/v.parallel. For
 comparison, the Makefiles of v.buffer2 and v.parallel2 could be modified
 to name the modules v.buffer2 and v.parallel2 and the modules recompiled.

 For me it works very well, much faster than v.buffer2. I was able to
 calculate 5km buffers of the entire, non simplified nc_spm railroads map
 in +/- 25 minutes. I stopped v.buffer2 after 40 minutes when it was at
 only 27% of breaking boundaries.

 Interestingly, simplifying railroads (with the v.generalize command
 mentioned in comment 7) does not seem to significantly increase the speed
 (running now, but I have to go...).

 Moritz

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