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.