Add fare containers

[omar-kabbani]

Hi everyone,

 MobilityData is moving forward with the second iteration of GTFS-Fares v2, for more information about the overall plan, you can check this issue.

This pull request covers Fare Containers, which is a section of the entire GTFS-Fares v2 proposal.

Fare containers correspond to cards or mobile applications that are used to load and use fares. In many cases, fares loaded on a fare container are cheaper than fares purchased as individual tickets outside a fare container.

The changes in this pull request are:

• Add new file; fare_containers.txt, to define new fare containers.
• Extend fare_products.txt with fare_container_id to assign fare products to fare containers and to define the price of a fare if a fare container is used to pay.

The behaviour of fare_leg_rules.txt and fare_transfer_rules.txt is unchanged as the cost of a fare leg or a transfer is tied to a fare product. The modelling of the cost of a one-way ticket purchased as a ticket vs. loaded on a fare container factors in fare_products.txt.

Here's a quick example:

• A fare container costs 5 CAD.
• A fare is 3 CAD, however, if riders load the fare on their fare container and pay with it, a fare is 2.95 CAD.
• Riders can transfer once - in a period of one hour - if they do not have a fare container, they will pay 0.05 CAD to transfer, however, if they transfer using their fare container, the transfer is free.

Define a fare container in fare_containers.txt

fare_container_id	amount	currency
container	5	CAD

Define the fare structure (paying for a fare with and without the fare container) in fare_products.txt

fare_product_id	fare_container_id	amount	currency
single_leg		3	CAD
single_leg	container	2.95	CAD
transfer_cost		0.05	CAD
transfer_cost	container	0	CAD

Define fare legs using fare_leg_rules.txt

leg_group_id	from_area_id	to_area_id	network_id	fare_product_id
leg1	zoneA	zoneB	bus	single_leg

Define transfer rules using fare_transfer_rules.txt

from_leg_group_id	to_leg_group_id	transfer_count	duration_limit	duration_limit_type	fare_transfer_type	fare_product_id
leg1	leg1	1	3600	0	0	transfer_cost

Data consumer: Apple
Data producer:

 Interline

Please go through the changes and share your thoughts here!
Looking forward to feedback and contribution on this proposal.

For other questions/concerns, don’t hesitate to reach out to specifications@mobilitydata.org.

[flocsy]

1. I think the following sentence is missleading: "File fare_containers.txt describes fare containers that are not represented in fare_attributes.txt and fare_rules.txt" This is basically the same that is already explained in another place under Versions where it explains which files belong to V1 vs V2.

2. It's unclear what's the difference between fare_container.amout and minimal_initial_purchase. Maybe I'm not familiar with this use case, but to me minimum_initial_purchase sounds unnecessary. If you think otherwise, please give some explanation with example.

3. To me it sounds that we're mixing a few things here: container (i.e: physical card) vs credit (i.e: amount I can load onto the card) vs fare product that represents a (probably discounted) fare that I can pay using the fare container. Let's say in a certain agency you can make a magnetic card (it might cost some amount or be free). And for this example let's say there are the following 3 "purchases" you can do to charge/load money on the magnetic card:

• credit $5 (costs $4.50)
• credit $10 (costs $8)
• credit $25 (costs $18)

So I can have the empty magnetic card, and charge it with $5 credit by paying $4.50. Then I can use it to pay a fare that costs $3. So the balance of my card (fare container) then becomes $2. I can't buy the next card (because it costs more than $2), so before I do my next trip I need to charge it. Let's say I charge it with $10 (by paying only $8) and now my balance becomes $12....

Anyway there are some things that I am missing in the proposal:

