[GRASS-dev] Re: [bug #2765] (grass) v.buffer produces strange results

[Hamish]

Maciej Sieczka wrote:
> > g.region ditches_buf
> 
> Which one is that? It's not there in the package I sent you.

It is the saved region:

$ cat vbuffer_bugs/vbuffer_bugs/windows/ditches_buf 
proj:       1
zone:       33
north:      5678240
south:      5677910
east:       600860
west:       600570
cols:       29
rows:       33
e-w resol:  10
n-s resol:  10
top:        1
bottom:     0
cols3:      33
rows3:      31
depths:     1
e-w resol3: 8.78787879
n-s resol3: 10.64516129
t-b resol:  1


> > can you isolate the problem with:
..
> > v.select ain=ditches bin=problem_box out=problem_areas
> > v.out.ascii format=standard in=problem_areas
..
> Done that before, to no avail.

clearer: if you can extract it to a few simple areas & export with
v.out.ascii it is easier to follow step by step in the debugger. Also
you can post that to the bug's history and others can try without
needing you to send them the 1mb location download- more data points.


> >> 'ditches' was hand digitised by me in QGIS 0.74, few months ago.
> 
> > maybe it is a FP epsilon problem, which is slightly different
> > machine to machine + compiler to compiler? e.g. 123.4000000000002 vs
> > 123.4.
> 
> Would that mean v.buffer is supposed to work on some Linuces and not
> on the other? That would be a nightmare.

I don't know. It is just a guess of why our two systems would be
different. I am testing with a Pent4 32bit debian/stable machine.
Is yours 64bit? v.buffer will try and do the same calculation, but the
computer may give a slightly different results. That will happen with
any 32bit and 64bit system doing FP math, with any program. It would be
a v.buffer bug if e.g. if it tests FP1==FP2 when it should test
"fabs(FP2-FP1) <= EPSILON"


> The point might propably be about the boundaries of the problematic
> area being recognized as snapped on your machine, while being
> recognized as disjointed on my machine. That'd be nuts tough.

does "d.what.vect -f" (or without -f check area size) show the original
as a closed area?


> Please watch the swf at [3], where I present step-by-step the two runs
> of v.buffer on the problematic dataset - before and after the required
> "edit", including how the "edit" looks like. I'm just moving vertex of
> a topologically clean boundary a bit and snapping it back. Strange...

sorry, I don't have flash installed. But I trust you are honest and we
have tried the same commands :)



Hamish