Solved: GDAL accuses no free disk space when there is plenty

Fellow researchers and open-source GIS enthusiasts,

Welcome to my blog!

I’d like to start with a disclaimer – I may be a researcher of this very area but that doesn’t mean everything I do or write here will work for you, in your own desktop configurations and package versions. I have no responsibility if you lose data or mess up your installation. I also do not authorize any copies of my content.

Recently, I ran into an error that did not seem to make sense. When running GDAL Translate tool on command line via Bash, gdal_translate accused no free disk space to make a simple clip and reprojection, but there was plenty. Or I thought so.

The error I got on the terminal was:

ERROR 3: Free disk space available is 85802630536 bytes, whereas 730874237760027488 are at least necessary. You can disable this check by defining the CHECK_DISK_FREE_SPACE configuration option to FALSE.
Input file size is 52258, 16564

For a raster that was supposed to have ~50 mb , this oversized output does not match the predicted.

However, the solution for this issue was quite simple.

The limits for the output raster were initially given in projected coordinates, while the input raster was in geographical coordinates. This way, it seems the GDAL tool took UTM extent (in meters) and interpreted it as an extent in latitude and longitude (degrees). Technically, I was asking to project the raster around all earth approximately 165 times. Of course it would take an enormous disk space to do that!

The command I was using was:

C:/…/gdal_translate.exe -projwin 111500.205796943 6802000.89149315 171000.731271099 6760000.94138945 -of GTiff "C:/…/input.tif" ./output.tif

To solve it, I just specified the coordinates in which the extent was being given using the -projwin_srs option. In case, UTM Fuse 22 South (EPSG:32722).

C:/…/gdal_translate.exe -projwin 111500.205796943 6802000.89149315 171000.731271099 6760000.94138945 -projwin_srs EPSG:32722 -of GTiff "C:/…/input.tif" ./output.tif

Solved!

Summary: the cause of the problem was that the limits were given in projected coordinates, while the input raster was in geographical coordinates.