Changes to fare_transfer_rules.fare_transfer_type #307
Description
Changes to fare_transfer_rules.fare_transfer_type
This GitHub issue was raised in response to a discussion in pull Request #286, and has been prioritized by MobilityData, who is going to work on it with the agenda described below.
The need
The specification should be human readable and flexible.
The issue
- Stakeholders have flagged that the wording of the enumerations in
fare_transfer_rules.fare_transfer_typeis not very intuitive - The current enumerations in
fare_transfer_rules.fare_transfer_typemay not cover all the industry use cases
Potential options
- Option 0: Leave as-is
- Pros: Lighter specification with fewer fields, ability to expand with additional fields by adding enumerations instead of fields
- Cons: Makes the field definition of
fare_transfer_rules.fare_transfer_typedense
- Option 1: Remove the field
fare_transfer_rules.fare_transfer_typeand replace with four new fieldsinclude_previous_fare_leg_rule_amounts: enum 0, 1include_previous_fare_transfer_rule_amounts: enum 0, 1include_next_fare_leg_rule_amount: enum 0, 1include_most_expensive_fare_leg_rule_amount: enum 0, 1- Pros: Allows for maximum flexibility through using different field combinations
- Cons: Adds three new fields to the specification. More fields might be added if additional use cases are required.
An analysis of the possible combinations using option 0 vs option 1 is presented below:
A corresponds to the fare for the first leg
B corresponds to the fare for the second leg
AB corresponds to the transfer cost
The table below demonstrates that while option 1 (using different fields) provides more flexibility and can represent more use cases, these additional use cases are not logical and do not describe practical use cases. Option 0 (enumerations) can represent all the logical combinations from option 1.
| incl A | incl AB | incl B | incl max(A,B) | Result | Logical use case? | Representation using current implementation | |
|---|---|---|---|---|---|---|---|
| Combination 1 | YES | YES | YES | YES | A+AB+B+MAX(A,B) | No | |
| Combination 2 | YES | YES | YES | NO | A+AB+B | Yes | enum 1 |
| Combination 3 | YES | YES | NO | YES | A+AB+MAX(A,B) | No | |
| Combination 4 | YES | YES | NO | NO | A+AB | Yes | enum 0 |
| Combination 5 | YES | NO | YES | YES | A+B+max(A,B) | No | |
| Combination 6 | YES | NO | YES | NO | A+B | Yes | enum 1 (amount=0) |
| Combination 7 | YES | NO | NO | YES | A+MAX(A,B) | No | |
| Combination 8 | YES | NO | NO | NO | A | Yes | enum 0 (amount=0) |
| Combination 9 | NO | YES | YES | YES | AB+B+MAX(A,B) | No | |
| Combination 10 | NO | YES | YES | NO | AB+B | Yes* | enum 1 (amount=AB-A) |
| Combination 11 | NO | YES | NO | YES | AB+MAX(A,B) | Yes | enum 2 |
| Combination 12 | NO | YES | NO | NO | AB | Yes | enum 3 |
| Combination 13 | NO | NO | YES | YES | B+MAX(A,B) | No | |
| Combination 14 | NO | NO | YES | NO | B | Yes* | enum 1 (amount=-A) |
| Combination 15 | NO | NO | NO | YES | MAX(A,B) | Yes* | enum 2 (amount=0) |
| Combination 16 | NO | NO | NO | NO | 0 | No |
*These combinations are possible, but correspond to unlikely use cases.
MobilityData's recommendations
MobilityData recommends implementing option 0 as it addresses the needs raised in this issue. With option 0, all the possible use cases can be modelled, additionally, the specification remains light, and any use cases which are not covered by the current implementation can be accounted for by extending the enumerations.
2022-01-31: Issue opened on GitHub
Phase 1
From 2022-01-31 to 2022-02-11 (10 business days): Conversations on GitHub with the community.
Phase 2
From 2022-02-14 to 2022-02-18 (5 business days): MobilityData will gather and analyze the feedback provided in phase 1, and will publish a summary by 2022-02-18.
Phase 3
If the community was unable to reach consensus by the end of phase 1, MobilityData will call for three meetings to resolve any outstanding items regarding fare_transfer_rules.txt. Feel free to block the below times in your calendars:
Meeting 1: 2022-02-22 11:00 to 12:00 ET
Meeting 2: 2022-02-23 11:00 to 12:00 ET
Meeting 3: 2022-02-24 11:00 to 12:00 ET
Please reach out to specifications@mobilitydata.org to receive an invite or react to this message to receive a meeting invite.
Phase 4
From 2022-02-28 to 2022-03-04 (5 business days): MobilityData will gather and analyze the feedback provided in the phase 3, and will publish a summary by 2022-03-04.
Phase 5
If consensus was reached, MobilityData will open the vote on the week of 2022-03-07, otherwise, MobilityData will act as a facilitator to help the community reach consensus through meetings, online conversations, or other appropriate means. The time period for this phase starts on 2022-03-07 and ends on 2022-03-11 (5 business days). MobilityData can be invited to take meetings notes or can be kept in Cc for those exchanges.
Phase 6
From 2022-03-14 to 2022-03-19 (5 business days): MobilityData will gather and analyze the information shared during phase 5, and will publish a summary by 2022-03-19.
Phase 7:
In all cases, the vote will be opened on the week of 2022-03-28. If the vote does not pass, MobilityData will end the work on these issues and will inform the community. This will not prevent other stakeholders from continuing the effort to drive the adoption of the base implementation of GTFS-Fares.