3

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?

Tim Autin
  • 594
  • 3
  • 18
  • 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 http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdalwarp-crash-td5036575.html. 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: https://gis.stackexchange.com/questions/89444/file-size-inflation-normal-with-gdalwarp), 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 09: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 09:25
  • Yes, same result :/ – Tim Autin Aug 14 '18 at 09:34
  • Might be worth noting that generating to 90m resolution seems to work (but the patterns may simply be too small to be seen at that resolution). – Tim Autin Aug 14 '18 at 09:37
  • 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 09:43
  • Adding a -wm 2047 option to gdalwarp seems to make it working. At least GDAL began the process (without the option it crashes after a few seconds). I just hope it won't crash after 3-4 hours... I'll let you know! – Tim Autin Aug 14 '18 at 09:48
  • So, with the -wm 2047 it crashed after a few minutes... – Tim Autin Aug 14 '18 at 10:04
  • Resolution of the raw.tif is 1296001 * 417601. It's the 30m resolution SRTM file, so I'm not oversampling. Result with -r average is a little bit better but the pattern is still there. – Tim Autin Aug 14 '18 at 10:06
  • But using the bilinear resampling is working, thanks a lot man! – Tim Autin Aug 14 '18 at 10:22
  • Oh well, in fact I get the integer overflow again when using the bilinear resampling on the whole tif :@ ... – Tim Autin Aug 14 '18 at 11:45
  • @TimAutin were you able to resolve this? – jwx Apr 19 '19 at 18:42
  • Not really, I ended up spliting the task in multiple times, processing tiles of 1° * 1° and merging the final result. – Tim Autin Apr 20 '19 at 19:15

0 Answers0