#699: v.buffer segfault: in Vect_get_isle_points()
---------------------+------------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Vector | Version: 6.4.0 RCs
Keywords: | Platform: All
Cpu: All |
---------------------+------------------------------------------------------
On Fri, Jul 24, 2009 at 1:17 PM, Corrado wrote:
{{{
> Yes it is reproducible with spearfish:
>
> v.buffer input=landcover output=lcb distance=2 --overwrite
>
> Buffering lines...
> 100%
> Buffering areas...
> Segmentation fault
}}}
Same here with GRASS 6.5:
{{{
GRASS 6.5.svn (spearfish60):~ > gdb v.buffer
...
(gdb) r input=landcover output=lcb distance=2 --o
Starting program: /home/neteler/grass65/dist.x86_64-unknown-linux-
gnu/bin/v.buffer input=landcover output=lcb distance=2 --o
[Thread debugging using libthread_db enabled]
WARNING: Vector map <lcb> already exists and will be overwritten
Buffering lines...
100%
Buffering areas...
[New Thread 0x7f8b055c4720 (LWP 3392)]
Program received signal SIGSEGV, Segmentation fault.
0x00007f8b051b64c8 in Vect_get_isle_points (Map=0x7fff0d60f6d0, isle=0,
BPoints=0x2362de0) at area.c:118
118 G_debug(3, " n_lines = %d", Isle->n_lines);
}}}
#699: v.buffer segfault: in Vect_get_isle_points()
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Vector | Version: 6.4.0 RCs
Resolution: | Keywords:
Platform: All | Cpu: All
----------------------+-----------------------------------------------------
Comment (by mmetz):
v.buffer is broken for areas. After I fixed the segfault (not submitted),
it hangs with the above example. Further on, with some simple test
vectors, it throws away isles of areas, removes boundaries between
adjacent areas with different categories, and buffers both boundaries and
areas causing damaged topology.
IMO,
- boundaries shared between two areas should not be touched when buffering
areas, because it can not be decided where the buffered boundary should be
- isles should only be modified if they consist of areas without centroid,
otherwise the should be preserved as is
- v.buffer should buffer either boundaries or areas, not both at the same
time
There is redundant code in Vlib/buffer2.c, functions that are present
elsewhere in the vector libs. New Vect_*() functions should make use of
existing functions instead of writing duplicates of existing functions.
Someone has to maintain all the code...
This is bad news, I have no time right now to attempt to fix it, best
would be if Rosen Matev fixes it, he knows the code best.
#699: v.buffer segfault: in Vect_get_isle_points()
----------------------+-----------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Vector | Version: 6.4.0 RCs
Resolution: | Keywords: v.buffer
Platform: All | Cpu: All
----------------------+-----------------------------------------------------
Changes (by hamish):
* keywords: => v.buffer
Comment:
see also #90 and #994.
mmetz:
> Something else I noticed is that categories get lost for areas,
> all areas get cat = 1.
that is by design. if the buffers of two areas will different cat overlap,
which cat gets to claim the new combined area? The question can not be
answered so we don't ask it- cats are wiped clean.
{{{
Starting program: /home/mlennert/SRC/GRASS/grass-6.4.0/dist.i686-pc-linux-
gnu/bin/v.buffer in=rail_simple dist=1000 out=rail1000
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib/libicudata.so.38 is .hash at 000000b4
[New Thread 0xb55c16d0 (LWP 31004)]
Buffering lines...
5%
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb55c16d0 (LWP 31004)]
0xb7ed0d00 in pg_create (Points=0x86b6558) at dgraph.c:471
471 v = si->ip[si->il[i].a[0].ip].group;
}}}
#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 |
----------------------+-----------------------------------------------------
Changes (by mmetz):
* milestone: 6.4.0 => 7.0.0
Comment:
Replying to [comment:7 mlennert]:
> Replying to [comment:5 mmetz]:
> > The segfault is fixed in 6.4 r38554, but the other problems remain.
>
> I still get a segfault in all three version (6.4, 6.5 and trunk). In
6.4:
>
>
{{{
> v.generalize railroads out=rail_simple method=douglas_reduction
reduction=20
> v.buffer rail_simple dist=1000 out=rail1000
}}}
>
This is unfortunately a different bug in v.buffer, happening in pg_create
in dgraph.c. The original bug reported in this ticket happened only when
buffering areas, whereas in this case lines are buffered and a different
bug has been detected.
I am changing Milestone because these bugs probably don't get fixed in
6.4.x.
#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:9 mmetz]:
> The second bug should now be fixed in r45219, r45220, r45221 (7.0, 6.5,
6.4), working on Linux 32bit and 64bit.
>
Correction, it works on Linux 32bit and Windows, but not always on Linux
64bit. On Linux 64 bit, v.buffer2 (and v.parallel2) create sometimes zero-
size areas, the bug is somewhere in the vector libs, more specifically in
buffer2.c and/or dgraph.c.
BTW, buffering works with the original v.buffer module (slightly modified)
where v.buffer2 fails. Umh, and v.buffer is up to 10x faster and easier to
maintain than v.buffer2...
#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 marisn):
Could this be some int overflow? This is output from 6.5 on AMD64.
{{{
D3/3: Vect_get_area_isle(): area = 2 isle = 19
D3/3: -> isle = 134
D3/3: Vect_get_isle_points(): isle = 134
D3/3: n_lines = 1
D3/3: append line(0) = -976
D3/3: Vect_read_line()
D3/3: V2_read_line_nat(): line = 976
D3/3: Vect__Read_line_nat: offset = 160553
D3/3: type = 4, do_cats = 0 dead = 0
D3/3: n_points = 11
D3/3: off = 160734
D3/3: line n_points = 11
D3/3: isle n_points = 11
D3/3: Vect_get_area_isle(): area = 2 isle = 20
D3/3: -> isle = 137
D3/3: Vect_get_isle_points(): isle = 137
D3/3: n_lines = 1
D3/3: append line(0) = -1002
D3/3: Vect_read_line()
D3/3: V2_read_line_nat(): line = 1002
D3/3: Vect__Read_line_nat: offset = 165931
D3/3: type = 4, do_cats = 0 dead = 0
D3/3: n_points = 11
D3/3: off = 166112
D3/3: line n_points = 11
D3/3: isle n_points = 11
D3/3: Vect_get_area_isle(): area = 2 isle = 21
D3/3: -> isle = 175
D3/3: Vect_get_isle_points(): isle = 175
D3/3: n_lines = 1
D3/3: append line(0) = -1233
D3/3: Vect_read_line()
D3/3: V2_read_line_nat(): line = 1233
D3/3: Vect__Read_line_nat: offset = 206334
D3/3: type = 4, do_cats = 0 dead = 0
D3/3: n_points = 11
D3/3: off = 206515
D3/3: line n_points = 11
D3/3: isle n_points = 11
D3/3: Vect_get_area_isle(): area = 2 isle = 22
==12849== Invalid read of size 4
==12849== at 0x4E43509: Vect_get_area_isle (area.c:288)
==12849== by 0x4E3D64D: Vect_area_buffer2 (buffer2.c:1096)
==12849== by 0x402D6E: main (main.c:478)
==12849== Address 0xdcfc978 is 0 bytes after a block of size 88 alloc'd
==12849== at 0x4C262CA: malloc (in /usr/lib64/valgrind
/vgpreload_memcheck-amd64-linux.so)
==12849== by 0x52A2027: G__realloc (alloc.c:109)
==12849== by 0x5D2BAFE: dig_area_alloc_isle (struct_alloc.c:333)
==12849== by 0x5D27E56: dig_Rd_P_area (plus_struct.c:368)
==12849== by 0x5D25045: dig_load_plus (plus.c:312)
==12849== by 0x4E497C5: Vect_open_topo (open.c:751)
==12849== by 0x4E4A0F2: Vect__open_old (open.c:229)
==12849== by 0x40269A: main (main.c:302)
==12849==
D3/3: -> isle = 0
==12849== Invalid read of size 4
==12849== at 0x4E43521: Vect_get_area_isle (area.c:288)
==12849== by 0x4E3D64D: Vect_area_buffer2 (buffer2.c:1096)
==12849== by 0x402D6E: main (main.c:478)
==12849== Address 0xdcfc978 is 0 bytes after a block of size 88 alloc'd
==12849== at 0x4C262CA: malloc (in /usr/lib64/valgrind
/vgpreload_memcheck-amd64-linux.so)
==12849== by 0x52A2027: G__realloc (alloc.c:109)
==12849== by 0x5D2BAFE: dig_area_alloc_isle (struct_alloc.c:333)
==12849== by 0x5D27E56: dig_Rd_P_area (plus_struct.c:368)
==12849== by 0x5D25045: dig_load_plus (plus.c:312)
==12849== by 0x4E497C5: Vect_open_topo (open.c:751)
==12849== by 0x4E4A0F2: Vect__open_old (open.c:229)
==12849== by 0x40269A: main (main.c:302)
==12849==
D3/3: Vect_get_isle_points(): isle = 0
==12849== Use of uninitialised value of size 8
==12849== at 0x4E43145: Vect_get_isle_points (area.c:118)
==12849== by 0x4E3D65A: Vect_area_buffer2 (buffer2.c:1097)
==12849== by 0x402D6E: main (main.c:478)
==12849==
==12849== Invalid read of size 4
==12849== at 0x4E43145: Vect_get_isle_points (area.c:118)
==12849== by 0x4E3D65A: Vect_area_buffer2 (buffer2.c:1097)
==12849== by 0x402D6E: main (main.c:478)
==12849== Address 0x30 is not stack'd, malloc'd or (recently) free'd
==12849==
==12849==
==12849== Process terminating with default action of signal 11 (SIGSEGV)
==12849== Access not within mapped region at address 0x30
==12849== at 0x4E43145: Vect_get_isle_points (area.c:118)
==12849== by 0x4E3D65A: Vect_area_buffer2 (buffer2.c:1097)
==12849== by 0x402D6E: main (main.c:478)
==12849== If you believe this happened as a result of a stack
==12849== overflow in your program's main thread (unlikely but
==12849== possible), you can try to increase the size of the
==12849== main thread stack using the --main-stacksize= flag.
==12849== The main thread stack size used in this run was 8388608.
==12849==
==12849== HEAP SUMMARY:
==12849== in use at exit: 7,945,280 bytes in 139,148 blocks
==12849== total heap usage: 139,617 allocs, 469 frees, 8,023,374 bytes
allocated
==12849==
==12849== LEAK SUMMARY:
==12849== definitely lost: 4,373 bytes in 13 blocks
==12849== indirectly lost: 240 bytes in 10 blocks
==12849== possibly lost: 0 bytes in 0 blocks
==12849== still reachable: 7,940,667 bytes in 139,125 blocks
==12849== suppressed: 0 bytes in 0 blocks
==12849== Rerun with --leak-check=full to see details of leaked memory
==12849==
==12849== For counts of detected and suppressed errors, rerun with: -v
==12849== Use --track-origins=yes to see where uninitialised values come
from
==12849== ERROR SUMMARY: 14 errors from 8 contexts (suppressed: 6 from 6)
Segmentation fault
}}}
#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:11 marisn]:
> Could this be some int overflow? This is output from 6.5 on AMD64.
{{{
> [...]
> D3/3: Vect_get_area_isle(): area = 2 isle = 22
> [...]
> D3/3: -> isle = 0
> [...]
> Segmentation fault
}}}
This should be fixed as of r45178 from 1/25/2011. Just to be sure, can you
confirm that the vector libs in your local copy of 6.5 are at least
r45178, better 45217? Thanks!
#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:10 mmetz]:
> Replying to [comment:9 mmetz]:
> > The second bug should now be fixed in r45219, r45220, r45221 (7.0,
6.5, 6.4), working on Linux 32bit and 64bit.
> >
> Correction, it works on Linux 32bit and Windows, but not always on Linux
64bit. On Linux 64 bit, v.buffer2 (and v.parallel2) create sometimes zero-
size areas, the bug is somewhere in the vector libs, more specifically in
buffer2.c and/or dgraph.c.
>
Test commands for the North Carolina dataset
{{{
WARNING: Next edge was visited but it is not the first one !!! breaking
loop
WARNING: Next edge was visited but it is not the first one !!! breaking
loop
WARNING: Next edge was visited but it is not the first one !!! breaking
loop
WARNING: Vect_get_point_in_poly(): Unable to find point in polygon
ERROR: Vect_get_point_in_poly() failed
}}}
if the patch from #1231 has been applied, otherwise it cycles forever as
described for v.parallel2 in #1231, which happens because
Vect_get_point_in_poly() can not find a point in a zero-size polygon. This
happens only on Linux 64bit, not on Linux 32bit or Windows. The same
command with distance=1000 completes on 64bit, but there are also warnings
like
{{{
WARNING: Next edge was visited but it is not the first one !!! breaking
loop
}}}
If this bug can not be resolved I would suggest to reactivate the original
versions of v.buffer and v.parallel (the bugs described there are easy to
fix within the module without touching the libs) and deactivate v.buffer2
and v.parallel2.
#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:13 mmetz]:
> If this bug can not be resolved I would suggest to reactivate the
original versions of v.buffer and v.parallel (the bugs described there are
easy to fix within the module without touching the libs) and deactivate
v.buffer2 and v.parallel2.
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.
#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: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.
#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...).
#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.
#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 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.
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.
#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.