Skip to content
This repository

Renders and serves map tiles using apache

branch: master

Merge pull request #53 from pnorman/patch-2

Update renderd.conf mapnik paths to default ubuntu paths with mapnik PPA
latest commit 6c2cb243e4
apmon apmon authored
Octocat-spinner-32 debian Make sure that renderd is started after postgresql in init script for… December 09, 2013
Octocat-spinner-32 docs Fix typos in render_list man page April 25, 2013
Octocat-spinner-32 extra add capability to export specific bbox or zoom October 02, 2013
Octocat-spinner-32 includes render_list was not blocking on requests and would swamp renderd with… December 24, 2013
Octocat-spinner-32 iniparser3.0b use autoconf / automake to find libraries and make it more portable January 15, 2012
Octocat-spinner-32 m4 Yet another attempt to fix the mapnik-config issue (probably not the … August 13, 2013
Octocat-spinner-32 munin Correct derivation expression for renderd_zoom_time munin graph August 29, 2013
Octocat-spinner-32 src render_list was not blocking on requests and would swamp renderd with… December 24, 2013
Octocat-spinner-32 .gitignore Don't ignore all .m4 files, only autogenerated ones May 16, 2013
Octocat-spinner-32 COPYING update license to latest V2.0 version - typo fixes and FSF address up… July 26, 2012
Octocat-spinner-32 Makefile.am fix linking on 32 bit systems December 06, 2013
Octocat-spinner-32 autogen.sh use autoconf / automake to find libraries and make it more portable January 15, 2012
Octocat-spinner-32 configure.ac Clean up mod_tile directory by moving source files into a common src/… August 09, 2013
Octocat-spinner-32 mod_tile.conf significantly increase the load thresholds after which mod_tile reduc… August 10, 2013
Octocat-spinner-32 modules.mk mod_tile: Update to a new meta tile scheme which stores all sub-tiles… February 16, 2008
Octocat-spinner-32 openstreetmap-tiles-update-expire Improve diff-importing and tile expiry script August 04, 2013
Octocat-spinner-32 readme.txt Update the readme.txt somewhat by deleting old and outdated content August 10, 2013
Octocat-spinner-32 render_all Add script which is used to run the bulk re-rendering of tiles each week July 01, 2008
Octocat-spinner-32 renderd.conf Update renderd.conf mapnik paths to default ubuntu paths with mapnik PPA November 13, 2013
Octocat-spinner-32 renderd.py Update renderd.py to obtain more config parameters from renderd.conf June 13, 2009
Octocat-spinner-32 replag Improve diff-importing and tile expiry script August 04, 2013
Octocat-spinner-32 slippymap.html Change absolute URL in slippymap.html to a relative one May 16, 2013
readme.txt
mod_tile
========
A program to efficiently render and serve map tiles for
www.openstreetmap.org map using Apache and Mapnik.

Requirements
============
OSM map data imported into PostgreSQL using osm2pgsql
Mapnik renderer along with the OSM.xml file and map
symbols, world_boundaries shapefiles. Apache with
development headers for APR module development.

Tile Rendering
==============

The rendering is implemented in a multithreaded process
called renderd which opens either a unix or tcp socket
and listens for requests to render tiles. It uses Mapnik
to render tiles using the rendering rules defined in
the configuration file /etc/renderd.conf. Its configuration
also allows to specify the number of rendering
threads.

The render daemon implements a queuing mechanism with multiple
priority levels to provide an as up-to-date viewing experience
given the available rendering resources. The highest priority
is for on the fly rendering of tiles not yet in the tile cache,
two priority levels for re-rendering out of date tiles on the fly
and two background batch rendering queues. The on the fly rendering
queues are limited to a short 32 metatile size to minimize latency.
The size of the main background queue is determined
at compile time, see: render_config.h

Tile serving
============

An Apache module called mod_tile enhances the regular
Apache file serving mechanisms to provide:

1) When tiles have expired it requests the rendering
daemon to render (or re-render) the tile.

