New performance data available in MBTA's API!

[Developer at MBTA]

The MBTA is excited to announce a significant set of additional API calls in the MBTA-realtime API that, for the first time ever, give developers and data scientists access to MBTA performance data. 

The API calls, part of a project called MBTA-performance, provide a quantitative measure of how MBTA service is performing, which will augment and complement the existing service alerts, vehicle locations, and arrival predictions. Performance metrics characterize what percent of customers are experience good waiting and travel times, and can specify either performance for the past hour or for the entire day up to the current time. In addition to this real-time performance information, additional API calls will allow developers to access historic performance data, including performance metrics for past days, or headways, dwell times, and travel times for a specified period in the past. This initial release of MBTA performance is only available for the subway services (including the Green Line!), but will be expanded to commuter rail and bus in the future. Much of this data is commonly requested by students, researchers, and developers, and we’re happy to finally be able to provide it publicly through an open data portal. This is the same data that underlies the subway reliability numbers on the MBTA’s new performance dashboard www.mbtabackontrack.com. We’re eager to see how our excellent developer community can put this data to good use!

 

Documentation (pdf link) for these new API calls is available at realtime.mbta.com. Also watch this space for more information on a developer's event on 3/5, hosted by Code for Boston, to learn more about this data and other data. 

Sincerely,

developer@mbta

[Matthew Danish]

Hi,

This looks very interesting. I will have to spend some more time with it later. I'm glad to see that you are moving towards people-weighted metrics. The Green Line at 69% today -- not surprised. A question: it seems that you've gone with an average of (Red+Orange+Green+Blue)/4 for overall "Subway Reliability". That seems to defeat the goal of people-oriented metrics. Shouldn't it simply be weighted by passengers as well?

Another: how are you measuring dwell times? I thought sampling was too coarse-grained to achieve this?

I'm reading about the metric you've concocted for the task of measuring subway reliability, "Wait Time Reliability." Sounds like an improvement over the old method. But I am getting an uneasy feeling about the discontinuity implicit in the metric. On the given "5 minute headway" service, a person who waits 5 minutes and 1 second is categorized as having an "excess wait" while another person who only waits 4 minutes and 59 seconds is categorized as as experiencing a "normal wait."

Was there a reason for not going with a continuous function, such as passenger-weighted average?

Matthew

--
You received this message because you are subscribed to the Google Groups "MBTA Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to massdotdevelop...@googlegroups.com.
To post to this group, send email to massdotd...@googlegroups.com.
Visit this group at https://groups.google.com/group/massdotdevelopers.
For more options, visit https://groups.google.com/d/optout.

[Developer at MBTA]

Hi Matthew,

Glad you're interested in this new data. The average is actually a passenger-weighted average reliability that is taking the total number of passengers with on-time waits and dividing by the total number of passengers. Keep in mind that this methodology, which is described in more detail on the data blog post about this metric, is actually using a rate of passengers per second and multiplying by the headway, so you cannot recreate these numbers by simply multiplying average monthly ridership by the reliability percentage per line. The absolute number of passengers is unimportant, what matters is the relative number of passengers on one segment or line compared to the others. If you want more details on the calculation, the metrics come directly from this MIT thesis. This also gets to the answer to your third question about a continuous function for counting passengers as delayed. The number of delayed passengers is actually the arrival rate per second multiplied by the number of seconds beyond the scheduled headway. So in your example, for a 301-second headway, only 1 seconds' worth of passengers are counted as late, which has little impact on overall performance. A 60 second delay, on the other hand, impacts 60 times as many people and thus factors more prominently into the numbers. 

As far as measuring dwell times, we get both arrival and departure records as trains enter and leave stops, so we use those to measure dwell times. For Red, Orange, Blue lines and the Green Line in the subway, there isn't really a polling cycle, the event is triggered as the train rolls over the track. For the Green Line on the surface, the GPS polling cycle is every 6 seconds, which isn't perfect but it will have to do for the moment. At worst, it means we could overestimate dwell times by 12 seconds, which is quite significant given that most dwells are under 30 seconds. 

If you have further questions, let us know. We'll be answering more things like this at our co-sponsored event with Code for Boston next Tuesday at the Cambridge Innovation Center.

Sincerely,

developer@mbta

To unsubscribe from this group and stop receiving emails from it, send an email to massdotdevelopers+unsubscribe@googlegroups.com.
To post to this group, send email to massdotdevelopers@googlegroups.com.

[Eric]

Hi, is there an ETA for when this API will be expanded to the commuter rail?

To unsubscribe from this group and stop receiving emails from it, send an email to massdotdevelop...@googlegroups.com.
To post to this group, send email to massdotd...@googlegroups.com.

[Developer at MBTA]

Hi Eric, we're working on it but don't have an ETA we can share yet. 

Sincerely,

developer@mbta

[Aaron Antrim]

Hi all,

Are there examples of 3rd party applications or analysis projects that use the MBTA-performance API?

-- 
Aaron Antrim
President & Founder, Trillium
503.567.8422 ext. 3