[GRASS5] 0 != no data

[Roger Bivand]

On Tue, 12 Jun 2001, Justin Hickey wrote:

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

No, not way off, but perhaps more in 5.1 territory? The chosen NULL
solution was dictated by the fact that all pre-NULL programs (many really
for categorical rather than numeric layers) used 0 as 0 and NULL (see
traces in r.slope.aspect adding 1 to zero slopes etc. and now commented
out. Moving straight to the representation you describe was thought to
raise too large transition problems for the many legacy users, so their
needs had to be incorporated. I don't know how the user base splits now
between 4.* and 5.* releases, but guess that 4.* still has a loyal
following. Maybe first we should get them over to 5.0 using the existing
transitional mechanisms, and only next time round migrate them away from 0
as NULL (a bit like lzw2z)? 

Roger

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand at nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.