4

I am processing several large (>40GB) geotiffs with GDAL_CALC.py and I encountered this error when attempting the process:

Error! Dimensions of file image.tif (198000, 126000) are different from other files (198752, 126000). Cannot proceed.

This was the command I use to replace problem areas in a DEM with values from another DEM:

gdal_calc -A problem_areas.tif -B mosaic_A.tif -C fill_mosaic_B.tif --outfile=dem_corrected.tif --calc="((A!=999)*B)+((A>=999)*C)"

My rather convoluted solution is to produce a convex hull vector from one raster and then use that to clip it and all other rasters with gdalwarp, thus redefining the dimensions:

gdalwarp -q -cutline convex_hull.shp -tr 0.5 0.5 -of GTiff -srcnodata 0 -dstnodata 0 mosaicA.tif mosaicA_clipped.tif

I imagine each clip will take at least a day to process (one is processing slowly as I write this). Does anyone know if it is possible to calculate (using GDAL_calc.py) rasters that have different dimensions without resampling or clipping the rasters? Is there an easier way to avoid adjusting the dimensions, or is this the correct (albeit painful) approach? For instance, can the one problematic file be clipped to the dimensions of the other DEMs?

4
  • 1
    No, you'll have to clip to match. But you can speed up the process considerably by writing out a VRT instead of a GeoTIFF. gdalwarp -of VRT -q -cutline convex_hull.shp -tr 0.5 0.5 -of GTiff -srcnodata 0 -dstnodata 0 mosaicA.tif mosaicA_clipped.vrt
    – user2856
    Feb 6, 2017 at 21:38
  • But you can't use VRTs with gdal_calc.py, correct?
    – Cliff
    Feb 6, 2017 at 21:40
  • 1
    No, not correct. Input VRTs are fine. You just can't output a VRT from gdal_calc.py
    – user2856
    Feb 6, 2017 at 21:41
  • Ok, tried it and you're right, it's a lot faster. I should have thought about using VRTs for this as I use them throughout earlier processing stages. Thanks again for the suggestion!
    – Cliff
    Feb 6, 2017 at 21:47

2 Answers 2

5

No, you'll have to clip to match. But you can speed up the process considerably by writing out a VRT instead of a GeoTIFF.

gdalwarp -of VRT -q -cutline convex_hull.shp -tr 0.5 0.5 -of GTiff -srcnodata 0 -dstnodata 0 mosaicA.tif mosaicA_clipped.vrt
1

Gdal 3.3 introduces an option --extent for gdal_calc to solve the problem of dimensions that don't match.

The Documentation provides more info.

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.