[gdal-dev] Quick question about gdal2tiles

Even Rouault even.rouault at spatialys.com
Wed Jan 28 12:28:46 PST 2015


Le mercredi 28 janvier 2015 20:17:08, Jorge Arévalo a écrit :
> Hi,
> 
> I'm working with a patched version of gdal2tiles, which makes use of
> parallelization:
> http://gis.stackexchange.com/questions/7743/performance-of-google-map-tile-
> creation-processes/74446#74446
> 
> I want to create a complete TMS cache from raster imagery. No
> assumptions about SRS of data type for input data.
> 
> I want the tiling process to be as fast as possible (gdal2tiles is
> really heavy process), do you have any recomendations about the data or
> the parameters used?
> 
> Right now, I'm doing this
> 
> Step 1: build vrt from input images
> 
> gdal_vrtmerge.py -o merged.vrt <list of input tif files>
> 
> Step 2: build tiles from vrt file
> 
> gdal2tiles.py -r cubic -s epsg:XXXX -z 0-19 -w all merged.vrt tms_dir
> 
> Even with parallelization, process still feels really slow. Would it be
> faster if, for example, I convert all my input files to epsg:3857? Or if
> I scale them to 8-bit? Or if I use near resampling method instead of
> cubic? (I'm using cubic because I'm working with continuous data:
> satellite images, am I doing it right?).

From a quick look at the source, it seems that there's an optimization if the 
input SRS == output SRS that avoids going through the warped VRT path.

That said, we definitely need one or several maintainers for gdal2tiles. There 
are quite a faw patches floating around in Trac that would need someone to 
review, test, fix, apply them, as well as writing tests (no autotest for 
gdal2tiles yet), etc...

> 
> Any other tips?
> 
> Many thanks in advance
> 
> Best regards

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list