[GRASS-dev] [bug #2765] (grass) v.buffer produces strange results
Maciek Sieczka via RT
grass-bugs at intevation.de
Sun Nov 26 16:38:08 EST 2006
hamish_nospam at yahoo.com wrote (Fri, Nov 24 2006 03:39:17):
> 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:
Oh, right. Sorry, my bad. I thought you meant some vector map (I missed the
fact you didn't put "vect=" into your g.region call).
>>> can you isolate the problem with:
> 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.
You are right, should have thought of using v.out.ascii for debugging.
>>> maybe it is a FP epsilon problem, which is slightly different
>>> machine to machine + compiler to compiler? e.g. 123.4000000000002 vs
>> 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?
No. 32 bit, Pentium M 750 (Dothan). Ubuntu Dapper 2.6.15-27-686. I'm not using
any optimization at the build time. GCC 4.0.3-1ubuntu5.
> 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"
This is propably not the case here. But I have a lead :). Please read at the
> does "d.what.vect -f" (or without -f check area size) show the original
> as a closed area?
$ d.vect ditches; d.what.vect -f
feature type: Area
area size: 475.449658
Database connection not defined
>> Please watch the swf at , 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 :)
Following your v.out.ascii hint here's what I found out.
Extract the problematic area 1205:
$ v.extract in=ditches out=ditch_1205 type=area list=1205
$ v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1
$ v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4
As expected, both outputs are wrong, see  and , respectively.
Running the ditch_1205 through ascii vector, like:
$ v.out.ascii ditch_1205 form=standard | v.in.ascii format=standard
doesn't change anything - buffering the ditch_1205_asciied still yields wrong
results, exactly the same as seen on  and .
However, after "editing" the ditch_1205 in v.digit, like shown on ,,,
ie. dissjoining the boundary and snapping the vertex back,
$ g.copy vect=ditch_1205,ditch_1205_edt
$ v.digit ditch_1205_edt #see ,,
buffering this resulting vector yields correct results; see ,, respectively:
$ v.buffer ditch_1205_edt out=ditch_1205_edt_b1 type=area buffer=1
$ v.buffer ditch_1205_edt out=ditch_1205_edt_b4 type=area buffer=4
Now, why does this "touch" of v.digit help? The *only* difference between
ditch_1205 and the "edited" ditch_1205_edt according to v.out.ascii is where
the boundary no #4 is mentioned, see:
$ v.out.ascii ditch_1205 form=standard | awk 'NR>10'
C 1 1
$ v.out.ascii ditch_1205_edt form=standard | awk 'NR>10'
C 1 1
Note there is no single difference between the 2 *besides* the order in which
boundaries are listed. Somehow, the ditch_1205 having boundary #4 listed as
first is wrong for v.buffer (on my machine), while the ditch_1205_edt, having
the same boundary listed as the last one, is OK.
Does this finding help?
-------------------------------------------- Managed by Request Tracker
More information about the grass-dev