OpenTripPlanner : The Portland Experience
description
Transcript of 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