Skip to content

Conversation

@bdferris-v2
Copy link
Contributor

@bdferris-v2 bdferris-v2 commented Nov 16, 2022

When the initial Fares v2 base implementation was added to the official spec (#286), it also included some changes for Fares v1. Specifically, fare_rules.txt was now marked as conditionally required if fare_attributes.txt is present. I believe this change was a mistake and should be reverted.

It's my understanding that fare_attributes.txt has always been allowed with a single entry to indicate a flat fare for all rides. In this scenario, fare_rules.txt is not required. This behavior was documented on the original Fare Examples wiki entry and has been (described elsewhere)[https://docs.google.com/document/d/1mK3--o5g4-3cCXaqmch92U63JTwChh0L2VCmcDViIlM/edit#heading=h.1xji1nf0ko4z] as well. More importantly, I count ~40 feeds in the MobilityDatabase that are currently relying on this behavior.

There was also a comment from @flocsy calling out this behavior in the original PR discussion (#286 (comment)), but I think it got dropped in the lengthy Fares v2 discussion?

Given all that evidence, my proposal is to revert the language change making fare_rules.txt conditionally required.

See also the related discussion in the #gtfs-fares slack channel and related discussion for the gtfs-validator.

gtfs-changes announcement: https://groups.google.com/g/gtfs-changes/c/Jn8OIuK6J54/m/RWg9hqwTBQAJ

@flocsy
Copy link
Contributor

flocsy commented Nov 17, 2022

+1

@isabelle-dr
Copy link
Collaborator

Thank you for opening this @bdferris-v2
I confirm the intention for this change was to describe the relationship between Fares v1 and Fares v2 files, and not make data with only fare_attributes.txt invalid.
I think the example section of gtfs.org provide a good explanation of this relationship.

@bdferris-v2
Copy link
Contributor Author

This pull request has been open for more than one week, so I am calling for a vote. Note that this is for the proposal to revert change that made fare_rules.txt conditionally required.

Please vote with a +1 (for) or -1 (against) in the comments. Voting ends on 2022-12-07 at 23:59:59 UTC.

@skinkie
Copy link
Contributor

skinkie commented Nov 30, 2022

Brian knows best +1 (OpenGeo)

@SteveGladstone
Copy link

+1 Maryland Transit Administration

@bdferris-v2
Copy link
Contributor Author

@flocsy any chance you could chime in with an official vote here?

@flocsy
Copy link
Contributor

flocsy commented Dec 7, 2022

+2 :)
not that it matters, 'cause so long everyone who voted voted for it it'll pass, even if it's just 1 vote IMHO

@isabelle-dr
Copy link
Collaborator

We need at least three (in addition to having no -1), thank you @flocsy :)

@bdferris-v2
Copy link
Contributor Author

The voting period has passed and the proposal received three +1 votes and no -1 votes. I believe that meets the bar for acceptance. Thanks everyone!

@bdferris-v2 bdferris-v2 merged commit f62ca84 into google:master Dec 8, 2022
@isabelle-dr isabelle-dr added the GTFS Schedule Issues and Pull Requests that focus on GTFS Schedule label Jan 20, 2023
@isabelle-dr isabelle-dr mentioned this pull request Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

GTFS Schedule Issues and Pull Requests that focus on GTFS Schedule

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fare_rules.txt requirement change in the Fares v2 base implementation is making existing data invalid

5 participants