Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properly handle stations with multiple stops #915

Closed
devinmatte opened this issue Dec 23, 2023 · 3 comments
Closed

Properly handle stations with multiple stops #915

devinmatte opened this issue Dec 23, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@devinmatte
Copy link
Member

devinmatte commented Dec 23, 2023

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.

@devinmatte devinmatte added the bug Something isn't working label Dec 23, 2023
@devinmatte
Copy link
Member Author

Nevermind, I was wrong. We did account for it

@rudiejd
Copy link
Contributor

rudiejd commented Dec 23, 2023

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.

@devinmatte
Copy link
Member Author

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.

@devinmatte devinmatte added this to the Dashboard V4.1 milestone Apr 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants