<br><br>El jueves, 29 de enero de 2015, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le jeudi 29 janvier 2015 00:05:32, Jorge Arévalo a écrit :<br>
> > Even Rouault <mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'even.rouault@spatialys.com')">even.rouault@spatialys.com</a>><br>
> > January 28, 2015 at 9:28 PM<br>
> ><br>
> > Le mercredi 28 janvier 2015 20:17:08, Jorge Arévalo a écrit :<br>
> >> Hi,<br>
> >><br>
> >> I'm working with a patched version of gdal2tiles, which makes use of<br>
> >> parallelization:<br>
> >> <a href="http://gis.stackexchange.com/questions/7743/performance-of-google-map-ti" target="_blank">http://gis.stackexchange.com/questions/7743/performance-of-google-map-ti</a><br>
> >> le- creation-processes/74446#74446<br>
> >><br>
> >> I want to create a complete TMS cache from raster imagery. No<br>
> >> assumptions about SRS of data type for input data.<br>
> >><br>
> >> I want the tiling process to be as fast as possible (gdal2tiles is<br>
> >> really heavy process), do you have any recomendations about the data or<br>
> >> the parameters used?<br>
> >><br>
> >> Right now, I'm doing this<br>
> >><br>
> >> Step 1: build vrt from input images<br>
> >><br>
> >> gdal_vrtmerge.py -o merged.vrt<list of input tif files><br>
> >><br>
> >> Step 2: build tiles from vrt file<br>
> >><br>
> >> gdal2tiles.py -r cubic -s epsg:XXXX -z 0-19 -w all merged.vrt tms_dir<br>
> >><br>
> >> Even with parallelization, process still feels really slow. Would it be<br>
> >> faster if, for example, I convert all my input files to epsg:3857? Or if<br>
> >> I scale them to 8-bit? Or if I use near resampling method instead of<br>
> >> cubic? (I'm using cubic because I'm working with continuous data:<br>
> >> satellite images, am I doing it right?).<br>
> >><br>
> >  From a quick look at the source, it seems that there's an optimization<br>
> >  if the<br>
> ><br>
> > input SRS == output SRS that avoids going through the warped VRT path.<br>
> ><br>
> > That said, we definitely need one or several maintainers for gdal2tiles.<br>
> > There are quite a faw patches floating around in Trac that would need<br>
> > someone to review, test, fix, apply them, as well as writing tests (no<br>
> > autotest for gdal2tiles yet), etc...<br>
><br>
> Ok. But the applications is taking hours to generate a complete tile<br>
> cache (zoom levels 0-19) for a 3MB tiff file, in epsg:3857. A 4 cores<br>
> machine with 8GB of RAM. The file is this one<br>
><br>
> <a href="https://dl.dropboxusercontent.com/u/6599273/gis_data/katrina-3857.tif" target="_blank">https://dl.dropboxusercontent.com/u/6599273/gis_data/katrina-3857.tif</a><br>
><br>
> Taking so much time for a 3MB file sounds ridiculous. I'm probably doing<br>
> something wrong. This is the line<br>
><br>
> gdal2tiles.py  -s epsg:3857 -z 0-19 -r cubic katrina-3857.tif tiles_dir<br>
><br>
> Do you see something wrong in this approach?<br>
<br>
The performance seems to be deeply impacted by "-r cubic", but even without<br>
it, it still sucks. The reason is the zoom level 19. Your dataset has a<br>
resolution of 3469 m. zoom 19 corresponds to a resolution of ~ 0.3 m. So you<br>
basically try to generate a TMS that is rougly 12000 x 12000 larger than your<br>
source dataset...<br>
<br></blockquote><div>Wow, thanks for the enlightment. So, with that resolution, I could easily create TMS cache until levels 5-6, according to this <a href="https://msdn.microsoft.com/en-us/library/aa940990.aspx">https://msdn.microsoft.com/en-us/library/aa940990.aspx</a></div><div><br></div><div>If I'd want higher zoom levels... That could mean high processing cost. Worse if cúbic resampling method is used.</div><div><br></div><div>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.</div><div><br></div><div>Thanks again, Even!</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> Anyway, if this is a problem of gdal2tiles and it needs fine tunning or<br>
> maintenance, we could talk. I don't know if there's any other method to<br>
> generate a complete TMS cache using GDAL.<br>
><br>
> >> Any other tips?<br>
> >><br>
> >> Many thanks in advance<br>
> >><br>
> >> Best regards<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
</blockquote><br><br>-- <br><div dir="ltr"><font face="arial,helvetica,sans-serif">Jorge Arévalo<br><br><a href="http://cartodb.com/" target="_blank">http://cartodb.com/</a><br></font><div>Skype ID: jorgecartodb</div></div><br>