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

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

3. Project Background 3

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 4

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 5 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 6 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 7

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 8

9. Why Open Source? 9 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 10

11. Building the Open Source Community 11

12. Kick-Off Workshop: July 2009 12

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 13

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 14

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

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 16

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 17

18. 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

19. Solving the Data Question 19

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 20

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

22. Data Sources Considered 1. Commercial routable street networks, such as TeleAtlas and Navteq 22 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 Considered 2. RLIS Street Centerline File, maintained by Metro 23 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 Considered 3. OpenStreetMap (OSM) 24 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 25

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 26

27. Testing & Evaluation 27

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 28

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 29

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 30

31. Bike-to-Transit Performance 31

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 32

33. Beta Launch & Reception 33

34. RTP Beta Launch: Oct. 15, 2011 34

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 35

36. Live Demo 36

37. Community Response 37

38. Future Directions 38

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 39

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

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 41

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

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

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