|License:||GNU Lesser General Public License v3 (free of charge)|
|Platforms:||Windows, Linux, and macOS|
Pedestrian and public transport routing engine
OpenTripPlanner (OTP)  is a collaborative effort among TriMet  (the public transportation agency serving Portland, OR, USA), OpenPlans , and the developers of Five Points , OneBusAway , and Graphserver , as well as several independent developers, to develop an open-source multimodal trip planning software system.
- Designed to use open data sources OpenStreetMap and the General Transit Feed Specification (GTFS) 
- 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  of OpenTripPlanner.
OpenTripPlanner relies on General Transit Feed Specification (GTFS) data to describe public transportation schedules and routes. 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  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 GraphBuilder page.
There are also efforts underway to integrate real-time transit data for estimated arrival times into OTP transit routing, based on research by a UC Berkeley team which has also created the BayTripper (http://www.baytripper.org/) mobile transit application (Jariyasunant, J. et al. “Mobile Transit Trip Planning with Real-time Data,” Proceedings of the US National Academy of Sciences’ Transportation Research Board, 90th Annual Meeting, January 2011)
The most recent progress on the OpenTripPlanner project can be found at the OpenTripPlanner Developers Group , OpenTripPlanner Users Group , and Transit Developers Group  mailing lists, as well as the main OpenTripPlanner website .
The OpenTripPlanner source code is licensed under the GNU Lesser General Public License (LGPL)  and is publicly available on the OpenTripPlanner.org website.
OpenTripPlanner employs two different methods for routing: the A* algorithm and Contraction Hierarchies. Originally, OpenTripPlanner used only plain Dijkstra's algorithm and A* 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 , 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. Additional routing performance improvements in OpenTripPlanner have included implementing improved A* heuristics for transit routing (inspired by ).
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.
- Get the up-to-date OSM data extract for the area you are interested in. At least Geofabrik and Metro Extracts by Mapzen are possible options. The size of the extract area affects how long the graph building takes. You should download the data in .pbf -format and place it in the directory you prefer. 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 .pbf -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[ http://opentripplanner.readthedocs.io/en/latest/Troubleshooting-Routing/ OTP Troubleshooting Routing page] for some info on the graph.
Whenever you get new GTFS file or OSM data extract, replace the old files with them and repeat the commands above.
There are several working demos and production instances of OpenTripPlanner. TriMet currently uses OpenTripPlanner for its map trip planner , 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  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  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 
OpenTripPlanner for Android  - An Android app for multi-modal trip planning and navigation using any OpenTripPlanner server
Access tags (such as bicycle/foot = yes/no/designated) can be used to override default graph-building parameters.
In general, weights are applied to the following tags for "bike friendly"/"safest" bicycle routing (as of 10/11/12). Weights act as multipliers, so ways with values of less than 1 appear shorter to the router, while those with values of greater than 1 appear longer.
|highway=footway with footway=crossing||2.5|
|highway=residential or highway=residential_link||0.98|
|highway=tertiary or highway=tertiary_link||1|
|highway=secondary or highway=secondary_link||1.5|
|highway=primary or highway=primary_link||2.06|
|highway=trunk_link or highway=motorway_link||2.06|
|highway=footway with footway=sidewalk||1.1|
|highway=footway with footway=sidewalk and bicycle=yes instead of bicycle=designated||2.5|
|highway=footway with footway=crossing||1.1|
|highway=residential or highway=residential_link||0.95|
|highway=tertiary or highway=tertiary_link||0.97|
|highway=secondary or highway=secondary_link||1.46|
|highway=primary or highway=primary_link||2|
|highway=trunk_link or highway=motorway_link||2|
|highway=residential or highway=residential_link||0.77|
|highway=tertiary or highway=tertiary_link||0.87|
|highway=secondary or highway=secondary_link||0.96|
|highway=primary or highway=primary_link||1.15|
|highway=trunk_link or highway=motorway_link||1.15|
|highway=residential or highway=residential_link||0.70|
|highway=tertiary or highway=tertiary_link||0.75|
|highway=secondary or highway=secondary_link||0.80|
|highway=primary or highway=primary_link||0.85|
|highway=residential or highway=residential_link||0.77|
|highway=tertiary or highway=tertiary_link||0.83|
|highway=secondary or highway=secondary_link||1.25|
|highway=primary or highway=primary_link||1.75|
|highway=residential or highway=residential_link||0.85|
|highway=tertiary or highway=tertiary_link||0.92|
|highway=secondary or highway=secondary_link||0.99|
|highway=primary or highway=primary_link||1.25|
|highway=trunk_link or highway=motorway_link||1.25|
|Highway tag||Weight (forward, backward)|
|highway=** (default)||1.0, 1.4|
|highway=residential or highway=residential_link||0.98, 0.98|
|highway=tertiary or highway=tertiary_link||1, 1|
|highway=secondary or highway=secondary_link||1.5, 1.71|
|highway=primary or highway=primary_link||2.06, 2.99|
|bicycle=yes and surface=**||1.18|
|bicycle=designated and surface=**||0.99|
Special weights for surface tags (surface=**)
|surface=fine_gravel or surface=sand||100|
|surface=unpaved or surface=compacted||1.18|
|surface=cobblestone, surface=paving_stones, surface=grass_paver, surface=pebblestone, surface=gravel, surface=ground, surface=dirt, surface=earth, surface=grass, surface=mud, surface=wood, surface=metal, or surface=artificial_turf||1.5|
For the TriMet deployment, a couple of special mixins have also been included that indicate caution areas for cycling that appear in jurisdictional data/maps
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.