[GRASS-dev] v.buffer2 issues

[Markus Metz]

On Tue, Apr 5, 2011 at 10:06 AM, Moritz Lennert
<mlennert at 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