OpenTripPlanner : The Portland Experience

1

OpenTripPlanner:The Portland Experience

Transit GIS Clearinghouse Webinar SeriesNational Center for Transit Research

Thursday, May 31, 2012

2

Presentation Overview

• Project Background• Building the Open Source Community• Solving the Data Question• Testing & Evaluation• RTP Beta Launch and Reception• Future Directions

3

Project Background

4

About TriMet• Provides bus, light rail,

commuter rail, and paratransit service to Portland, Ore. region

• Over 250,000 weekday boardings in 2011

• Recognized leader in open data and innovative rider information delivery

5

About OpenPlans• NYC-based technology

organization founded in 1999; 50 people today

• Focus on Livable, Sustainable Communities; Open Government; Open Technologies

• Contracted by TriMet to support MMTPS Project

Livable Cities

Gov 2.0 “Open”

6

MMTPS Project Overview

Project Tasks Estimated Completion Date

Actual Completion Date

Project Management Plan 

September 2009 

September 2009 

Software development and implementation of working prototype

 January 2011

 February 2010

Evaluation studies for data efficacy and OTP planned trip results

 May 2011

 July 2010 – June 2011

• MMTPS: Multimodal Trip Planning System• Funded by Regional Travel Options (RTO)

grant from Portland Metro

7

Trip Planners, Circa 2009• Primarily single-

mode (e.g. bike only, transit only)

• Most transit agency planners relied on proprie- tary technology outside of agency’s control

8

Multimodal Trip Planners• Support planning integrated trips across

multiple modes (e.g. bike, walk, transit)• Several active, emerging projects as of

2009, but no framework for cooperation

9

Why Open Source?• Proprietary solutions

often cost-prohibitive

• Early innovation in multimodal routing driven largely by open source projects

• Challenge: build unified multimodal routing platform with strong user/developer community

10

MMTPS Project Goals• Develop a complete open source, multi-

modal trip planner building on existing open source trip planning and routing tools

• Build a healthy development community to ensure long-term growth and support

• Deploy a working trip planning system using TriMet's datasets for use in Portland

• Test usability and accuracy of trips planned using the new system

11

Building the Open Source Community

12

Kick-Off Workshop: July 2009

13

Key Workshop Take-Aways

• OTP would use an open source development method

• OTP would use open architecture • Open data would be explored as an

option • An appropriate open source software

license would be explored

14

The Open Source Approach

• Code available under agreed-upon open source license (GNU Lesser General Public License)

• Collaborative method for tracking work and progress using online issue tracker

• Established system for proposals and voting by project contributors

• Active project mailing lists and chat room

15

Typical OTP WorkflowData Inputs

OTPGraph

Builder

GraphObject

OTPTomcatServer

API

Third-PartyApps

Main OTPWebapp

16

Progress in Year 1• Established project name, domain, and basic

project infrastructure (e.g. issue tracker)• Designed trip planner Application

Programming Interface (API)• Initial implementation of core modules:– Core routing engine – Narrative engine – Data store and manager – Front-end user interface – Administrative user interface

• Initial documentation and packaging

17

2010: One-Year Anniversary

• “Sneak Preview” event held in July 2010, one year after kickoff workshop

• Initial wave of positive publicity helps build anticipation for launch

18

Progress in Year 2Wide Range of OTP Bug Fixes and Enhancements, Including:• Overall speed / performance / memory usage

improvements • Improved transfer support (minimum transfer

times; transfers now routed on walking network) • Improved wheelchair accessibility support• Support for traffic circles / roundabouts • Better slope visualization and slope override for

bridges • Preferred/non-preferred/banned routes • Better Code documentation, tutorials and user

guides • Translations from English into seven languages

19

Solving the Data Question

20

Multiple Data Sources Required

• Transit Data: General Transit Feed Specification (GTFS) feed, already maintained by TriMet

• Elevation Data: National Elevation Dataset (NED) rasters, open data maintained by USGS

• Street Network Data: Open Question at outset of MMTPS project

21

Street Network Considerations

• Does it have the necessary attribution to support multi-modal routing in the Portland Metro area? Can it support driving directions for a future phase?

• Is the linework seamless between jurisdictions (including neighboring cities in OR & WA) and is it accurate?

