I'm not sure if this is something that has improved in GDAL or something that could/should be fixed. I have a particular GeoTIFF here that has values (-32767) that are supposed to represent NODATA values. Note that if I run gdalinfo on this raster, it does not have any specific NODATA values defined even though the -32767 values are supposed to represent NODATA. I am using gdaldem to generate a color relief map of this file. In GDAL 2.3.1, the GeoTIFF driver seemed to do something to automatically recognize the NODATA values on the raster when running the gdaldem command and generating a color relief map. In 2.3.1, gdaldem seemed to set anything with a value <= 0.0 to a NODATA value and generate a map based on this assumption. In GDAL 3.4.2 however, gdaldem no longer seems to recognize the -32767 or any other value as a NODATA value. Maybe this works as designed since the GeoTIFF does not have any explicit NODATA value defined, but I was wondering if there's a setting or something to get gdaldem (or the GeoTIFF driver) to work the way it used to in GDAL 2.3.1. I checked out the GTiff documentation for GDAL and did not find any obvious information about this.

For example, here's the output that I get in GDAL 2.3.1:

gdaldem color-relief -alpha -of GTiff Mt_Fuji.tif colorTable.txt relief.tif
0...10...20...30...40...50...60...70...80...90...100 - done.

and here's the colorTable.txt file I'm using:

nv 0 0 0 0
0 0 0 255 255
450 0 255 169 255
900 21 255 0 255
1350 127 255 0 255
1800 234 255 0 255
2250 255 212 0 255
2700 255 159 0 255
3150 255 106 0 255
3600 255 53 0 255
4050 255 0 0 255

The output image is here:

Color relief map from gdaldem in GDAL 2.3.1

Here's the output that I get in GDAL 3.4.2:

gdaldem color-relief -alpha -of GTiff Mt_Fuji.tif colorTable.txt relief.tif
Warning 1: Input dataset has no nodata value. Ignoring 'nv' entry in color palette
0...10...20...30...40...50...60...70...80...90...100 - done.

(Note the warning message...it does not recognize any NODATA values. I think this warning message must have been added sometime between GDAL 2.3.1 and 3.4.2). The image that is output is shown here:

Color relief map from gdaldem in GDAL 3.4.2

Notice the areas where the NODATA values are filled on the corners of the raster. I can use gdal_translate with the "-a_nodata -32767" option to explicitly set the NODATA value in the raster, but I'd like to avoid doing that. I'm trying to upgrade GDAL in my software and I want the image to display the same way it used to without having to write some custom code to attempt to determine the NODATA value from each individual raster.

TL,DR: Is there a way to tell gdaldem or the GeoTIFF driver in GDAL 3.4.2 to automatically determine NODATA cells like it did in GDAL 2.3.1 or is this behavior something I'll just have to live with?

  • 1
    If gdalinfo doesn't show a defined nodata value on the source TIFF then you could try setting that using gdal_edit without having to re-write the entire raster. I don't see another way to supply the input nodata value to gdaldem directly
    – mikewatt
    Commented Jun 3, 2022 at 19:34
  • I doubt gdaldem used to interpret 0 as nodata, unless it was actually defined as such for the given raster. That wouldn't make much sense for elevation data.
    – mikewatt
    Commented Jun 3, 2022 at 19:40

1 Answer 1


As said in a comment, if you have the GDAL Python utilities available it would be best to set the nodata with

gdal_edit -a_nodata -32767 Mt_Fuji.tif

And if you do not have the Python utilities you can use virtual raster VRT as an interim format

gdal_translate -of VRT -a_nodata -32767 Mt_Fuji.tif Mt_Fuji.vrt

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.