OpenTripPlanner

Past, Present and the Future

Hannes Junnila

FOSDEM 2023 — 4 February 2023

​

About me

Tinkered with OTP since ~2011

• City of Helsinki 2014
• Helsinki Region Transport & Digitransit 2015–2018
• Kyyti 2020
• Entur 2021–

​

hannes.junnila@gmail.com

Past — OpenTripPlanner 1

​

Present — OpenTripPlanner 2

• How it works
• New features
• Sandbox extensions
• Simplified setup

​

Future — Roadmap

Agenda

Past

Pain points with OTP 1

Time-dependent A* search with trip banning

• Insufficient performance for nationwide deployments
• Focus on research capabilities
• Solved by split into OTP and R5
• Lack of architectural vision and focus
• Fragmented development
• Each organization had its own fork

Run search

Ban trips in

found path

Present

OTP Routing Process

API Routing Request

API Routing Response

Street Search

Fixed Route

09:00

09:05

09:08

09:12

09:15

09:20

09:24

09:30

Hail and Ride Sections

09:00

09:05

09:08

09:12

09:15

09:20

09:24

09:30

• Fixed route and schedule

​

• Between stops 3 and 6, you can board or alight anywhere along the route

Flexible Areas

Area A

• Door to door anywhere within a service area

Flexible Areas

Area A

• One area for boarding and another for alighting

Area B

Flexible Areas

Area A

Area B

Area C

• Any number of areas, some with only boarding some with only alighting

​

Fixed Stops in an Area

Area A

• Stop to stop within an area

Feeder services

Area A

• Area to stop and vice versa

Complex services

Area A

Area B

Raptor

• Raptor works in rounds
• Implicit graph model using memory layout
• One round for each transit trip & transfer
• Exploring the transit network following transit routes.
• Find all pareto optimal paths by
• [ Arrival time | Number of transfers ] – Given departure time
• Range Raptor
• Iterates backwards over departure time within a search window
• Only explores new trips not reached by previous rounds
• Pareto optimal by
• [ Departure time | Arrival time | Number of transfers ]
• Multi-criteria Range Raptor
• One or more additional criteria – with performance penalty
• Pareto optimal by
• [ Departure time | Arrival time | Number of transfers | Generalized cost ]

28

Samples

�Search�Window�2 - 20 h��Dataset

Norway

​

Transfer optimization

Where to transfer between a pair of trips?

• Transfer priority cost
• Station transfer priority*
• Guaranteed transfers
• In-seat transfers

​

• Optimal wait time
• Avoid very short transfer times*
• Avoid back-travel*

​

* Not in raptor

Itinerary Filtering & Decorating

• Limit the number of results
• Worse but optimal results
• Grouping too similar results
• Park & ride, where the car is parked almost immediately

​

• Decorate results
• Real-time alerts
• Price calculation

​

• Sorting of results

NeTEx–GTFS

• New internal data model independent of the import format
• OTP 1 used GTFS POJOs internally
• New entities from NeTEX not existing in GTFS

​

Different formats have different benefits

• GTFS
• Easy to produce and consume
• YAGNI — Requires producer and consumer before appending spec
• Netex
• Much more complex and nuanced
• Caters for almost all use cases

Sandbox extensions

• New feature in OTP 2 for code not suited for core
• Extremely successful, currently 22 extensions
• New APIs
• GraphQL
• Travel time
• Vector tiles
• New data formats
• Data overlay
• SIRI
• New functionality under development
• GTFS-Fares v2
• GTFS-Flex v2
• Deployment-specific code
• Non-GBFS vehicle rental updaters
• Cloud integrations

GraphQL APIs

Two APIs with different vocabularies

• GTFS
• Transmodel

Vector tiles

• Mapbox vector tile format
• Multiple layer types available
• Stops & stations
• Rental stations & vehicles
• Car and bike parking
• Configurable mapping from internal model to tile layer
• Real-time info
• Multilingual

Travel time analysis

• Requested feature from OTP 1
• Two output formats
• GeoJSON — isochrones
• GeoTIFF — travel time rasters
• Configurable street & transit modes

Simplified operations

• Abstracted data sources
• Local file system
• HTTPS
• Cloud storage services
• GCP storage
• Azure blob storage
• AWS S3 (open PR pending somebody using it)
• All input and output paths can be configured
• Data can be read from or written to an data source
• Improved monitoring support
• Prometheus endpoint

https://docs.opentripplanner.org/en/dev-2.x/BuildConfiguration/

//build-config.json

{

"transitModelTimeZone": "Europe/Brussels",

"osmCacheDataInMem": "true",

"osm": [

{

"source": "https://download.geofabrik.de/europe/belgium-latest.osm.pbf",

"osmTagMapping": "germany"

}

],

"transitFeeds": [

{

"type": "gtfs",

"feedId": "NMBS",

"source": "http://gtfs.irail.be/nmbs/gtfs/latest.zip"

},

{

"type": "gtfs",

"feedId": "LIJN",

"source": "http://gtfs.irail.be/de-lijn/de_lijn-gtfs.zip"

},

{

"type": "gtfs",

"feedId": "TEC",

"source": "https://gtfs.irail.be/tec/tec-gtfs.zip"

},

{

"type": "gtfs",

"feedId": "MIVB",

"source": "https://gtfs.irail.be/mivb/mivb-gtfs.zip"

},

]

}

Future

Performance

Competition neutrality

• New Raptor criteria
• Fixed size bitset for used authority/operator group

​

• Operator 1, departure from A at 18:00, arrival at B at 21:00
• Operator 2, departure from A at 18:01, arrival at B at 20:59
• => Only operator 2 is showing up

​

Unified GraphQL API

• Currently two GraphQL APIs and one REST API
• Deprecate REST API
• New unified GraphQL API
• One structure
• Two dialects, GTFS and Transmodel
• Use translation file go from internal model to API

Useful links

• https://www.opentripplanner.org/

​

• https://docs.opentripplanner.org/en/dev-2.x/

​

• https://github.com/opentripplanner/OpenTripPlanner

​

• https://gitter.im/opentripplanner/OpenTripPlanner

​

• https://otp-performance.leonard.io/

​

​

​

​