Skip to content

OpenTripPlanner and Navitia comparison

Stephan Simart edited this page Nov 25, 2015 · 10 revisions

Presentations

OTP

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.

History

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

Navitia is an open-source web-service which act as a framework to build front end applications with traveler informations:

  • multi-modal journeys computation
  • explore public transport data like spider maps
  • proximity search for map information
  • line schedules
  • next departures or arrival

The "all in the box" open service API can be found at http://api.navitia.io/ with open data informations.

Navitia is released under the AGPL license.

History

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 Ile de France data ( http://www.vianavigo.com ), SNCF data, big city data (www.tcl.fr) and to feed different media: standard web-site, specific web-site, station screens, paper line schedules... Open-sourcing the system has been decided in 2013 while starting the development of the re-writing of the system.

Kisio assumes the head of navitia roadmap, following these tenets :

  • adapted source code (with documentation and adapted comments only when necessary :) )
  • modular architecture (autocomplete module, PT module, street network module...)
  • code commit management using the pull-request github system
  • dedicated continuous integration platform
  • dedicated non-regression system
  • 2 weeks development cycle

Difference: how make the good choice

Overall, OTP will shine in data analysis and making analysis maps, and Navitia will star when you need a framework to make passenger information.

Why choosing OTP

OTP is designed to manage mass informations with computing complex request like isochrones, range itinerary, etc. It is really useful to build new analysis tools around people travels.

Source of variation in Journeys

Several methods used. We use "trip Banning" in point to point searches, and a home made algorithm in Modeify to retain suboptimal but interesting routes.

Technical architecture

The system is really simple to run and configure on a personal computer. Its monolitic architecture simplifies at most installation and code modification.

Why choosing Navitia

Navitia focus on each specific passenger, helping him to choice the best trip between pertinent alternatives. It is more useful to build personal information applications.

Source of variation in Journeys

The RAPTOR algorithm has been adapted most on reading result. 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.

Technical architecture

The system is very modular. It allows to deploy navitia in every kind of technical architecture

  • possibility to adapt power allocation between the front-end module, the different engine modules, the feeding modules... The modular architecture allows you to manage strong consumption
  • possibility to manage multiple geographical regions within a lonely end point. The system masks regional specifications to end users and can be worldwide.
  • possibility to manage developer user account in order to follow consumption of the system

Feature list

I'm not sure following point has to be there, they might be in the spreadsheet https://framacalc.org/OTP_Navitia_comparison https://framacalc.org/Itinerary_feature

Feeding systems

GTFS vs NTFS

Extended format very similar to GTFS, but it has become incompatible. Some changes:

  • lines: groups of routes, e.g. RER A is composed of RER A1 A2 A3 A4
  • modes: wider range of mode types, GTFS already allows for this with extended mode codes
  • geometry: trips, lines, routes

Real Time

OTP: Description in spreadsheet is for Dijkstra point to point. In Transport Analyst for scenario comparison, we have non-destructive stateless RAPTOR table patching. Network modifications are sent along with an individual request and applied temporarily only for the duration of the request.

Navitia vs. OTP: closures and delays are currently slower to apply in Navitia because both use copy-on-write snapshots, but Navitia makes a full deep copy where OTP uses hierarchical targeted copying, relying on reuse of references and garbage collection.

Web-service

Navitia exposes a Hateoas API for every service. Every service response contains links to other services. For example, it is possible to request directly every line schedule from an itinerary roadmap. The end point is able to manage a multiple-region system.

Geocoding

Journeys

street network

OTP wheelchair mode:

  • maximal slope
  • forbidden tad

PT network

Navitia uses Raptor algorithm. It has been deeply adapted to manage specific context:

  • On Demand Transport
  • Political restriction rules
  • Optimizations of pick up/drop off stop when multiple choice via a dedicated "Raptor reader" algorithm

Annexes

workshop source

https://framacalc.org/OTP_Navitia_comparison https://framacalc.org/Itinerary_feature