is_symmetrical in fare_leg_rules.txt and fare_transfer_rules.txt #305
Description
is_symmetrical in 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.
The need
The specification should forbid:
- Erroneous logical errors
- Ambiguities regarding Primary Keys
The issue
Currently, two entries in fare_leg_rules.txt and in fare_transfer_rules.txt can be identical except for values in the is_symmetrical field. This leads to conflicting information on whether the fare is symmetrical or not, see sample data below (are transfers from area_2 to area_1 possible or not)
| leg_group_id | from_area_id | to_area_id | network_id | is_symmetrical |
|---|---|---|---|---|
| group_1 | area_1 | area_2 | bus | 0 |
| group_1 | area_1 | area_2 | bus | 1 |
More importantly, this affects Primary Keys as the above sample data demonstrates that the other remaining four (or even six, if all fields are utilized) fields cannot describe a unique entry. This would require including is_symmetrical in the list of Primary Keys
Potential options
- Option 0: Leave as-is
- Pros: Keeps the verbosity of the specification minimal
- Cons: Leaves the door open for logical errors, unnecessarily complicates Primary Keys
- Option 1: Extend the definitions of is_symmetrical with the following
fare_leg_rules.txt: A record must not be duplicated with any arrangements of the samefrom_area_idandto_area_idvalues with different values foris_symmetrical.fare_transfer_rules.txt: A record must not be duplicated with any arrangements of the samefrom_fare_leg_idandto_fare_leg_idvalues with different values foris_symmetrical.- Pros: Forbids ambiguous data and simplifies Primary Keys
- Cons: Makes the specification more verbose, might set a precedence for adding more restrictions in the specification
MobilityData's recommendations
MobilityData recommends Option 1 as it addresses the needs raised in this issue.
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 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 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.