Inter-agency transfer fare processing (within the same GTFS dataset)

[omar-kabbani]

Hey everyone - this issue is on processing fares for transfers between different agencies. For example: riders with ticket A on agency#1 can transfer for free to agency#2. This is based on this proposal by Transit.

This requires adding two fields to fare_leg_rules.txt and fare_transfer_rules:

• filter_fare_product_id: Indicates that this rule is in effect if a fare product is being used
• transfer_only: Indicates that this rule is only considered if the rider transfers to this leg. This rule will not be considered if it matches the first leg of a rider's journey.

To keep this issue short, please refer to the proposal hyperlinked above for information on the files and fields in this proposal as well as an example.

It seems that fare_leg_rules.txt and fare_transfer_rules.txt cannot represent a use case where a certain leg cannot be travelled unless a previous condition has been met (in the example in the above proposal, a rider has travelled on the Goatville express).

• Without the field fare_leg_rules.transfer_only, it is not possible to represent the fact that riders cannot travel on the Marmottown local using their Goatville express ticket unless they travelled on the Goatville express.
• Without the field fare_transfer_rules.filter_fare_product_id, it is not possible to represent the fact that riders need to have a valid fare for the Goatville express to travel on the Marmottown local.

The only action item would be to agree on the definitions and presence of filter_fare_product_id and transfer_only as well as the Primary Keys for fare_leg_rules.txt and fare_transfer_rules.txt.

fare_leg_rules.txt: transfer_only (enum, Optional): changed from bool to enum from the proposal)

• 1: This rule may only be considered if there is a matching fare transfer rule from the preceding leg to the current leg. A rule with transfer_only=1 can never match the first leg of a journey.
• 0 or unspecified: This rule may be considered regardless of whether any transfer rules apply.

fare_transfer_rules.txt: filter_fare_product_id (ID referencing fare_products.fare_product_id, Optional):

• Identifies a valid and active fare product that a rider needs to be eligible for this transfer.

transfer_only needs to be added to the Primary Keys for fare_leg_rules.txt. filter_fare_product_id needs to be added to the Primary Keys for fare_transfer_rules.txt.

We are happy to open a pull request for this issue if we can get consensus.

[omar-kabbani]

@npaun @irees

Since you both +1'd this proposal and we have a public dataset which uses the field transfer_only - are we okay to open a pull request?

Dataset here: https://511.org/open-data/transit

[davidlewis-ito]

Personally I think there is a broader need to prescribe the allowable order of a series of transfers.

There have been a few historic discussions on this topic with differing approaches. We have been considering extending the fare_transfer_rules.txt to provide an optional "output" field - transfer_leg_group_id. This is intended to be used to match against from_leg_group_id for examination of the table for the next journey leg. This new field acts to retain the state of transfers already applied.

We think this allows us model both the kind of example referenced in the above proposal, as well as supporting the myriad of special fare transfer arrangements that we see in cities around the globe.

We can also use this record of state to prevent two rules interacting together in ways which are not intended. Consider a city where one may transfers free from bus to subway, or alternatively from subway to bus. However, one may not transfer more than once - ie not free bus -> subway -> bus -> subway (etc..)

fare_transfer_rules : from_leg_group_id,to_leg_group_id,fare_transfer_type,transfer_count, fare_product_id. transfer_leg_group_id bus, subway, 0, 1, freetransfer, bustosubway subway, bus, 0, 1, freetransfer, subwaytobus

Because bustosubway and subwaytobus do not exist in from_leg_group_id only one transfer can be matched, which is as intended.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.