[GRASS5] 0 != no data

[Justin Hickey]

Hi Michel

Michel Wurtz wrote:
> 
> Justin Hickey wrote:
> >
> > Interesting, but I think you may be thinking of instances where 
> > Grass interprets CELL files as unsigned 1 byte values (ie all
> > values are in the range of 0 to 255). However, Grass cannot change
> > the size of type CELL, so CELL files can only be 1 byte data if all
> > CELL values are 1 byte. In the file src/include/gis.h we have the
> > following line:
> >
> > typedef int CELL;
> >
> 
> 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.

>  I have also some
> (uncompressed) raster files clearly in bytes (image size = row x 
> column)

Hmmm. Did these files originate with Grass 4.x? Perhaps they are still
in Grass 4.x format (ie you never saved these maps using Grass5). In
this case, Grass would represent your data with 4 bytes internally (ie
when Grass reads your file into memory) but the file would be unchanged.
If these files originate with Grass 5 then I would say that whatever
module saved the file does not save CELL data but uses the header
"format" field instead. This would indicate (to me anyway) that the
module in question was not converted to floating point code properly,
since the resulting file would not be CELL data.

Anyone with more knowledge about the "format" field please clarify how
it works in Grass 5.0 (if at all).

> > Thus, all CELL values would be 1 byte if type int was 1 byte. Since 
> > most machines define int as 4 bytes, then I think what is happening
> > is that whatever modules you were using interpreted CELL values as
> > unsigned 1 byte values, but the actual size would still be 4 bytes.
> > Thus, the NULL value would still be 80000000.
> >
> [...]
> > So, if type int is a single byte, then cellNullPattern would be 80 
> > in hex.
> >
> > The critical assumption is that CELL will always be defined as a
> > "signed" integer (of any size) so that the NULL value is the lowest
> > number in the possible range of values. I think this is a safe
> > assumption since most people would expect valid CELL data to 
> > include negative values. Of course, if it is unsigned, then my code
> > will choose a value in the middle of the range, for example 128 for
> > a 1 byte unsigned int, which is not an end point of the range of
> > values.
> 
> This is the reason that make me worry about the changes : a classic 
> sheme is to use positive number for categories and 0 for "unknown" or
> NULL. On the other hand, i have found that Grass null files are often
> bigger than their raster counterpart.  Maybe just adding a field
> "null: value" in the header file have been enough... this also take a
> value from the range of possible values (which is only annoying for
> byte encoded raster), but you can choose it (and even consider that
> the null value is 0 when the field is missing, ensuring compatibility
> with grass4.0 rasters)

Well, using a "null" field in the header would be convenient, but it
would be difficult to maintain the code. For floating point data, we
have perfect values for NULL, all 1 bits, which is defined as "not a
number". That is, the value is illegal. We should not let user's choose
floating point NULL values since floating point representation differ's
per machine. Thus, you would have two mechanisms for NULL (fixed for
floating point, and user choice for CELL) which is confusing.

Also, for CELL data all integer values are valid and the NULL library
routines need to know which value should be considered NULL. Bit
patterns were chosen for the NULL value since we could ensure that for
any given machine the bit pattern would be the lowest signed int. This
is not the case if user's choose their own value, which can lead to
different patterns for NULL on different machines. It also goes against
good programming practice. NULL would be dependent on the data instead
of the system.

Anyway, I have to go. Talk to you later.

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