[OSM-dev] Improvement of tile rendering

Stefan de Konink stefan at konink.de
Fri Mar 20 16:53:13 GMT 2009


Ceriel Jacobs wrote:
> On Tue, 17 Mar 2009 18:35:18 +0100 Stefan de Konink wrote:
>> I have set this up completely inside a webserver. Cherokee, no php, just
>> the python script that renders the thing on demand. Runs in production
>> for months now.
>>
>> <snip>
>> vserver!10!domain!1 = tile.openstreetmap.nl
> 
> This looks really well, as tiles are shown after rendering to the 
> requesting user.
> No "...more OSM coming soon" messages are sent to the user.

That was the idea ;)

> Regarding expiry:
>> <snip>
>> vserver!10!rule!100!expiration = time
>> vserver!10!rule!100!expiration!time = 1w
> 
> This tells the client to not contact the webserver when there is a tile 
> in the local browser cache not older than 1 week?

It is not that black/white; basically it tells the browser "do not check 
for new stuff by yourself", but if a user presses F5 on the page, it 
will recheck anyway :) So it is basically a bandwidth thing that makes 
'speedytile' speedy.

> But how is expiry of the tile files themselves being done?

That part is handled using the 'default' code provided in SVN. The 
invalidator code; there were some modifications by Roeland; I guess he 
can elaborate more on this subject.

> There is something said about this in the about of 
> tile.openstraatmap.nl, located at http://tile.openstreetmap.nl/info.html
> Daily at 6.15, after NL dump is downloaded and imported, something 
> happens that removes tiles older than 48 hours.

There are two things; tile that are not accessed are going to be 
deleted. This is just smart resource management; next to this in the 
same way we invalidate, just remove the tile. If someone needs it, it 
will be generated, send back to the user. (It can be done *one* step 
more efficient, send a redirect, so the tile is cached the first time 
for the user that first requests it. Micro optimisation ;)

> My question is: how are the old tile images removed? Would you share 
> that code too?

I think that is not a problem :) Roeland can probably tell more about 
what code actually was modified.


Stefan




More information about the dev mailing list