How does Journey Planner v3 actually work?

Journey Planner v3 is a service for finding travel options for public transport and mobility for all of Norway. It serves as a backend service for most journey planning apps within the public transport sector in Norway today. However, how does it actually work? This article aims to provide an overview of how this service works and what makes it return travel options for your search.

Using data from multiple sources

To enable multi-modal travel options several datasets are fed into the search engine.

Static dataset:
  • OpenStreetMap dataset for all of Norway (geofabrik.de)
  • Elevation data for all of Norway (kartverket.no)
  • All Norwegian Stop Places for public transport (entur.no)
  • All Timetable data for all Norwegian public transport services (entur.no)
Dynamic dataset:
  • All real-time feeds for Norwegian public transport service (entur.no)
  • All available feeds of shared mobility (entur.no)

All datasets and feeds are fed into the search engine which continuously holds an instant representation of the entire public transport network.

The algorithm for finding the optimal path

Any query for a journey between A and B will run the full search algorithm on the current representation. The search algorithm uses the RAPTOR (https://www.microsoft.com/en-us/research/wp-content/uploads/2012/01/raptor_alenex.pdf) algorithm to find relevant journeys. Broken down, this means the algorithm checks for each minute from the requested search time and looks for pareto-optimal results. The current implementation checks for pareto-optimality on the following factors:

  • Arrival time - earliest possible arrival is optimal
  • Departure time - latest possible departure is optimal
  • Transfers - fewer is optimal
  • Cost - accumulated value for all elements of a journey; walk paths, transfers, waiting time, time on public transit vehicle, and boarding/alighting a vehicle. Lowest value is optimal

Given the above factors, a journey is returned as an option only if the journey is optimal with respect to one of these factors. Additionally, some journeys are filtered out of the returned sets of journeys to avoid obviously undesirable alternatives.

Neutrality

The nature of journey planning is complex and what is considered the “best” option is subjective to the preferences of the end user. The system is designed to try to find a sweet spot for representing travel options as neutral as possible while still providing relevant options to the user. Basing this on calculation of finding pareto optimal paths, given the factors described above, is not perfect, however provides the best collection of travel options in most cases within a reasonable response time. Additionally, the API is rich with parameters to tune your query to achieve desired result, however this is not the default behavior of the service.

NOTE: This document tries to describe a high level description of how the service works. If you want the full details of exactly how the algorithm works, the search engine is open source and you can find the full source code at www.github.com/opentripplanner. There are multiple deployments of this search engine around the word and additional information can be found on the project webpage - www.opentripplanner.org.