What's new? | Help | Directory | Sign in
Google
                
Search
for
Updated May 15, 2008 by naomi.bilodeau
Labels: Featured
FareExamples  
Illustrates how to implement different fare structures with the GTFS

Introduction

The fare_attributes.txt and fare_rules.txt files in the Google Transit Feed Specification can be confusing. The following examples work through different kinds of fare structures and show how to represent them in a Google transit feed.

Fare Examples


Example 1: All trips have the same fare, unlimited transfers

Suppose Demo Transit Agency has the following fare structure:

Since all trips have the same fare, Demo Transit can omit fare_rules.txt.

fare_attributes.txt

fare_id price currency_type payment_method transfers
only_fare 1.00 USD 0

Calculating an adult fare

The trip planner calculates a fare of $1 for each leg of the itinerary that includes a change of vehicle. However, unlimited transfers are permitted, so the trip planner only displays the lowest charge. Adult fare: $1


Example 2: All trips have the same fare, no transfers

Suppose Demo Transit Agency has the following fare structure:

Since all trips have the same fare, Demo Transit can omit fare_rules.txt.

fare_attributes.txt

fare_id price currency_type payment_method transfers
only_fare 1.00 USD 0 0

Calculating an adult fare

The trip planner calculates a fare of $1 for each leg of the itinerary that includes a change of vehicle. So an itinerary that requires a change of buses would be $2.


Example 3: All trips have the same fare, transfers allowed

Suppose Demo Transit Agency has the following fare structure:

Since all trips have the same fare, Demo Transit can omit fare_rules.txt.

fare_attributes.txt

fare_id price currency_type payment_method transfers transfer_duration
only_fare 1.00 USD 0 5400

Calculating an adult fare

The trip planner calculates a fare of $1 for each leg of the itinerary that includes a change of vehicle. Then it calculates the time for the itinerary. If the itinerary time is less than 90 minutes, the fare is $1.


Example 4: Different pricing for local and express routes

Suppose Demo Transit Agency has the following fare structure:

Since some trips cost more than others, Demo Transit must include fare_rules.txt, and each route must have an entry to associate it with a fare.

fare_attributes.txt

fare_id price currency_type payment_method transfers
local_fare 1.75 USD 0 0
express_fare 5.00 USD 0 0

fare_rules.txt

fare_id route_id
local_fare Route_1
express_fare Route_2
express_fare Route_3

Calculating an adult fare

The $5.00 fare is only applicable if you ride routes 2 or 3. The $1.75 fare only applies on route 1. If an itinerary uses routes 1 and 2, the fare is $6.75.


Example 5: Buying a transfer increases the fare

Suppose Demo Transit Agency has the following fare structure:

Since these rules apply to all trips, Demo Transit can omit fare_rules.txt.

fare_attributes.txt

fare_id price currency_type payment_method transfers transfer_duration
simple_fare 1.75 USD 0 0
plustransfer_fare 2.00 USD 0 5400

Calculating an adult fare

Technically, both fares apply on itinerary that has no transfers. However, the trip planner always chooses the least expensive applicable fare:


Example 6: Fare depends on station pairs, how you get there doesn't matter

In this example only the entry and exit points from the system matter.

To define this fare structure for the feed, each station must have its own unique zone ID defined in stops.txt. Each station is considered a single zone.

fare_attributes.txt

fare_id price currency_type payment_method transfers
S1_to_S2 1.75 USD 0
S1_to_S3 3.25 USD 0
S1_to_S4 4.55 USD 0
...
S10_to_S1 5.65 USD 0

fare_rules.txt

fare_id origin_id destination_id
S1_to_S2 S1 S2
S1_to_S3 S1 S3
S1_to_S4 S1 S4
...
S10_to_S1 S10 S1

Calculating an adult fare

The trip planner calculates an itinerary, and then looks up the fare rules until it finds a matching origin/destination station pair.

The public feed from SF Bay Area BART provides a real-world illustration of this type of fare structure.


Example 7: Fare depends on zones

Suppose Demo Transit Agency has a concentric three-zone system, where fares depend on which zones a rider passes through during an itinerary.

To define this fare structure for the feed, fare_attributes.txt and fare_rules.txt must contain a line for each possible combination of zones. For very complex cross-zone fare structures, it may be simpler to programmatically output fare_rules.txt using origin and destination to define fares.

fare_attributes.txt

fare_id price currency_type payment_method transfers
F1 4.15 USD 0
F2 2.20 USD 0
F3 2.20 USD 0
F4 2.95 USD 0
F5 1.25 USD 0
F6 1.95 USD 0
F7 1.95 USD 0

fare_rules.txt

fare_id contains_id
F1 1
F1 2
F1 3
F2 1
F2 2
F3 1
F3 3
F4 2
F4 3
F5 1
F6 2
F7 3

Calculating an adult fare

Let's look more closely at the definitions in fare_rules.txt.

The trip planner calculates an itinerary, and then looks up the fare rules to determine the fares that apply based on zone. Since F1 also includes travel in zone 1, only F4 ($2.95) applies to a trip from zone 2 to zone 3.

A fare rule only applies when the set of zones passed through in an itinerary exactly matches the set specified by the fare rule. For a trip between zones 2 and 3, the trip planner reports $2.95 as the adult fare.

The public feed from Portland TriMet provides a real-world illustration of this type of fare structure.


Sign in to add a comment