[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:16 mlennert]:
 > Replying to [comment:15 mmetz]:
 > >
 [...]
 > > 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...).
 >
 It should still be the same number of railroads, the same number of
 created buffers, and a similar amount of cleaning that needs to be done on
 the created buffers.

 I managed to fix the segfaults v.buffer2 caused in Vect_get_isle_points()
 and pg_create(), but the test cases not properly working with
 v.buffer2/v.parallel2 are

  * this ticket comment 13
  * ticket #90
  * ticket #1231
  * ticket #1244
  * ticket #994 does not apply to v.buffer, maybe I fixed it for v.buffer2

 All these test cases are successfully completed by v.buffer/v.parallel; on
 confirmation by I would reactivate v.buffer/v.parallel and deactivate
 v.buffer2/v.parallel. For trunk that would mean that v.buffer which is
 actually v.buffer2 gets replaced with v.buffer, same for v.parallel.

 Markus M

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