Add rule_priority field to fare_leg_rules.txt about transit HOT 6 OPEN

At Transit, we're in favour of the idea of rule priority in principle, as a way to make fare leg rules easier to write and understand. A big thank you to the folks from ITO World who've been working on advancing this.

There are so many unanswered questions we need to hammer down, hence why we asked for it to be in another PR.

So far the following questions have come up internally:

1. What happens when multiple matching fare_leg_rules have equal rule_priority? There should be a clear statement in this case.
2. The proposed changes appear to consist solely of adding a rule_priority field. As a result, the confusing special case for empty values for fields like from_area_id, to_area_id and network_id continues to apply (where they match all values not otherwise specified).
   • If left as is, we worry this would limit the value of rule_priority.
   • Perhaps when rule_priority is set, empty values truly mean empty?
   • Or instead, the use of empty values could be banned when rule_priority is set?
3. This proposal doesn't appear to be backwards compatible, in that consumers that do not recognize the rule_priority column will derive a different meaning for the fare leg rules than that intended by the producer. Users could see incorrect fare calculators.
   • I think the proposed specification text will need a clear and extensive section describing the backwards compatibility situation when rule_priority is used.
   • I've only skimmed the proposal so far; if it is in fact backwards compatible, I'd love to see a worked example.

from transit.

We have been thinking about unintended consequences of rule_priority and considering whether we need a way to restrict its effect.

As an example, take the example at the top, and imagine that those are contactless fares, and there is a different cash fare that is constant through the whole day.

In this case, when off-peak, the contactless and cash products will match. However in peak times, only the contactless_peak product will match, as it matching causes any rule_priority=0 rules to be discarded. This is clearly undesirable, and could be a surprise if those rules are much further apart in the file.

One approach could be to have an optional scope that limits the override mechanism eg

This would be one way, it could also be something like a fare_products.fare_product_group_id that connects the two contactless products.

This example also raises the question of whether the rule_priority mechanism operates on just the predicates in the fare leg rules, or whether it considers whether the fare products themselves actually match (at eg fare media level).

Our initial work around this feature was connected to zonal schemes, and so the language in the original proposal was around "cheaper fares being selected", such that we wouldn't present zones 1-4 as an option for a zones 2-3 journey. We probably need to resolve that case via a different mechanism, so I've changed the area-based proposal to override regardless of it being cheaper or more expensive.

from transit.

@npaun Glad it's looking useful.

Some initial answers:

1. I've tweaked the proposal mentioned to say "those rules" rather than "the one rule". Ie all rules that have the equal highest priority are selected and the rest discarded.
2. We have only used this in a world where those fields are never left empty (from_area_id = "anywhere" etc). I think working with them being empty would work, but maybe the the third option of requiring those fields be populated might be the best for now. At a later date, if we get a mechanism to opt-in change the rules of those empty values, we could relax that rule.
3. We may be missing something, but we see this as similar to any proposal that adds predicates to the fare leg rules, such as timeframes.

from transit.

Hey everyone - just a reminder that MobilityData is hosting a GTFS-Fares v2 monthly meeting, and we will discuss this issue tomorrow at 11 AM EDT. To participate in the meeting, please subscribe via this link.

For a summary and more details, please check out the meeting notes.

from transit.