a. A way to represent the different options I have to charge the card (that preferrably has the credit I get (i.e: $10) and the amount I pay (i.e: $8)). I think that these options could be probably listed somehow (with some additional field(s) in fare_products.txt

vs

b. A way to represent the fare prices I pay when I use the container (this is actually in the proposal, I just list it here so we see it's different from the amount I need to pay when I charge the card)

[npaun]

The primary key of fare_products.txt needs to be updated from (fare_product_id) to (fare_product_id, fare_container_id) to match the description of the proposal.

[davidlewis-ito]

I wonder whether there is appetite to re-think containers and take a broader look at "payment types".

We see a strong need to be able to discriminate fares by the method of purchase and payment. As an example, take TfL London which has different prices and terms for :
-a paper ticket purchased at the station (with cash or card)
-use of a pre-paid oyster card (a true "container")
-use of a contactless bank card

Further complicating matters are reduced rate fares for children etc which require the rider to have a specific child oyster card - which becomes proof of entitlement to the reduced fare.

It is very tempting to use the container to differentiate these cases but clearly this is not the current specifications intention.

With many agencies such as TfL implementing contactless payments it seems to me to be worthwhile to consider a broader remit for containers.

[flocsy]

as always I am for rethinking :)

[omar-kabbani]

Thanks all for the feedback - this is what we propose to move forward:

@flocsy

1. This is the same wording we used for fare_leg_rules.txt, fare_transfer_rules.txt, and fare_products.txt to clearly separate the files that correspond to Fares v1 from those of Fares v2. Until we can deprecate Fares v1, it is important to have these notices.
2. Absolutely! amount corresponds to the cost of the fare container only. Some agencies require that a card must be loaded with some money when purchased. This is what minimal_initial_purchase describes (it is an optional field). For example, in Toronto, the PRESTO card is the fare container for agencies in the city. The card cost 6 CAD, and if purchased from a ticketing machine, it must be loaded with at least 5 CAD (source). That would be described as amount=6.00, currency=CAD, and minimal_initial_purchase=5.00. Hence riders wishing to purchase a new PRESTO card are expected to pay 11 CAD.
3. The scope of this pull request is:

• Defining fare containers (name, cost, initial purchase).
• Describing trip costs if a fare container is used to pay (in comparison to using cash or tickets).
  This does not cover credit, how much money is loaded into a card, tracking how much money is in a rider's card as they use it and refill it, and purchasing credit. What you are describing is important, but not in the scope of this particular pull request.

@npaun
Noted - will do

@davidlewis-ito, there is a broader proposal titled GTFS-TravelRules, which contains the file travel_rules.txt which contains the field payment_method, which has enumerations for coins, exact cash, cash with change, bank card, contactless bank card NFC, and mobile wallet. Does this cover the use cases you are describing?

[flocsy]

So this proposal is kind of useless alone (if I can't re-charge the container). I mean it kind of gives me a one-time throw-away container and even that is only the cheapest possible option.

The GTFS-TravelRules just make everything even more complicated... It also contradicts the example you gave in the proposal: from the proposal it looks to me that a producer would be able to tell that a certain ride either costs $4 if paid using a container or $5 otherwise by only using the files we already have + fare_containers.txt. However after looking at GTFS-TravelRules it's not clear if this is even the intention, or even the simplest cases would need the travel_rules.txt?

[bdferris-v2]

Is the Interline MTC Regional feed the one we should be looking at as a Data producer example?

[bdferris-v2]

I'll also echo @flocsy 's comment that the semantics of fare container amount and minimal_initial_purchase aren't super obvious from the field names and the field descriptions as-written only sort of help.

[irees]

@bdferris-v2 Interline is in the process of updating MTC data - we're still producing a slightly older version of the spec. Our new implementation of adopted fares v2 + containers should be available shortly, I will update this thread when it is.

[omar-kabbani]

Hey everyone - just a reminder that MobilityData is hosting a roundtable discussion on Thursday 25 August at 11:00 AM ET to discuss the outstanding items regarding fare containers. If you would like to attend, please react to this message or send an email to specifications@mobilitydata.org and we will send you the invite.

For a summary and more details, please check out this post.

[omar-kabbani]

Summary of roundtable discussion on fare containers:

August 25 11:00 AM ET

Attended by: @Cristhian-HA, @omar-kabbani, @e-lo, and Chris Erickson (Trillium).

Scope of this extension

• It was discussed that the scope is twofold
  • To define the fare containers that an agency accepts
  • To describe the fares if riders pay using their fare containers (vs. tickets not loaded on a fare container)
• The scope does not include any functionalities that pertain to tracking when riders recharge or use up their fare containers.

Fare container type

• It was suggested to extend fare_containers.txt with a field called fare_container_type that defines whether the container is a physical card, a mobile app, or both.

Payment options

• Currently, payment methods are described in travel_rules.txt, which describe how riders can pay for a trip (coins, exact cash, cash with change, bank card, contactless bank card NFC, and/or mobile wallet). However, travel_rules.txt is outside the scope of this pull request.
• It was discussed during the call that travel_rules.payment_method could be moved to fare_products.txt, to provide information on how can riders can pay for the fare products.

Fare container cost

• The field name amount does not seem intuitive to describe the cost to purchase the fare container.

[omar-kabbani]

Hey everybody, I will close this pull request since I will be leaving MobilityData and therefore I cannot remain the advocate for this proposal.

In order to preserve the conversation history, I will open an issue in google/transit and reference this pull request. Please continue the discussion here, and provide feedback on how to move forward with this proposal.

I also wanted to thank you all for your constant engagement in these GTFS extension proposals and for all the valuable feedback!

[isabelle-dr]

Opened PR #355 to continue the work on this proposal