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

GRASS GIS trac at osgeo.org
Mon Apr 4 09:01:47 EDT 2011


#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                      
----------------------+-----------------------------------------------------

Comment(by mlennert):

 Replying to [comment:27 mmetz]:
 > Replying to [comment:26 mlennert]:
 > > However, testing with the other example (see Mon, Oct 9 2006 08:02:33)
 from the old RT report gives the following, seems to reveal some remaining
 issues.
 > >
 > > First of all, I cannot reproduce the procedure exactly, as the
 v.buffer call with bufcolumn=lane_cout gives me
 > >
 > >
 > {{{
 > > GRASS 7.0.svn (nc_spm_06):~ > v.buffer vbuf_fill_bug bufcol=lane_count
 out=vbuf_fill_bug_lanes scale=150
 > > ATTENTION : The bufcol option may contain bugs during the cleaning
 step. If
 > >             you encounter problems, use the debug option or clean
 manually
 > >             with v.clean tool=break; v.category step=0; v.extract -d
 > >             type=area
 > > ERREUR :The bufcol option requires a valid layer.
 > }}}
 >
 > Note that v.buffer in grass 7 is the same like v.buffer2 in grass 6.x.
 The original v.buffer has been removed from grass 7 some time ago. Testing
 the buffer/parallel modules should take place in grass 6.5 only.

 Oops. I had forgotten that I'd done the tests in dev6 before, and just
 assumed that it was in grass7.

 >
 > It seems v.buffer2 has issues with the test cases described in the old
 RT bug 2765 whereas v.buffer does not...

 Just tested in dev6: I actually don't see any difference between v.buffer
 and v.buffer2 with the two test cases mentioned above. Both work fine.

 Sorry for the noise...

 And I still support Markus in replacing v.buffer2 by v.buffer. I know this
 will be frustrating to see a SoC project apparently disappear, but IIUC,
 Markus has actually integrated some of the code into v.buffer, or ?

 Moritz

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



More information about the grass-dev mailing list