I have a number of raster datasets (with common projections, pixel sizes, and pixel alignments) that I want to mosaic into a single dataset. The source datasets overlap in a number of areas; in those areas, I want to use the newest data (which I can already determine easily on my own). What's the easiest way to do this with GDAL?

GDAL's virtual format seems ideal here; I can just throw all of the source datasets into a single .vrt file and then use that .vrt file in subsequent processing. I can't tell, though, how (or even whether) I can make sure that, say, source dataset "A" takes precedence over source dataset "B" in places where "A" and "B" overlap. I could also use gdal_merge.py (or gdalwarp) to create a new dataset, but I don't want to do that if it's not necessary, because a) it'll take a while to copy all of the data from the source datasets to the destination; and b) I'll waste a fair bit of time copying data that'll just be overwritten by later files, in the case of spatial overlaps.

What's my best path forward?

  • 1
    As far as I remember, you can order the files in your VRT manually, by editing the VRT-file in a text editor. However, you may have too many files for that to make sense, in which case you can create a template VRT by the standard 'gdalbuildvrt output.vrt *.tif' and then program your way out of the ordering them correctly. Commented Feb 10, 2016 at 14:55
  • But does the order in a .vrt file matter and, if so, which way? (i.e. Does the first file take precedence, or the last?) The only reference I've found to ordering of a virtual dataset is in gdalbuildvrt's man page, which says, "If there is some amount of spatial overlapping between files, the order may depend on the order they are inserted in the VRT file, but this behaviour should not be relied on," which doesn't seem very promising.
    – asciiphil
    Commented Feb 10, 2016 at 15:03
  • I'm quite certain that the order does matter, but I don't have any files to test it with right now. Should be easy to test for you. Just build a VRT with only two images where you have an overlap and see if things change if you modify your VRT. Commented Feb 10, 2016 at 15:09
  • I'm concerned about the "don't rely on this behaviour" bit in gdalbuildvrt's documentation. That sounds like any ordering I might discover empirically could change in future GDAL releases.
    – asciiphil
    Commented Feb 10, 2016 at 15:12
  • As far as I can see, that "don't relay on this behavior" bit has been there since the first documentation available (albeit with a typo in the original) - see web.archive.org/web/20081227024932/http://www.gdal.org/… - I wouldn't worry about it changing any time soon. Commented Feb 10, 2016 at 15:16

1 Answer 1


Creating a GDAL virtual dataset is probably the most efficient approach. In cases where multiple source datasets overlap within a VRT dataset it appears that the last one listed in the .vrt file takes priority, so in this specific case, the VRT should have the newer datasets listed last.

The warning in the gdalbuildvrt documentation about not relying on the ordering of datasets in the .vrt file is a little worrisome, but according to Mikkel Lydholm Rasmussen in the comments, it's been there for a long time without any apparent changes to the code, so it's probably safe to ignore it for now.

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.