GTFS-fares v2: Fare Leg Rule "Scope" Support
- Dominant language
- No language data
- Stars
- 1.1k
- Forks
- 225
- Avg merge
- 7d 17h
- Merged PRs (30d)
- 3
Description
The `fare_leg_rules.scope` field is derived from @bdferris-v2's [Fare Leg Rule "Scope" Support proposal](https://docs.google.com/document/d/1EeHaY5S0rDLFMdXQ6OrF_-0R7-r_8vBMSAkCdQVAtyw/edit), which can indicate the evaluation scope of the rule relative to other rules. Here is the summarized context, for details please see the [proposal document](https://docs.google.com/document/d/1EeHaY5S0rDLFMdXQ6OrF_-0R7-r_8vBMSAkCdQVAtyw/edit#heading=h.2uewgmrw3fdf).
### Problem
The existing empty matching semantics allow producers to specify a fare rule for a particular matching predicate and then specify a rule that matches all other possible values without having to specify all of them explicitly. `fare_leg_rules.network_id` as an example:
> If there are no matching `fare_leg_rules.network_id` values to the `network_id` being filtered, empty `fare_leg_rules.network_id` will be matched by default.
An empty entry in `fare_leg_rules.network_id` corresponds to all networks defined in `routes.txt` excluding the ones listed under `fare_leg_rules.network_id`
However, since empty value semantics apply to the entire `fare_leg_rules` file, sometimes producers need to "repetitively" specify exhaustive networks/combinations of areas to avoid unintended exclusion based on existing empty semantics in `fare_leg_rules.txt`
### Proposed solution
Field Name | Type | Presence | Description
Add `fare_leg_rules.scope` field to provide a mechanism to limit the scope of empty-value matching semantics.
-- | -- | -- | --
scope | ID | Optional | An identifier that indicates the evaluation scope of the rule relative to other rules. For a rule using empty-value matching semantics, excluded values should only be considered for rules with the same scope value. An empty or unspecified value indicates the “default” scope, where a rule in the “default” scope will only be evaluated against other rules in the “default” scope.
### Example usage
scope | network_id | from_area_id | to_area_id | fare_product_id
-- | -- | -- | -- | --
subway | subway | z1 | z1 | subway_z1_fare
subway | subway | z1 | z2 | subway_z12_fare
bus | bus | | | bus_fare
Since "bus" scope is different from "subway" scope, The empty `from_area_id` and `to_area_id` for "bus" scope will **NOT** exclude `from_area_id` and `to_area_id` defined in "subway" scope (i.e. zone1 - zone1 & zone1 - zone2). The “bus” rules will now match all zones.
### Open questions
- Should “scope” be in the primary key for `fare_leg_rules.txt`?
- What are the implications for the `rule_priority` proposal for fare leg rules?
Please share any thoughts on `fare_leg_rules.scope` in this issue.
Contributor guide
Assessment
This issue has not been assessed yet.