Mod tile - Other languages
Afrikaans asturianu azərbaycancaBahasa Indonesia Bahasa Melayu bosanskibrezhoneg català čeština dansk Deutsch eestiEnglish español Esperanto euskara français Fryskgalego hrvatski interlingua íslenska italiano Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu​Lëtzebuergesch lietuvių magyar Nederlands norsknorsk nynorsk occitan polski português românăshqip slovenčina slovenščina srpski (latinica)‎suomi svenska Tagalog Tiếng Việt Türkçe ZazakiΕλληνικά беларуская български македонскимонгол русский српски / srpski українськаհայերեն עברית العربية فارسی پښتو नेपाली বাংলা தமிழ்മലയാളം සිංහල ไทย မြန်မာဘာသာ ქართული 한국어ⵜⴰⵎⴰⵣⵉⵖⵜ 中文(简体)‎ 中文(繁體)‎ 日本語粵語
mod_tile is a system to serve raster tiles for example to use within a slippy map. It provides a dynamic combination of efficient caching and on the fly rendering. Due to its dynamic rendering, only a small fraction of overall tiles need to be kept on disk, reducing the resources required. At the same time, its caching strategy allows for a high performance serving and can support several thousand requests per second.
Mod_tile was originally written for serving the tiles of the main OSM map (Mapnik layer), but since is being used on a variety of different servers providing maps ontop of OpenStreetMap data.
The code is split into two parts:
Features provided by mod_tile
Installing a tile server based on mod_tile requires a number of steps, some of which can be skipped depending on your needs:
Install mod_tile From Source
(tested with Ubuntu 16.04 LTS)
mkdir ~/src cd src/
Checkout the mod_tile source from Git and enter the directory
git clone cd mod_tile
Compile the sources
./ ./configure make
Install mod_tile
sudo make install sudo make install-mod_tile sudo ldconfig
Mapnik rendering toolchain
mod_tile uses Mapnik as a rendering backend. Therefore it is necessary to install it first and populate the PostGIS database with data first using osm2pgsql. The detailed steps are shown at [1]
tile expiry
After rendering a tile, it gets cached on disk for fast serving. As OSM data is constantly updated, improved and changed, a mechanism is needed to correctly expire the cache to ensure updated tiles get re-rendered.
There are several possible mechanisms available for expiring and updating tiles (either through mod_tile or by directly re-rendering cached tiles), of which often a combination is used:
mod_tiles expiry works by comparing the time stamp of rendered tiles to the date of the last full data import into the database.
If the planet time stamp is updated, all tiles are automatically marked as in need for re-rendering (dirty) and will be submitted to the rendering backend on next visit.
For the diff-based updates of the database, expiring all tiles would be too costly, and so only those tiles for which the data was updated get expired by altering the time stamp of those tiles to date far in the past. Again there are two different scripts for doing this. One ruby script and one based on output from osm2pgsql.
Alternatively, there are a number of helper utilities that can directly talk to renderd or tirex, submitting tiles for rerendering. This is often used to re-render low-zoom tiles on a periodical basis in the background, as it would be too costly to update them through the normal diff-based expiry.
See also for more details: Tile expire methods.
Making your server support https/ssl is a simple matter of creating a new Apache site (generally by copying the config from the http version) and adding the SSLEngine configuration options like any other site. Remember to change the port from 80 to 443.
HowTos contains many guides to set up a tile server based upon mod_tile, for instance
Build your own OpenStreetMap Server - Describes the setup of the mapnik rendering toolchain
Most config can be done in the apache config and in /etc/renderd.conf
Some special options like MAX_ZOOM can only be set on complile time in render_config.h
You will likely need to do some more preparation to load the data for rendering in mapnik.
The style sheet also needs adjusting
Testing and debugging installation
After installation and configuration, it is important to test that everything is working.
Here is a list of some of the common mistakes and problems and how to detect them:
Check if mod_tile is loaded into Apache. First you should check if mod_tile is correctly loaded into your apache. One way of doing this is by verifying that you get the mod_tile status page under http://your.server/mod_tile . The status page should give you a number of tiles mod_tile has served, split by zoom-level, their status codes and how many requests it has sent to the rendering back end.
Additional help in trouble shooting might be found in the general help system of OSM
Source code
The code is in Git at​, the readme.txt file contains other important information which you should read before trying to use this code.
git clone
Bug reports and feature requests
Mod_tile has been running stable on the OSM main page and many other sites for quite some time now with little trouble. It should thus be very stable and robust. Nevertheless, as will all software, it can have bugs. If you find any problems or instability using mod_tile, please report it on our bug tacker so that any remaining issues can be fixed:
mod_tile tickets on github
You can also report feature requests, however as always, there is no guarantee that any of the feature requests will get picked up.
Alternatively some issues and enhancements are listed below
This article or section may contain out-of-date information. The information is no longer correct, or no longer has relevance.
If you know about the current state of affairs, please help keep everyone informed by updating this information. (Discussion)
This page is being considered for cleanup. Please discuss this page.
The current code has been running with few problems now for over a year but there are always some things which could be improved...
Lots of parameters are set in the render_config.h file and compiled into the mod_tile & renderd code. Ideally mod_tile should get all these parameters from some suitable module config options in the Apache config file. The renderd process would also need a config file or some command line options. Update: Many parameters are now set at runtime thanks to r12950 by Brian Quinion
Update: REQUEST_TIMEOUT, MAX_LOAD_OLD, MAX_LOAD_MISSING, and RENDER_SOCKET can now be set in Apache Config with ModTileRequestTimeout, ModTileMaxLoadOld, ModTileMaxLoadMissing, and ModTileRenderdSocketName. Update: socket name, number of threads, and some mapnik parameters can now be set in renderd.conf.
More ideas
The current server is managing to keep up fairly well with the rendering load. In Feb 2008 the server can re-render all the present tiles within the 7 day window between planet updates. It should take less than 14 days for any new data to appear on the map tiles (up to 7 days for the next planet dump and then up to 7 days for all the tiles to be re-rendered). Often it will be less, e.g. data added on Tuesday will often appear on the map on Thursday.
Unless specified, the configuration is read from the file /etc/renderd.conf installed with 'make install'
External links
Last edited on 18 August 2021, at 18:04
OpenStreetMap Wiki
Content is available under Creative Commons Attribution-ShareAlike 2.0 license unless otherwise noted.
Privacy policy
HomeRandomLog inSettingsDonationsAbout OpenStreetMap WikiDisclaimers