[GRASS5] r.mapcalc and NULL question
neteler at geog.uni-hannover.de
Mon Jan 15 17:09:24 EST 2001
On Mon, Jan 15, 2001 at 12:40:21PM -0800, Eric G . Miller wrote:
> On Mon, Jan 15, 2001 at 12:41:58PM -0700, Roger S. Miller wrote:
> > On Mon, 15 Jan 2001, Markus Neteler wrote:
> > > Hi there,
> > >
> > > maybe a r.mapcalc/NULL FAQ, but I don't get it...
> > >
> > > Assume you have a streams map (streams contain values,
> > > other cells=NULL).
> > >
> > > Now I want to add some values *everywhere* using r.mapcalc, but
> > > it is only added in those cells not containing a NULL value.
Perhaps I am not very clear... I will try to find a better example.
I got the impression, that value replacing is o.k. (replace NULL by
something else), but only if you use the isnull() function.
Yes, just now I got an example:
- take a map containing NULL holes (say, it is "map1")
- take a second map without NULLS (say, it is "map2")
Now I want to fill the NULLs in map one with values of map2:
r.mapcalc new="if(isnull(map1), map2 + 1000., map1)" # make a silly addition
r.mapcalc new="if(isnull(map1), map2, map1)" # replace value
-> both are o.k.
But (Option 2):
r.mapcalc new="if(map1, map2 + 1000., map1)"
r.mapcalc new="if((map1), map2, map1)"
-> NULLs are not replaced.
Is it a bug or a feature? From you kind responses I was at least aware
what's going on here :-)
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.
> > Markus,
> > I guess you probably want the NULL-valued cells to be treated like zeros.
> > To add maps A and B (where B contains NULLs) to get a map C you can use a
> > construction like
> > C=A+if(isnull(B),0,B)
> > I found a need for this when I used Grass 5 to run the Leicestershire
> > tutorial, which was written for Grass 4.x.
Thanks for the hint! From that I could construct above example.
> > There's another NULL-related behavior that I find rather annoying. I
> > guess that the numerical value of NULL is actually -129. I constructed a
> > raster map of water-level changes from a ground water model and found a
> > band of nulls scattered across the map, wherever the surface passed -129
> > feet.
> 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?
2000-08-20 16:10 markus
* null_val.c: fix for Linux on -129 NULL bug
src/libes/gis/null_val.c (here the fix has to go).
CREATING SUPPORT FILES FOR test
range: -129 -129
If this is not the result, you may not use Linux or have a very old GRASS 5
> the embedded NULL values (when the file is read via G_* funcs) are
> CELL : MAX_INT
> FCELL : NaN (float version)
> DCELL : Nan (double version)
> However, applications should always use the G_is_null_value() family of
> functions. The CELL Null value is problematic if used incorrectly
> because you can silently get overflow/underflow errors. NaN used in any
> context should always produce NaN (NaN = NaN - NaN) -- at least, that's
> how it's supposed to work ;)
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