Hamish wrote: > > The problem still occurs in all cases. I would simply work around it, but > > r.mapcalc will not replace "nan" values. I am out of ideas. Any suggestions? > > will r.null replace "nan" values? If not, we should probably add a flag to > r.null to allow that.
We should look into changing G_is_[fd]_null_value() to test for any NaN value, rather than for the specific bit patterns which GRASS uses. If we have isnan() (C99), we can use that. For IEEE-754, NaN has an all-ones exponent and a non-zero mantissa. Testing for x!=x may also work. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grassuser mailing list [email protected] http://grass.itc.it/mailman/listinfo/grassuser
