[GRASS5] 0 != no data

[Justin Hickey]

Hi Eric and all

"Eric G. Miller" wrote:
> 
> On Tue, Jun 26, 2001 at 06:17:16PM +0700, Justin Hickey wrote:
> > Hi Michel
> >
> > Michel Wurtz wrote:
> > > Hmmm... Does this mean that the "format" field in the header file
> > > is not used ? (Cf progmangrass50, section 5.3.1).
> >
> > Quite possibly. I'm not sure if this section has been updated for
> > floating point code (there are several sections that need to be
> > updated), but I see no way of Grass being able to change the type 
> > of CELL data. CELL is defined as an int, thus all CELL data will be
> > of type int.
> 
> No. We must distinguish between the file format and the memory
> representation.  Most programs I've worked on never do anything
> to check how many bytes should be used for a CELL when writing a new
> file.  It can be specified, however, via the G_set_cell_format()
> function. CELL's are always represented as an int in memory (unless
> they're being read as an FCELL or DCELL, the contrary is also true).

Ahh, I didn't know Grass had the option to specify saving files with
different byte lengths. I had assumed that CELL data was saved as is.

> The G_[set/get]_cell_format() functions apparently are not 
> documented.
> 
> So, regards NULL's in CELL files with a decreased byte count, do you
> say -128 is NULL for single byte, etc... ?  All integers must be
> treated as signed, I think.  If you had an unsigned byte CELL, would
> 0 == NULL? Sounds like what the whole NULL file concept was trying to
> avoid.

Thanks for pointing me to the proper place in the code. Thinking about
your last paragraph got me wondering why do we support saving CELL data
in different byte sizes. Does anyone know why Grass allows storage of
CELL data in smaller byte sizes. The only reason I can think of is to
save disk space. But this does not seem like a good reason to me,
especially if we eliminate the null file. Seeing as the null file can
sometimes take up more space than the original cell data file, storing
CELL data as type CELL (ie 4 bytes) can use the space freed by the null
file. So, I don't see why we cannot store CELL data as 4 bytes.

Then I looked through the code and found that if we eliminate both the
null file and the multiple byte size CELL files, then the file handling
code becomes greatly simplified. I noticed that the floating point code
uses XDR, thus, if we save 4 byte CELL data only, then we can use XDR
for CELL files as well. What do people think?

A couple of things I saw in my brief look:

In the file src/libes/gis/G.h XDR_FLOAT_NBYTES and XDR_DOUBLE_NBYTES are
both hardcoded to 4 and 8. Shouldn't these be based on sizeof(FCELL) and
sizeof(DCELL)?

In the same file, the G__ structure defines both "fp_nbytes" and inside
the fileinfo struct "nbytes". But it seems that the code (at least
G__open_cell_old() in src/libes/gis/opencell.c) uses the fileinfo nbytes
value, so does anyone know what the fp_nbytes is used for?

Finally, out of the 8 people that gave an opinion concerning removing
the "0 = no data" feature, 7 of them indicated they would like it
removed. Furthermore, some would like to see the null file removed in
5.0 as well. I originally planned to actually leave the null file in
place and only change references to it in the code that users would see.
The reason for this was that eliminating the null file requires major
changes to the gis library and I think changing it is not a good idea
when we are trying to finalize a release. However, with this new input
from the users, perhaps we need to think about the right course of
action. I still think we should keep the null file for now but maybe
others have different opinions.

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