Recommended NoData value for DEM/DTMs created using gdal

Question

Background info: I've been generating some raster DTMs from vector points using gdal_rasterize, and was wondering if there is any consensus as to what is the best NoData value to use. The Python GDAL script I'm using appears to default to 0, but obviously that might be problematic if my country-wide dataset has areas close to sea level.

Sample of script I'm using:

try:  from osgeo import ogr, osr, gdal
except: sys.exit('ERROR: cannot find GDAL/OGR modules')

nztmSRS = osr.SpatialReference()
nztmSRS.ImportFromEPSG(2193)
xRes, yRes =(5,5)  #Spatial resolution defaults to 5 (metres)

src = "Points.shp"
dst = "Output.tif"

gdal.Rasterize(dst, src, outputSRS=nztmSRS.ExportToWkt(), xRes=xRes, yRes=yRes, noData="0",attribute='ELEVATION')

I've seen NoData values out there choosing -9999, -3.4028230607371e+38, etc. There are probably valid arguments for using any of those, and I'd like to have a feel of A) what the NoData options are and B) what seems to work better in different use cases. E.g. when:

1. The output will need to be reprojected using gdalwarp
2. The outputs will need to be mosaicked together with other geotifs
3. The output will need to be loaded into Spatialite/Postgis down the line

Answer 1

For floating-point DEMs, I use -9999 because it's easy to remember, easy to type and, in terms of terrain elevations (in metres), impossible. If you can meet the latter condition, it doesn't really matter what you choose. A lot of climate-related datasets use some variation on the negative-multiple-nines theme, but it's conceivable that some other scientific dataset could have -9999 as a valid value. Ultimately it depends on the context.

With integral types, you have to be careful. If you're using the Byte type, you only have 256 values to work with. If you cannot afford to dedicate one to nodata, you have to choose a larger type. In the case of Byte, you might change to Int16 and use -1 as your nodata value. If you were using Byte before, you didn't need any negatives to represent your data, so -1 is free. However, you've just doubled the size of your dataset for the sake of one nodata value.

One final thing: sometimes your choice of nodata value can help you discover errors in your algorithms. If I'm computing some canopy metrics, a -9999 will skew my results in an obvious way. If I'm using zero or some other small value, I may not notice it at all. This is mostly an issue if you're writing your own code, or haven't set the nodata value correctly.

If your nodata value is properly declared, mosaicking, projection and loading into databases shouldn't be affected by your nodata choice. No calculations will be performed on nodata pixels so wrapping, saturation, etc. shouldn't be a concern either.