transitmatters/t-performance-dash

Properly handle stations with multiple stops

Closed this issue · 3 comments

Stations like Park Street (and South Station for the commuter rail) have many platforms and stops within the station that the T could stop at. Right now we just use the first of the array of stops

{
        "stop_name": "Park Street",
        "branches": ["B", "C", "D", "E"],
        "station": "place-pktrm",
        "order": 12,
        "stops": {
          "0": ["70200"],
          "1": ["70196", "70197", "70198", "70199"]
        },
        "accessible": true
}

I suspect this was meant to be eventually fixed before launch, and we just never did.
https://github.com/transitmatters/t-performance-dash/blob/main/common/components/widgets/StationSelectorWidget.tsx#L38-L41

We need to fix this especially before adding commuter rail

Since we use the stop keys in url params, we need to probably send to the backend a list of all the stops for a station, given one of the other stop ids from the url params.

Nevermind, I was wrong. We did account for it

I actually ran into this issue while calculating the distance between stations: #909 (comment)

While we might handle using the stop in the URL by converting it to a station, I still think using the actual station ID might be a useful refactor. That way, our scheme could match the MBTA URLS e.g. https://www.mbta.com/stops/place-sstat and we don't have to worry about doing that conversion.

I believe the choice to use stop ids was because v3 used them and we wanted to maintain links.

If we were to switch to using station ids we would need a middleware to ensure all old links still work.