Hello,
I'm totally lost in v.buffer/2 issues. I recompiled v.buffer and
v.buffer2 on 6.5 and was trying out different use cases from trac. All
of them where working fine with v.buffer2. Old v.buffer was still
failing with landcover dataset. I had not tested attribute based
buffering, as it should not be hard to fix buffering by attribute if
in general it works fine.
Can anyone give me sample data that triggers failure of v.buffer2?
Maris.
On 05/04/11 09:40, Maris Nartiss wrote:
Hello,
I'm totally lost in v.buffer/2 issues. I recompiled v.buffer and
v.buffer2 on 6.5 and was trying out different use cases from trac. All
of them where working fine with v.buffer2. Old v.buffer was still
failing with landcover dataset. I had not tested attribute based
buffering, as it should not be hard to fix buffering by attribute if
in general it works fine.
AFAICT both now work fine in the cited test cases, but v.buffer is way faster than v.buffer2. Try buffering the railroads layer in the nc_spm location.
Moritz
On Tue, Apr 5, 2011 at 9:40 AM, Maris Nartiss <maris.gis@gmail.com> wrote:
Hello,
I'm totally lost in v.buffer/2 issues. I recompiled v.buffer and
v.buffer2 on 6.5 and was trying out different use cases from trac. All
of them where working fine with v.buffer2. Old v.buffer was still
failing with landcover dataset.
Hmph. Updated v.buffer indeed fails with spearfish landcover map.
I had not tested attribute based
buffering, as it should not be hard to fix buffering by attribute if
in general it works fine.
Buffering by attributes is now working in both versions. Both versions
still have different problems with generating and cleaning buffers.
Can anyone give me sample data that triggers failure of v.buffer2?
E.g. in nc_spm with roadsmajor:
v.buffer2 input=roadsmajor@PERMANENT output=roadsmajor_buf2_2000 distance=2000
fails, but works fine with updated v.buffer
v.buffer input=roadsmajor@PERMANENT output=roadsmajor_buf1_2000 distance=2000
v.parallel2 has more issues than v.buffer2 (see tickets #1231 and
#1244). According to the relevant thread in the grass-dev ml [1], I
got the impression that Rosen Matev was aware of the problem with
parallel lines, but did not get around to fix it [2] (last mail of
[1]).
Markus M
[1] http://thread.gmane.org/gmane.comp.gis.grass.devel/27534/
[2] http://article.gmane.org/gmane.comp.gis.grass.devel/28445
On Tue, Apr 5, 2011 at 10:06 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:
On 05/04/11 09:40, Maris Nartiss wrote:
Hello,
I'm totally lost in v.buffer/2 issues. I recompiled v.buffer and
v.buffer2 on 6.5 and was trying out different use cases from trac. All
of them where working fine with v.buffer2. Old v.buffer was still
failing with landcover dataset. I had not tested attribute based
buffering, as it should not be hard to fix buffering by attribute if
in general it works fine.AFAICT both now work fine in the cited test cases, but v.buffer is way
faster than v.buffer2. Try buffering the railroads layer in the nc_spm
location.
v.buffer2 is now as fast as v.buffer, and v.buffer2 does produce more
accurate results than v.buffer for particular shapes, e.g. spearfish
landcover and v35 of ticket #1231 with distance=25. Additionally,
v.buffer2 should now always complete the job with all known test cases
and various different settings. This is however a workaround and not
necessarily a fix. There is an open issue with v.buffer2: different
results on Linux 32bit and 64bit. I have no time right now to look
into this, opening a ticket for that.
v.parallel2 remains broken (see tickets #1231 and #1244), whereas
v.parallel produces reasonable results.
Markus M