[GRASS5] Presence of NULL data in raster maps?

[Glynn Clements]

Markus Neteler wrote:

> there seems to be missing a function which reports the presence 
> of NULL data in a raster map. This functions is needed for 
> interfacing GRASS to GDAL, especially for 8 bit data.
> At time the entire map must be scanned, right?

Right.

> This can become pretty time consuming.

Probably; but that doesn't automatically make the alternatives
feasible.

> Is it sufficient to test the presence of the 'null' file 
> within this potential function?

I don't know.

If there isn't a null file, and it isn't a reclass map, and there
isn't a mask, and the current region doesn't extend outside the map's
boundaries, then I don't think that there can be any null cells.

OTOH, even if there is a null file, it is presumably still possible
that none of the cells are actually null.

In any case, we should arguably be getting rid of the null file and
just storing null values in the cell file. ISTR that the use of a
separate null bitmap was identified as a significant performance hit.

Iis this for GDAL's --with-grass functionality, or for r.out.gdal? If
it's the latter, it definitely *should* be honouring the mask and
region. For the former, you can presumably ignore the mask and region,
although there may still be the issue of reclass maps (a reclass map
won't have its own null file, and may have null cells even if the
underlying map doesn't).

> A bit dirty, but otherwise the
> cellhd file needed an addition (null: true or whatever).

Or you just accept the cost of scanning for nulls, or you assume that
all maps conceptually have null cells, even if, for some maps, the
number of null cells happens to be zero.

Regarding the approach of adding a null flag to the cellhd file, I
suspect that it may be harder to get right than it might initially
appear. I.e. you could spend the next few years occasionally bumping
into cases where the flag ends up out of sync with reality.

-- 
Glynn Clements <glynn.clements at virgin.net>