Collect metadata and validate GTFS feeds

[dfsnow]

We should start to collect metadata on GTFS feeds (and corrective actions) used in this project in order to ensure reproducibility. Metadata can be stored in a simple flat file in inputs/shared/feeds and could contain fields such as date feed last updated (on TransitFeeds), feed location, feed name, list of potential errors/issues, and a list of corrective actions taken to fix said issues.

Potential feed issues include:

• Invalid geometries (usually incomplete linestrings). Can be corrected with any GIS geometry validator i.e. st_make_valid. OR dropping geometries, since they are not needed for r5r
• Invalid or unroutable route_type in feed. Can be fixed by forcing route_type to something within GTFS spec
• Arrival/departure times that are too fast or slow, resulting in bad travel times. Rafa suggests using gtfs2gps R package to correct times
• Missing information or files
• Scheduled dates outside of the dates needed for routing. Can be fixed by coercing dates into the desired routing date range

We may even want to compile a collection of validated feeds + metadata and tarball it in this repo. This would ensure reproducibility but would be a lot of work.

For feed validation, I've used this tool in the past. Google also has a tool here. Rafa also mentions they're working on a gtfstools R package specifically for this purpose.

[eric-mc2]

I'm not sure if these are the same errors that bubble up to r5r, but a lot of the errors seem to be more physical, file-structure related rather than logical attribute-value related. For instance, most files fail on tidytransit::read_gtfs(path) or tidytransit::get_route_geometry(feed_sf) before we're even able to try sf_is_valid(route_geom)