On v3 prediction changes

[William Kaupinis]

Not long ago, predictions by stop and trip for commuter rail were
available about 60 minutes before the trip. This seemed
about right allowing a commuter to check predictions before
leaving home for the train station. That number is probably
too large to be meaningful for subway and buses which run far
more frequently.

Now, commuter rail predictions seem to generally be available
25 minutes before an event. In monitoring Haverhill inbound
218 on March 6, 2018, the first prediction available listed
only North Station as the destination and "on time".  At 25
minutes before departure, a Haverhill prediction was added
with prediction by trip only showing Haverhill and North
Station. Progressive disclosure ensued with other stops being
added only when the station's stop time met the 25 minute
criterion. Presenting these progressive disclosure predictions
to commuters can be confusing and misleading.  It is understood
that a prediction is only a prediction that can change, but any
trip prediction should really be complete.

It would be nice if:

1. Predictions by trip list predictions for all stops on that
trip giving a true picture of what stops are actually
anticipated for that trip. (No progressive disclosure.)

2. Predictions for commuter rail be available 60 minutes before
start if possible allowing commuters to better plan when to
leave home.

(By the way, green line data is much nicer.)

Bill

william_...@eightolives.com

[Developer at MBTA]

Hi William,

Thanks for pointing out this issue. The configuration has been updated so that now, instead of 25 minutes, predictions up to 60 minutes in the future will be available.

You had also asked for a way to get, along with predictions, a list of stops that will be served by a particular trip. With the increased limit of 60 minutes, this will only be a problem for trips predicted to take longer than 60 minutes. The easiest way to get this information using the V3 API is by making a "schedules" call and adding "include=prediction" to get a combination of predictions along with scheduled times in cases where no prediction is yet available. For example, here is an API call that would work: https://api-v3.mbta.com/schedules?trip=CR-Weekday-Fall-17-118&include=prediction

Full documentation for the V3 API is available here: https://api-v3.mbta.com/

Sincerely,

Developer@MBTA

william_kaupinis@eightolives.com

[William Kaupinis]

Thanks for the 60 minute predictions.  That covers most cases just fine.

Using the suggested "schedules call with included predictions" instead of a "predictions call" seems to be the right thing for most cases.  A few side effects had to be addressed and one anomaly was noted.

The side effect cases addressed involved late trains beyond 60 minutes and early trains (most noted on the Green line).

One anomaly was noted.  Fewer predictions were sometimes reported by the "schedules call with included predictions" vs just a "predictions call with included schedule".  I could not identify the exact conditions for the anomaly to occur, but I have captured one situation.

On March 13, 2018 (the blizzard day) incoming train 1104 was running 15+ minutes late. Schedule by stop indicated it was near Swampscott. Three data sets were captured in sequence.  Attachment 1 shows the command and response for "schedule including prediction" only indicating a prediction of destination North Station. Attachment 2 shows the command and response for "predictions include schedule" indicating Lynn, Chelsea and North Station.  Attachment 3 is a subsequent excution of "schedule including prediction" which again only shows North Station.

I'm guessing only Attachment 2 is correct.

Bill Kaupinis
william_...@eightolives.com

william_...@eightolives.com

[Developer at MBTA]

Hi Bill,

Thanks for sharing this. It looks like the stop-times you're looking for are being filtered out in attachment1 and attachment3. They both include a filter by min_time, i.e.

filter[min_time]=13:07

That filter is applied to the scheduled times. The trip is scheduled to have already arrived at and left Lynn and Chelsea by then, so that filter will exclude those stop-times. If you remove that filter you should get better results.

Sincerely,
developer@mbta

On Tuesday, March 13, 2018 at 3:55:13 PM UTC-4, William Kaupinis wrote:

Thanks for the 60 minute predictions.  That covers most cases just fine.

Using the suggested "schedules call with included predictions" instead of a "predictions call" seems to be the right thing for most cases.  A few side effects had to be addressed and one anomaly was noted.

The side effect cases addressed involved late trains beyond 60 minutes and early trains (most noted on the Green line).

One anomaly was noted.  Fewer predictions were sometimes reported by the "schedules call with included predictions" vs just a "predictions call with included schedule".  I could not identify the exact conditions for the anomaly to occur, but I have captured one situation.

On March 13, 2018 (the blizzard day) incoming train 1104 was running 15+ minutes late. Schedule by stop indicated it was near Swampscott. Three data sets were captured in sequence.  Attachment 1 shows the command and response for "schedule including prediction" only indicating a prediction of destination North Station. Attachment 2 shows the command and response for "predictions include schedule" indicating Lynn, Chelsea and North Station.  Attachment 3 is a subsequent excution of "schedule including prediction" which again only shows North Station.

I'm guessing only Attachment 2 is correct.

Bill Kaupinis

william_kaupinis@eightolives.com