WARNING: If you are standing up your own instance of the Tilezen stack (rather than doing development), it's best practice to checkout the latest tagged release rather than running off master. At the time of this writing that is v1.4.0, so you'd git checkout v1.4.0 to be on the same code base as the production Mapzen Vector Tile service. Similarly, you'd need to pin yourself against the related project's versions, e.g.: Requires: tileserver v2.1.0 and tilequeue v1.8.0 and mapbox-vector-tile v1.2.0 mentioned in the release notes in the sections below.

Setup a virtualenv

There are numerous ways to deploy python packages. virtualenv is used here, but other methods should work

At the moment, only Python 2.7.xis supported, so make sure you have a Python 2.7 version installed

# Create a virtualenv called 'env'. This can be named anything, and can be in the tileserver directory or anywhere on your system.
virtualenv env --python python2.7
source env/bin/activate

Install tileserver and tilequeue

pip install -U -r requirements.txt
python setup.py develop

3. Load data

Set up database

If you are setting up PostgreSQL for a single-user install, you may want to create a new database user (i.e: whoami). You can skip this next step if you already have your database roles established.

Load PBF data

Vector-datasource uses the slim tables, so --slim is required and the --drop option cannot be used.

You may also need to pass in other options, like -U or -W, to ensure that you connect to the database with a user that has the appropriate permissions. For more details, visit the osm2pgsql wiki page and the postgresql docs for creating a user. You may need to check your connection permissions too, which can be found in the pg_hba.conf file.

Note that if you import the planet, the process can take several days, and can consume over 1TB (2TB is preferred cause need more space to prepare the database) of disk space at the time of writing. The OSM planet gets bigger every week, so it might be necessary to do a few trial runs to find out what it takes today. Have a look at some our own performance tuning docs or those from Switch2OSM.org for recommendations.

Load additional data and update database

The additional data included with shapefiles.tar.gz is from a combination of sources, the full list is in data/assets.yaml, including a pointer to the latest cached datestamp. Everything bundled is open data, although some of it is manually generated or curated. The data comes from:

openstreetmapdata for static land/water polygons, and is under the same ODbL as the primary OpenStreetMap data it derives from.

admin_areas is based on OSM data and available under the ODbL. It gets generated by manually running Valhalla's mjolnir tool occasionally.

buffered_land is based on Natural Earth data and available under the public domain. It is manually curated by Tilezen and is a slightly buffered land polygon to clip admin boundaries against so that we don't get admin boundaries going off into the sea.

NOTE that you may have to pass in a username/password to these scripts for them to connect to the database. Anywhere -d osm is specified, you may need to also pass in -U <username> and perhaps set a password too. For example, if my username is "foo" and my password is "bar", here's what I would do:

Run

Directly, as a single-threaded Python process. This is better if you want to debug or step through code, but will not be able to use all the cores of your computer.

As a WSGI application through a multi-threaded (or multi-process) WSGI server such as gunicorn. This is better if you want to make best use of your computer by handling requests concurrently. However, it can complicate debugging or stepping through code.

To run tileserver using gunicorn, we recommend using the same number of workers as CPU cores (the -w argument, here for example 4):

gunicorn -w 4 "tileserver:wsgi_server('config.yaml')"

To run tileserver stand-alone for debugging:

python tileserver/__init__.py

5. Global build

Need to build tiles for the whole world? There's a new way to do that using tilequeue and RAWR tiles instead of Postgres:

Sample test URLs

Keeping up to date with osm data

OpenStreetMap data is constantly changing, and OpenStreetMap produces diffs for consumers to keep up to date. Mapzen uses osmosis and osm2pgsql to pull down the latest changes and apply them.

Generally speaking, tile service providers make the trade-off to prefer generating stale tiles over serving the request on demand more slowly. Mapzen also makes this trade-off.

A lot of factors go into choosing how to support a system that remains up to date. For example, existing infrastructure, tolerance for request latency and stale tiles, expected number of users, and cost can all play roles in coming up with a strategy for remaining current with OpenStreetMap changes.

Tracking releases

If you are on a particular release and would like to migrate your database to a newer one, you'll want to run the appropriate migrations. Database migrations are required when the database queries & functions that select what map content should be included in tiles change.

Note that the migration for each release in between will need to be run individually. For example, if you are on v0.5.0 and would like to upgrade to v0.7.0, you'll want to run the v0.6.0 and v0.7.0 migrations (we don't provide "combo" migrations).