[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