[GIS] Keep NoData values when using gdal_merge

gdalgdal-mergejavascriptnodata

I'm using gdal_merge to join several BioClim rasters, which I will then feed into a Java program that "snaps" points to the nearest BioClim raster tile of non-NoData value. However, when I run gdal_merge, it assigns the NoData value of the BioClim file (NoData Value=-3.39999999999999996e+38) to each of the tiles as if it's a proper value (I think).

Running gdal_info on the merged raster shows that value as the minimum, with no indication of a NoData value; whereas running gdal_info on one of the pre-merged raster tiles shows it assigned to the NoData values.

I think this is creating an IndexOutOfBoundsException error when I then run the Java program… preventing me from snapping the points successfully.

I have two questions:

1) How do I use gdal_merge such that the NoData classification of cells are preserved in the merged output?

2) Could something else be causing the IndexOutOfBoundsException? I'm a novice with Java programs.

Best Answer

In order to maintain NoData cells in the output you seem to need to use both the "-n" option (specifying the NoData value for the input) and the "-a_nodata" option (specifying the NoData value for the output). For example:

gdal_merge.py -n -9999 -a_nodata -9999 -o merged.tif in*.tif

My version of gdal_merge does not overwrite existing files (it just touches them), so I have to remove "merged.tif" before running the command.

Related Solutions

GDAL – Resolving Nodata Value Issues When Stacking Files with GDAL_merge

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.

gdal – Replacing NoData Values by a Constant Using GDAL CLI Tools

One (slightly hacky) way of doing it is to use an intermediate VRT with the gdalbuildvrt command and specifying a new NoData value with the srcnodata and vrtnodata arguments. This does actually change the underlying values.

First, get your actual nodata value from gdalinfo:

$ gdalinfo input.tif | grep No
NoData Value=3.39999995214436425e+38

Assign it to a bash variable: na=3.39999995214436425e+38

Or if you have jq installed (in ubuntu/debian based Linux distros sudo apt install jq):

na=$(gdalinfo input.tif -json | jq '.bands[0].noDataValue')

And use it in the following examples:

gdalbuildvrt -srcnodata ${na} -vrtnodata 0 output.vrt input.tif

However, it also sets those values to NoData in the output, so you need to specify a different value to be considered as NoData when converting to your final GeoTIFF.

gdal_translate -a_nodata ${na} output.vrt output.tif  # original 3.39999995214436425e+38 values from input.tif are now 0

Chaining it together with a pipe so you don't need to clean up any intermediate VRT files:

gdalbuildvrt -srcnodata ${na} -vrtnodata 0 /vsistdout/ input.tif | gdal_translate -a_nodata -9999 /vsistdin/ output.tif

Best Answer

Related Solutions

GDAL – Resolving Nodata Value Issues When Stacking Files with GDAL_merge

gdal – Replacing NoData Values by a Constant Using GDAL CLI Tools

Related Question