[OSM-dev] Documentation about Tirex update strategies configuration

Frederik Ramm frederik at remote.org
Mon Jan 10 19:22:26 GMT 2011


Hi Radek,

Radek Bartoň wrote:
> Writing own parser of osc.gz files that determines which tiles are affected by 
> the change is quite complex task and I'm quite sure there must be something 
> already (it must run on the official OSM tile server). I just don't know how 
> it's called and how can I setup it.

There are different ways to do that. It is not something that is done in 
  tirex (or renderd for that matter) because these systems do not know 
when data is updated in the database. You need something that processes 
the .osc files. There's more than one way to do it (tm):

Option 1: Have osm2pgsql write out a list of dirty tiles (options 
-e/-o). Process that with render_expired (in mod_tile directory). This 
will slow down your osm2pgsql runs by something like 25%, and IMHO it 
tends to re-render more than required because it makes an attempt to 
understand polygon relations.

Option 2: (AFAIK this is used in the OSM production system) use a ruby 
script to parse the OSC diffs and generate rendering instructions: 
http://trac.openstreetmap.org/browser/applications/utils/export/tile_expiry

Option 3: (used by OpenPisteMap) use a python script that processes OSC 
diffs and stores expiry information in a database: 
https://subversion.nexusuk.org/trac/browser/openpistemap/trunk/scripts/expire_tiles.py

- On some tile servers I run, I simply use the 
tirex-create-stats-and-update-tiles.sh script from tirex/utils. This 
script completely ignores any changes from the OSC diffs, and simply 
finds the oldest tiles on disk an re-renders them. This is somewhat 
low-tech but also quite robust.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"



More information about the dev mailing list