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

headways data quality? #10

Open
hamima-halim opened this issue Apr 19, 2024 · 3 comments
Open

headways data quality? #10

hamima-halim opened this issue Apr 19, 2024 · 3 comments

Comments

@hamima-halim
Copy link
Contributor

the scheduled headways in LAMP are pretty irregular. in gobble, we disregard the reported scheduled headways entirely and recalculate our own from gtfs.

  • gtfs does not include NONREV-* or ADDED* stops
  • gobble (realtime API) does report NONREV-* and ADDED* events
  • LAMP does report NONREV-* and ADDED* events

THAT BEING SAID....
the headways we calculate seem to be identical the ones we report in gobble, and if we recalculate the lamp events in the same was we get the same numbers. but also, i might be illiterate.

@devinmatte
Copy link
Member

devinmatte commented Apr 19, 2024

We also process the monthly data files: https://github.com/transitmatters/t-performance-dash/blob/main/server/rapid/process_events.py

There may be some logic in here worth looking at (looks like we don't touch gtfs in this, so maybe not)

@devinmatte
Copy link
Member

Aha I knew there was something: https://github.com/transitmatters/t-performance-dash/blob/main/server/bus/bus2train.py

We do this for bus monthly data we ingest (but for some reason not for train data, may want to update that)

@devinmatte
Copy link
Member

We should look into smoothing headways into 15 or 30 minute averages to avoid these jumps in the bar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants