2011 OTP Workshop Notes
Andrew Byrd edited this page Dec 17, 2014
·
1 revision
Below are notes from the two-year OTP development workshop held in Portland in July 2011. See agenda for full schedule.
- Hosting models are important for agencies of all sizes, esp. for early stage test/development.
- Data management, particularly important for regional transit systems
- OTP replacement at TriMet
- How to transition from ATIS?
- How does TriMet's migration process differ from transitions at other agencies?
- How will customer service interfaces be handled post-ATIS?
- OTP Service Discovery -- How to share OTP service availability with client/apps that need this data?
- OSM -- RoadMatcher conflation software
-
GTFS data exchange: lists and archives data feeds
-
Can we build comparison tools that allow inter-agency coordination for stop/schedule changes?
-
Role for FTA coordination/aggregation?
-
Specific agency experiences
-
Toronto: encourage operators to export gtfs, challenges stitching data together from separate feeds
-
Humboldt County: multi-agency feed created via Trillium software. Agencies can see but not modify other agency's stops
-
NYC --regional data standard database.
-
Seattle area: Sound Transit, King Co. Metro, etc.
- ST service operated by KCM and vice versa
- How to aggregate service that is expressed in different formats?
- Is there QC on how feeds from different providers integrate?
-
-
User feedback -- how to route to the right person with the agency (customer rep might not be the right person)
-
GTFS data cleaning/validation
- What about "valid" data that's wrong (e.g. taking a train from the stoarage yard)?
- Can we build tools that help solve issues at a conceptual level?
-
Shortest path tree: generate a path from one point to everywhere
-
Isochrone maps – shortest path from all points to all points (e.g. walkscore, transit score) – indicates a place's general levels of accessibility.
-
Time geography maps, space-time prism - demarcates the spatial extent of places that can be accessed within a given time-frame
-
Agency data -- how to leverage for analysis?
- Ridership, e.g. TriMet has boardings/exits at every stop
- Onboard rider surveys
-
Volpe center is interested in mega-regions for planning, particularly in intercity services.
-
Cost reduction/optimization: reducing/changing stops to improve timing.
-
Help communicate to public consequences / impacts of changes to network (e.g. service reductions / additions)
-
Use Census, address point data to analyze population distributions
-
Consider trip planner query data as an expression of demand; validate against automatic passenger counters or other existing data sources
-
Utah bubble maps developed using fare collection, APC: possible to combine with query/trip planner sources?
-
Privacy issues: search logging /how to ensure anonymity?
- Multiple-destination routing
- Real-time service visibility (active/historical information), similar to flight tracking services (e.g. Flight Aware)
- Measure carbon footprint
- Parking information (ITS / smart parking information, particularly relevant to park and ride users)
- Evaluation demos for agencies
- Allow agencies to provide GTFS data and see opt implementation for short test period
- Potential for multi-agency data loading * OTP evaluation opportunities - A – multi-agency implementation important OS
- OSM Page with info, docs, etc.
- Geocoding options
- Success stories at various agency scales.
- Integration of van-pool, ride-share into trip-planner
- Long-term: integrated, inter-regional planning
- Service discovery to expose data for multi-jurisdiction planning
- SFMTA is an example, but many metro regions don't have
- Federated search: bounding box, multi-jurisdiction
- Gap analysis for multi-provider trips
- National-level: who maintains service discovery meta-data,
- Better integration of system map with OTP interface
- Executive summary of benefits and requirements. Include benefits/flexibility of cloud computing, potential for new customers.
- Hosted service to minimize what agencies need to change in terms of server space, lower cost of initial testing, particularly for smaller agencies
- Incorporate real-time information in trip planning results, compare to maintenance of legacy real-time systems
- Messaging on API for private development, common to all instances of OTP
- Within hosted solution, how much control does agency have over data? Release management, quality control, improving communication between developers and agencies
- System for testing GTFS, ensuring changes produce valid results. Better to edit GTFS on hosted service? Ensure on-the-fly transfers work. How does the data feed factor in? Automating scripts to streamline QC and agency personnel can quickly identify errors in street data/transit data/software.
- Managing updates from OSM, ensuring quality of street network, mollifying agency concerns regarding crowd-sourced data.
- Changelog to show where the changes in GTFS/OSM data. Tool to allow rapid inspection of changes in data.
- How to cope with disruptions in routes/schedules? How can that workflow be streamlined with OTP from dispatch to operations and trip planning?
- Provide agency tools to have control and consistency in messaging to public across all trip planning access points (including external apps) when service disruptions happen. Aggregating many small disruptions into one public message. Which areas are on-time? Which areas have long wait times?
- Ability for a regional service to choose among contributing localized GTFS feeds when informing public of disruptions/trip options. Supplying appropriate links to other agencies/connecting services.
- Non-trip planning uses of OTP (removing ATIS dependencies). Ex: school field trips. Enable OTP to track ‘reservations’ of buses for large parties to avoid over-crowding
- Real-time rerouting (e.g. adverse weather / emergencies)
- How to include re-route path plan vs actual based on vehicle tracking? How to notify customers which routes are affected and where to go in emergency situations? Do these re-routes get expressed in trip planning option or as note? Dynamic messaging to improve customer experience. Coping with policy vs. practice. Real time info most needed in bad weather, particularly for mobile.
- Ability to attach notes to routes to reflect service disruptions, reservations, etc to administrators can manage these parameters
- Use SIRI/real-time inference on re-routes
- Use inference algorithm to help manage re-route analysis
- Allow private shuttles to access relevant portions of GTFS data in shuttle trip planning. Or allow only private shuttle users to see integration of private shuttle within agency’s GTFS?
- Bicycle rack and wheelchair space availability in real time. How to ensure correct information? How to communicate that information to riders? Notes?
- Directing ADA to correct station access pathway (locations of ramps and elevators).
- Tracking capacity in real time.
- Agencies that have buses without bike racks need to indicate non-bike routes within GTFS
- Call center / CRM integration issues
- Paratransit / demand response
- Fixed service: info about the customer, call routing, information about service provided, performance reporting
- IVR provides service info for scheduled and real-time
- Customer complaints
- Determination of driver responsibilities
- System health communication (e.g., poor service today on ___)
- More detailed information available to customer service mode
- Preferred transfers editor (currently provided by ATIS but data can't be pulled from HASTUS)
- Data workflow for changes (permissions for editing, visibility and propagation)
- Bike preferences triangle
- Real-time alerts - GRTFS integration
- Ability to print route maps
- Email, social media sharing
- Fare calculations
- API stability/versioning
- (x,y), top-left bounding box
- HTML 5 mobile interface
- Text-based, text messaging interface.
- how to manage geo-coding?
- Map-based feedback form in trip planner
- Building a ui/admin around feedback?
- University engagement, mind-share with younger developers that might be help move platforms forward
- Better support for internationalization efforts
- Give people credit / make sure community is reflected in the site
- Streamlined web presence -- Merging existing .com/.org sites
- How to message procurement opportunities? -- Moodle as an example
- Clarify differences between capital purchase and operational costs / services
- Can qualify as capital expenditure because the software has a physical deliverable
- Capitalize initial procurement, software development, & data collection; operating / services for future support
- Focus on getting new folks up and running
- Continue effort for quick responses (< 24 hrs) on lists
- Move internal discussions away from personal email to the mailing lists / wiki
- Ticketing system, mailing list and IRC -- need for better integration / cross-visibility
- Road mapping -- how to summarize?
- Clarify use of branches
- Ticketing system -- review status of tickets, clean-up outdated ones
- Used wiki to document explorations, works in progress
- RSS feed for website tools (could we provide rss feeds for particular wiki pages?)
- Crediting contributors (svn status, looking at commit logs, etc.)
- Stakeholder communication: prioritization, advocacy, etc.
- Developer sync-up
- How to get everyone who cares together at the same time to make that a real conversation
- IRC vs phone: alternate week to week? Email poll about venue and times?
- Better communication about internationalization opportunities
- Clarify coding standards / stylistic considerations
- Better articulation of point release process
- QA - think about process / staffing / time requirements
- Pre-release testing -- make better use of data from agencies and agency expertise
- Collaborative test development (agency test harnesses can be shared with the entire community)
- Website redesign / merge .org & .com (David E)
- Git migration (David T)
- Resume weekly developer sync-up (David E)
unless you are intentionally working with legacy versions of OpenTripPlanner. Please consult the current documentation at readthedocs