Use Case

1. When riders transfer between multiple legs during their journey using fare products, there are typically two scenarios:

• In the case of a "ticket-based system" (i.e., a product similar to a pass), special transfer rules between two legs (such as free transfers) must be applied using the same fare product.
• In a "stored-value system" (i.e., a general pay-as-you-go product), special transfer rules between two legs do not require the use of the same fare product.

2. Most transfer rules between two legs necessitate the use of the same fare media to apply, but there are exceptions. For instance, within a region, two networks might exist where one has introduced an app media while the other only uses paper tickets. In such cases, transfer rules might apply between two distinct fare media (for example, showing a paper ticket to the driver to get a free transfer).

Problem to solve

The current Fares v2 spec does not have mechanism for differentiating the above use cases or provide explanation within its description, leading to potential ambiguity. This is especially relevant for certain transit systems, such as STM, that operate 100% with a ticket-based system. Transit firstly posed the question, "Should fare transfers require that the same fare product is used on both legs?" Subsequently, Google also raised the following questions in this transfer semantics document [this issue only discusses the first three questions in this document]:

• For a leg-to-leg transfer to match a row in fare_transfer_rules.txt, is it required that both legs have the same fare media type?
• Is it intended that multiple rows in fare_transfer_rules.txt can match a single leg-to-leg transfer?

Proposed solution

On October 24th, the working group reached a consensus to clarify these questions, leaning towards a default behavior mechanism to minimize any potential breaking changes. Based on this consensus, we drafted this proposal that aims to resolve the above 3 questions.

In the November discussion, the working group is currently leaning towards option 1 proposed, which involves adding fare_product_behavior, fare_media_behavior, and filter_fare_product_id to fare_transfer_rules. This option is favored as this mechanism appears to be more like the attributes of fare_transfer_rules (with option 2 being an alternative).

We'd love to see any feedback on this proposal or any related use cases. Please feel free to share any thoughts on this issue.