[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