[gdal-dev] Masks vs nodata?

[Even Rouault]

Sean,

> 
> Not being able to unset nodata values for datasets is tripping up GDAL
> users at work. I'm considering measures that require 1-bit internal masks
> (we're primarily using GeoTIFF) instead of nodata values because, unlike
> nodata, the masks can be "cleared" by setting them uniformly to True using
> the GDAL API (GDALFillRaster() specifically).

If there are external masks .msk, you'd better just deleting the file. That 
will save a bit some processing time for algorithms that deal with masks.

> 
> Background: the GeoTIFF driver's SetNoDataValue() method doesn't let us
> remove or set a null or empty nodata value or unset the bNoDataSet flag.

A ClearNoDataValue() could be an interesting addition to the GDAL API indeed. 
I'm pretty sure there are tickets about that.

> Passing a value outside the range of values in the dataset can be
> problematic, especially for 8-bit data. Passing -inf, nan, or 256 to
> SetNoDataValue() has the same effect on derived masks as passing 0.

Looking at gcore/gdalnodatamaskband.cpp, it indeeds casts dfNoDataValue to 
GByte without checking. Should probably do better checking, although setting 
out-of-range nodata value is a bit in the unspecified behaviour area.

> 
> I'm looking for expert advice on consequences of using masks instead of
> nodata values. Are there features of GDAL that rely on nodata values and
> don't respond to masks? 

I wouldn't be surprised that some algorithms there or there only work with the 
nodata concept and not with the more general concept of masks (GDALContour for 
example from a quick searching)

> Are there adverse implications for
> interoperability?

In TIFF, I don't think one of nodata or nodata masks can be considered as more 
interoperable as the other. the GDAL_NODATA TIFF tag is a GDAL specific TIFF 
tag. If you use external masks (.msk), they are a GDAL specific thing. And if 
you use TIFF internal masks, they are quite an esoteric formulation of TIFF.

> Would it be better to simply accept nodata values as
> being part of the structure of datasets, like tiling and interleaving, and
> immutable once set?

Some drivers accept modifying geotransform or projection, so it is not really 
clear what users might want to change after a dataset has been created. But in 
your use case, it seems that the users do have use case for clearing an 
existing nodata value, so I'm not sure to follow your reasonning about what 
should be immutable.

The easiest way to clear nodata currently is to use :
gdal_translate -a_nodata none in.tif out.tif

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com