[GRASS5] Opinion wanted - null data

[Justin Hickey]

Hello all

As you know, I have been looking at the issue of removing the feature of
"0 is no data", and the situation is currently at a point where I'm not
sure what is the best thing to do.

First, there have been 8 out of 9 users request that the "0 is no data"
feature disappear in 5.0. Originally I was planning to hide the null
file from the users for 5.0 since we are close to a release and then
remove it for 5.1. However, the more I look at the code and think about
it, the more I feel that there will not be an elegant way to eliminate
the null file for 5.1. The best I can think of is some way to detect
whether a data file is pre 5.1 and then automatically convert it when
grass reads it. Even though this sounds simple, we would have to keep
the code that interprets the null file around for quite a while in order
to convert these files.

The best solution would be to make the change now. That way the users
are happy and the code for reading the old data is kept in a script, or
at least it would be separate from Grass, since the users would run the
script themselves. Of course, there is a big problem with this option.
This change does not seem to be trivial (especially since it changes the
gis library), and would probably leave the code in an unstable state for
some period of time. Thus, there would be a slight delay in the release
of Grass 5.0.

On top of all this is the fact that I have run out of time. Next week I
am moving to Canada and therefore, I will be off-line for an unknown
amount of time. It could be a couple of weeks, or it could be over a
month. I just don't know. Thus, it is unlikely I will be able to
contribute anything to this change in the near future.

One bit of good news is that the change, in theory, is relatively simple
if we also eliminate the multiple byte lengths for storing CELL data. We
simply save the data as it is in memory and remove references to the
null file and multiple byte length CELL data. However, I'm not sure if
it will be a simple change practically. I have not had time to do a full
investigation of the code, but so far, I have not found anything that
would indicate a major problem (which of course means nothing :-) ).

Thus the situation is:

1. We have a request from our users to eliminate the null file for 5.0

2. The change would involve library code changes but we are close to
   a release

3. The developer that would most likely make the changes (me) is
   unavailable for an unknown time

The options I see that we have are (in no particular order):

1. Release 5.0 stable without any null changes and indicate to users
   that an investigation of the code revealed that a major change was
   required and thus the change is delayed until 5.1 rather than
   risking the stability of 5.0

2. Make the change and prolong the release by the amount of time for me
   to get back on-line and for coding and testing

3. Another developer volunteers to make the changes and the release is
   delayed for only a minimum amount of time (coding and testing)

4. Another developer volunteers to hide the null file and we do an
   automatic change for 5.1

Frankly, I'm at a loss as to which option is best. I think I prefer
option 3 since it would please the users, but I hate passing off work to
others.

Anyway, I just thought that I should raise this issue with the
developers. What do people think of these options? Is there anybody who
wants to volunteer for 3 or 4?

Thanks for listening.

-- 
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!!!
==================================================================