-
Notifications
You must be signed in to change notification settings - Fork 209
Description
👋 Hello GTFS Community!
I'm opening this issue as a request for information from those who were involved in the Fares v2 discussions.
Context
In PR #286, amending the specification with Fares v2 base implementation, fare_rules.txt changed from being Optional to being Conditionally Required if fare_attributes.txt was present. This change results in some existing production data becoming invalid, and I'd like to know if this was the intention.
Quoting @bdferris-v2 below, who is currently updating the Canonical GTFS Schedule Validator with the Fares v2 base implementation rules.
"Looking back at the original Fares V1 example documentation (not really hosted anywhere anymore, but available at https://web.archive.org/web/20111207224351/https://code.google.com/p/googletransitdatafeed/wiki/FareExamples), having a fare_attributes.txt file with a single entry and no fare_rules.txt file was a supported use-case for systems that have a single base fare.
There are 62 feeds in the MobilityDatabase that have a fare_attributes.txt file but no fare_rules.txt file. Of those, 39 have a single entry in fare_attributes.txt, indicating a default fare."
There was a comment from @flocsy calling out this behavior, and I think during the roundtable discussions, it was decided not to tackle this problem to keep the focus on the scope of the PR (please correct me if I'm wrong).
Needs
I would like to have insights from those who were involved in the Fares v2 base implementation so that MobilityData can best support the organizations that might be affected by this change.
- Is the behavior described above now a spec violation?
- I know there were many iterations in this PR. Was this change intentional, or was it part of an earlier version?
Thank you in advance 🙏