Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to process some bioclimatic raster files, such as can be downloaded from (bioclim set). They seem to have nodata values set to -3.4e+38 according to QGIS (looking at the output of gdalinfo, it's -3.39999999999999996e+38).

It seems that gdal tools aren't able to deal with this nodata value, and qgis doesn't seem to be able to recognise it either. In the layer styling, there's an entry for -3.4e+38 set to 100% transparent, but it still displays such values, even though the "Identify features" picker shows them as having value -3.4e+38.

I have tried creating a vrt to convert the nodata values to -9999 instead, but that hasn't worked either.

How can I process such files to have usable nodata values?

nodata values picked up from file setting transparency has no effect

share|improve this question
Supposedly in the new version qgis has MUCH better nodata support. I had many "nodata" issues with 1.8 (especially when I was trying to calculate the histogram or means within an area). – nickves Nov 29 '12 at 14:29
up vote 3 down vote accepted

GDAL can handle these values. In fact GDAL's default NoData value is pretty much the same as yours. I think the problem is a floating point error in QGIS though. I have the same problem with floating point NoData values.

If you want to change the NoData value using GDAL you could use gdalwarp or perhaps gdal_translate and set the nodata value to an integer from there (-dstnodata and -a_nodata respectively). For inastance, I have had success setting my NoData Value to -999 in a 64bit float raster in the past. However, given that we've established there is a floating point issue in this regard, I wouldn't like to guarantee this will work in all cases though.

share|improve this answer
Thanks for your answer, Sylvester. I couldn't get gdal_translate to work using gdal_translate -a_nodata -9999 input.tif output.tif although gdalwarp -dstnodata -9999 input.tif output.tif did the trick. From a 9MB input file, my approach resulted in a 26MB file, whereas gdalwarp resulted in a 52MB output file. However, if the raster contains float values, my approach won't work where this one will. – rudivonstaden Nov 29 '12 at 14:56
Have you checked if there is an open ticket in QGIS bug tracker for this? – underdark Nov 29 '12 at 15:47
The data bloat could be due either to using a greater pixel depth (63-bit vs. 16 bit, say) or could be simply due to the original being a JPEG and your new result being a TIFF. @underdark - Sorry! No, I haven't checked whether there is an open ticket. – MappaGnosis Nov 29 '12 at 16:02
@underdark I couldn't find a ticket that matched this, so I added a bug report ( – rudivonstaden Nov 29 '12 at 16:12
@rudivonstaden Thank you! – underdark Nov 29 '12 at 16:12

I managed to find a workaround for this issue by converting the data format to Int16 from Float32. The minimum value is then -32768 and can be processed as a nodata value. The following command did the trick:

gdal_translate -ot Int16 -a_nodata -32768 input.tif output.tif

There's probably a better solution, but this solves my immediate problem at least.

nodata picked up correctly

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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