[GRASS5] r.mapcalc and NULL question

[Markus Neteler]

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:

Option 1:
 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.

Other comments?

> > 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?

>From changelog:
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).

Try
 r.mapcalc test=-129
 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
version.


>  Generally
> 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 ;)
> 

Markus

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'