OpenTripPlanner
| OpenTripPlanner | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
 | ||||||||||||||||||||
| License: | GNU Lesser General Public License v3 (free of charge) | |||||||||||||||||||
| Platforms: | Windows, Linux, and macOS | |||||||||||||||||||
| Website: | https://www.opentripplanner.org/ | |||||||||||||||||||
| Source code: | opentripplanner/OpenTripPlanner GitHub | |||||||||||||||||||
| Programming language: | Java | |||||||||||||||||||
|
Pedestrian and public transport routing engine |
||||||||||||||||||||
| ||||||||||||||||||||
OpenTripPlanner (OTP) [1] is an open-source multimodal trip planning software system. It started as a collaborative effort among TriMet [2] (the public transportation agency serving Portland, OR, USA), OpenPlans [3], and the developers of Five Points [4], OneBusAway [5], and Graphserver [6], as well as several independent developers.
Features
- Designed to use open data sources OpenStreetMap and the General Transit Feed Specification (GTFS) [7] as well as NeTex
- Allows users to plan a trip that can combine multiple modes of transportation, such as bicycling or walking to reach public transportation
- Interlines (transfers) between different public transportation systems
- User can specify departure or arrival times for public transportation
- Optional routing criteria
- Quickest trip
- Fewest transfers
- A "bicycle preference triangle" that allows users to adjust between quickest, flattest, and bike-friendly routes
- Can incorporate several popular bike-sharing systems
- Wheelchair accessibility
- Maximum walking distance to public transportation
- Point-and-click or geocoder to set origin and destination
- Permalinks available for generated routes
- Routing across plazas/piazzas open pedestrian areas (highway=pedestrian, area=yes)
- Support for planning travel that combines transit and bike-sharing services
- Deployable as a multimodal trip planning website that can be offered via industry-standard Web browsers. There are several working demo instances [8] of OpenTripPlanner.
Data
OpenTripPlanner relies on General Transit Feed Specification (GTFS) data to describe public transportation schedules and routes. More recently Entur has contributed the import of NeTex data which can be used instead of GTFS.
It can use OpenStreetMap (or commercial data sources) for data on sidewalks, bicycling infrastructure, and streets. The two sources of data are linked through transit stops, which are parts of both sets of data. OpenTripPlanner also can link to the US National Elevation Dataset (NED) data [9] and provide an elevation graph for bicycle trips. Compatibility with similar elevation datasets for other countries is uncertain.
Detailed descriptions of the different types of data that OpenTripPlanner can use to build a network for routing, or graph, are available on the OpenTripPlanner configuration page.
In order to provide realtime routing that takes delays and cancellations into account both GTFS-RT and Siri feeds can be consumed by OTP.
Design
The core of OpenTripPlanner consists of three basic software components: a graph builder, a routing engine, and a debug user interface. While the debug user interface (i.e., map and visual representation of route) is written in JavaScript, the other components are written in the Java programming language.
Originally the main way to access the OpenTripPlanner routing engine was a RESTful API however in the more recent past both Entur (Norway) and HSL (Finland) have contributed their own separate GraphQL APIs. These APIs are part of the OTP2 code but need to be enabled separately.
The most recent progress on the OpenTripPlanner project can be found at the OpenTripPlanner Developers Group [10], OpenTripPlanner Users Group [11], and Transit Developers Group [12] mailing lists, as well as the main OpenTripPlanner website [13].
The OpenTripPlanner source code is licensed under the GNU Lesser General Public License (LGPL) [14] and is publicly available on the OpenTripPlanner.org website.
Routing
The routing algorithm used by OTP has undergone several revisions.
In the early days OpenTripPlanner used only plain Dijkstra's algorithm and the A* algorithm with a Euclidian distrance metric to route trips for all modes of transportation. Those algorithms performed very slowly on large graphs. Recent research has shown a new technique, Contraction Hierarchies [15], to perform better on large graphs. The idea behind Contraction Hierarchies is that a large graph can be contracted by removing vertices one at a time and replacing any paths through the removed vertex with a shortcut representing that path. As the OpenTripPlanner community implemented this functionality, it became apparent that transit routing would be difficult with this new approach as the nodes for transit were time-dependent. Their solution was to use core-based routing which means that only non-transit segments of routing would receive the benefit of faster performance with Contraction Hierarchies.
In version 1 the contraction hierarchies were dropped in favour of implementing improved A* heuristics for transit routing (inspired by [16]). This lead to an improvement of the routing performance.
Version 2 of OTP saw another rewrite of the core algorithms: developers at the Norwegian national travel agency Entur have implemented the RAPTOR algorithm for the public transport portion of the routes while keeping A* for on-street routing for walking, cycling and driving. Whilst it was infeasible with the previous implementation, RAPTOR allows the performant traversal of large, nation-wide graphs. Norway's national railway information system, for example, is based on OTP2 for example.
Routing visualization
You can visualize the OTP route graph if you, for example, want to improve OSM data for routing or if you want to do routing related software development.
Assuming that you have cloned the OTP GitHub repository and built it (see Building OTP from source) do the following steps:
- Get the up-to-date OSM data extract for the area you are interested in either in PBF or XML format. The size of the extract area affects how long the graph building takes. Note that the GTFS-file (see the next step) has to be in the same directory. The gtfs.zip file should be recognized by the OTP no matter how you name it.
- Get the up-to-date GTFS file for the area you are interested in. GTFS wiki page lists some possible options for finding the file. Place the file in the the same directory where you placed the osm extract file.
After getting the data run the following commands:
cd path_to_your_OTP_github_clone_dir java -Xmx4G -jar target/otp-1.1.0-SNAPSHOT-shaded.jar --build path_to_your_data_dir --inMemory --visualize
Consider increasing the used maximum memory (-Xmx parameter) if your system has more memory as the graph building does consume memory.
Wait that the graph building finishes and there is message "[HttpServer] Started". You probably see warnings but they do not prevent the graph building. You can now open your web browser and go the page http://localhost:8080/?debug_layers=true.
As a result you should see the routing graph and be also able to choose the visualized layer. See the OTP Troubleshooting Routing Page for some info on the graph.
Whenever you update your GTFS or OSM data, replace the old files and repeat the commands above.
Deployment
There are several working demos and production instances of OpenTripPlanner. TriMet currently uses OpenTripPlanner for its map trip planner [17], which was made possible by a project (RLIS) to improve the OpenStreetMap data in the Portland, OR, USA area. Researchers at the University of South Florida’s Center for Urban Transportation Research in Tampa, FL, USA have set up a demonstration instance [18] and have proposed a trip planning system for the University campus that, if implemented, will use OpenTripPlanner and data from OpenStreetMap. OpenPlans is discussing deployment with organizations in several US and international cities and regions, as of early June, 2011. OpenTripPlanner.com [19] has information on hosted OpenTripPlanner solutions.
Instructions for downloading and creating your own OpenTripPlanner website deployment can be found on the OpenTripPlanner setup instructions page.
More detail on OpenTripPlanner, and discussion of the software and its use, can also be found in a recent research report from the University of South Florida [20]
Mobile Apps
OpenTripPlanner for Android [21] - An Android app for multi-modal trip planning and navigation using any OpenTripPlanner server
How OpenTripPlanner uses OSM tags for routing
Basic, binary permissions
OTP excludes ways tag with certain tags from its routing result but that doesn't differ from how many people would instinctively expect a route planner to select the roads:
- As a default, foot and bicycle traffic is not allowed on highway=trunk, highway=trunk_link, highway=motorway, highway=motorway_link, or highway=construction.
- Finally, bicycles are not allowed on highway=footway when any of the following tags appear on a footway: footway=sidewalk, public_transport=platform, or railway=platform.
- Other access tags (such as access=no and access=private affect routing as well). While access=no prohibits all traffic, access=private disallows through traffic.
However, these binary on/off switches only apply to a small number of streets as most don't fall into those categories but rather have a sliding scale of attractiveness for cyclists. This is discussed in the next section.
More complex tagging
OTP also computes the bicycle friendliness for each way. In general the following tags are taken into account when calculating this score:
You can follow your general intuition when trying to figure out if a tag value makes a way more or or less attractive for cyclists. Here are some examples:
- The presence of cycleway=* tags increase the safety score for a way.
- highway=residential is considered safer than highway=primary
- surface=compacted is treated more preferentially than surface=sand
- Since OTP is geared towards the general, casual cyclist so any way tagged with sac_scale=* or mtb:scale=* are never used for cycle routes as these are routes for experienced hikers and mountain bikers.
These tags can also be combined with each other to make a stretch of road even more desirable for cyclists, so there is a long (~200 in 2021) list of rules to compute the safety score.
Detailed list of tagging rules
If you are interested in the details of the roughly 200 rules to compute the safety score you ought to enable the ReportAPI in OTP2. After enabling it you can visit http://localhost:8080/otp/report/bicycle-safety.html to view the full list of all bicycle safety rules. This HTML page is also searchable.
The data is derived from the OTP code itself. This means that it automatically updates itself once the rules are updated.
A preview instance of this searchable HTML view is available at https://otp2debug.entur.org/otp/report/bicycle-safety.html
Note: To understand this report you need to be quite familiar with the way that the bicycle routing code works in OTP. More information is available at the OTP documentation.
Seeing the results of the bicycle safety calculation
OTP can visualise the results of the bicycle safety calculation on a map for closer inspection.
To see it, follow these steps
- Start OTP
- Open http://localhost:8080
- Open the layer selector in the top right corner
- Select "Bike safety"
The darker the colour the less safe the way is. When you zoom in you can see the numeric value for each individual piece of road.
Elevators
A reasonably new feature for OpenTripPlanner is the ability to read highway=elevator nodes. When these nodes are connected to ways with levels defined by level=** tags, layer=** tags or level_map relations, they should be interpreted correctly.
See also
- OpenTripPlanner homepage
- OpenTripPlanner official documentation
- Digitransit Platform - Route planning algorithms and APIs are provided by OTP [22]