Hackpads are smart collaborative documents. .

640 days ago
Unfiled. Edited 640 days ago
709 days ago
Unfiled. Edited by Carol Schweiger 709 days ago
Carol S Moved these notes to the hackpad attached to the actual session in the schedule
 
Questions: What is the quality of service provided, and What is the quality of service experienced?
 
709 days ago
Unfiled. Edited by Carol Schweiger 709 days ago
A: A couple months; stay tuned regarding the data. 
 
Carol S Added my notes from another hackpad:
 
Questions: What is the quality of service provided, and What is the quality of service experienced?
 
Photo of Daily Performance report for the Red Line -  oriented toward the dispatchers.  Will break it into components/metrics
 
Measure 2 things: (1) Passenger Waits and (2) Passenger Travel Time
Passenger Waits=What percent of pax wait less than the headway of the trains?  Gets measured at every station.
  • x% < Headway (Goal: 90%)
  • y% < Big Gap (Goal: 98%)
  • z% <2X Headway (Goal: 100%)
Passenger Travel Time=How long did it take me to travel (using avg values) from point A to point B?
  • x% delayed < 3 min. (Goal: TBD)
  • y% delayed < 6 min. (Goal: TBD)
 
Wait time explanation - headway performance (measured at Park Street) - helps to visualize issues - shows avg headway vs. difference from published headway
 
Running Time Performance by Segment Graph: breaking the line into major segments and graphing running times and highlighting problems in red. 
 
So what? Management and Customers need to know
 
Ritesh Warade: In real-time?  How do you measure performance in real-time?
 
Flowchart:   Bus, Subway/LRT and Commuter Rail creates normalized feeds to MBTA-realtime.  MBTA-realtime produces GTFS-realtime and goes to MBTA-performance and produces an API
 
Another Flowchart: GTFS-RT creates arrival/departure times, travel times, headways and dwell times.  These calculate performance metrics: schedule adherence, pax wait times and pax travel times with input from archive data and pax arrival rates, and GTFS.  All of this produces through the API info to MBTA mgmt and MBTA customers
 
Sample output shows real-time performance as well as last five days; headways at Park St. Station towards Harvard Station; and Travel Time from Park St. Station to Harvard Station.
 
Thought about predictions of what performance will be in 20 or 30 minutes - that is a little harder to do, but it is a goal
 
Question: have you looked at connections?  Going from Kendall to Kenmore - how much time do I spend at Park Street?  Or maybe an express bus to the suburbs - even a 3-minute delay on a train might make me miss a bus.  London does this - you tap on and tap off, so they know the journey time for every journey.  The T would like to know an entire journey time for an individual.  Could also measure how many connections were missed.
 
Question: How to deal with bus bunching?  Transit Master allows dispatchers to see where all the buses are, but each dispatcher is managing 250 buses.  Need to get the info into the field to someone who is managing a lot less buses.  
 
The MBTA has 1,000 buses operating at rush-hour with 4 dispatchers
 
Question: platform with back-end for managers in the field and then on the front side for public accountability.  Will this replace the scorecard?  Will they be able to drill down into the details? It is going to augment or replace parts of the scorecard.
 
Question: What is the conversation with dispatchers to improve their role in this chain?  Dispatchers handle too much right now.  Currently, the hierarchy of decisionmaking is not well-defined.
 
Question: When bunching, would you be able to let the driver know that there is bunching?  You would have to add yet more hardware on all 1,000 buses.
 
Question: How close are we to autonomously-run trains?  The T has discussed this.  London has retrofitted a few lines for full automation.  Because of safety, there is no room for error.  If we had the funding, several lines could be automated.  in the meantime, we need to have humans mimicking computers.  Is the cost of automating trains increasing, and should we invest earlier?  It is an expensive policy discussion.
 
Question: The way that bunching handled - have a hyper-screen that displays the whole system.  Each on-the-ground staff person has a tablet in their quadrant to show if they need to deadhead someone back to the terminal.
 
Question: Is there a difference between schedule capacity and design capacity?  Yes.  The limitation of rail is the signal system.  What is the capacity you are actually running - the T is more interested in this.  During every rush hour, how close are we to design capacity?  Is that a management element for discussion?  At rush hour, most Green Line trains are at capacity.
 
Question: Handling scheduled events.  For example, Red Sox game, Green Line is over capacity.  Look at impact of special events - studied at Harvard.  Peak hour starts 3 hrs before the game - 200 people every 15 minute before the game.  Carrying an additional 12,000 people on the system before the game.  Don't know if the T has ever calculated the numbers.
 
Ari O Good comment: we can analyze where the problems exist, but then have to work with communities to change streets where they exist.
 
