Given a West North East South bounding box, I want to crop this data from a hundreds of inputXX.tif. Nearly every times but once, the query first print out that it “falls completely outside raster extent but is going on [processing it] however”, then uselessly start to process the out-of-range raster, spenting huge amoint of time on EACH file.
$gdal_translate -projwin 0 55 -10 45 ./data/input${i}.tif ./tmp/crop.${i}.tmp.tif
Input file size is 6001, 6001
Computed -srcwin 296400 -57000 38400 39000 from projected window.
Warning: Computed -srcwin 296400 -57000 38400 39000 falls completely outside raster extent. Going on however.
0...10...20...30...40...50...60...70...80...90...100 - done.
As I’am processing SRTM3′s 871 files via a makefile-bash loop…
#!bash
files=(`ls ../data/cgiar-csi_90/ | grep .tif$`)
for i in "${!files[@]}"
do
gdal_translate -projwin $WEST $NORTH $EAST $SOUTH ../data/cgiar-csi_90/${files[${i}]} ./tmp/crop.${i}.tmp.tif
done
gdal_merge.py -o ./crop_xl.tmp.tif ./tmp/crop.*.tmp.tif -n -32768
…How to NOT process such raster when query is outside the raster extent ? and pass without error.
Note: gdal_translate doesn t seems to have native way to jump over such out-of-range inputs, as far as i understand.