3

I am trying to create a 4-band raster image using gdal_merge.py but only the first band is getting the correct no data values assigned, according to ArcGIS and PCI. Here is my command:

gdal_merge.py -co COMPRESS=LZW -co BIGTIFF=YES -ul_lr %s -ot Int16 -separate -n -999 -a_nodata -999 -o %s %s' % (extent, outputFile, inputFilesString)

where:

inputFilesString = "input1.tif input2.tif input3.tif input4.tif"

Where there is NoData, ArcGIS is showing NoData for Band1, but 0's for Bands2-4. However, this problem doesn't occur in QGIS (where all bands show NoData where they should). Also, according to gdalinfo (and ArcGIS/QGIS properties), each band's NoData value is correctly -999. All these things were leading me to think it could just be a bug in ArcGIS/PCI. However, when I read these bands (2-4) into individual arrays and write each of them each back to their own single band .tif (not setting the ND val) using GDAL API, it is writing these NoData areas as 0 while for band1 it correctly writes them as -999. So it is likely an issue in GDAL, not Arc/PCI.

I double checked (in ArcGIS and QGIS), and each of the individual tiffs that are the inputs for gdal_merge have NoData values of -999 that are correctly in areas where there should be NoData.

This is just not translating to the tiff output from gdal_merge.

Is this a bug with GDAL? Or am I not correctly assigning the NoData values in the gdal_merge.py command? From the documentation, it appears the NoData values should be assigned once for all bands as opposed to explicitly defining the values for each band, but I could be wrong.

UPDATE: I reran the exact same command as above but without the "-n -999" string, as suggested in an answer below, but nothing changed.

Improve this question

3 Answers 3

Reset to default
2

So I encountered this problem again, and I found a solution thanks to Dr. E. answer on this similar question:

  • The -n option allows you to ignore pixels with a certain value. This can be useful if there is no NoData value set in your input band, or if you want to ignore another value than your NoData value.
  • The -init option allows you to place a certain value at the place of the ignored pixels.

In your case, you can get rid of the -n -999 option and add a -init -999 option in your gdal_merge command, and the output should have -999 set as NoData value for each band.

Improve this answer
1

This behavior is likely due to using the -n flag, which means "ignore these pixels". As a result there may not be values written into raster bands. Though the NoData value for each band is set to -999, the actual pixels values are not -999, because they were never written.

Improve this answer
1
  • Thanks for responding. I tried the exact same command as above but without the -n -999 flag and the same thing happened. very frustrating!
    – user20408
    Jan 9, 2017 at 21:13
1

I encountered a similar problem when merging sentinel-2 bands of coastal areas on which I masked the continent, and which already had nodata pixels.

I solved the issue by changing my workflow and making sure that I assigned every nan/nodata/null pixel to the same nodata value (in your case -999) at each step of the process.

Now I can't reproduce the problem anymore.

Maybe check the method used to assign these nodata pixels to the indivual files beforehand ?

(By the way, isn't this question a duplicate of GDAL_merge - Stacking Files - Nodata Value wrong ?)

Improve this answer

Your Answer

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

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