[GRASS5] 0 != no data

[Justin Hickey]

Hi Roger

Roger Bivand wrote:
> 
> On Tue, 12 Jun 2001, Justin Hickey wrote:
> > 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?

For the actual change, yes.

> 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)?

I tend to disagree on this one. In your proposal, the users will have to
go through two transitions: one for using new floating point and NULL
code, and then a second one for removing the 0 = NULL feature. To me,
making a single transition is better in this case. Also, I don't think
the transition problem in this case will be large. The 4.x users are
used to 0 being NULL. All we do is inform them that they need to run
r.mapcalc (or we can provide a script for them) to update their data to
GRASS 5 if they want to convert their 0 values to NULL values, and that
from now on 0 is a valid value. They would probably expect this anyway
since they know the data format has changed.

In order to implement this, we simply hide the fact that a null file is
required. As far as I can tell, most import programs generate the null
file. The only case we need to worry about is when users copy 4.x data
to 5 databases. In this case, we tell them to run our script to upgrade
and we run r.mapcalc and generate the null file for them.

The only remaining case I can think of is if a user wants 0 to represent
NULL for newly created maps. In this caes I think we should say "Sorry,
but Grass 5 requires 0 to be a valid data value". Although backward
compatibility is good in most cases, sometimes it is bad, and I believe
that this is one of those cases. I think it is pretty safe to say that
most users (if not all) consider "0 as an invalid data value" a bug.
Afterall, that's the reason the NULL value concept was introduced, to
fix this bug.

So now we get users accustomed to upgrading their data with our upgrade
script, and when we eliminate the null file for 5.1, there is no
transition for them. I think they would be happier this way because they
are expecting a big change in their operation methods this time round.
But they probably will not expect a big change in their operations for
5.1.

That's just my 2 cents worth.

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