Commuter Rail predictions

[Developer at MBTA]

All, 

We wanted to follow up on our plan for applying hold times to commuter rail predictions. As people following the forum will know, we rolled out and then rolled back a change to commuter rail predictions last week. It applied the logic "if the train will arrive before its scheduled departure time, and the stop isn't an L-stop, then use the scheduled departure time as the prediction." We were viewing this as an accuracy improvement, but we heard from developers and stakeholders a variety of good reasons why the change wasn't necessarily an improvement. We're sorry for any inconvenience caused by the change.

What we'd like to do going forward is to leave existing API behavior the way it is now, returning arrival predictions, and include both the existing arrival time and the adjusted departure time in GTFS-realtime. Currently in our GTFS-realtime feed the StopTimeUpdate "arrival" and "departure" fields always contain the same value. That will change. If a commuter rail train is expected to hold for schedule at a stop then the "arrival" field will still contain the arrival time as it does now, and the "departure" field will contain the time the train is expected to depart. (If the train is running late, they will contain the same value. If the stop is an L-stop, they will contain the same value.) So developers will be able to choose whether they want to use the arrival time or the departure time. 

When we have this change ready we'll provide a live sample feed with it for a week before moving it to production, to give developers a chance to test it and offer feedback. 

Please let us know what feedback you have, and we'll update this group when we have a GTFS-realtime sample feed ready. 

Sincerely,

developer@mbta

[Stefan Wuensch]

This sounds excellent!! This appears to bring the same richness of the APIv2 to GTFS-RT... meaning, having the arrival prediction which is so vital plus the departure timepoint.

When you say "leave existing API behavior the way it is now" does that mean that this proposed change will literally only affect GTFS-RT?


Also, will there be a direct correlation between APIv2 and GTFS-RT field values like this pseudo-code?

{ GTFS-RT[ StopTimeUpdate->arrival ] == APIv2[ trip->stop->pre_dt ] }

if ( GTFS-RT[ StopTimeUpdate->arrival ] <= APIv2[ trip->stop->sch_arr_dt ] ) # train on time (arrive early, or as scheduled)
{ GTFS-RT[ StopTimeUpdate->departure ] == APIv2[ trip->stop->sch_dep_dt ] } # departure as scheduled


if ( GTFS-RT[ StopTimeUpdate->arrival ] > APIv2[ trip->stop->sch_arr_dt ] ) # train is late
{ GTFS-RT[ StopTimeUpdate->departure ] == APIv2[ trip->stop->pre_dt ] } # departure as predicted, later than scheduled


It would help me understand how the GTFS-RT and API relate if you could validate those three assertions for me. (I don't currently use GTFS-RT but I very likely will in the future.)

Thank you!!


-- Stefan

[Developer at MBTA]

Yes your understanding is correct. The pseudo-code does capture the idea, although this will only apply to commuter rail stop_times with a timepoint value of 1, and there will be some additional logic to handle certain corner conditions. 

Sincerely, 

developer@mbta