Uniqueness of fare_product_id

[omar-kabbani]

Uniqueness of fare_product_id

This GitHub issue was raised in response to a discussion in https://github.com/google/transit/pull/286, and has been prioritized by MobilityData, who is going to work on it with the agenda described below. MobilityData is trying this format to resolve open issues with GTFS extensions - if you have any feedback regarding this format, please reach out to specifications@mobilitydata.org.

The need

A clear way to model how fare products work for different rider categories (for example: the cost of the same one way ticket, but for adults, seniors, students, etc.).

The issue

No agreement on how this is modeled in fare_products.txt.

Potential options

• Option 1: Make the field fare_products.fare_product_id unique - so the same fare_product_id cannot be used in more than one record. For this, a different fare_product_id is required for each instance. For example:

fare_product_id	rider_category	amount	currency
one_way_ticket_adult	adult	3	CAD
one_way_ticket_senior	senior	2.5	CAD

• Option 2: Make the field fare_products.fare_product_id not unique - so that the same fare_product_id can be used in more than one record. For this, one fare_product_id is required per fare product, however, multiple records with the same fare_product_id define the different costs for different rider categories. For example:

fare_product_id	rider_category	amount	currency
one_way_ticket	adult	3	CAD
one_way_ticket	senior	2.5	CAD

Recommendation:

Even though this will not directly affect the base implementation of GTFS-Fares v2, this affects the future modeling of fare_products.txt. MobilityData recommends Option 2. This serves the following benefits:

• Keeps the data lighter by only requiring one fare_product_id per fare product
• Keeps fare_leg_rules.txt significantly lighter by only requiring one record to define a leg with one fare_product_id instead of multiple records; each with a different fare_product_id
• Provides the flexibility to enable data producers to produce data with unique fare_products.fare_product_ids if needed and express the fare legs explicitly in fare_leg_rules.txt

[drewda]

@omar-kabbani, thanks for writing this up.

Interline is in agreement that Option 2 is preferable. It is necessary for us to model complex fares with various types of transfer discounts here in the SF Bay Area.

//cc @jewel1965

[davidlewis-ito]

Putting aside for a moment the choice between the two options, there seems to the implication that the rider_category has been moved from the fare_leg_rules table to this product table.

The fare purchased by a traveller can be thought of as being "discriminated" by a number of separate factors including:

• the journey taken
• the user class / rider category
• the product being purchased (single, return, period pass, contactless, paper ticket)
• the time of day / day of week

Are we heading towards the fare_leg_rules table performing only the function of the journey discrimination (combined with transfers of course) and the product table providing a means to cover the other discriminating factors (user class, products, times, etc.) ?

[omar-kabbani]

Hi @davidlewis-ito Yes - if we were to proceed, then fare_leg_rules.txt contains records that outline travel, for example:

• Origin
• Destination
• The network
• Which fare product is required to travel

The other details will be represented in fare_products.txt, for example:

• Cost of the fare product
• The rider category eligible for travel on this leg using this fare product ( ⚠️ rider categories are out of scope for the base implementation - I just gave it as an example)

[omar-kabbani]

Summary of roundtable discussions on the uniqueness of fare_product_id

(26 April 2022 at 11 AM ET)

Attended by @omar-kabbani, @michellenguyenta, @jsteelz, @npaun, @timMillet, @irees, @flocsy

---

During the discussion, it was agreed to proceed with Option 2 presented in the first message on this issue.