You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fares can be quite complex. This page illustrates examples of how to specify them.
Single leg, no transfer, flat fare
The example below illustrates how the fare for a single leg transit trip using a service
that has flat fare system. First fare_rules.txt is queried on route_id, origin_id &
destination_id to return it’s fare_id. In this case, the origin and destination zones have a value of None,
which represents cases where stops are never used in a zonal fee
structure. Then, fare_periods_ft.txt is queried on fare_id and the time of departure (>= to
start_time, <= end_time) to return fare_period. Finally, fare_attributes_ft.txt is queried
on fare_period, and the cost of the fare is returned by the price field.
To capture the cost of this scenario, the cost of each leg is calculated using the same
method proposed for a single leg trip. We then use the fromfare_period and the tofare_period to get the transfer_fare_type, which has three possible values: transfer_cost, transfer_discount, or transfer_free. The transfer is free if the value of this field is transfer_free. If transfer_discount, the amount in the transfer_fare field is subtracted from the the full cost of the fare of the to leg. If transfer_cost, the full amount of the transfer_fare field is the cost of the transfer.
Multiple Transfers
A second transfer would work in a similar fashion, however, it is possible (unlikely ?) that the fare would have to be calculated using the fromfare_period for both the first and second leg to determine which transfer_rule to use. For example, a rider uses the same fare_period in the first and third leg of a three leg trip. This fare_period is entitled to a free transfer (transfer_fare_type = transfer_free) when staying with the same fare_period during a transfer (e.g. a metro bus to metro bus transfer). Assuming the transfer has not expired (and this scenario is permitted), the rider is eligible for a free transfer based on the fare_period associated with the first leg of the trip, even if there is a transfer cost associated with the second and third leg.
Systemwide Fare
The following two-leg (one transfer) trip demonstrates how a system-wide fare would be
calculated using Pierce Transit as an example. First, fare_rules.txt is queried on the
route_id, origin_id and destination_id of the first leg to return its fare_id. In
this case, the origin and destination have zones but are the same because these stops need
zones for Sound Transit, our regional express bus service. Then fare_periods_ft.txt is
queried on fare_id and the time of departure (>= to start_time, <= end_time) to return
fare_period. Next, fare_attributes_ft.txt is queried on fare_period, and the cost of the fare
is returned by the price field.
The next step is to determine the transfer rule for this particular transfer. We use the
route_id of the second leg to get the fare_id which, along with departure time, is used
to get fare_period from fare_periods_ft.txt. The from_fare_period and the to_fare_period are used
to get tranfer_fare_type and transfer_far from fare_transfer_rules_ft.txt. In this case transfer_fare_type is transfer_free indicating that there is no fee for the second leg of this trip.
The following illustrates how an inter-agency fare (one transfer, two different fare classes) would be calculated. First, fare_rules.txt is queried on the route_id, origin_id and destination_id of the first leg to return its fare_id. Then fare_periods_ft.txt is queried on fare_id and the time of departure (>= to start_time, <= end_time) to return fare_period. Next, fare_attributes_ft.txt is queried on fare_period, and the cost of the fare is returned by the price field.
The next step is to determine the transfer rule for this particular transfer. We use the route_id of the second leg to get the fare_id which can then be used to get fare_period. We then get the rule that applies to this transfer, which is returned by querying fare_transfer_rules_ft.txt on from_fare_period and to_fare_period. In this case, the field transfer_fare_type in the returned record is transfer_cost, indicating the amount in the transfer_fare field is the cost of the transfer.
Origin-destination based fares are common on heavy rail systems, such as BART. They are
a special case of zone-based fares, where every station has its own zone, and could be
specified as follows.