I am working with a bunch of satellites images downloaded from Google Earth Engine as .tifs. I have masked some of the pixels in Earth Engine with values of -999999 where there are clouds. Everytime I open them up in Python, I have to remove the -999999 values with something like

with rasterio.open(raster_file, 'r') as src:
    raster = src.read(1)
    raster[raster == -999999] = np.nan
    raster[raster== 0] = np.nan

I am wondering, can I just save the .tifs with np.nan instead of -999999, or could this cause some unforeseen problem down the road? I ask because I have never seen rasters with NaN for NoData values, usually it is some impossibly large number like -3.4028231e+38 or -999999. So perhaps there is some reason I am not seeing.


2 Answers 2


Generally, it's a lot better to use NaN.

I can think of one reason not to, however. NaN only exists with floating-point data types. So if you need to write out or read a GeoTIFF with integer values (e.g. perhaps you have some final classification with five classes, represented as integers 1-5), then you cannot use NaN and save it out with a UInt8 datatype (for example). The same goes for using a Byte type for a binary classification: I do this a lot with modelling, since I don't do much actual image analysis—but then I usually don't need NaN here, since the ones represent pixels that meet the criteria, and the zeroes represent everything else, including pixels that were not considered by the model, i.e. were NaN. It's useful to use these datatypes since they make output datasets a lot smaller.

Fortunately you can still use an integer to represent NaN and then declare it to be a special value, with SetNoDataValue: Python-gdal write a GeoTiff with binary color and NaN

So the downside would be: if your raster is best represented with integers, don't write an output with floats (including NaN), but delcare a special integer value, e.g. 999, instead.


Here is a downside:

>>> numpy.nan == numpy.nan
>>> numpy.isclose(numpy.nan, numpy.nan)

I'm using a python program that does raster algebra and it smartly tries to mask out nodata values using equality checks like these, so the math only operates on valid pixels. If numpy.nan is the nodata value, the masking will fail and we'll end up with unexpected nan in the output.

This is a bug in the program I'm using, but I'd also consider it a reason to avoid nan as the nodata value. Since the dataset itself is aware of its own nodata value - and good GIS software checks for it - there's no harm in using an actual number.

  • 2
    Having a bug in your program isn't a valid argument against using NaN for nodata. np.isnan() is the proper way to do that kind of check
    – mikewatt
    Dec 1, 2021 at 21:00
  • Agreed. But using a value that behaves differently than every other number in your raster might be a valid reason to avoid it.
    – davemfish
    Dec 1, 2021 at 21:33
  • 1
    It behaves differently than other numbers because it's not a number. Dec 2, 2021 at 0:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.