this bug's URL: http://intevation.de/rt/webrt?serial_num=5163
-------------------------------------------------------------------------
Subject: v.to.rast use=dir: some nans are present in the output instead of nulls
Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 2006-09-13
I can't reproduce it in spearfish60, but the bug is confirmed by Martin Landa using my sample dataset and discussed on the dev-list. I'm reporting the bug to the bugtracker as nobody seems to be working on fixing it.
Glynn has found a solution - I'm quoting him in the bottom of the bug.
THE BUG:
$ g.region vect=cieki10_2zl res=10 -a
$ v.to.rast input=cieki10_2zl output=cieki10_2zl_dir use=dir
There are several nan cells in the output:
$ r.stats -1g cieki10_2zl_dir | grep -i nan
r.stats: 600265 5680715 nan
600335 5680575 nan
600395 5680435 nan
599735 5680345 nan
598695 5679865 nan
600245 5679475 nan
599125 5679245 nan
599675 5678955 nan
598915 5678935 nan
599815 5678765 nan
598785 5678655 nan
600345 5678335 nan
600545 5678015 nan
THE REASON:
Glynn Clements wrote on grass-dev:
Without having tried the data, my first guess is that the NaN values
result from a domain error in the flow-direction calculation,
specifically from the call to acos() in v2angle(), in do_lines.c.The main problem is that you can't pass GRASS FP null values around
like normal values. When dealing with NaN values, the implementation
isn't required to maintain the specific bit pattern, only that
"NaN-ness" is preserved.It would be easy enough to add a check to v2angle(), e.g.
if (costheta < -1 || costheta > 1)
{
/* acos() will return NaN */
}However, there's no way to report this; we can't just return GRASS'
null value, as the hardware may transform it to a different
bit-pattern en route.We could try to detect the NaNs before the data is written to file,
but isnan() isn't in C89, and other ways of detecting NaNs are
unreliable. ANSI dictates that "x == x" is false if x is NaN, but some
compilers (particularly for architectures without full hardware FP
support, e.g. Alpha) overlook this (and others may optimise "x == x"
to true with certain optimisation switches).The only robust and portable solution is to change v2angle(),
deg_angle() and set_dcat() to accept/return the value via a pointer
argument, to ensure that the all-ones bit pattern is preserved, and
change v2angle() to specifically check for out-of-domain values.
The thread is here http://grass.itc.it/pipermail/grass-dev/2006-September/025764.html.
Maciek
-------------------------------------------- Managed by Request Tracker