Solved: GDAL accuses no free disk space when there is plenty
GDAL Translate Error 3
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
Summary: the cause of the problem was that the limits were given in projected coordinates, while the input raster was in geographical coordinates.
- How and when to use QGIS 3 tools “Warp (reproject)”, “Clip raster by extent” and “Clip raster by mask layer”
- Batch processing – automatizing the use of GDAL and SAGA GIS tools using Bash Shell scripts
- How to open, edit and save raster files (.tif) using Python
- Using SAGA Raster Calculator on QGIS - a quick tutorial
- When I mosaic two rasters, the size of the resulting raster is almost always larger than the sum of the sizes of the original rasters. Why is that?