[GRASS5] Presence of NULL data in raster maps?

[Markus Neteler]

On Sat, Jul 03, 2004 at 12:02:29AM +0100, Glynn Clements wrote:
> 
> 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.

This was proposed a long time ago, I can't remember why the change
wasn't done. Maybe the person lost track on the idea.
 
> Iis this for GDAL's --with-grass functionality, or for r.out.gdal?

Currently it's for GDAL's --with-grass functionality.
The r.out.gdal script is just a workaround unless someone is willing
to contribute a C version.

> If it's the latter, it definitely *should* be honouring the mask and
> region. 

It should, but it will do only in a C version.

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

Scanning all maps first is practically a problem. Imagine all
QGIS users waiting such long for every GRASS raster map...
That's why we should find a better way.

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

Embedding the NULL values seems to be the best solution.
Would it be complicated (in fact it might simplify the GRASS 
raster lib)?

Markus