[gdal-dev] using NaN as no-data value

[Rahkonen Jukka]

Hi,

I do not quite understood why nodata is so commonly used when there are better alternatives by using alpha band or binary mask. But I do know by my own experience that they both sucks, too. Some programs consider that alpha band is for transparency, not for boolean true/false, and the theoretically best option to use mask band has the worst support in programs.

-Jukka Rahkonen-
________________________________________
Lähettäjä: gdal-dev <gdal-dev-bounces at lists.osgeo.org> käyttäjän Daniel Evans via gdal-dev <gdal-dev at lists.osgeo.org> puolesta
Lähetetty: Maanantai 30. maaliskuuta 2026 17.52
Vastaanottaja: Even Rouault <even.rouault at spatialys.com>
Kopio: gdal dev <gdal-dev at lists.osgeo.org>
Aihe: Re: [gdal-dev] using NaN as no-data value

Hi Javier,My thoughts and experience seem to be in line with the position of the essay Even links to:- Bugs that come from failing to deal with NaN nodata tend to be quite obvious "huh, my output is full of NaNs - what input am I getting them from?"- Bugs that come from failing to deal with non-NaN nodata are more likely to appear as "the numbers are a little weird; maybe my algorithm is wrong?" followed by a much longer debugging session.NaNs can be marginally more effort to deal with - by which I mostly mean needing to use `isnan` rather than `==`. However, that feels sensible - you ought to be putting in thought about how to deal with nodata, and have obviously bad results if you forget to do so. Noting the essay's comments on ensuring compatible behaviour, I've spent plenty of time debugging differences in floating point rounding when working on geospatial data, but none dealing with differences in NaN treatment (although I'll admit I've not worked much outside the comfort of x86 environments).If you're deciding to use a floating point data type to escape the limitations of integer data types, it would also generally seem sensible to me to remove the limitation of nodata values having an unclear distinction from usable values. Perhaps in the case of the DSMs you mention there was a requirement to retain the same nodata values as a previous integer version of the dataset.Cheers,DanielOn Mon, 30 Mar 2026 at 15:18, Even Rouault via gdal-dev <gdal-dev at lists.osgeo.org> wrote:Javier,> I have seen some GeoTIFFs for DSMs (float32) with NaN as no-data > value. It was not set in the metadata, but worked as that.Most (I wouldn't claim "all") code in GDAL that does no-data checking does for floating point values "if (std::isnan(pixel_val) || pixel_val == nodata)", so yes, even when not advertized as the band nodata value, a NaN pixel will be deal as it>  I think I have also seen it with NaN set in the metadata.> Also many other numbers as no-data value, like -10000 or -9999 or > -8888 (yes, and many other posible values).>> Is there any reason to prefer or discourage NaN as a no-data value for > a float32 GeoTIFF?If you are curious there is a 10 page essay on that topic on https://docs.ogc.org/per/24-040r1.html#Geomatys_contribution_misconceptions_about_NaN . Personnally that didn't help me to draw a conclusion on your question. Maybe except that both suck in different ways.Even-- http://www.spatialys.comMy software is free, but my time generally not._______________________________________________gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev