I retrieved the SRTM 1" data and merged it in one huge tif. Now I want to warp it. It's working fine for low resolution (eg 5000, 1000, 500), but it doesn't for 90m resolution. I'm using this command:

gdalwarp -multi -co BIGTIFF=YES -co TILED=YES -co COMPRESS=LZW -co PREDICTOR=2 -t_srs "+proj=merc +ellps=sphere +R=6378137 +a=6378137 +units=m" -r bilinear -tr 90 90 src.tif dst.tif

And Gdal crashes with the following error:

Creating output file that is 445278P x 177313L. Processing input file raw.tif. 0ERROR 1: Integer overflow : nSrcXSize=1296001, nSrcYSize=417601

Is there something I can do, other than splitting my tif in several parts?

EDIT: I tried the solution proposed here: File size inflation normal with gdalwarp?

gdalwarp -tap -tr 30 30 -t_srs "+proj=merc +ellps=sphere +R=6378137 +a=6378137 +units=m" -of vrt raw.tif test.vrt
gdal_translate -co BIGTIFF=YES -co TILED=YES -co COMPRESS=LZW test.vrt warp.tif
gdaldem hillshade -z 1 -compute_edges -co BIGTIFF=YES -co TILED=YES -co COMPRESS=JPEG warp.tif hillshade.tif

While it indeed solves the integer overflow error, here's the result:

enter image description here

When using normal process (compressed gdalwarp + gdaldem hillshade), I get this (but I get the integer overflow error when running on my huge tif, here I ran it on a smaller file):

enter image description here

Is there a way to get the gdalwarp + gdal_translate + gdaldem solution to produce a result without the weird pattern?

  • The error message, if I read it right, means that GDAL is reading 1296001x417601 pixels worth input data. It exceeds the 2 GB limit in memory allocation osgeo-org.1560.x6.nabble.com/…. How have you created your merged, huge source tif? Is it tiled? – user30184 Aug 13 '18 at 18:18
  • Thanks! I created my tiff with gdal_merge.py. LZW compressed, tiled, bigtiff=yes. I think I found a solution (here: gis.stackexchange.com/questions/89444/…), I'm still waiting the end of the process to visualise the result. – Tim Autin Aug 13 '18 at 19:01
  • So, the solution I found indeed avoids the integer overflow, but the image produced has a weird pattern. I edited my question. – Tim Autin Aug 14 '18 at 9:07
  • Interesting, translate into vrt should not affect the data at all. Is the result the same if you run gdaldem from test.vrt? – user30184 Aug 14 '18 at 9:25
  • 1
    What is the native resolution? If you oversample then the default nearest neighbor resampling may lead to artifacts. I would have a try with "average". – user30184 Aug 14 '18 at 9:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.