[GRASS5] 0 != no data

[Justin Hickey]

Hi Helena

Helena Mitasova wrote:
> as I understand it, this issue has already been resolved (I believe I 
> was wrong in my answer when I thought that it was not). The null file
> should stay - that is the file which ensures that NULL is different
> from 0.

Please forgive my ignorance here, but I still do not see the purpose of
the null file. The gis library has a null value defined for each type of
map; CELL, FCELL, and DCELL. Namely, in hex these are (on a 32 bit
machine):

CELL  => 80000000  which is INT_MIN from float.h
FCELL => FFFFFFFF  defined as NaN
DCELL => FFFFFFFFFFFFFFFF  defined as NaN

None of these values are 0, so why do we need a null file to ensure NULL
is different from 0? The library should handle that automatically.

> What had to be changed was reading of files which did not have NULL
> file - originally, 0 was treated as NULL for such files. As I
> understand it (correct me if I am wrong) this was changed to read 0
> as a 0-value if NULL file is missing. 

Unfortunately, this wasn't changed. If the null file does not exist,
then 0 values are interpreted as NULL. But I agree with you, it should
be changed and 0 should never be interpreted as NULL.

> When NULL file is there, there is no problem,

Ahh, but if 0 is not interpreted as NULL, the problem doesn't exist in
the first place and thus, the null file is not necessary.

> the only issue were old files which did not have
> NULL-file, which was your case. With NULL file present 0 should not
> be treated as NULL unless you define it as such.

With old files, there would be no problem if 0 was not interpreted as
NULL, that is, 0 would be 0. If a user wanted 0 to be interpreted as
NULL he/she simply runs the following command in r.mapcalc

map=if(map,map,null())

Now the map file has proper null values defined (or at least it should
since I don't know if this info would be stored in a null file with the
current source code) and 0 can still be used as 0 if need be in the
future.

Therefore, if we eliminate the code that interprets 0 as NULL, then we
can also eliminate the null file. And then we can clean up programs like
r.support by eliminating references to this confusing (in my opinion)
concept of 0 as NULL.

This seems to me to be a clear and clean method. The only NULL values
are those defined in the library. Using a null file to switch between a
feature that is not really necessary seems like a hack to me.

Unfortunately, if we decide to eliminate the null file, it would have
been nice to have done this for 5.0. But this type of change is too
major at this late point. Perhaps we can make minor changes to r.support
and d.what.rast to hide the fact that there is a null file to minimize
the effect of eliminating it for 5.1.

I don't know, maybe I'm way off base here and am missing something. I
just can't see a reason for the null file.

-- 
Sincerely,

Jazzman (a.k.a. Justin Hickey)  e-mail: jhickey at hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
==================================================================
People who think they know everything are very irritating to those
of us who do.  ---Anonymous

Jazz and Trek Rule!!!
==================================================================