problems with prediction data for commuter rail trains

[Brian Card]

Hello,

I'm seeing occasional problems with the prediction data for commuter rail trains, the predictions will be 40+ minutes off based on the schedule.  It's usually a single train that's affected but I've seen it a couple of times and I'm wondering if you can take a look into it.  An example train is the 1404 inbound train for the Fitchburg Line on Saturday 12/03.

At 11:35 this train reached the Ayer stop according to the GPS coordinates.  It was supposed to get there at 11:17 based on the schedule so it was 18 minutes late, but the predictions API reported that it was 60 minutes late at 11:35:46 am.  At 11:49 the train reached South Acton, it was supposed to get there at 11:31 so it was still 18 minutes late, but the predictions API reported it was 81 minutes late.  The prediction increased until 12:18:37 pm where it seemed to reset and reported 17-18 minutes late for the remainder of the stops.  I've seen this on other trains as well, for instance it looked like it was happening to the 66 train on the Kingston line about an hour ago.

Let me know if you need more information, thanks,

Brian

[Developer at MBTA]

Thanks for reporting this to us Brian. Our contractor has investigated this and they think they have identified the root cause, and are working on a fix. 

Sincerely,

developer@mbta

[Eric]

Hi, can you let us know when the fix is deployed? I'm seeing this bug multiple times per day.

[Developer at MBTA]

Hi Eric, will do. We expect the fix to take a couple of weeks. 

Sincerely,

developer@mbta

[Eric]

Hi, just wanted to follow up on this and see if a fix is close to being deployed. I saw the bug again on Haverhill 206 this morning.

[Eric]

Hi,

I'd really appreciate an update on this even if it's just "we're still working on it". I've received a few complaints of passengers missing their train due to this bug and I'd like to know if I should spend the effort on developing a workaround for it.

To show you how bad it's getting, Lowell #343 hit this bug on 1/26, 1/30, 1/31, 2/2, 2/3, and 2/6.

Thanks,
Eric

On Thursday, December 15, 2016 at 9:41:24 PM UTC-5, Brian wrote:

[Developer at MBTA]

Hi Eric,

Apologies for the late reply. We are still working on this issue. We will post a more detailed reply later this week.

Sincerely,

Developer@MBTA

[Developer at MBTA]

This issue occurs when multiple trains (physical trainsets) could be operating the same trip. The prediction software evaluates which one is the most likely to be the real one operating that trip. The problem occurs because of limitations in the way that decision is being re-evaluated over time once the trains have moved making more information available. Our vendor's working on improvements to that, which should address the issue you're seeing. 

Sincerely,

developer@mbta

[Eric]

Awesome, thanks. Do you happen to have an ETA?

[Developer at MBTA]

Eric, 

We've put a fix in place as of today. If you're able to, it would be helpful if you could keep an eye out and let us know if you see it happen again or something like it. 

Sincerely,

developer@mbta 

[Eric]

Thanks! Unfortunately I saw it again this morning on train p507. GPS got stuck in Boston causing the train to report 120+ minutes late by the time it reached Worcester.

[Eric]

I saw it again on Saturday, Fairmont train 1756 and this morning on Franklin 703.

[Eric]

I noticed that Kingston 064 continues to experience this issue almost every day. Once the trip is somewhere between 50% and 100% over the corrects itself.

[Eric]

Here's an email I received which highlights why this bug really needs to be addressed:

I can't even explain what a hassle that created by being told this wasn't going to be on time, having to find another way in via the red line with a broken foot. The. Worst. When in the end, there was nothing wrong with the train and it showed up on time. I can't even handle it.

Eric

[Developer at MBTA]

Thanks for the bug report and information Eric. We're investigating this now.

Sincerely,
developer@mbta

[Eric Hynds]

Hi, any updates on this? I'm seeing it a lot more lately. Five trains are currently experiencing it:

F/W 583
Providence 8803
Newburyport 150
Lowell 300
Middleborough 002

[Developer at MBTA]

Hi Eric,

We are currently investigating this issue. Thanks for your report.

Developer@MBTA

[Eric Hynds]

Hi there, me again :)

This issue has started to rear its head again significantly over the past week. Some reports of bad data I've received just in the past two days:

1. All this week, Worcester 521's GPS gets stuck at Back Bay and corrects itself around West Natick. Interestingly I'm told the onboard announcements say the same thing; while flying through Wellesley the announcements say approaching Back Bay.
2. This morning, Worcester 510's GPS/next stop prediction pinned it at West Natick when the train was actually 2 stops away at Wellesley Square
3. Also this morning, Franklin 702 reported its position at Franklin for at least 15 minutes even though the train had moved on and was on time.
4. Also this morning, Worcester 506 reported being at Ashland even though it had just left Framingham station.
5. Same story with 584 this am, data was 10-12 minutes stale
6. At 9:10am train Lowell 314 reported West Medford stop being 22 minutes away when it was actually 8 minutes away.
   
7. From a rider on the Providence line: "My train is running late, but even though the app says it refreshed data at 8:33, its still claiming that the last reported position at Mansfield at 8:23 was "one minute ago", and that the stop at Sharon is scheduled for 8:29 and "predicted" to arrive at 8:30 (which is already three minutes past and patently false because we were still sitting at Mansfield)."

Please please please take a closer look into this. The issue was was never completely fixed from when I first started this thread back in December of 2016 (!) but the uptick in bad data this week is starting to break down any trust consumers have with the API.

[Developer at MBTA]

Hi Eric,

As always, thanks very much for reporting this to us. We're in the midst of looking into these right now and will keep you posted.

Developer @ MBTA

[Developer at MBTA]

Hi Eric,

Are you still seeing this issue? We've made some changes on our end and have not been able to reproduce this issue.

Sincerely,

Developer@MBTA

[Eric Hynds]

Nope, looks good on my end. Thank you!