Closed hathix closed 4 years ago
Hey @hathix so data is still being collected so we haven't lost anything (you can confirm this in the old OpenTransit map here: http://opentransit-map.s3-website-us-west-2.amazonaws.com).
What happened is that Muni hasn't updated their GTFS (their recentmost one ended on May 29) so the API's returning null because of missing date keys (I think, I can look more into it this weekend, @youngj would know more about this). The arrivals are still getting computed with the old GTFS route configs and are in S3.
I see... can we reuse the old GTFS (pre-5/29) if Muni hasn't given a new one? Or is the data useless unless we have the freshest GTFS?
@hathix yep that's what https://github.com/trynmaps/metrics-mvp/pull/648 does, it is the freshest GTFS except that it's expired which is why the pre-computing scripts failed.
There could be a note (like a banner or something) saying that all schedule-based metrics (ie. scheduled times, scheduled headways, on-time performance, scheduled runtimes) for Muni are inaccurate since April as they've been running entirely on a headway-based system, so would be worth making into a ticket. Still it's the runtime data that's the most interesting - like making a more detailed and granular version of this graphic Muni made a few weeks back: https://www.masstransitmag.com/bus/press-release/21140228/san-francisco-municipal-transportation-agency-sfmta-shelterinplace-order-allows-sfmta-to-analyze-sources-of-delays
Great! I'll look at that PR. I agree that we should give some notification that recent stats are off, I can make a PR to let us put notifications on screen
https://muni.opentransit.city/metrics?firstDateRange%5BstartDate%5D=2020-05-29&firstDateRange%5Bdate%5D=2020-06-01 shows data. https://muni.opentransit.city/metrics?firstDateRange%5BstartDate%5D=2020-05-30&firstDateRange%5Bdate%5D=2020-06-01 doesn't.
Did we do something that broke data collection on 5/30?