t-performance-dash icon indicating copy to clipboard operation
t-performance-dash copied to clipboard

Double check metric calculation

Open austinjpaul opened this issue 5 years ago • 2 comments

We should confirm the logic on dwell calculation in s3_historical.py. It is possible that the same trip can arr/dep a stop multiple times in quick succession, and we should handle any irregularities accordingly. (aka, also worry about park street?)

Existing headways logic should handle this scenario, though we can't rule out very same-train headways when the trip id's are empty.

Travel-times logic is close to correct, though the same trip departing twice might give rise to 2 very-similar travel-times.

I believe there are only a small handful of stops that exhibit this behavior with any regularity. (e.g. Tufts)

Any update to these functions should consider run-time performance, since they run on very long lists and slow down long aggregate requests. In addition, when we start fixing issues about the green-line, this may be important to revisit as well.

Last thought- right now, my approach has been 'do what makes most sense', though we might want to consider changing this approach to 'do exactly what the T does' iffen we figure out how they calculate these things.

https://github.com/mbta/transit-performance/ and the google doc linked here might give some clues.

austinjpaul avatar Mar 06 '21 18:03 austinjpaul

Travel times was updated in 8ab931be1db0a9247433bedc9f6fea9e45dda36e for sanity, but we should still consider correctness.

austinjpaul avatar Mar 23 '21 20:03 austinjpaul

This should be confirmed in the massdotdev google group, but i think they say that PRD and DEP are 2 different entities, the first being predicted and the latter being actual. For subway, the actual might not be recorded, so PRD is used instead. But if both/multiple are ever present, we might want to default to the right one.

austinjpaul avatar Apr 12 '21 12:04 austinjpaul