Defining fares which require transferring at certain stations within a general transfer network

### Introduce yourself

_No response_

### Ask a question

From my understanding of the modelling in GTFS Fares v2,

1. Physical legs are joined into effective fare legs using `fare_leg_join_rules.txt`
2. Each fare leg is matched with the applicable fares. If multiple fare legs match a rule in `fare_transfer_rules.txt`, the transfer is processed.

In the PAYG rail network in London, in general fares are defined on a station-to-station basis, and the fare system does not care how you transfer within the network within stations.

That means the above fact can be modelled by defining a rule for `fare_leg_join_rules.txt` that all legs in the PAYG route network should always be joined, by setting `from_network_id` to be the PAYG network, `to_network_id` to be the PAYG network (the default is that the legs joined must be at the same station - we can add rules for the likes of Hackney Central / Hackney Wick, or Bank / Monument where they are within the same gateline).

However, there are also some situations where how you transfer will affect the fare. These are divided into two categories:

1. Changing between two different stations (an OSI) where you *must* validate your fare media. This may increase or decrease your fare.
2. Changing within the same station, where you *may* validate your fare media to decrease the fare.
Both of the above actions may or may not change your fare. So I am thinking about using `fare_transfer_rules.txt` to model them, but it now becomes extremely difficult:

For the case OSI between Underground and National Rail at a London Terminal, for an A-B1/B2-C journey where B1 is the National Rail station and B2 is the corresponding Underground station, if I model it using `fare_transfer_rules.txt`, it will require defining nearly a million rules (as there are approximately a thousand stations in the whole network) for every pair of A-C, to specify that two effective fare legs of A-B1 and B2-C with a transfer at B1/B2, which may resolve to a normal A-C fare, or some other fares. Multiply it with about a hundred OSIs in the network, it will soon become unmanageable. Moreover, if there are multiple such OSIs joined together, for example, an A-B1/B2-C1/C2-D1/D2-E journey to resolve to a certain A-E fare (which, in the fare collection system, is defined by the existence of a certain transfer within the sequence), I don't even know how I can model it in `fare_transfer_rules.txt`, because the only "rule" which does not take the individual leg fare into account is `fare_transfer_type` = 2, and in this case it will result in a A-C1 (transferring at B1/B2) + B2-D1 (transferring at C1/C2) + C2-E (transferring at D1/D2) fares as the total. There can be unlimited number of such consecutive OSIs in the network.

Before of the above nature and the fact that such joining is treated as a single fare leg in the fare collection system, it should really be modelled by `fare_leg_join_rules.txt` so the whole journey can be matched to one fare. However, it is impossible to match a fare product to a fare leg with the requirement that there must be a "physical" transfer within the "effective fare leg" (this is how the fares are technically implemented in the fare collection system). Moreover, we also need a way to exclude fares from changing at these specified places as well.

In the "changing within the same station" example, the same problem also exists. You can't obtain a certain fare just by passing through the station. You must get off and make a transfer at that station to validate for a certain fare, but the system doesn't care about how many other transfers you make within the network, and treats your journey as a single leg.

Can anyone guide me if the above is possible in GTFS-v2?