[OSM-dev] Slippy Map, automatic Tile Rendering

Thomas Walraet thomas at walraet.com
Thu Jan 18 11:18:11 GMT 2007

Frederik Ramm a écrit :
> (That's the reason the low-detail zoom levels look so faint; on the  
> other hand, if one were to define modified stylesheets for these  
> levels, it would be next to impossible to download the amount of osm  
> data needed to render one because of their large bounding box. This  
> will probably only be possible if the OSM API did support some sort  
> of filtering.)

As I understood, when tiles at home clients render an area, they picked up 
the data from the API and render :
- 1 tile level 12
- 4 tile level 13
- ...

They could render one more tile at level 12 dedicated to the lowest 
zoom. It should draw primary and secondary roads very large, display 
name only for major cities, rails with just one black line, etc.

Bonus : If those tiles could include the land/sea data currently in use 
on the mapnik db layer for zoom 1-9, it could look real nice. Or maybe 
downloading the corresponding landsat tile and draw on it.

> (a) Which tiles are outdated? One could of course just re-generate  
> all existing tiles but that would be very time-consuming (I guess  
> about 20 days of round-the-clock computing for a modern PC; less of  
> course if many take part in the distributed computing). I will try to  
> evaluate the last-change-timestamp in the planet file and use that to  
> determine which tiles are out of date.

A solution is to have a daily dump with modification of the day. 
(addition, deletion, modification)

With the planet dump and those diff dumps, maps could be kept up to date 
fairly easily. And renderer will stop hammering the DB through the API.

Diff dumps could even be more frequent than daily. If the frequency goes 
up, the total size remain the same. With a dump every hour or two, the 
RSS feed is no more needed.

Thomas Walraet

More information about the dev mailing list