Skip to content

Comparing OTP2 and OTP1

Summary

OpenTripPlanner has been under development since 2009, leading up to a 1.0 release in 2016. Research and development on higher performance routing has been ongoing since 2013-2014, and work on the second major release referred to as OTP2 officially began in 2018. As of Q3 2023, OTP2 is the only version to receive regular updates and OTP1 is considered legacy and unsupported. This page explains key differences between the two versions (referred to as OTP1 and OTP2).

OTP1 has existed for over a decade and is in widespread use. It aims to do many things for many people: it provides passenger-facing itinerary services over APIs, but also serves as a network analysis toolkit for urban planning and research. Though OTP1 is widely used and gets the job done, its transit routing approach is obsolete. We have long recognized that more resource-efficient approaches were possible. Reasonable response times and scaling to larger data sets have been achieved through a series of complex incremental interventions that became difficult to maintain. OTP1 has also accumulated large amounts of experimental code and specialized tools, which can be useful in a research or consulting setting but complicate long-term maintenance.

OTP2 offers much better performance in larger transportation networks and geographic areas, and a wider variety of alternative itineraries. OTP2's public transit routing component has been completely rewritten, and is now distinct from bike, walk, and motor vehicle routing. Non-transit routing remains very similar to OTP1, benefiting from years of adaptations to nuances of OpenStreetMap data and end-user walking and biking preferences. Unlike OTP1, OTP2 is completely focused on passenger-facing itinerary services. The innovations in OTP2 have already been applied to planning, research, and analysis work for several years through Conveyal's R5 project, which informed and inspired the OTP2 transit routing system.

OTP2 Use Cases

The benefits of OTP2 will be most evident in large or dense networks spanning multiple cities: entire countries (Netherlands, Switzerland, Norway), US states, metropolitan regions and cross-border conurbations (e.g. NYC metro area). Although the scale of trip planners is sometimes limited by the geographic extent of administrative structures (national rail or bus operators or ticketing agencies), OTP2 should be capable of handling even larger networks, and we do for example regularly test on a unified Nordic trip planner in hopes that such systems will materialize over time as more territories adopt OTP.

OTP2 development has been driven by adoption of open source routing software in Northern Europe. Importantly for deployments in Europe, OTP2 introduces support for EU-standard Netex and SIRI data sources in addition to GTFS. The Nordic profile of Netex understood by OTP2 uses the same schema as the EU profile, and generalization to the EU profile should be feasible once it is standardized.

High-level feature comparison

Feature OTP1 OTP2
OSM street data yes yes
GTFS transit data yes yes
Netex transit data no yes
(Nordic profile)
GTFS-Realtime yes
(streaming, polling, incremental)		 yes
(streaming, polling, incremental)
SIRI Realtime no yes
Elevation data TIFF and NED TIFF and NED
One-to-many routing,
isochrones and scripting		 yes no
Java version 8+ 11+
Multiple regions per server yes no
Hot reloading of graphs yes no
Street (OSM) routing algorithm Generalized cost A* Generalized cost A*
Transit routing algorithm Generalized cost A* Multi-criteria range-RAPTOR
Search segmentation Single search through access, transit, egress Access/egress separate from transit search
Goal direction Upper bound search backward from destination,
over streets and transit, interleaved with forward search		 Upper bound search backward from destination
on transit only, before forward search begins
Alternative itineraries "Trip banning",
N lowest generalized costs		 True Pareto-optimal results
Departure/arrival time Single departure or arrival time only Every minute in a window up to several days long
API Paging no yes
Timetable View no yes
Plugin Sandbox Extensions no yes (See extensions)
Data storage local, S3 (elevation only) extensible with local, ZIP,
and Google Cloud plugins, S3 available
Transfer Priority yes yes

Commentary on OTP1 features removed from OTP2

OTP2 brings significant improvements in speed and scalability, but does not retain all features of OTP1. We have chosen to prioritize long-term maintainability, so only those features that are "owned" by a team of professional developers will be carried over to OTP2.

Some features have been removed to simplify the code base and improve maintainability. Others have been removed to reflect separation of concerns: following principles of modular design they should be handled outside OTP, or are already covered by other projects where they are more actively developed.

Analysis

