trynmaps / metrics-mvp

Prototype of public transit data visualization system
https://muni.opentransit.city
MIT License
30 stars 34 forks source link

Use recentmost date key if date is not active in GTFS #648

Closed EddyIonescu closed 4 years ago

EddyIonescu commented 4 years ago

Resolves https://github.com/trynmaps/metrics-mvp/issues/647

As to identify the GTFS date corresponding to a given date (ie. the GTFS date containing the scheduled trips for that date) a date_keys lookup is done.

The lookup is done on the date_keys file, which persists the GTFS date for each date that was processed, as to allow for re-running pre-computation on older GTFS's.

Since the recentmost GTFS file Muni put out expired on 2020-05-29, the pre-computation as well as the API failed due to the date key lookup failing.

This PR modifies the get_date_key function as to return the recentmost date key corresponding to the same day of the week. Note that it does not take holidays into account. It raises an exception if it cannot find a suitable date_key to use.

It prints a warning if it succeeds in using another date_key, although a future PR could send out an email so that we are aware the GTFS is outdated, which the save_routes batch should be doing too.

hathix commented 4 years ago

How does the frontend find out if the get_date_key function still can't find a suitable date_key? Is it possible for that function to return null or something so the frontend can raise an error to the user instead of just showing an empty screen? Or is there another way to check this?

EddyIonescu commented 4 years ago

@hathix so the frontend doesn't find out it just gets empty fields so it shows - for all the dashboard cells. It's the same behaviour as when you enter a date that we don't have data for (like say in 2015). If the fields are null the frontend could say something like "Sorry we don't have any data for this date" but that'd be a separate issue/PR.

hathix commented 4 years ago

Got it, we can do that in a separate pr quite easily.