[GRASS5] r.mapcalc and NULL question
Roger S. Miller
rgrmill at rt66.com
Mon Jan 15 17:07:48 EST 2001
On Mon, 15 Jan 2001, Markus Neteler wrote:
> Generally I consider this as a bug because you can't always know if
> a map contains NULLs. If only a few pixels would be nulls you may
> use option 2 and don't realize that the result is not want you want.
> I feel this behaviour is somewhat dangerous. The isnull() is useful,
> but if you have to apply it on default in if-clauses, it's a bit annoying.
>
> Other comments?
I first felt that it was a bug, but the best alternative I could required
a default value to be used in the place of null. Zero is the most obvious
choice for a default value, but I could think of plenty of cases where
that wasn't a good idea. Requiring the user to provide a value for null
also seemed like a bad idea. So I decided it must be a feature.
For what it's worth, Golden Software's Surfer package (and Topo before
that) has for years used a value of 1.70141e+038 as a null value -- they
use it for "blanking". Their grid math calculations treat blanks pretty
much the same way that r.mapcalc treats null; any operation on a blank
cell returns a blank cell.
> > No, the NULL value depends on the CELL type. Think this is/was a bug in
> > r.mapcalc specifically (If I recall, it has been corrected).
> Yes, this bug is definitly fixed for FreeBSD, Solaris and Linux.
> Which platform are you using?
Thanks, I see what happened.
I am running Linux, but I was running grass beta7 at the time. That was
in November, just before I updated to beta10. I didn't start reading this
list until after the code was changed, so I missed any announcement or
discussion.
I guess this is evidence that problems do get fixed :)
Roger Miller
Lee Wilson and Associates
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev
mailing list