[REQUEST] Automated marking of inactive / deprecated feed statuses (or embed GTFS timeranges in CSV export?)

[mil]

What problem is your feature request trying to solve?
I have an an application that consumes data based on the Mobility Database's catalog and its often reported to me by users of my app that certain feeds are stale (e.g. contain calendar/calendar_dates months / years in the past - and thus unusable for routing / schedules etc.). These feeds are marked in Mobility Database's catalog with a status of empty (``) or active; but in actuality are inactive or deprecated (containing data from years past).

Describe the solution you'd like
CI or a cronjob could run and automatically mark feed the status field as inactive/active by two approaches:

1. A script in CI could run to open a PR using the Github API for each outdated feed to change its status to inactive or active OR
2. During the CSV generation process (which also generates static URL links), we could generate the "timespan" the feed is active for (e.g. start/end of calendar/calendar_dates)

(2) may actually be preferred because if I understand MobilityData's CI correctly this could already be done just by some simple CI modifications, correct?

Describe alternatives you've considered

The current alternative is to rely on end-users to manually change each feed's status - but that's error-prone & requires a great deal of manual user-intervention & QA.

How will we know when this is done?
As a user, if you see a feed as active in the Mobility Database catalogs CSV, you are guaranteed that GTFS feed is active (e.g. in that the download day is within the valid calendar/calendar_dates range provided by the GTFS feed) as of the day of downloading the CSV.

OR

As a user, the Mobility Database catalogs CSV could present two new columns for each GTFS feed: start_date and end_date. Optionally in this approach, the status field (inactive/active/deprecated) could be removed all together.

[emmambd]

Thanks @mil! This is a feature request on our radar and why we've recently added the service window range to the GTFS Schedule Validator summary report: https://gtfs-validator.mobilitydata.org/. We intend to use this information to populate the data in the Mobility Database API and website.

[emmambd]

You can learn more about the Mobility Database API repo here to contribute to it: MobilityData/mobility-feed-api#718

[mil]

Thanks @mil! This is a feature request on our radar and why we've recently added the service window range to the GTFS Schedule Validator summary report: https://gtfs-validator.mobilitydata.org/. We intend to use this information to populate the data in the Mobility Database API and website.

Thanks for the additional info @emmambd

So now that the service window range is supported in the GTFS Schedule validator summary; will the service window range info additionally eventually be planned to be passed along to the Mobility DB CSV (or only the API / website)?

If it helps, I could likely assist with dev effort on implementing the service window range feature in the CSV generation (with a bit of guidance on which path / implementation would be accepted as outlined above or if there is some other ideal implementation?).

[mil]

I think this should be covered by new version of CSV / 779 as discussed in other ticket.

We can probably close this ticket

[emmambd]

Thanks @mil! The epic for adding the service date ranges is here: MobilityData/mobility-feed-api#865