gis - gdalwarp too slow (compared to gdal_merge) -


i have 70+ raster images in tiff format trying merge.

originals can found here: http://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/

after pre-processing (pct2rgb, gdalwarp individual charts, gdal_translate cut collars) try run them through gdalwarp mosaic them using command this:

gdalwarp --config gdal_cachemax 3000 -overwrite -wm 3000 -r bilinear -srcnodata 0 -dstnodata 0 -wo "num_threads=3" /data/aeronav/sec/c/albuquerque_c.tif .....70 other file names ...master.tif 

after 12 hours of processing:

creating output file 321521p x 125647l. processing input file /data/aeronav/sec/c/albuquerque_c.tif. 0...10...20...30...40...

this means gdalwarp never going finish.

in contrast. gdal_merge command this:

gdal_merge.py -n 0 -a_nodata 0 -o /data/aeronav/sec/master.tif /data/aeronav/sec/c/albuquerque_c.tif ......70 plus files..... 

finishes in couple of hours.

problem gdal_merge inferior quality output because of "average" sampling. use "bilinear" @ minimum - , "cubic" sampling if possible , gdalwarp required.

why there such big difference in performance of 2 ? why doesn't gdalwarp want finish ? there other command line option speed things in gadalwarp or there way add sampling option gdal_merge ?

it seems gdalwarp not ideal command merge these geotiffs (since not interested in warping again). instead use

gdalbuildvrt /data/aeronav/sec/master.virt .... 70+ files in order 

to build virtual mosaic. , use gdal_translate convert virt file geotiff:

gdal_translate -of gtiff  /data/aeronav/sec/master.virt /data/aeronav/sec/master.tif 

thats it- took less hour (even faster gdal_merge , preservs quality of original files).


Comments

Popular posts from this blog

javascript - Count length of each class -

What design pattern is this code in Javascript? -

hadoop - Restrict secondarynamenode to be installed and run on any other node in the cluster -