14

I wanted to merge around 20 dem tiffs each around 100MB, and I used gdalwarp (I know about virtual file option):

gdalwarp $(list_of_tiffs) merged.tiff

However this command took very long time, and after some 15min it was processing 5th image from set. I terminate it.

I then found that gdal_merge.py script can be used also for mosaicing, and tried it:

gdal_merge.py $(list_of_tiffs)

which completed in less then 3min.

As I expected that both commands would produce same result, I wonder what's the difference between the two, as to why gdalwarp takes so much time if result is same?

19

While I don't know why GDAL provides this overlap in functionality, be sure to set the cache for gdalwarp to make it really fast:

# assuming 3G of cache here:
gdalwarp --config GDAL_CACHEMAX 3000 -wm 3000 $(list_of_tiffs) merged.tiff

Be sure to not define more cache than having RAM on the machine.

  • Had no idea about this tuning switch, which indeed speeds up the process. For reference 3000 is 3GB (more info trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp) I have NumPy build with MKL in my system Python, but still gdalwarp must be doing something more, as NumPy can't be faster then C implementation, although can reach it. – zetah Dec 27 '12 at 4:30
  • is 3000 really 3GB or should it be 3072? – miln40 Nov 12 '17 at 13:29
12

I just happened to come across this question and a potential answer when looking for something else.

gdal_merge.py uses nearest neighbor resampling. If you want control over the resampling used, you should use gdalwarp instead.

source: trac.osgeo.org

5

gdal_merge.py loads all files into memory before processing them. therefore it is not able to process large files if your memory is small. see here

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.