[OSM-dev] Multithread generate_tiles.py, generate_images.py and question about attribution.

Jon Burgess jburgess777 at googlemail.com
Mon Oct 5 19:05:02 BST 2009


On Mon, 2009-10-05 at 15:57 +0200, Radek Bartoň wrote:
> Dne neděle 04 Říjen 2009 05:09:51 Dane Springmeyer napsal(a):
> 
> > I meant to ask if you had yet compared your generate_tiles.py
> > threading support to the recent additions in svn?
> > 
> > I assume not since you wrote yours, as you say several months ago, but
> > it would be interesting to test the speed of each version.
> 
> Now I tried and the results are quite interesting. I tested on 3GHz Intel Core 
> 2 Duo machine with 2GB RAM and using 2 threads.
> 
> Result for OpenStreetMap generate_tiles.py was:
> 
> real 42m10.608s
> user 21m39.037s
> sys 4m36.265s
> 
> Result for OpenTrackMap (mine) generate_tiles.py was:
> 
> real 56m57.562s
> user 32m7.568s
> sys 8m24.184s
> 
> Then I noticed that OSM version doesn't use any overlapping. 

It does. It uses the Map.buffer_size feature of the newer Mapnik which
provides the benefits of an overlap with less overhead.

> When I removed 
> overlapping from mine version the result (even when full color version of tile 
> is stored to the disk and then converted to 256 color version using 
> ImageMagick) was:
> 
> real 40m35.201s
> user 21m42.249s
> sys 6m42.197s
> 
> Anyway, OSM version should use some overlapping because then there are some 
> artifacts on tile borders. Maybe the best solution would be to render for 
> example 16x16 (or more) tiles image with small border and then cut the image 
> to separated tiles. This could bring also another performace gain because of 
> better memory utilization or less access to DB.

This meta tile scheme is implemented in more advanced tools like the
mod_tile renderd.py. If there is interest i'll port that across to
generate_tiles.py too... I have been reluctant to do this in the past
because generate_tiles.py was just meant as a simple example script,
never a fully developed tool.

> Mine version has small benefit compared to OSM version - it can be interrupted 
> with CTRL+C keys, while mine version doesn't use job queue so it probably 
> doesn't scale as well as OSM version.

The KeyboardInterrupt handler would be useful and is just a couple of
lines of code.

	Jon







More information about the dev mailing list