Re: real time commuter rail predictions observed after upgrade

[Developer at MBTA]

Hi Charlie. Thanks for your questions, let's take them one at a time. 

1. We can't turn our focus to it immediately but we'll take some steps internally to evaluate what it will take to revert to a one-minute increment and maintain a level of "steadiness" in the predictions that's satisfactory. 

2. It is not a rule to stop predicting for a train that is very late, but if a train is very late and has not moved for a fixed period of time, an algorithm working by itself cannot predict when the train will start moving again with any confidence and can stop publishing predictions for that reason. That's where alerts come in, and particularly the integration of alerts and predictions which is an area of interest for us. Regardless looking at this morning's data that's what happened; when the train was moving again the lateness value was filled in again (showing 35 minutes). 

3. The data source for the displays at stations and the online predictions are the same, so overall they are equally accurate. However since they form different functions there are different steps taken to optimize them for those functions, so in different circumstances one or the other might be slightly more accurate. 

Sincerely,

Developer at MBTA

On Thursday, May 23, 2013 11:57:22 AM UTC-4, charlie wrote:

This morning's commute the Fitchburg Action 404 train broke down just beyond its starting point - Fitchburg. (It leaves Fitchburg at 5:15 AM and I pick it up at Littleton/495 at 5:43 AM normally.  )

I noticed some things from the real-time commuter rail predictions I'd like to share.

5:35 AM: real time feed said "5 minutes" late. (this seemed fine given the location reported and time)
5:36 AM: real time feed said "10 minutes late". (also seemed fine given the location reported and time, but I expected this to increase by 1-2 minutes)
5:50 AM: I arrived at station to see "24 minutes late" on the red (physical) sign at the station stop. Real time predictions had stopped completely. An alert went off about this time saying train was about 30 minutes late.

Someone on the group had recently commented about the "either 5 minutes late or on time" rule which recently changed in the April feed updates. I don't like this change. I liked being able to show "1 minute late" or "2 minutes late" - and it was generally accurate. However, I had expected this "5 minute rule" change because we were warned it may happen in developer meetings.

What I didn't expect was increments in 5 minute units beyond 5 minutes. It appears to me as if 4 minutes late will report as "On time", while 6 minutes late reports as "10 minutes late". This behavior pretty much ruins the intent of my app.

I'm also seeing this: It seems beyond 10-15 minutes late any reporting just shuts off. To me this appears to be "hiding" information out of "embarrassment". I could be completely wrong here, so I was wondering if developer@massdot can comment on these observances. It's possible that what I observed was not the norm, missed an update, or that my app is misleading me somehow.

Specifically:

1. Will the feed ever report non-5 minute increments e.g. "6 minutes late"?
2. Is there a rule to shut off real-time feeds beyond a certain amount of lateness?
3. Is the data as good as the "Red Sign" data?

Thanks,

Charlie

[Matt Pietal]

I'd also like to reiterate the preference for one-minute increments.  After observing the new feeds for some time, I feel like the data has lost some value.  For the users of my Android application, standing on the platform or walking to the train, they like to know at that very moment if their train is on-time.  Having the feed show that a train is 5 mins late after the commuter can observe that delay for themselves is a bit redundant.

[Joachim Pfeiffer]

Pushing out departure estimates (one minute intervals or smaller) is customary in the various feeds in the region, including MBTA's bus and subway feeds. MIT's feed works like that also. For consistency across the services, and by extension, in traveler facing apps, it's desirable to keep the departure estimates and drive delay messages through the alerts feeds.

JP

--
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 http://groups.google.com/group/massdotdevelopers.
For more options, visit https://groups.google.com/groups/opt_out.