[GRASS5] 0 != no data

mlennert at club.worldonline.be mlennert at club.worldonline.be
Tue Jun 12 03:33:46 EDT 2001


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



More information about the grass-dev mailing list