In discussions with @irees at the MobilityData Summit, he mentioned they have a concept of a "fallback" feed that is used for instances when the most recent version of a feed is not acceptable for various QA reasons. QA reasons happens a lot in our data (with recent notable example of https://github.com/cal-itp/data-analyses/issues/1216) and quite frequently with various "future" feeds. It may be helpful for us to automatically have a way flag a feed that represents an acceptable level of quality when the latest feed shouldn't be used.
Acceptance Criteria
Create an algorithm that can be used to generate fallback feeds when needed
Create a new table or flag upon an existing table that marks what should be an appropriate feed for a particular date
Notes
This could be split into 2 efforts. 1st effort to calculate current fallback feed, 2nd effort to flag fallback feed for any date. Data from the Transit Database could be used to check for services that have been deprecated to ensure we're not adding some feeds that have truly ceased operations.
User story / feature request
In discussions with @irees at the MobilityData Summit, he mentioned they have a concept of a "fallback" feed that is used for instances when the most recent version of a feed is not acceptable for various QA reasons. QA reasons happens a lot in our data (with recent notable example of https://github.com/cal-itp/data-analyses/issues/1216) and quite frequently with various "future" feeds. It may be helpful for us to automatically have a way flag a feed that represents an acceptable level of quality when the latest feed shouldn't be used.
Acceptance Criteria
Notes
This could be split into 2 efforts. 1st effort to calculate current fallback feed, 2nd effort to flag fallback feed for any date. Data from the Transit Database could be used to check for services that have been deprecated to ensure we're not adding some feeds that have truly ceased operations.