Trapi

From OpenStreetMap Wiki
Jump to navigation Jump to search

Trapi (Tiled Read-only [map] Application Program Interface) is a way to fetch osm data, optimized for tiles@home requests. It is an implementation of the Tile data server idea. Whereas the main API was not capable of coping with the extremely high demand put on it by t@h, there used to be a TRAPI setup, which could handle the load comparatively well.

Status

Trapi is (probably) no longer available anyway. Although it had other potential applications, its primary purpose was to serve data to tiles@home clients, and so it seems to be completely discontinued along with tiles@home.https://github.com/simonpoole/trapi/tree/64bit

2017-03-21: https://github.com/simonpoole/trapi/tree/64bit is a version of Trapi that will run with 64bit ids (required for current OSM data). It requires a 64bit perl version which in turn implies that it will only work on a 64bit OS and corresponding HW. Otherwise it works just fine and might be the fastest way to get a RO-API server running. Note: updating from diffs has not been tested with this version.

Running instance of TRAPI?

There was a publicly accessible instance of TRAPI running at http://api1.osm.absolight.net/api/0.6/map?bbox=%b which supports the rendering of T@H clients. It actually consists of a load balancer, balancing request across 4 different instances of TRAPI and its status can be seen at http://api1.osm.absolight.net/haproxy?stats however none of this seems to be available any more

Using Trapi

It is updated by the diff files from planet.openstreetmap.org, so it should usually be less than 10 minutes behind the main database.

Depending on the configuration Trapi does not store all tags, data from such a Trapi instance should not be used to edit and upload back to openstreetmap.

Trapi will round all bbox requests up to z14 tile boundaries. It is an implementation of the Tile data server idea. In low node-density areas, data from z13, z12, or z11 tiles may be returned. Occasionally, ways or relations that used to be in the tile may be returned as well. Areas near the poles will be returned with the closest valid tile.

Trapi supports the queries:

  • api/0.6/map?bbox=S,W,N,E
Same as api
  • api/0.6/map?tile=Z,X,Y
Fetch a single tile
  • api/0.6/map?node=ID
  • api/0.6/map?way=ID
  • api/0.6/map?relation=ID
Fetch a single object (ways include nodes)

These queries can also be made from a command line:

  • fetch.pl map?bbox=S,W,N,E
  • fetch.pl map?tile=Z,X,Y
  • fetch.pl map?node=ID
  • fetch.pl map?way=ID
  • fetch.pl map?relation=ID

Installin, running and developing Trapi

Trapi uses much less disk space (especially with a filesystem specifically configured for it) than ROMA. It also appears to respond to requests faster than ROMA. Space should be allowed for growth, of course. As of mid-February 2009 the entire planet takes about 16 Gigabytes. As of planet-100609.osm.bz2 - 9.5G in size, /trapi will take 67G space and 13M inodes on tmpfs.

Trapi source is in svn. Installation and use documentation is in the INSTALL file.

Please let blarson@scd.debian.net (blarson on irc.oftc.net #osm) know if you decide to install it or have problems.

Replication diffs

As of early 2010 that the old minute and hourly diffs that TRAPI uses are no longer in service. You must follow the instructions below to fetch and apply the new replicate diffs to your TRAPI database. The new method uses Osmosis and the --rri option to fetch the replicate diffs and convert them to the type expected by TRAPI.

Download the updated files. They are monitor.pl, go (a bash script), and a slighly updated trpcs.pl.

The process is as follows: use the "go" bash script to invoke osmosis with --rri, rename the output file, and move it to the change directory (CHANGEDIR). The "go" script should be located in your osmosis/bin/ directory. There are two locations that need to be changed in the go script. Please edit the script and set CHANGEDIR and WORKDIR equal to something appropriate for your system. CHANGEDIR should be an empty directory where Osmosis will dump the .osc files and WORKDIR is the Osmosis workingDirectory used with the --rri task.

monitor.pl replaces trup.pl. It monitors CHANGEDIR for new files and feeds the filenames to trpcs.pl via STDOUT. monitor.pl should be placed in the same directory as trapi.pm as it reads config info from there. trapi.pm needs to define the constant CHANGEDIR, so a line like "use constant CHANGEDIR => "/home/user/change/"; should be added to trapi.pm. Of course you should change the directory to suit your environment.

Note that monitor.pl requires File::Monitor for perl.

If you haven't yet loaded your database with your initial planet dump, now would be a good time. See the TRAPI INSTALL file for details. You should fetch the initial dump from a mirror, because TRAPI will (obviously) catch up.

At this point you should install Osmosis, run the --rrii task, and find and download the appropriate state.txt file from planet.openstreetmap.org or mirror. This is typically one from slightly before the dump you used to initialize your database.

Once osmosis is ready, just run the "go" script and osmosis should start dumping .osc.gz files into your CHANGEDIR. Once it's done at least one, you can then invoke monitor.pl in your TRAPI directory with something like ./monitor.pl | ./trpcs.pl. Trpcs should start updating your database with the files that it finds in CHANGEDIR.

Any questions, email the talk list or contact user Milenko.


Possible future improvements:

  • Make pdtb.pm a real package.
  • Change maxzoom to 16. This changes the index format.
  • Use more balanced directory structure. (rebuild again)
  • real bbox handling
  • Rename programs.
  • Document how to access a Trapi database in a program

Done:

  • Change how relations are stored to allow ordered relations.
  • Fetch data by tile.
  • Split configuration into a separate file and use it in ALL tools (including cleardb and tahdbload.pl).
  • Compress data. Requires change in tiles@home client. Apache mod-deflate does this for us, so only client change needed.
  • Use incremental garbage collection.
  • Use table of common key values to reduce storage.
  • Code cleanup
  • cache tiles ways are in. Much of the update time is spent calculating this for complex relations.