Many OpenTripPlanner contributors have been primarily interested in transportation and urban planning use cases. We consider these use cases quite important. This has been a major area of application for OpenTripPlanner and has helped popularize cumulative opportunities accessibility metrics. For example, the University of Minnesota Accessibility Observatory used OpenTripPlanner for Access Across America. Nonetheless, the analysis code in OTP1 is essentially an unmaintained and unsupported early prototype for later projects, specifically Conveyal's R5 (and the Conveyal Analysis system built upon it). OTP1 seems to have gained popularity for analysis uses due to the existence of documentation and an active user community, but has significant technical shortcomings. One of these is simply speed: OTP1 can be orders of magnitude slower (and more memory-intensive) than the approaches exemplified in R5. The other is the requirement to search at a single specific time. Travel times and especially wait times on scheduled transit vary greatly depending on when you depart. Accounting for variation over a time window requires repeated independent searches at each possible departure time, which is very inefficient. R5 is highly optimized to capture variations in travel time across time windows and account for uncertainty in waiting times on frequency-based routes.

Due to its similarity to the R5 approach, OTP2's transit router would not have these same problems. Nonetheless, we have decided not to port the OTP1 analysis features over to OTP2 since it would broaden the focus away from passenger information and draw finite attention away from existing projects like R5 and Conveyal Analysis.

Accordingly, we have made an effort to clean up and augment OTP1 analysis documentation for researchers who will continue to need it. It should remain possible for people to continue using OTP1 if they prefer. If you would instead like to apply the innovations present in OTP2, we recommend looking into R5 or Conveyal Analysis.

Routers API and Hot Reloading

Via it's Routers API, OTP1 allows loading data and serving APIs for multiple separate geographic areas. This is functionally equivalent to running more than one OTP server with separate data sets. This system also allows reloading transportation network data when it changes, or even pushing new data over a network connection.

These were all adaptations to the very different IT environment that existed earlier in OTP history. These days, containerization and on-demand cloud servers have become ubiquitous, and most users solve these problems in totally different ways - by provisioning and starting up entirely new virtual servers, then switching a load balancer over to those new servers. Because the Routers API is complex and exposes potentially damaging functionality over the network, it has been removed from OTP2 to simplify the code base and make it easier to reason about security.

Routing request parameters

Less parameters are available on the OTP2 REST API than in OTP1. Often there is no practical loss of functionality, just a different way of expressing things due to the new routing algorithms. A summary of parameters that have been removed and their replacements can be found in the migration guide

OTP Trip planning and Transit index APIs

OTP1 had two APIs for trip planning, the REST API and an GraphQL API (early version of the GTFS GraphQL API). This API has been formalised and is now, together with the Transmodel GraphQL API, the only supported way of sending requests to the OTP routing engine.

Details of those two APIs are available at the following pages:

The plan is to merge the two APIs above, clean it up and make it the new official API. The HSL API uses GTFS terminology, while the Entur API is Transmodel(NeTEx) based. Both APIs are similar in semantics and structure, and provide the same functionality.

Additional characteristics added in OTP2

Sandbox Extensions OTP2's Sandbox system allows for plugins, proprietary extensions, and experimental feature development with less overhead. It forces OTP2 to become more extensible, while reducing process overhead when developing non-core features.

Cloud support In OTP1 all data access (config, input data, and graph output) is by direct access to the local filesystem. The only exception is elevation data, which can be loaded from AWS S3 as well. In OTP2, all data access is through an abstraction layer. This can be configured to support individual local files, zip files, and Google Cloud Storage. The new data access treats directories and zip files as “equal”, and this functionality is used to read the contents of GTFS and NeTEx archives. Other data sources can be supported by writing plugins. Entur has written a plugin for AWS S3 which has not been merged. If requested they can provide this code for AWS S3.

Library upgrades We have adapted OTP2 to run on Java 11+ and moved to newer versions of some dependencies such as GraphQL and One Bus Away.

Bugfixes At least bug issues have been resolved in OTP2. Critical fixes have been backported to OTP1. See https://github.com/issues?q=is%3Aclosed+is%3Aissue+label%3AOTP2+label%3Abug

Other features removed from OTP2

AlertPatch GTFS-RT Service Alerts will no longer affect routing (e.g. cancel trips). A GTFS-RT Trip Updates feed should be used for this purpose.

Migration guide

The development community has maintained a migration guide from version 1.5.0 up to 2.2.0 when it was no longer feasible to document every change as version 2 was considered the only supported one. The document can be found in the documentation of version 2.2.0.