[GIS] Virtual Raster Mosaic – gdalbuildvrt – data gaps

gdalgdalbuildvrtqgisraster

I'm trying to create a virtual mosaic of several raster images (.tif) in R using the function "gdalbuildvrt" from the "gdal" package. The raster images are flight lines from a drone flight over a field.

I specified the corresponding NoData value for the input raster in the function

gdalbuildvrt(gdalfile = paste(--path--), 
         output.vrt= paste(--path--), 
         separate=FALSE, srcnodata="-3.4e+38", vrtnodata="-3.4e+38", 
         overwrite = TRUE, r="average")

The "NoData" areas of the individual raster files seem to overwrite each other, resulting in a mosaic with missing data.

faulty_mosaic

The raster images are in formatted "Float32 – Thirty two bit floating point" data type and the same value specified as their NoData value (I checked in QGIS, checking the value from an area without data).

raster_file_nodata

Manually merging the raster files in QGIS using Raster –> Tools –> Merge is successful and yields a correct mosaic without the white overlapping areas.

gdal_merge.bat -ot Float32 -of GTiff -o 
C:/.../OUTPUT.tif --optfile 
C:/...\mergeInputFiles.txt

correct_mosaic

Also, when changing the data type to 8bit (0 to 255) beforehand and defining "255" as srcnodata value, the resulting mosaic from the gdalbuildvrt function is correct. However, that's not an option since that requires stretching the data range of the individual rasters – which I don't want to do before the whole mosaic is created.

What is the fault with my approach? I've also tried specifying various other nodata values for srcnodata/vrtnodata ("nan", "0", "3.4e+38") but I get the same results.

Best Answer

Without -srcnodata or changing it to -3.39999999999999996e+38 didn't help and yielded the same faulty mosaic with data gaps.

However, changing the -srcnodata to "-3.3999999521443642e+38" (as displayed in QGIS) worked, and now I can obtain a proper mosaic. I understand that this is just a workaround and rather should be fixed by converting the source data. Thank you @user30184 !