21

I am trying to process some bioclimatic raster files, such as can be downloaded from http://www.worldclim.org/current (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

Improve this question
1
  • 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
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

Improve this answer
6

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.

Improve this answer
7
  • 1
    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
  • 1
    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 (hub.qgis.org/issues/6786).
    – rudivonstaden
    Nov 29 '12 at 16:12
  • 1
    For smaller file size, you just need to add -co COMPRESS=LZW.
    – j08lue
    May 19 '16 at 15:06
0

The answer to this question would probably also solve this problem: Changing nodata pixels of -3.40282347e+38 to a different number in QGIS

In summary, you can use r.null from processing toolbox to change the values.

Improve this answer
0

you could try gdal_calc.py input.tif --outfile=output.tif --calc="A*(A>0)" --NoDataValue=0

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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