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

[Daniel Evans]

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,
Daniel

On 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.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20260330/4a25df5e/attachment-0001.htm>