[GRASSLIST:3656] Re: more r.mapcalc troubles

[Glynn Clements]

Maciek Sieczka wrote:

> The reason was trivial - there was a mask made of the aerial photo borders
> which I forgot
> and I didn't know that r.mapcalc ignores the mask when no raster is given as
> an argument i.e. "r.mapcalc 'raster=100'" (like in case of the formula on
> the very top of the email).
> So there was a difference beetween the 'kor_lx' and 'copy' because only
> 'copy' was masked.
> 
> Just to finish this toppic, could you only explain why it is so?

The mask is applied automatically when *reading* maps. If a mask
exists, any masked cells appear as nulls. This functionality is built
into the core functions which are used to read maps, and not
individual programs, so it applies consistently to all programs which
read raster maps (unless they explicitly use the _nomask versions,
which is rare).

The mask doesn't apply to writing maps (amongst other things, this
would make it rather awkward for programs such as r.fillnulls, r.grow2
etc which are meant to fill in null cells).

The fact that "r.mapcalc dst = src" results in dst being a masked copy
of src is largely intentional; this (or, alternatively, r.resample) is
a standard technique for creating a new map which "freezes" the
current region and the current mask into an existing map.

> > > Is there a way to learn about the value range etc. in case of such a low
> > > value raster in Grass 5.03?
> 
> > I don't know. The range is actually stored as binary data, so the
> > information exists. However, r.info displays it using "%f", so small
> > values will be rounded to zero. I don't know of any other program
> > which will provide this information.
> 
> some solution: "r.colors raster_name color=rules" prints the value range
> with a pretty good precission
> 
> for instance:
> 
>     r.colors kor_lx_bis color=rules
>     Enter rules, "end" when done, "help" if you need it.
>     fp: Data range is 0.0000000000000281236708076 to
> 0.0000000000004543557189319

That only works interactively. I have no idea how a script could
obtain the range if the values were small. We should consider
extending "r.info -r" to allow the use of %f/%g.

This issue does get discussed occasionally, but it's never resulted in
action. The main problem is that the issue is so widespread; lots of
code uses "%f", which falls down for very large or very small values. 
OTOH, it's surprising (to me) how infrequently people actually get
bitten by it.

-- 
Glynn Clements <glynn.clements at virgin.net>