USING OPEN DATA TO DEVELOP MULTIMODAL
TRIP PLANNERS FOR LIVABLE COMMUNITIES
Sean J. Barbeau
Edward L. Hillsman
Center for Urban Transportation Research @
University of South Florida
GIS in Transit Conference
St. Petersburg, Florida
September 14, 2011
Funded by the Florida Department of Transportation and the National Center for Transit Research
PURPOSE
• Advise on two
emerging technologies
– Multimodal trip
planning
– Crowd-sourced
data/applications
• Explain state-of-the-art
and relationship to GIS
WHY MULTIMODAL TRIP PLANNERS?
• If you want to drive, the question is “How do I
get there?”
– Road networks are dense, connected, complete
– Google, Mapquest, Yahoo can easily tell you
• For bike/walk/bus, the question is “Can I get
there (by a safe route)?”
– Networks are sparse, incomplete, or both
– Route-specific info is more important than when
driving
TRIP PLANNING SOFTWARE TYPES
• Multimodal
• Unimodal
– Similar to what Google
Maps/Transit/Bikes, Yahoo
Maps, Mapquest offer
– One mode per trip:
only
only
only
only
– Options to mix modes for a
trip
– Examples
• Bike to bus, ride bus, bike or
walk to final destination
• Drive/bike to park-and-ride,
take bus
• Wheelchair-accessible routes
• Various access to/from bikesharing, car-sharing
+
+
+
+
PROPRIETARY TRIP-PLANNING SOFTWARE
• Custom-built software and data are expensive
– Goroo® in Chicago cost more than $1 million and
is still being improved
• Web-based software is proprietary and closed
– Google, Yahoo, etc. are free to use, but
• Services depend on the needs and desires of the
providers
• Providers limit use and presentation of their systems
(frequency, branding)
OPENTRIPPLANNER
• Free, open-source software - opentripplanner.org
• Development spearheaded by Tri-Met in Portland,
with grant funding (2009-present)
• Active worldwide developers’ group
• Available for anyone to download, install, modify
– (and, with approval, contribute back)
• Non-profit OpenPlans can provide installation,
customization, maintenance support
• OpenPlans will be giving Keynote on OTP status
and roadmap on Thurs. morning at 8:30am
OPENTRIPPLANNER – TRUE MULTIMODAL
• USF’s OTP Demo for Tampa, Fl - http://opentripplanner.usf.edu
– Example: Bike->Bus->Bike
OPENTRIPPLANNER – INTERLINING BETWEEN TRANSIT SYSTEMS
HART
USF
Bull
Runner
WHY DON’T WE JUST USE GOOGLE MAPS?
© 2011 Google – Map data © 2011 Google
Google Maps
•
•
Data CC-By-SA OpenStreetMap
OpenTripPlanner
In USF community, Google Maps can’t find USF building names or abbreviations
Google Maps gives walking directions on Alumni Dr. (where there were no sidewalks)
and using a cross-street (instead of the nearby crosswalk)
OTP WHEELCHAIR ACCESSIBLE ROUTING OPTIONS
Regular route with stairs
OTP WHEELCHAIR ACCESSIBLE ROUTING OPTIONS
Wheelchair-accessible route
GIS DATA
• To provide this kind of service, you need data
– Transit routes and schedules
– Street network
• (plus addresses, points of interest for geocoding)
– Bicycling facilities
• (lanes, routes, parking)
– Sidewalks, crosswalks, and other pedestrian
infrastructure
– Future: Park-and-ride lots, car-sharing, and/or
bike-sharing stations
12
OPEN DATA SOURCES FOR OPENTRIPPLANNER
General Transit Feed Specification (GTFS)
– Over 140 agencies in US have transit data in this format,
more than 447 world-wide
– Most agencies did this to get on Google Transit
– But, GTFS is open-data format that anyone can use
• Used by many mobile apps
• OpenTripPlanner
• Becoming a de facto standard
– See “GTFS Data Exchange” for list of agencies with GTFS
data
• http://www.gtfs-data-exchange.com/
• Or, ask your local agency
– Major transit scheduling software packages can prepare
GTFS
OPEN DATA SOURCES FOR OPENTRIPPLANNER
OpenStreetMap.org
– Think “Wikipedia for
geographic data”
– People contribute data
under a Creative
Commons AttributionShareAlike 2.0 license
– Edit online, using
custom GPS traces, or
programmatically
– Anyone can download
and use the data (not
just the maps)
OPEN DATA SOURCES FOR OPENTRIPPLANNER
National Elevation Dataset (NED)
– Provides elevation data for biking/walking in OTP
– Currently used to produce elevation graph, and for
some biking routing decisions
OPEN DATA SOURCES FOR OPENTRIPPLANNER
Geographic Information
Systems (GIS) files
– OpenTripPlanner can also
support loading GIS (e.g.,
.shp) files
– Local government sources:
• City
• County
• Special Districts (parks, etc.)
• Ask your local government
what data might be available
– Especially if there isn’t much
OpenStreetMap activity in
your area
Multimodal trip planning is a new field, and there are still . . .
OPEN ISSUES
17
PEDESTRIAN SIGNALS & CROSSINGS
• “Implicit” vs. “Explicit” data coding of
pedestrian infrastructure in OpenStreetMap
• Implicit – less work when sidewalks are always
present and follow roads (e.g., downtown):
Street
Sidewalk is attribute of street
(highway=footway)
• Explicit – less work when sidewalks are sparse,
or don’t follow roads:
Street
Sidewalk
18
Legend
Footway (i.e., Sidewalk)
Curb Cut coding (e.g., Sloped Curb, Tactile Paving)
Crosswalk
Pedestrian Crossing Coding (e.g., Type of Marking,
Accessibility, Pedestrian Signal)
Highway
Vehicle Traffic Signal Coding
Street A
Crossing 2
Stairs
Footway
Node 1(Pedestrian Crossing Coding)
Street B
Crossing 1
Node 3
Node 2
(Vehicle Traffic Signal Coding)
(Curb Cut Coding)
Explicit example
19
Explicit coding example
Legend
Footway (i.e., Sidewalk)
Stairs
Crosswalk
Curb Cut coding (e.g., Sloped Curb, Tactile Paving)
Pedestrian Crossing Coding (e.g., Type of Marking,
Accessibility, Pedestrian Signal)
Highway
Footway
Vehicle Traffic Signal Coding
Street A
NodeCrossing
1(Pedestrian
2 Crossing Coding)
Crossing 1
Stairs
Footway
Node 1(Pedestrian Crossing Coding)
Street B
Node 2
(Curb Cut Coding)
Crossing 1
Node 3
Node 2
(Vehicle Traffic Signal Coding)
(Curb Cut Coding)
20
Explicit coding example
Stairs
"highway=crossing”
+
"crossing=pedestrian signals“
"marking=zebra”
"wheelchair=yes”
Footway
Node 1(Pedestrian Crossing Coding)
Crossing 1
"highway=footway”
"footway=crossing”
Node 2
(Curb Cut Coding)
21
PEDESTRIAN SIGNALS & CROSSINGS
Stairs
"highway=crossing”
+
"crossing=pedestrian signals”
"marking=zebra”
"wheelchair=yes"
Footway
Node 1(Pedestrian Crossing Coding)
FOR OTP ROUTING:
Crossing 1
"highway=footway” (normal sidewalk tag)
"footway=crossing" (new tag)
Node 2
(Curb Cut Coding)
22
PEDESTRIAN SIGNALS & CROSSINGS
Street A
Sidewalk is attribute
of street here
Street B
...but separate feature here
• How to support implicit coding routing, and
locations where explicit/implicit codings merge?
23
OPEN ISSUES – CROWD-SOURCING LEVEL OF SERVICE
• Having traffic characteristics for roads would
help in pedestrian/biking routing decisions
• However, traditional road traffic metrics (i.e.,
traffic volume, width of lanes) are
difficult/dangerous to crowd-source
• Need better objective metrics to define bike
and walk "level-of-service" (i.e., how "good" an
OSM way is for walking or biking) that can
easily be recorded by a casual observer
24
OPEN ISSUES – PERSONALIZING BIKING DIRECTIONS
• Level-of-service metrics must translate to
subjective judgments for whether a cyclist would
be comfortable riding on a specific road
• Different for every cyclist:
– Some expert cyclists would be comfortable riding on
high traffic roads where other beginner cyclists would
not
– Also depends on presence of bike lanes, shoulder, etc.
• What does an “ideal” user interface look like to
meet everyone’s needs, but not be overwhelming?
• Should we customize based on some selfassessment of skill/comfort level?
25
OPEN ISSUES – SPARSENESS OF OSM DATA
• Many areas of U.S. are still sparsely populated
in OSM
• We believe OTP is a “game-changer” – now
OSM contributors can see direct benefits of
their work in OTP routing
• What are the motivations/profiles of current
U.S. contributors?
• How can we leverage this knowledge, and
visibility of benefits in OTP, to motivate a larger
crowd of OSM contributors?
26
GO-Sync
A Software Tool to Synchronize Transit Agency
GTFS Datasets with OpenStreetMap
Coded by Khoa Tran
GO-SYNC MOTIVATION
• Shortcomings of official transit GTFS datasets
– Inaccurate bus stop locations
• Lack of transit data in OSM for many U.S. cities
• Goal – create a tool that can:
– Share transit agency data with OpenStreetMap
community
– Leverage social mapping model to improve bus
stop inventory, and allow agency to retrieve these
improvements
CHALLENGES
• Need to respect work by other OSM users
– Avoid overwriting existing OSM data
• Lack of a strict tagging system in OSM
– Ex: “route”, “routes”, “route_id”  “route_ref”
• Need to avoid duplicating OSM data
• Ongoing updates to GTFS data
• Integration of crowd-sourced data into transit
agency internal datasets
GO-SYNC
• General Transit Feed Specification (GTFS) –
OpenStreetMap (OSM) Synchronization
– http://code.google.com/p/gtfs-osm-sync/
– Open-source, under Apache 2.0
• GO-Sync is an open-source tool that can
synchronize GTFS datasets with OSM
– Performs “Point-conflation”, or merging, for bus
stops in OSM
1) Input GTFS data and Agency Info
GO-Sync analysis, allowing user changes before upload
33
34
EVALUATION IN TAMPA
• On July 2010, 3,812 new HART stops uploaded
(133 stops previously existed)
• By January 2011, 173 modifications were made
Example:
moved
EVALUATION IN TAMPA
Bus Stop Location Movement Distribution
60
Number of
stops moved
50
40
30
20
10
0
0-5m
5-10m
10-15m
15-30m
30-70m
70-120m
Distance of Moved Stop from Original Location
120-400m
GO-SYNC SUMMARY
• GO-Sync can help you leverage crowd-sourced
edits for your bus stop inventory
• Available to download from Google Code
– http://code.google.com/p/gtfs-osm-sync/
• Caveats:
– Must have the GTFS owner’s permission before
upload!!!
– It’s a prototype – read the instructions carefully!!
– May not be appropriate for all transit agencies
– Knowledge of OSM is highly suggested
– Respect others work!
• We would welcome improvements by other
contributors!
37
What should I take away from today’s presentation?
CONCLUSIONS
38
TAKEAWAYS
• Open-source multimodal trip planners are a reality
• Get your GIS data together for your community
– GTFS
– OpenStreetMap
– Local GIS
• Think about multimodal data connections
– Bike/walk is part of trip, not whole trip
– Park-and-Ride lots, carsharing, bikesharing
– Intersection data
• How might you benefit from crowd-sourced data?
• Benefits of open software/data
– No vendor lock-in
– Community add-ons (USF students created OTP Android app,
USF BullRunner GTFS data)
CONTACT INFORMATION
• Project Website:
– http://www.locationaware.usf.edu/ongoingresearch/projects/open-transit-data/
• OpenTripPlanner Tampa Demo:
– Opentripplanner.usf.edu
Sean Barbeau, M.S.
(OpenTripPlanner/Android)
barbeau@cutr.usf.edu
(813) 974-7208
Ed Hillsman, Ph.D.
(OpenStreetMap)
hillsman@cutr.usf.edu
(813) 974-2977
40