2) Remapping of the file path to the hashed layout

3) Prioritizes rendering requests depending on the available
resources on the server and how out of date they are.

4) Use tile storage other than a plain posix file system.
e.g it can store tiles in a ceph object store, or proxy them
from another tile server.

5) Tile expiry. It estimates when the tile is next
likely to be rendered and adds the appropriate HTTP
cache expiry headers. This is a configurable heuristic.

To avoid problems with directories becoming too large and to avoid
too many tiny files.  Mod_tile / renderd store the rendered tiles
in "meta tiles" in a special hashed directory structure. These combine
8x8 actual tiles into a single metatile file.  This is a more efficient
use of disk space and inodes. For example, many sea tiles are 103 bytes
long. In the old scheme a meta tile of blank sea tiles would take
64 inodes of 4kB each, a total of 256kB. In this optimized scheme it
needs a single file of about 7kB. The metatiles are then stored
in the following directory structure:
/[base_dir]/[TileSetName]/[Z]/[xxxxyyyy]/[xxxxyyyy]/[xxxxyyyy]/[xxxxyyyy]/[xxxxyyyy].png
Where base_dir is a configurable base path for all tiles. TileSetName
is the name of the style sheet rendered. Z is the zoom level.
[xxxxyyyy] is an 8 bit number, with the first 4 bits taken from the x
coordinate and the second 4 bits taken from the y coordinate. This
attempts to cluster 16x16 square of tiles together into a single sub
directory for more efficient access patterns.

Apache serves the files as if they were present
under "/[TileSetName]/Z/X/Y.png" with the path being
converted automatically.

Compiling
=========

mod_tile and renderd utilize a number of third party, some of which it
depends on and some provide optional features and are compiled in
if the respective libraries are installed. Once the dependencies are installed
you can compile and install mod_tile / renderd the usual way:

./autogen.sh
./configure
make
sudo make install
sudo make install-mod_tile


Setup
=====
Create a new apache config file to load the module,
e.g.

/etc/httpd/conf.d/mod_tile.conf

See the sample mod_tile.conf for details

Edit /etc/renderd.conf to indicate the location of your
mapnik style sheet and the uri you wish to use to access
it.  You may configure up to 10 (by default) mapnik
style sheets - simply give each section a unique name and
enter the uri and style sheet path.

Make sure the /var/lib/mod_tile directory is writable by 
the user running the renderd process and create a file an
empty file planet-import-complete in this folder.

Run the rendering daemon 'renderd'

Restart Aapche

Note: SELinux will prevent the mod_tile code from opening
the unix-socket to the render daemon so must be disabled.

Try loading a tile in your browser, e.g.
http://localhost/osm_tiles/0/0/0.png

The render daemon should have produce a message like:

Got incoming connection, fd 7, number 1
Render fd(7) xml(Default), z(0), x(0), y(0)

The disk should start thrashing as Mapnik tries to pull
in data for the first time. After a few seconds you'll
probably see a 404 error. Wait for the disk activity to
cease and then reload the tile. With a bit of luck you
should see a tile of the world in your browser window.

If this fails to happen check the http error log.  You can 
increase the level of debugging using the LogLevel apache
directive.  If no log messages are shown check that you
are accessing the correct virtual host - the new version
of mod_tile is only installed on a single host by default.
To install on multiple hosts either use ServerAlias or
use the LoadTileConfigFile in each virtual host.


Performance
===========
mod_tile is designed for high performance tile serving. If the
underlying disk system allows it, it can easily provide > 10k tiles/s
on a single serve.

Rendering performance is mostly dependent on mapnik and postgis performance,
however renderd tries to make sure it uses underlying hardware as efficiently
as possible and scales well on multi core systems. Renderd also provides
built-in features to scale to multi server rendering set-ups.


Something went wrong with that request. Please try again.