[gdal-dev] Quick question about gdal2tiles

[Jorge Arévalo]

El jueves, 29 de enero de 2015, Even Rouault <even.rouault at spatialys.com>
escribió:

> Le jeudi 29 janvier 2015 00:05:32, Jorge Arévalo a écrit :
> > > Even Rouault <mailto:even.rouault at spatialys.com <javascript:;>>
> > > January 28, 2015 at 9:28 PM
> > >
> > > 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-ti
> > >> le- 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...
> >
> > Ok. But the applications is taking hours to generate a complete tile
> > cache (zoom levels 0-19) for a 3MB tiff file, in epsg:3857. A 4 cores
> > machine with 8GB of RAM. The file is this one
> >
> > https://dl.dropboxusercontent.com/u/6599273/gis_data/katrina-3857.tif
> >
> > Taking so much time for a 3MB file sounds ridiculous. I'm probably doing
> > something wrong. This is the line
> >
> > gdal2tiles.py  -s epsg:3857 -z 0-19 -r cubic katrina-3857.tif tiles_dir
> >
> > Do you see something wrong in this approach?
>
> The performance seems to be deeply impacted by "-r cubic", but even without
> it, it still sucks. The reason is the zoom level 19. Your dataset has a
> resolution of 3469 m. zoom 19 corresponds to a resolution of ~ 0.3 m. So
> you
> basically try to generate a TMS that is rougly 12000 x 12000 larger than
> your
> source dataset...
>
> Wow, thanks for the enlightment. So, with that resolution, I could easily
create TMS cache until levels 5-6, according to this
https://msdn.microsoft.com/en-us/library/aa940990.aspx

If I'd want higher zoom levels... That could mean high processing cost.
Worse if cúbic resampling method is used.

Conclussion: better guessing the highest zoom level for that resolution
using the table on the previous link, and building the TMS cache with that
constraint in mind.

Thanks again, Even!

>
> > Anyway, if this is a problem of gdal2tiles and it needs fine tunning or
> > maintenance, we could talk. I don't know if there's any other method to
> > generate a complete TMS cache using GDAL.
> >
> > >> Any other tips?
> > >>
> > >> Many thanks in advance
> > >>
> > >> Best regards
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>


-- 
Jorge Arévalo

http://cartodb.com/
Skype ID: jorgecartodb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150129/b942dd91/attachment.html>