<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi Even,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Apr 20, 2015 at 11:20 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sean,<br>
<span><br>
><br>
> Not being able to unset nodata values for datasets is tripping up GDAL<br>
> users at work. I'm considering measures that require 1-bit internal masks<br>
> (we're primarily using GeoTIFF) instead of nodata values because, unlike<br>
> nodata, the masks can be "cleared" by setting them uniformly to True using<br>
> the GDAL API (GDALFillRaster() specifically).<br>
<br>
</span>If there are external masks .msk, you'd better just deleting the file. That<br>
will save a bit some processing time for algorithms that deal with masks.<br>
<span><br>
><br>
> Background: the GeoTIFF driver's SetNoDataValue() method doesn't let us<br>
> remove or set a null or empty nodata value or unset the bNoDataSet flag.<br>
<br>
</span>A ClearNoDataValue() could be an interesting addition to the GDAL API indeed.<br>
I'm pretty sure there are tickets about that.<br>
<span><br>
> Passing a value outside the range of values in the dataset can be<br>
> problematic, especially for 8-bit data. Passing -inf, nan, or 256 to<br>
> SetNoDataValue() has the same effect on derived masks as passing 0.<br>
<br>
</span>Looking at gcore/gdalnodatamaskband.cpp, it indeeds casts dfNoDataValue to<br>
GByte without checking. Should probably do better checking, although setting<br>
out-of-range nodata value is a bit in the unspecified behaviour area.<br>
<span><br>
><br>
> I'm looking for expert advice on consequences of using masks instead of<br>
> nodata values. Are there features of GDAL that rely on nodata values and<br>
> don't respond to masks?<br>
<br>
</span>I wouldn't be surprised that some algorithms there or there only work with the<br>
nodata concept and not with the more general concept of masks (GDALContour for<br>
example from a quick searching)<br>
<span><br>
> Are there adverse implications for<br>
> interoperability?<br>
<br>
</span>In TIFF, I don't think one of nodata or nodata masks can be considered as more<br>
interoperable as the other. the GDAL_NODATA TIFF tag is a GDAL specific TIFF<br>
tag. If you use external masks (.msk), they are a GDAL specific thing. And if<br>
you use TIFF internal masks, they are quite an esoteric formulation of TIFF.<br>
<span><br>
> Would it be better to simply accept nodata values as<br>
> being part of the structure of datasets, like tiling and interleaving, and<br>
> immutable once set?<br>
<br>
</span>Some drivers accept modifying geotransform or projection, so it is not really<br>
clear what users might want to change after a dataset has been created. But in<br>
your use case, it seems that the users do have use case for clearing an<br>
existing nodata value, so I'm not sure to follow your reasonning about what<br>
should be immutable.<br>
<br>
The easiest way to clear nodata currently is to use :<br>
gdal_translate -a_nodata none in.tif out.tif<br></blockquote><div><br></div><div>Yes. Thanks for the advice, Even. I'm not ready to take on driver enhancements, so I'll work on adapting workflows to the constraints of nodata.</div></div></div></div>