[gdal-dev] gdalwarp on large files
even.rouault at mines-paris.org
Mon Jun 1 14:34:33 EDT 2009
Actually my computation was wrong. I forgot that the datatype of a DEM is
coded on Int16. So the expected size is 432000 * 40800 * 2 = 35.2 GB.
And as it is over 4GB, applications that can use such a TIFF file must be able
to deal with BigTIFF.
Le Monday 01 June 2009 20:30:46 Even Rouault, vous avez écrit :
> From the error message, I guess you are running gdalwarp on a remote server
> through a ssh connexion. There's probably a timeout that occurs since your
> operation takes hours. You should check the ssh options of the
> client/server for that.
> In your use case, if you just want to create a mosaic of SRTM files and not
> really warp them, you'd better use gdalbuildvrt to create quickly a VRT
> file (XML-based) and then translate it to geotiff. This should run much
> faster than gdalwarp. But the 432001P x 40801L output size will remain. As
> it is huge, it will also likely take some time !
> gdalbuildvrt mosaic.vrt *hgt
> gdal_translate mosaic.vrt mosaic.tif
> If you only use the mosaic with GDAL enabled tools, you can skip the
> gdal_translate step. That will save space (17.6 GB!) and time (a few
> seconds v.s. several hours).
> Best regards,
> Le Monday 01 June 2009 19:58:44 Laura Toma, vous avez écrit :
> > Hi,
> > I am trying to create a large DEM from SRTM3 data. I have a folder
> > 'australia' which includes 1060 .hgt tiles downloaded from
> > 'rome0srp01u.ecs.nasa.gov/', and I am trying to create a tiff for all
> > the tiles in this folder.
> > I have tried to run 'gdalwarp' several times and every time the
> > server gets reset (see below) after processing the first .hgt file.
> > The tiles are not that large (i think i3600x3600), but processing the
> > first tile takes hours.
> > Has anybody tried anything similar? Am I doing something wrong? Any
> > advise would be greatly appreciated.
> > thanks,
> > Laura
> > > gdalwarp *hgt srtm_mosaik_australasia.tiff
> > Creating output file that is 432001P x 40801L.
> > Processing input file S11E119.hgt.
> > Using internal nodata values (eg. -32768) for image S11E119.hgt.
> > 0...10...20...30...40...50...60..Read from remote host cod: Connection
> > reset by peer
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev