Primary Keys for fare_leg_rules.txt and fare_transfer_rules.txt #304
Description
Primary Keys for fare_leg_rules.txt and 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. MobilityData is trying this format to resolve open issues with GTFS extensions - if you have any feedback regarding this format, please reach out to specifications@mobilitydata.org
The need
The specification should enable easy lookup for entries, where unique rows can be located with the least computational resources. The modelling of Primary Keys serves to optimize lookups, and does not impact passenger information.
The issue
All fields in fare_leg_rules.txt and fare_transfer_rules.txt were initially marked as Primary Keys, this is not optimal as it results in high computational load for lookups. A group of stakeholders proposed a smaller subset of these fields to define Primary Keys.
Potential options
- Option 0: Leave as-is
- Pros: N/A
- Cons: Requires higher computational load to find unique entries, leaves room for logical errors in datasets
- Option 1: Reduce the Primary Keys to:
fare_leg_rules.txt:network_id,from_area_id,to_area_idfare_transfer_rules.txt:from_leg_group_id,to_leg_group_id- Pros: Optimizes lookups
- Cons: Restricts potential use cases (see option 2 below)
- Option 2: Reduce the Primary Keys to:
fare_leg_rules:from_area_id,to_area_id,network_id,amountfare_transfer_rules:from_leg_group_id,to_leg_group_id,spanning_limit,fare_transfer_type,amount- Pros: Balances the number of primary keys to optimize lookups while covering a wider range of use cases (see below for three use cases that cannot be represented using option 1)
- Cons: Requires more fields than Option 1
Use case 1: Agencies that accept multiple currencies
| leg_group_id | from_area_id | to_area_id | network_id | currency | amount |
|---|---|---|---|---|---|
| group_1 | area_1 | area_2 | bus | USD | 5 |
| group_1 | area_1 | area_2 | bus | CAD | 7 |
Use case 2: Travel between the same areas with different networks
| from_area_id | to_area_id | network_id |
|---|---|---|
| area_1 | area_2 | local_bus |
| area_1 | area_2 | comfort_bus |
Use case 3: Agencies that charge different fees for different transfers between the same leg groups (ex: the first 3 transfers are free but the remaining 2 cost 0.5 CAD)
| from_leg_group_id | to_leg_group_id | spanning_limit | duration_limit | duration_limit_type | fare_transfer_type | currency | amount |
|---|---|---|---|---|---|---|---|
| group_1 | group_2 | 3 | 7200 | 0 | 0 | CAD | 0 |
| group_1 | group_2 | 5 | 7200 | 0 | 0 | CAD | 0.5 |
MobilityData's recommendations
Both options 1 and 2 address the needs raised in this issue, however, MobilityData recommends option 2 as it allows for the representation of three use cases that would not be possible with option 1.
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 was unable to reach consensus by the end of phase 1, MobilityData will call for three meetings to resolve any outstanding items regarding Primary Keys and fare_leg_rules.is_symmetrical and fare_transfer_rules.is_symmetrical. Feel free to block the below times in your calendars:
Meeting 1: 2022-02-22 13:00 to 14:00 ET
Meeting 2: 2022-02-23 13:00 to 14:00 ET
Meeting 3: 2022-02-24 13:00 to 14:00 ET
Please reach out to specifications@mobilitydata.org 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 phase 3, and will publish a summary by 2022-03-04.
Phase 5
If consensus is 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.