[GRASS5] 0 != no data

[Eric G. Miller]

On Thu, Jun 28, 2001 at 06:37:40PM +0700, Justin Hickey wrote:
> 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.

The NULL file probably should never be bigger than the CELL data, but it
could be because it is not compressed.

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

No, I think the 4 and 8 bytes *are* the definitons for the xdr_float,
and xdr_double.  Granted, on machines with a different idea of floats
and doubles there will be a loss of precision, but I think XDR has a
type corresponding to long double as well.

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

There's more than one place where the bytes are looked at.  I believe
the "nbytes" is taken from cellhd (which is -1 for any floating point),
and then the fp_nbytes is taken from the cell_misc/<cell>/f_format file.
I'd have to look to be sure, but I think that's what is going on.  The
representation for CELL's is totally different from FCELL/DCELL.

> 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.

It's not a trivial task.  It would probably add instability to the code
base for a while...

-- 
Eric G. Miller <egm2 at jps.net>