Open Trip Planner The Portland Experience Transit GIS

Open. Trip. Planner: The Portland Experience Transit GIS Clearinghouse Webinar Series National Center for Transit Research Thursday, May 31, 2012 1

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

Project Background 3

About Tri. Met • 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 4

About Open. Plans Livable Cities Gov 2. 0 “Open” • NYC-based technology organization founded in 1999; 50 people today • Focus on Livable, Sustainable Communities; Open Government; Open Technologies • Contracted by Tri. Met to support MMTPS Project 5

MMTPS Project Overview • MMTPS: Multimodal Trip Planning System • Funded by Regional Travel Options (RTO) grant from Portland Metro Project Tasks Project Management Plan Estimated Completion Date September 2009 Software development and implementation of working prototype Evaluation studies for data efficacy and OTP planned trip results January 2011 May 2011 Actual Completion Date September 2009 February 2010 July 2010 – June 2011 6

Trip Planners, Circa 2009 • Primarily singlemode (e. g. bike only, transit only) • Most transit agency planners relied on proprietary technology outside of agency’s control 7

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 8

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 9

MMTPS Project Goals • Develop a complete open source, multimodal 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 Tri. Met's datasets for use in Portland • Test usability and accuracy of trips planned using the new system 10

Building the Open Source Community 11

Kick-Off Workshop: July 2009 12

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 13

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 14

Typical OTP Workflow Data Inputs Main OTP Webapp Graph Object OTP Graph Builder Third. Party Apps API OTP Tomcat Server 15

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 16

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 17

Progress in Year 2 Wide 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 18

Solving the Data Question 19

Multiple Data Sources Required • Transit Data: General Transit Feed Specification (GTFS) feed, already maintained by Tri. Met • Elevation Data: National Elevation Dataset (NED) rasters, open data maintained by USGS • Street Network Data: Open Question at outset of MMTPS project 20

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? 21

Data Sources Considered 1. Commercial routable street networks, such as Tele. Atlas and Navteq PROS • Seamless, worldwide datasets • Have necessary attributes for multimodal routing CONS • Very expensive • Proprietary licenses • Agency loses control over data update process 22

Data Sources Considered 2. 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 23

Data Sources Considered 3. Open. Street. Map (OSM) • • • PROS Free & non-proprietary Designed for routing Seamless across U. S. Large community of maintainers Aligns with Tri. Met’s open data policy CONS • Relies on user-maintained “crowd-sourced” data • Not consistent with regional base map • Linework needs improvement in some cases 24

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 25

OSM Improvement Project Team of four Tri. Met 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 26

Testing & Evaluation 27

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 Tri. Met service area selected for testing OTP against two other bike planners, using both default and customized weighting configurations 28

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 29

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 30

Bike-to-Transit Performance 31

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 32

Beta Launch & Reception 33

RTP Beta Launch: Oct. 15, 2011 34

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 35

Live Demo 36

Community Response 37

Future Directions 38

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 39

Next-Generation Interface • Migrate to more modern, lightweight mapping library • Leaner and more adaptable UI design • Improved social media integration 40

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 41

OTP Analyst Package • Leverages OTP routing engine to enable sophisticated analysis of transit accessibility, level of service, and related measures 42

Automated Deployment • OTP Deployer automates creation of OTP instance given GTFS inputs http: //deployer. opentripplanner. org • Option for long term hosting and data management support 43

Thank You! David Emory demory@openplans. org Kevin Webb kwebb@openplans. org Bibiana Mc. Hugh mchughb@tri-met. org 44