@dhersz Feeds are sometimes nested within directories prior to zipping (and i don't think the specifications actually explicitly forbid this). When that happens, this line also lists the directory as one of the "files"
https://github.com/r-transit/gtfsio/blob/e083a15e2f6b6b8ee3bafbb8606d82239da5bff6/R/import_gtfs.R#L118
That doesn't end in ".txt", and so triggers the warning in the subsequent line. These feeds are nevertheless processed okay, and there is nothing wrong with the code. This PR simply helps to appropriately identify such cases and avoid the warning. It's perhaps not the best way to identify them, so happy to iterate, but allows feeds to be nested at arbitrary depth within the zip archive - let me know if you think of a better way.
I don't have any live examples, but have it on several older versions of the Madrid feed. It seems to have been updated now to the expected flat format, but definitely used to come in a "google-gtfs" directory.
@dhersz Feeds are sometimes nested within directories prior to zipping (and i don't think the specifications actually explicitly forbid this). When that happens, this line also lists the directory as one of the "files" https://github.com/r-transit/gtfsio/blob/e083a15e2f6b6b8ee3bafbb8606d82239da5bff6/R/import_gtfs.R#L118 That doesn't end in ".txt", and so triggers the warning in the subsequent line. These feeds are nevertheless processed okay, and there is nothing wrong with the code. This PR simply helps to appropriately identify such cases and avoid the warning. It's perhaps not the best way to identify them, so happy to iterate, but allows feeds to be nested at arbitrary depth within the zip archive - let me know if you think of a better way.
I don't have any live examples, but have it on several older versions of the Madrid feed. It seems to have been updated now to the expected flat format, but definitely used to come in a "google-gtfs" directory.