Tile data server

From OpenStreetMap Wiki
Jump to navigation Jump to search

two merging arrows

It has been proposed that this page or section be merged with Vector tiles. (Discuss)

The idea of a tile data server is to serve up OpenStreetMap data in regularised square shaped portions called tiles, rather like the very widespread approach of serving Tiles of raster map data, but this time with vector data. The main OpenStreetMap API offers data by the bounding-box, but there are number of benefits of restricting requests to a fixed grid of tiles. The page details the general idea, and links specific implementations.


  • Trapi - No longer running anywhere, but this used to be set-up to serve the (considerable) data needs of tiles@home clients.
  • OJW's tile data server [1] - No longer running. Some perl code.
  • tiledata2 - Python code for generating protocol buffer formatted tile data.
  • VectorTileMap [2] - part of OpenScienceMap, a new project from University of Bremen using a protocol buffers based format. An experimental Mapnik backend serving tiles is available at [3].

Tile data. General idea

bbox API limitations

Downloading OSM data is done via the API. The format is defined as:

GET /api/0.6/map?bbox=W,S,E,N

However, there are several problems with that:

  • no guarantee of getting data back (node limit)
  • using it while not actively editing is considered abuse
  • bbox isn't very convenient way of specifying boundary
    • tile renderers would prefer to specify zoom/x/y
    • results aren't very cacheable

XAPI offers a similar service and is hosted on several different servers with varying speeds.

planet.osm is available, but there are several problems with that too:

  • 8GB of (heavily-compressed) download
  • difficult to quickly extract the area you want
  • ways only contain the node IDs, not lat/long (so you have to store all 240,000,000 nodes and query them efficiently just to test if a particular way is anywhere near your map)

The tile data server solution

What if a server were available that supported

GET /api/0.6/tiledata/z/x/y

then a renderer could simply download the data for a tile it's interested in

What else might benefit

Downloading data to mobile devices, and keeping track of the downloaded areas

When routing, start by downloading your local tile, and just keep downloading more tiles when your route wanders off the edge of the area