17

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?

zetah
  • 843
  • 2
  • 10
  • 25

3 Answers3

23

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.

markusN
  • 12,976
  • 31
  • 48
  • Had no idea about this tuning switch, which indeed speeds up the process. For reference 3000 is 3GB (more info http://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 04:30
15

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

dave_h
  • 176
  • 1
  • 3
7

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

joaoal
  • 891
  • 7
  • 14