-
Notifications
You must be signed in to change notification settings - Fork 126
OpenTripPlanner and Navitia comparison
OpenTripPlanner (OTP) is an open source multi-modal trip planner, which runs on Linux, Mac, Windows, or potentially any platform with a Java virtual machine. OTP is released under the LGPL license.The code is under active development with a variety of deployments around the world, and we are working toward a 1.0 release in the coming year.
OpenTripPlanner was launched by Portland, Oregon's transit agency TriMet, who wanted to create a true multi-modal router using an open source model. TriMet had created the GTFS format together with Google, and wanted to stimulate reuse of their open schedule data was used by both commercial partners and open source projects. The project was kicked off by the authors of the major open source transit passenger information software of the day: David Emory of FivePoints, Brian Ferris of OneBusAway, and Brandon Martin-Anderson of GraphServer. From 2008 through 2012, development was coordinated by New York nonprofit OpenPlans. By early 2013, OpenTripPlanner had become the primary trip planning software used by TriMet in the Portland regional trip planner and was the back end for several popular mobile applications and journey planning web sites mainly in North America and Europe. At this point the OpenPlans transportation software team became the independent consultancy Conveyal. The original OpenTripPlanner development team from OpenPlans still actively participates in programming, design, and community coordination via the mailing list and their roles on the OTP Project Leadership Committee.
In 2013-2014 OpenTripPlanner was a focal point in the Dutch Transport Ministry's MMRI (MultiModal Travel Information) project which encouraged investment in trip planning platforms and services. A consortium of five companies worked together to improve OpenTripPlanner performance in large regional transport networks and account for real-time service modifications and delays. The Plannerstack Foundation is now providing OpenTripPlanner as a hosted service including high quality open data integration for the Netherlands.
In 2014 a new commute planning site for the Washington, DC metropolitan area was launched. It depends on OpenTripPlanner to weigh the costs and benefits of various travel options using profile routing. As of 2015, OTP now powers the New York State department of transportation's transit trip planner. It provides itineraries for public transit systems throughout the state in a single unified OTP instance.
Navitia is an open source web service which acts as a framework on which front end traveler information applications can be built. Its provides:
- Multi-modal journey planning
- Support for multiple regions, districts, or countries (using multiple Kraken components)
- Ways to explore public transport data including spider maps
- Proximity search for map information
- Timetables/schedules for transit lines
- Upcoming departures and arrivals at a given stop
The Navitia API is provided as a hosted open service at https://api.navitia.io/ and is pre-loaded with open data from several regions.
Navitia is released under the AGPL license.
Navitia as currently disposable, is the re-writing of the 2003 system. It has been written to provide unitary transport information services to web sites. The system was written to manage data for the Paris region Ile-de-France (http://www.vianavigo.com), French national railways (SNCF), and larger cities in France such as Lyon (www.tcl.fr). The data reach end users via different channels: inter-regional trip planning sites, web sites specific to one region or transport operator, displays inside stations, printed paper timetables, etc.
In 2013 we were carrying out a complete re-write and decided to open source this new version of Navitia. You can find more useless historical information here https://github.com/CanalTP/navitia/wiki/History :)
Kisio Digital controls the Navitia roadmap, following these principles:
- adapted source code (with documentation and adapted comments "only when necessary")
- modular architecture (separate components for autocomplete, public transport, street routing, etc.)
- source code control using Github pull requests
- dedicated continuous integration platform
- dedicated regression testing system
- two-week development cycle
OTP and its new R5 computation module are increasingly used in analyzing public transport networks and visualizing or mapping the results of such an analysis, while Navitia focuses on being a framework for making a wide range of passenger information systems (apps or web sites).
OTP and R5 are designed to manage the mass of information needed to compute complex responses like isochrones, optimization over time ranges, etc. It is particularly useful for building passenger transport analysis tools.
Several methods are available. OTP mainly uses "trip banning" in point to point searches: after a path is found the vehicles that path uses are eliminated and the search is re-run. A custom algorithm in Modeify to retain suboptimal but otherwise interesting routes.
When used as a trip planner, the OTP system is quite simple to run and configure on a personal computer. Its monolithic architecture simplifies installation and code modification.
Navitia focus on individual passengers' journeys, helping them choose among relevant alternatives. It is specifically designed as a base upon which to build personal information applications.
The RAPTOR algorithm has been extended from its original published version. It gives bounds at each stop in terms of time and number of transfers. Navitia finds all the paths that respect those bounds. This allows us to impose secondary objectives to break ties. For example, if there are two equally fast places to transfer between two lines, we want to choose the one that allows the longest layover time to be safe.
The system is very modular, which allows Navitia to be deployed in many different configurations. It is more appropriate for a high-throughput hosted open service rather than use on a stand-alone personal computer. Navitia has these characteristics:
- The possibility allocate computing power differently between the front-end module, the different computation modules, the input data processing modules, etc.
- The modular architecture allows you to manage heavy traffic.
- It is possible to manage multiple geographical regions within a single endpoint. The system can have worldwide coverage, matching each user to a region.
- Developer user accounts exist for bulk re-users of the system, in order to follow their consumption of system resources.
Navitia uses an extended transit data format that is very similar to GTFS, but has become incompatible. Differences include:
- "Lines" which are groups of GTFS routes, e.g. the line RER A is composed of routes RER A1, A2, A3, and A4
- There are a wider range of mode types. GTFS provides for this with extended mode codes.
- Geometries (alignments) are provided for lines and routes, not only trips as in GTFS.
OTP is able to receive GTFS-RT real-time delays, cancellations etc. as a continuous stream. They are immediately visible in routing results. Somewhat related: for network analysis scenarios, we have a system for stateless non-destructive patching of the RAPTOR timetables. Network modifications are sent along with an individual request and applied temporarily only for the duration of the request.
In Navitia, delays and cancellations are currently somewhat slow (~1 sec per 1000000 stop-times) to apply because they are both implemented using copy-on-write snapshots. Navitia makes a full deep copy where OTP uses hierarchical targeted copying, relying on reuse of references and garbage collection.
Navitia exposes a HATEOAS API for all of its services. Every response contains links to other services. For example, it is possible to request a schedule for every transit line referenced in a Navitia itinerary, using an embedded link. The endpoint is able to manage multiple regions, creating a coherent worldwide API.
When converting text to coordinates, Navitia manages spelling mistakes, typing errors, missing words etc. It finds a Navitia object id and coordinates based on addresses, POIs, city districts, or public transport objects.
When converting coordinates to text, the system uses its multi-coverage capability to find the id within every Kraken (regional calculation engine) it manages.
Navitia's algorithm is designed to find many multi-modal alternatives when possible. It has replaced the standard question "how do I arrive ASAP" with "give me every relevant itinerary". The marketing tagline is "Responsive Locomotion", and this is how we have made responsive JSON :) When there are multiple geographical regions, Navitia is able to choose the right region even for the simplest coordinate-to-coordinate requests.
Navitia uses the RAPTOR algorithm. It has been greatly adapted to manage local circumstances such as:
- On-demand Transport
- Political restrictions and rules about using national lines for local service
- Optimization of pick up/drop off stops when multiple choices are available via a dedicated "RAPTOR reader" algorithm
OTP wheelchair mode adjusts trips based on:
- A maximum acceptable slope
- OSM ways marked as inaccessible to wheelchairs
The Navitia algorithm handles wheelchair itineraries within a particular coverage. We will work on a new dedicated module in order to be multi-coverage.
Navitia's HATEOAS interface is designed to provide information on every kind of public transport object and offer all its service in a simple way. It allows API users to build their own web site experience upon the hosted Navitia service without setting up any additional local databases. Read https://github.com/CanalTP/navitia/blob/dev/documentation/navitia.io/source/integration.rst#public-transportation-objects-exploration-networks-or-lines-or-routes for more explanation.
This wiki page is a summary of the results of a workshop conducted by Kisio Digital and Conveyal in late 2015. The original notes from that workshop are available on the following pages:
| Sphere | Feature | Navitia | OTP |
|---|---|---|---|
| Web service | RestFul API | Yes | Yes |
| URIs | yes | yes | |
| Itinerary | See below | ||
| Schedules | get schedule at a stop | yes | so-so |
| get schedule for all trips on a route | yes | so-so | |
| filtering schedules and objects in REST API | yes | so-so | |
| upcoming arrivals/departures at a stop(area) | so-so | yes | |
| Geocoding | autocomplete | yes | prototype |
| spelling mistake | yes | yes | |
| input mistake | yes | so-so | |
| sentence mistake (ie Manhattan vs Man-hattan) | yes | so-so | |
| house number not in data | yes | no | |
| reverse geocoding | yes | not integrated | |
| Transport data | Autocomplete on transport objects | yes | so-so |
| Exploring the referential via API (Hateoas) | yes | no | |
| Combining filters | no | ||
| Proximity filters | |||
| Debugging tool | |||
| Data analysis | Basic isochrons at Date-Time | yes | yes |
| Isochrons in Time window | yes | ||
| Isochrons with walking at end | yes |
| Sphere | Feature | Navitia | OTP | note |
|---|---|---|---|---|
| Public transport | nxm | yes | not in api | Available in algo |
| over midnight connection | yes | yes | ||
| minimum transfer time at the same stop | yes | yes | OTP: parameter that applies to all transfers unless overridden in transfers.txt | |
| use complete list of enumerated transfers | yes | yes | OTP: switch to use only transfers.txt instead of street network | |
| interlining transfers (blockId) | yes | yes | ||
| maximum connection duration | yes | yes | OTP: very easy to extend or parameterize this behavior | |
| banning routes/stops/trips | yes | yes | Avoid using specific route/stop/trip in result | |
| Wheel chair accessibility | yes | yes | Biggest problem is data in input files, OTP uses per-stop and per-vehicle info | |
| local traffic ban | yes | no | "ITL": you can't take intercity trains for local trips | |
| board/alight (dis)allowed | yes | yes | GTFS pick up and drop off type | |
| Demand responsive transit with stop time | yes | maybe | OTP: We may actually handle this with a "call agency" message | |
| Demand responsive transit with stop point | yes | no | ||
| Demand responsive transit via zones | yes | no | Instead of stops, the line passes through a series of services zones | |
| Demand responsive transit for wheelchair | no | no | ||
| Detail: intermediate stops and route sub-shape | yes | yes | List of all stations the train passes through with timings | |
| Street network | Bike share | yes | yes with rt | |
| Car park | yes | yes | ||
| bike | yes | yes | OTP: use bike path, slope | |
| Car only | yes | yes | navitia: using park and ride | |
| turn restriction | in progress | yes | ||
| one way | yes | yes | navitia: wrong one way at the arrival | |
| speed by segment | in progress | yes | based on OSM speed tags, or on real-time congestion | |
| handicap accessibility | no | yes | OTP: fauteuil roulant seulement, OSM wheelchair=false tag and maximum slope | |
| turn by turn directions | yes | yes | OTP: roundabout | |
| Alternatives | Optimization criteria managing | |||
| Y connection: earliest of equiv. transfers | yes | so-so | Navitia finds transfer with longest wait; OTP has addressed this problem, but not certain to still work optimally | |
| Transfer point selection on common trunk | yes | maybe | Navitia finds transfer with longest wait within the transfers.txt file; OTP attempts to respect transfers.txt preferred transfers | |
| Three-pass transfer length compression | yes | so-so | OTP does three passes, but restricted to exactly the same routes. After switch to RAPTOR OTP will do true re-optimization. | |
| Real time | Messages attached to objects (route, line...) | yes | yes | GTFS-RT "alerts" |
| Closing and cancellations (stop, trip...) | yes | yes | Navitia: can take one minute to appear. OTP: applied instantly. Both use Copy on Write snapshots, but Navitia makes a full deep copy and OTP uses hierarchical targeted copying. | |
| Next departure times at a given stop point | yes | yes | OTP: streaming. | |
| Delay/modification of stop times for vehicle | yes | yes | Navitia: takes a minute; OTP: streaming. We agree that propagating delays down the line is an upstream data processing step (external module) |