[OSM-dev] Slippy Map, automatic Tile Rendering

Jochen Topf jochen at remote.org
Thu Jan 18 12:04:06 GMT 2007


On Thu, Jan 18, 2007 at 11:40:50AM +0100, Frederik Ramm wrote:
> (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.
> 
> (b) If I want to regularly find outdated tiles, the perfect way would  
> of course be to process a full change log instead of the limited RSS  
> feed. Ideally, I would want to ask the server "please send all nodes  
> changed or added since <timestamp>", then use this regularly to re- 
> generate all affected tiles. Does someone know if a feature like this  
> is planned or even likely? - The other approach is,  again, using the  
> weekly planet files to find out which nodes have changed. But this  
> would lead to weekly updates only.
> 
> I am not saying that we should abandon the current tile regeneration  
> based on the RSS feed, but it seems to me that it needs to be  
> supplemented by something else if it alone cannot guarantee that our  
> tiles are halfway current.

How about this: For every update the API could increment a version counter
for the tile this update is in. So you have an every-increasing counter
for every lowest-level tile. Whenever you render a tile you store the
current counter for this tile. It is now very easy to find out how many
changes there were between the time you rendered the tile and the
current counter. The details on how to handle higher-level tiles have to
be worked out of course.

The API would need some code to calculate the tile number from the
lat/lon coordinates. The biggest problem would probably be that for
changes in segments and ways you have to get the participating nodes first
and find their coordinates and then tile numbers. But with some clever
optimization this could be fast enough. We don't have to check both ends
of a segment for instance, because generally they are very close. So it
wouldn't really matter in most cases.

The benefit of this approach is that it is totally generic. Every
renderer can use the same counter infrastructure to find outdated tiles.
This is important because we'll get more and more renderers and special
maps and layers. Also it doesn't use the main database at all, the
counters can be kept somewhere separate, maybe even in memory. So it has
no performance impact on our most critical asset. Compare this to any
kind of "diff" approach where the database has to do all the work.

Jochen
-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298





More information about the dev mailing list