[GRASS5] 0 != no data

[Roger Bivand]

Hi Justin

On Tue, 12 Jun 2001, Justin Hickey wrote:

> Roger Bivand wrote:
> > 
> > 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 seems well judged. My explanation was really about the history -
essentially the same points that Helena made earlier in this thread. I
still feel that 5.0 should be as open as possible to people using 4.*, but
agree that from 5.1 the solutions chosen should be as clean and
maintainable as possible. While the pipe-sockets transition doesn't affect
legacy data, NULL might, so your script solution would work well. I know
that the legacy NW Leicestershire data set is 4.* style - I suppose
updating the demonstration data sets would help too?

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.