I masked a large raster stack by separating the stack in 18 chunks, masking each and writing each chunk to a file (due to memory problems).

Then, I use gdal_merge to stack the 18 GTiff files. All files have exactly the same resolution and extent. Also, the nodata value (-32768) and the data type (INT2S) are equal.

The resulting file (GTiff format) has the correct nodata value and data type in each band. However, beginning with the 6th band, the nodata pixels are changed to zero. The nodata value is still set to -32768, but the pixels that were -32768 (nodata) are 0 now.

When I stack the files beginning with, for example, the 16th up to the 18th file, the first 5 bands are correct again, and starting at band 6 (which comes now from the 16th, not the 1st file), the nodata values are set to 0 again. This means that the files itself are ok.

This behaviour is so strange that I can't even start debugging. I have no idea where the problem is.

Does anyone have an idea where this behaviour comes from? Please let me know if you need additional information.

  • did you specify the source no data value in the gdal_merge.py command, i.e. -n -32768
    – dmci
    Apr 26, 2016 at 13:04
  • Yes, I specify the following parameters: -a_nodata -32768 -n -32768 -of GTiff -separate
    – bask0
    Apr 27, 2016 at 8:15

2 Answers 2


Looking at the code of gdal_merge what I understand is this:

The effect of the "-n" option is the same as using input files with the NoDataValues set (to the same number). In both cases, gdal_merge ignores the pixels which present these values (the ones set beforehand as NoData or the ones set by the "-n" option). The value it places at their place is the value set by the "-init" option (if set, otherwise 0).

So, in your case you should just add the option "-init -32768" at the gdal_merge call (and you can ignore the -n option.

N option is useful, I guess, only if your input files don't have NoDataValues set, if they are set to different numbers or if you want to ignore other values, apart from the ones already set to NoData to your input.

My conclusion is that it's extremely important to always set your -init value in order to keep control of your dataset.


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 -32768) 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 ?

(Similar question posted more recently: gdal_merge.py not properly assigning NoData values)

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.