Uniqueness of fare_product_id

This GitHub issue was raised in response to a discussion in #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:

• 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:

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