Carol S Dominick Tribone (dtribone@mbta.com) and Ritesh Warade (ritesh.warade@ibigroup.com)
 
711 days ago
Unfiled. Edited by Alice Brown 711 days ago
Resilience: need greater recognition that walking is most resilient option. Facilities and operations should support this. Private transport providers can fill gaps when public options are struggling, have complementary roles. Climate change, emissions, materials- can there be system for rating using metrics.
 
  • Economy
 
711 days ago
Unfiled. Edited by Sheldon A. Brown 711 days ago
Presenters: Sheldon A. Brown  and Alex Bromley
 
  • Open Source 
  • Deployed officially in several places across US
  • Deployed experimentally in many more:
  • (others...)
 
Patrick G How it works
  • Load GTFS and other data into memory and provide access via an internal API
  • internal API wrapped with public API
  • Interfaces(SMS, Mobile etc) use a combination of internal/public APIs
 
Looking for People to help
  • How to make it better?
 
Sheldon B Interfaces
OneBusAway includes a robust, secure, scalable back end that accepts, stores, archives and interprets real-time vehicle location data in combination with transit schedules and other related data.
 
OneBusAway supports many interfaces:
  • 2 desktop web applications
  • 1 mobile web application
  • several native mobile applications
  • 2 SMS interfaces (TextMarks and MobileCommons)
  • 2 IVR interfaces (hardware vs Twilio)
 
OneBusAway offers a suite of application programming interfaces (APIs) that facilitate the support the development of a wide range of third party applications, based on actual vehicle locations and on scheduled and predicted arrival times.
 
 
Sheldon B Native (Mobile) Applications
Look for OneBusaway in the iPhone, Android, or Windows app stores!
 
Also, recently the MTA contributed an app that uses PhoneGap, it can be found in the Android app store as "OneBusaway - Boston".  
 
 
Patrick G OneBusAway Watchdog
The Watchdog is a generic monitoring and statistics web application that allows you to compare your static GTFS to your GTFS-realitime feed for:
  • Bus locations within agency region
Sheldon B
  • Latency of updates
  • Total Trip Ids, matched Trip Ids, invalid Trip Ids
  • Total Stop Ids, matched Stop Ids, invalid Stop Ids
  • Performance metrics such as buses in service
  • Using monitoring packages such as Icinga/Nagios you can alarm on metrics should they fall below certain threshold/number.
 
More info on the Watchdog wiki.
 
Hardware
Currently OneBusAway expects Automated Vehicle Location (AVL) software to already be in place.  There is no open source on-board bus hardware available, but it should be relatively easy to create.  Just follow this specification .  The BusTime installation performs its own AVL based on this specification.
 
 
713 days ago
Unfiled. Edited by Zachary Agush 713 days ago
"Real" BRT (Bus Rapid Transit) in Boston: Challenges to Building Grassroots Support
 
713 days ago
Unfiled. Edited by Thomas Craig 713 days ago
Thomas C How did CS frame it, get developers here in particular: 
  • outreach to developers
  • knowledge that there needs to be balance (planners, advocates, etc.)
 
How did we hear about transportationCamp initially
  • YPT/YIPS
  • Other developers
  • GreaterGreater Washington
 
Cyber TranspoCamp?
  • face-to-face is important
 
How to you get tech-people to talk to other groups?
  • Personal invites to a few great public speakers
  • Local agencies starting to come more (2012 very little participation), more recently WMATA, NYCT, MBTA are showing up more
 
Price point is necessary
  • needs to be low, but needs to be not free
 
Are we reaching out to the right communities?
Outreach to get more diversity
  • COMTO
  • WTS
  • Girl Develop It
 
Core elements of TranspoCamp/Unconference
  • Collaborative/interactive
  • Some focus on Networking
  • there's magic in the person that designs the board
 
Ideas for TranspoCamp NYC
  • orange umbrellas
  • keep the long 15 minute periods inbetween sessions
 
Alternate schedules?
  • luke warm on giving more time
  • if more time were offered for some spots, some filtering in advance could be necessary
 
 
Members (76)
Marc Ebuña arthurstrang Dominick Tribone Anna Stokes paul.schimek@gmail.com Sheldon A. Brown Alice Brown John Mickey Anson Jeremy Mendelson Brian Laverty Brad Johnson jonathan megan krusi Patton Mia Ellis Christine Breen Daniel Andrlik Gabriel E. Sánchez-Martínez Harsha Ravichandran

Create a New Collection

Cancel

Move XXX to XXX


XXX will be invited to the XXX on XXX.

Cancel

Contact Support



Please check out our How-to Guide and FAQ first to see if your question is already answered! :)

If you have a feature request, please add it to this pad. Thanks!


Log in / Sign up