• Is it affordable? • What are the maintenance and update

issues?

22

Data Sources Considered1. Commercial routable street networks, such as TeleAtlas and Navteq

PROS• Seamless, worldwide

datasets• Have necessary

attributes for multimodal routing

CONS• Very expensive• Proprietary licenses• Agency loses control

over data update process

23

Data Sources Considered2. RLIS Street Centerline File, maintained by Metro

PROS• Accurate linework

based on aerial photography

• Consistent with regional base map

• No licensing fees

CONS• Lacks some attributes

needed for routing• Not seamless beyond

3-county core coverage area

24

Data Sources Considered3. OpenStreetMap (OSM)

PROS• Free & non-proprietary• Designed for routing• Seamless across U.S.• Large community of

maintainers• Aligns with TriMet’s

open data policy

CONS• Relies on user-maintained

“crowd-sourced” data• Not consistent with

regional base map• Linework needs

improvement in some cases

25

Evaluation Process• Preliminary instance of OTP set up for

testing using RLIS street centerline dataset

• Second instance of OTP created for Portland using OSM data for comparative purposes

• Further analysis concluded that the OSM street network should be used for routing rather than the local RLIS dataset

26

OSM Improvement Project

Team of four TriMet interns spent much of 2011 improving Portland OSM data• Improve street alignment

geometry• Add additional linework:

(missing streets, trails, bicycle lanes, etc.)

• Add/correct attribution • Verify street directionality

and add turn restrictions

27

Testing & Evaluation

28

Preliminary Testing, 2011

• Transit Testing – 250 trips collected from call-center inquires fed into OTP-based planner; OTP itineraries were found to be consistently accurate and optimal

• Bicycle Testing – 15 typical bike trip within TriMet service area selected for testing OTP against two other bike planners, using both default and customized weighting configurations

29

Bicycle Evaluation Results

• Does the OTP router choose safe, efficient bicycle routes? Yes, assuming OSM contains complete and accurate data on bicycle infrastructure and road type, as is the case in the test area.

• Do user specifications (quickest trip vs. safest trip) generate meaningful results? Yes, once the specific values selected for each weight are given careful consideration and testing

30

Bicycle Evaluation Results

• Are the routes easy to follow? Are the itineraries user-friendly? Not initially, however, improvements made and tested in preparation for the public release – specifically, simpler routes with fewer steps and minimized number of turns

• Does the OTP router break up elevation gain/loss efficiently? Yes; OTP results are comparable to existing bicycle trip planners, particularly for quickest trip

31

Bike-to-Transit Performance

32

Key Insights from Testing• OSM is capable of storing valuable, routable

information related to bicycle routing • OTP is capable of combining OSM data and

elevation data to produce viable bicycle routes

• Weighting will be critical to generating optimal bicycle routes in OTP

• Further development needed to generate user-friendly itineraries from OSM data -- To be addressed in advance of beta launch

33

Beta Launch & Reception

34

RTP Beta Launch: Oct. 15, 2011

35

Launch Features• Fully multimodal (bike/ped/transit) trip

itinerary planning• Advanced bike preference input via

“bike triangle” widget• Visualization of route topography• Geocoding support (using legacy

geocoder)• Support for printing and sharing trips• Support for GTFS-Realtime alerts

36

Live Demo

37

Community Response

38

Future Directions

39

Replacing Call Taker Functionality

• Open source geocoding• Group / field-trip reservation module• Preferred transfers editor• Customer service call-taker interface• Mailable itinerary templates• Text-only interface

40

Next-Generation Interface

• Migrate to more modern, lightweight mapping library

• Leaner and more adaptable UI design

• Improved social media integration

41

Mobile Support• OTP open architecture

supports development of wide range of native mobile apps as independent efforts

• Native Android app currently under active development at USF

• Better mobile support in default OTP webapp

42

OTP Analyst Package• Leverages OTP routing engine to enable

sophisticated analysis of transit accessibility, level of service, and related measures

43

Automated Deployment• OTP Deployer

automates creation of OTP instance given GTFS inputs

• Option for long term hosting and data management supporthttp://deployer.opentripplanner.org

44

Thank You!David Emory

[email protected]

Kevin [email protected]

Bibiana [email protected]