On Tue, Apr 5, 2011 at 10:06 AM, Moritz Lennert <[email protected]> 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
