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.


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).


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 


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.

  • 1
    Probably -3.4e+38 is not the correct nodata value but it is -3.39999999999999996e+38. If you can't use that you should probably convert source data to have nodata value that you can manage with QGIS. See gis.stackexchange.com/questions/42555/…. – user30184 May 15 '18 at 14:44
  • Have you tried without -srsnodata? gdal.org/gdalbuildvrt.html If the option is not specified, the intrinsic nodata settings on the source datasets will be used (if they exist) – user30184 May 15 '18 at 14:55

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 !

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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