[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