Improvements to fare_transfer_rules.txt

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 clear regarding how transfers are handled.

The issue

• The specification does not define how transfers from one fare_leg_group to another fare_leg_group if those leg groups are not listed as a pair in fare_transfer_rules.txt

• The field fare_transfer_type is forbidden if the amount field is not defined. However, an undefined amount field corresponds to amount=0. Without a defined fare_transfer_type, the transfer costs cannot be properly conveyed (A, B, A+B, or 0?)

Potential options

• Option 0: Leave as-is
  • Pros: None
  • Cons: Leaves the door open for logical errors
• Option 1: Clarify in the pull request and in future best practices documents that for undefined pairs of fare_leg_group, a transfer is not possible. Therefore, the second leg corresponds to the beginning of a new sub-journey. This means that the total journey cost is equal to the sum of the costs of the sub-journeys.
• Option 2: Add the following wording in the header for fare_transfer_rules.txt
  • "Transfers are only possible between fare leg groups defined in fare_transfer_rules.from_leg_group_id and fare_transfer_rules.to_leg_group_id. A new fare is required to travel between an undefined pair of leg groups.”
• Option 3: Make fare_transfer_type a required field

MobilityData's recommendations

MobilityData recommends implementing both options 1 and 3 as they address the needs raised in this issue. Option 1 clarifies the ambiguity within the community and within best practices documents without making the specification more verbose. On top of option 1, option 3 will eliminate the risk of errors in communicating passenger information.

Timeframes

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 is 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/reply 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.