[GRASS5] r.mapcalc and NULL question
Eric G . Miller
egm2 at jps.net
Mon Jan 15 17:44:47 EST 2001
On Mon, Jan 15, 2001 at 03:07:48PM -0700, Roger S. Miller wrote:
>
> 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.
I tend to agree with Roger here. There doesn't seem to be an obvious
way to handle the scenario, so trying to outsmart the user may create
more problems than solutions. Maybe we need to get the word out better
than any math performed with NULL values should always result in a NULL
value. This is the very definition of NULL as an "undefined/unknown value".
--
Eric G. Miller <egm2 at jps.net>
----------------------------------------
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