CUTR Webinar - Web-based Trip Planner Options for Transit Agencies

Center for Urban Transportation Research | University of South Florida
Web-based Trip Planner Options for Transit Agencies
Dr. Sean Barbeau
Justin Begley
April 18, 2013

2
Overview of Webinar
• Available web-based transit trip planning
options
• Importance of Open Data
• How to Assess Trip Planner Options
• Open Data Implementation Plan

3
Context
• This presentation is based on project funded
by FDOT “SunRail Electronic Trip Planning
Study”
• Final Report at http://bit.ly/SunRail-Trip-Planning
• SunRail (http://www.sunrail.com ) is new rail
service for central Florida coming Spring 2014
• FDOT wanted information on options to make
online trip planning services available to riders
– Including possible connections to LYNX in Orlando
and VoTran in Daytona Beach

5
WEB-BASED TRIP
PLANNING OPTIONS

6
Online Trip Planner Options
Proprietary Vendor-
based Solutions
Third-Party
Applications
(based on Open
GTFS Data)
Open-Source
Solutions
Hosting Options for Proprietary & Open-source Solutions
• Self-hosted – agency maintains software in-house
• Third-party hosted – agency outsources software hosting to third party
Integration Options
• With 511 system
• With other regional agencies
Progression of industry
(1) (2) (3)

7
Proprietary Vendor-
based Solutions
Third-Party
Applications
(based on Open
GTFS Data)
Open-Source
Solutions
Integration Options
• With 511 system
(1) (2) (3)

8
• Vendor-supplied trip planners
• Routing engines fed from proprietary schedule data
software packages
• Limited set of options, closed architecture
• Reliant on GIS street networks that were still ‘in
development’
– Few companies sold/maintained this data
– Expensive licenses
– Data came from address ranges maintained by the
postal service
– Often wrong, one company wanted customers to
identify problems send them changes to improve
quality
In a Land Before Time – pre-2005
& GTFS/Google Transit

9
Proprietary Products Can Still Be
Found In Use
Proprietary Product Advantages:
Turnkey system (Mostly – may
require customization funded by
agency)
 Provided high level of functionality
(for its time)
Capitalized on existing transit
schedule software
Image : Ann Arbor Transit's Trip Planner
Proprietary Product
Disadvantages:
High cost to procure and
maintain
Technical issues with
deployments – reliance on
single vendor to fix
Vendor lock-in
Difficult to maintain over time

10
- First Multimodal Trip Planner
• 2004 – ‘goroo’ (http://www.goroo.com/) - Chicago RTA
• FTA-funded $1.35 million project to create a state of the art, door to
door, proof-of-concept multimodal trip planning system
• Goals:
– Integrate transit, driving, walking, bicycling and rideshare
transportation in a single end to end trip for users
– To use Transit Communications Interface Profiles (TCIP) standards
• Downsides:
– Same limitations of traditional vendor-based solution
– Costly
– Software not open-source
– Proprietary data formats

11
Image : Goroo Interface
Goroo Market Research Costs:
Focus Group - $40,000
User Research Study - $100,000
Search Engine Optimization -
$48,000
Anticipated Costs per Goroo
website visit:
23 cents per visit over 10 years
Interface &
Expenditures

12
• Local control over the trip planner and its evolution
is needed, which can grow to meet the needs
specific to its ridership base.
• Implement features at its own pace and
discretion, accelerating certain functions such as car
and bike sharing, which is not a priority feature of
competing products.
• Dynamic trip planning which responds to
environmental conditions
• Risk of technology becoming outdated is high vs.:
– Third party web hosted trip planning services
– Open-source trip planning solutions
Lessons Learned – RTA & USDOT

13
Proprietary
Vendor-based
Solutions
Third-Party
Applications
(based on Open
GTFS Data)
Open-Source
Solutions
Integration Options
• State 511 system
(1) (2) (3)

14
511 Systems
• Real-time roadway information on major
corridors with road
closures, accidents, incidents and traffic.
• In locations where transit is a viable
alternative to personal auto travel, being
able to compare the road and transit
network side-by-side can help travelers
make informed decisions about mobility.

16
Proprietary Vendor-
based Solutions
Third-Party
Applications
(based on Open
GTFS Data)
Open-Source
Solutions
(1) (2) (3)

17
What is open data?
• Transit data that is shared
with the public
– Typically shared via
website/FTP site/web
services
• No login should be required
(may use API key)
– Should be updated
regularly, with any changes
in schedule/routes/stops

18
Why is open data important?
• Allows public to contribute
services that are cost/time-
prohibitive for the public
sector
– e.g., many mobile platforms
• Vendors are unpredictable
– Some agencies have shared
data only with Google
– When Apple dropped Google
Maps, iPhone users lost
transit directions in major
map solution for 2.5 months
– Apple relied on 3rd party apps
to fill the gap – only possible
if open data was available

19
General Transit Feed Specification
(GTFS)
• Created by TriMet and Google in 2005
• Has become a de facto standard for static transit
schedule/route/stop data
GTFS data consists of multiple text files GTFS data powers Google Transit
and other apps

20
General Transit Feed Specification
(GTFS)
• Over 500 agencies worldwide have transit data
in GTFS format
– 49 of top 50 largest U.S. transit agencies share GTFS
data, over 227 total
– At least 20 Canadian agencies share open data
• In early stages, most agencies created GTFS data
for Google Transit
– But, GTFS is open data format used by mobile
apps, OpenTripPlanner, OneBusAway, etc.
• See “GTFS Data Exchange” for list of agencies
with GTFS data
– http://www.gtfs-data-exchange.com/
– Or, ask your local agency
[1] City-Go-Round, http://www.citygoround.org/, Dec. 4, 2012

21
Recommendations for Creating &
Disseminating GTFS data
1. Understand the GTFS format, and determine how your data will fit
into this format.
2. Determine if you will create and maintain the GTFS data in-house,
or whether you will depend on external organizations for this
service.
– Major transit software packages, other tools, can prepare GTFS
– Estimated cost for putting data in GTFS format using consultant is
$200-500 per route
– Coordinate with other regional stakeholders, if possible
3. Create a “Terms of Use” license – see other agency examples[1-5]
4. Maximize exposure of GTFS data
– Share via agency website, GTFS-Data-Exchange, regional sites
– Create relationship with developers (hack-a-thons, meetups, etc.)
5. Share a list of third-party transit application using GTFS data with
the general public
[1] TriMet (Portland, OR) - http://developer.trimet.org/terms_of_use.shtml [2] BART (SF Bay Area) - http://www.bart.gov/dev/schedules/license.htm
[3] Corona, CA - http://www.discovercorona.com/City-Departments/Public-Works/Transportation/GTFS.aspx
[4] PSTA (Clearwater, FL) - http://www.psta.net/developers/License%20Agreement%20for%20App%20Devs.pdf
[5] HART (Tampa, FL) - http://www.gohart.org/developers/terms_of_use.html

22
3rd party apps - Google Transit
• Includes:
– stop locations
– departure times
– estimated travel
time
– fare amounts
Available for for 800
cities across more
than 25 countries
around the world

23
Other 3rd Party
Apps
Image : The Transit App
Image : HopStop WebInterface
Image : Mapnificent
• Numerous local apps specific to regions also available
• See APTA TransITech presentation (http://bit.ly/Z8VWJZ) for
more details on GTFS-powered apps

24
Downsides of relying on 3rd party
Apps
• Lack of control over services to users
– 3rd party service may be discontinued at any time, leaving
agency without solution (e.g., iOS 6 and transit = 2.5 month
service gap)
• 3rd party apps may not fill particular needs
– Multimodal (bike/walk/etc)
– Bike/car sharing
– Apps for particular mobile interfaces (e.g., SMS)
– Regional integration
• Agencies may need to supplement 3rd party offerings
– What do your riders need?

25
Proprietary Vendor-
based Solutions
Third-Party
Applications
(based on Open
GTFS Data)
Open-Source
Solutions
(1) (2) (3)

26
Open-Source Software
• Open-source solutions provide opportunity for
shared investment into a core set of transit
information services that anyone can use
• Uses open data (GTFS)
• Today, exciting developments in the world of
open-source customer-facing transit software
– OpenTripPlanner – Multimodal trip planner, with
API
– OneBusAway – Real-time transit info, with API

27
• Open-source software –
http://opentripplanner.org
• Development spearheaded by
TriMet in Portland, with
OpenPlans (2009-present)
• Available for anyone to
download, install, modify
– (and, with approval, contribute
back)
• Vendors can provide
installation, customization, maint
enance support
– e.g., Conveyal
(http://www.conveyal.com/, form
erly OpenPlans)
– See http://opentripplanner.com
OpenTripPlanner Deployments
In Production:
• Portland, OR, USA (TriMet)
• Valencia, Spain
• Poznan, Poland
• Lublin, Poland
Tech Demo:
• New York City
• Tampa, FL
• Chattanooga, TN
• The Netherlands
• Ottawa, CA
• Pune, India
• Spain
• Bilboa, Granada, Gipuzkoa - Spain
• Dublin, Ireland
• Budapest, Hungary
• Hamakor, Tel Aviv - Israel
• Athens, Greece
• South Africa
• London, UK
• Canberra, Austrailia
• Singapore

28
TriMet – Portland, OR
• Primary motivation
was to merge
separate transit and
bike trip planners
– http://rtp.trimet.org
• Launched beta
version Oct. 2011
• Switched to OTP
Summer 2012

29
OpenTripPlanner – Tampa demo
• USF’s OTP Demo for Tampa, Fl - http://opentripplanner.usf.edu
– Truly multimodal. Example above is: Bike->Bus->Bike->Bus->Bike

30
Can Add New Transit Systems
HART
USF
Bull
Runner

31
Bike Routing Options
• OTP bike routing
supports mix of
multiple options:
– Time (fastest)
– Hills (flatest)
– Safety (dedicated
bike lanes)
• Still open research
area

32
OpenTripPlanner – Mobile Apps
• OTP provides API so that
anyone can create mobile
apps
• Examples using OTP:
– The Transit App
– Moovit
• “Seed” source code:
– iPhone tech demo OTP app
• Source code on Github
– Android tech demo OTP app
• Source code on Github
• Demo app on Google Play
CUTR @ USF - OTP for Android
The Transit App
Moovit

33
ASSESSING TRIP PLANNER
OPTIONS
What trip planner is right for you?

34
Scenarios Where a Proprietary
Vendor-Furnished Trip Planner May
be Preferred:
• When control over the methods of delivery of transit information are a greater
priority than cost and effort to maintain the system.
• When interoperability with other current and planned transit information
systems and dissemination methods (e.g., mobile apps, SMS, mobile phone
payment) is not a priority to the agency
• When the agency is comfortable with the risk that comes with an investment
in a proprietary product that can only be maintained by a single vendor
• When the agency has an existing relationship with a specific vendor and the
proprietary trip planner is a marginal cost as part of a larger software
purchase.
• When a vendor offers a proprietary trip planning product at little to no cost to
the agency (e.g., in return for an opportunity to monetize the trip planner
through ads).

35
Scenarios Where Third Party Web
Hosted Trip Planners May Be
Preferred:
• When the agency seeks a large saturation in the open
marketplace of mobile apps and other services.
• When insufficient resources (staff and money) are
available to implement a self-sustained product across
many different platforms
(e.g., Web, SMS, iPhone, Android, Windows Phone)
• When the agency is comfortable ceding responsibility to
third parties for trip planner
aesthetics, functionality, availability, usability and
development.

36
Scenarios Where an Open-Source
Trip Planner May Be Preferred:
• When there is functionality required of the trip planner that is not currently found in
commercial third party services.
– Examples include multimodal (e.g., transit, bike, and walk) directions within a single trip, as well as car and
bike-sharing.
• When the agency wants to control trip planner aesthetics, functionality, availability,
usability and development.
• When the agency wants to avoid the risk of “vendor lock-in” that can come with
proprietary products.
• When the freedom of choice to either internally manage or outsource management to
any willing software developers/vendors to maintain and improve the system is
important to the agency
• When interoperability with other current and planned transit information systems and
dissemination methods (e.g., mobile apps, SMS, mobile phone payment) is a high
priority to the agency
• When there is a desire for tight coordination with other regional entities, and a desire
for control over how a trip planner suggests how passengers should transfer from one
service to another.
• When there is a desire to either build a product user information database or monetize
the web planner and its accessibility.

37
OPEN DATA
IMPLEMENTATION PLAN
Best practices for open data

38
Context for Report Recommendations
• FDOT “SunRail Electronic Trip Planning Study”
• Final Report at http://bit.ly/SunRail-Trip-Planning
• Assumptions for recommendations:
– Currently no internal initiatives for SunRail to
pursue its own trip planner
– Funding not available to build a trip planning
solution for launch
• Recommendation – open data with initial
reliance on 3rd party apps
• When future funding is available – open-
source trip planner (OpenTripPlanner.org)

40
Performance Monitoring & Feedback
Data Dissemination
Policy & Administration

41
Step 1: Create a Policy and Procedures
for Generating GTFS Data
• Adopt an internal policy and set of procedures to
generate GTFS data. As an example, many transit
agencies choose to generate their GTFS data at the
same time they are processing schedule changes
• Ensures GTFS data generation becomes as engrained
to agency operation as any other mission critical
task
• Language to require GTFS data generation of a third
party contractor

42
Step 2: Coordinate with Regional
Transit Partners on Goal Setting and
Technical Issues
• An opportunity to build logical connections
to its partner agency data
• Coordinated release, reduce the effort
required for developers to create a
seamless network of regional transit travel
planning

43
Step 3: Draft and Approve a User
Agreement that Accompanies the Data
Based on existing examples from
industry[1-5], licenses typically contain
the following content:
•The agency reserves the rights to its
logo and all trademarks. These marks
should be an indicator used for official
information from the agency only.
•The data is provided without
warranties.
•No availability guarantees are
expressed or implied
•The agency retains full rights to the
data
[1] TriMet (Portland, OR) - http://developer.trimet.org/terms_of_use.shtml
[2] BART (SF Bay Area) - http://www.bart.gov/dev/schedules/license.htm
[3] Corona, CA - http://www.discovercorona.com/City-Departments/Public-
Works/Transportation/GTFS.aspx
[4] PSTA (Clearwater, FL) -
http://www.psta.net/developers/License%20Agreement%20for%20App%20Devs.pdf
[5] HART (Tampa, FL) - http://www.gohart.org/developers/terms_of_use.html

44
Data Dissemination

45
Step 4: Create a Publicly Accessible
Web Address that Contains GTFS
Data
• Host GTFS data (e.g.,
google_transit.zip file) on a
publicly-accessible web server
• The URL to the GTFS data that
is shared with the public
should always point to the
most recent GTFS dataset

46
Step 4a: Create a Developer
Webpage that Links to the GTFS
Data and User Agreement
• Consider creating a developer
webpage that contains links to
the GTFS data, Terms of Service
agreement (if any), and any
application programming
interface (APIs) information.
• An API increases the likelihood
that the local community would
create apps that incorporate
GTFS data

47
Step 5: Use Email Blasts to Notify Third
Party Service Providers and the Transit
Developers Google group
Third Party Service Contact Information
Google Maps https://support.google.com/transitpartners/bin/request.py
Open Trip Planner Transit App www.openplans.org
The Transit App for iPhone info@thetransitapp.com
Routeshout http://www.routeshout.com/support/transit-contact
HopStop doug@hopstop.com
BingMaps bingmapstransit@microsoft.com
MapQuest http://help.mapquest.com/contact-us
Mapnificent mail@mapnificent.de
Walkscore www.walkscore.com/contact-us.php
Trip Planner Contact List
First visit the Transit Developers
Google Group page
(https://groups.google.com/forum/?
fromgroups=#!forum/transit-
developers) and the Google Transit
Data Feed Google Group page
(https://groups.google.com/forum/?
fromgroups#!forum/googletransitda
tafeed) and join each group,
Second, directly contact the
third party providers listed in
the table above to inform them
that GTFS data is available and
that you would like to be added
to their service.

48
Step 6: Verify that the GTFS data is
publicly available on GTFS Data Exchange
• It is preferable to be added to the site
automatically by developers, as they have
an automated tool that will constantly keep
the data at GTFS Data Exchange in sync with
the most recent GTFS data to your site. If
you manually upload the data instead, then
it must repeat this manual process each
time a new GTFS file is generated.
– www.gtfs-data-exchange.com

49
Data Dissemination

50
Step 7: Create an ‘App Center’
[1] TriMet "TriMet App Center." http://trimet.org/apps/
[2] BART "Third Party Apps." http://www.bart.gov/schedules/appcenter/
[3] MTA "App Center." http://www.mta.info/apps/
[4] CTA "App Center." http://www.transitchicago.com/apps/
[5] GoTriangle. "App Center." http://www.gotriangle.org/developers/transit_apps
[6] HART "App Center." http://www.gohart.org/developers/appcenter.html
[7] MBTA "App Center." http://www.mbta.com/rider_tools/apps/
[8] KCATA "App Center." http://www.kcata.org/maps_schedules/app_center/
[9] UTA"App Center." http://developer.rideuta.com/DeveloperApps.aspx

51
Step 8: Conduct Feedback Surveys
• Gauge satisfaction in the performance of
existing trip planning tools and solicit ideas
for improvement and future capabilities.
• Builds awareness in the ridership
community of the existence of apps

52
Step 9: Establish an Interagency
Trip Planning and Technology Group
• A technology centered group (or subgroup)
would discuss developments in the trip
planning industry and ensure compatibility
should any of the agencies’ IT infrastructure
change.

53
Step 10: Conduct a Public Awareness
Campaign
• Essential to create trip planning product awareness and
adoption
• May be accomplished through existing communications
channels but may benefit from a campaign dedicated to
these tools

54
Sean J. Barbeau, Ph.D. - barbeau@cutr.usf.edu
Justin Begley - begley@cutr.usf.edu
SunRail Electronic Trip Planning Report
• http://bit.ly/SunRail-Trip-Planning

CUTR Webinar - Web-based Trip Planner Options for Transit Agencies

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to CUTR Webinar - Web-based Trip Planner Options for Transit Agencies

Similar to CUTR Webinar - Web-based Trip Planner Options for Transit Agencies (20)

More from Sean Barbeau

More from Sean Barbeau (20)

Recently uploaded

Recently uploaded (20)

CUTR Webinar - Web-based Trip Planner Options for Transit Agencies