Skip to content

problems with current trip planners

Andrew Byrd edited this page Dec 17, 2014 · 1 revision

Problems with current trip planners

The following issues were produced by workshop participants on July 15, 2009. Transcribed here, then grouped after-the-fact.

Feedback:

  • Customer feedback to improve routes

  • "Trip not planned" as planning tool

  • Data: Feedback from customers helps fix the data, a la Open Street Map

  • Routing algorithm that "learns" based on user feedback

  • Collect data from trip planner usage

Data:

  • Agency format of data & cooperation -- all mix of data structures into a commmon DB (and definitions of fields)

  • Barriers, roadway, topography

  • Bike-to-transit: Location of bike locking facilities? Presence of bike capacity on vehicle? Difference in available capacity peak vs. off-peak?

  • Referral to other transpo services in case of transit service unavailability. If outside service hours / outside service boundary: refer to taxis, or refer to complementary ADA / paratransit

  • Integration with real-time data: detours, delays, service changes

  • ADA data collection and levels of ADA - Visually impaired vs. wheelchair at a stop that may service a bus w/ curbcuts vs. subway or lr platform w/ oeh (?)

  • Interagency / cross-agency trip planning (+3)

  • Integration with more transportation providers, both public and private

  • Need for standardized data formats across systems (+1)

  • Incorporate near time info to trip planner

Routing:

  • Support for driving / zipcar (+1)

  • Bike option

  • Ride share as a mode

  • Multi-stop routing (+1)

  • Draggable routing

  • Drive-to-transit / bike-to-transit: Allow "last-mile" up to 25 miles or so --> useful for intercity services (Amtrak, etc.)

  • Drive-to-transit: Will there be parking capacity there? Traffic?

  • Elevation. Search for a plan that has zero grade changes between transfers.

  • Deviated fixed routes. Define flexible service zones and allow end-user to find this.

  • Bad geocoding

Design & user experience:

  • Easy user interface for first-time transit user

  • Control of walking speed, distance, topography

  • Integrated map, satellite & street-view w/ transit planning

  • Ability to compare trip options such as: bus only; car w/par & bus; bike & bus

  • Needs good printing

  • Hard to compare routing options

Platform:

  • Open system that allows easy addition of new applications & features

  • Scalable complexity

Administration:

  • Quicker application of data improvement

  • Improved process for introducing changes to data

  • Technology updated with in-house program

Mobile:

  • Interactive system map -- sort of a "you are here" with dynamic GIS data for different modes

  • Missing: (for mobile device trip planners): Ability to adjust / re-plan trip when you miss a bus or a vehicle is late (kind of like how a car GPS re-routes when you take a different turn)

  • Needs mobile version

Other:

  • "What-ifs" - transit planning support

  • Usage logging / friends

The documentation on this wiki is outdated and should not be used

unless you are intentionally working with legacy versions of OpenTripPlanner. Please consult the current documentation at readthedocs

Clone this wiki locally