Context

rider_categories.txt is a key component of the GTFS Fares-v2 proposal and a primary key of fare_product.txt.
Example: flat fare but free for children (STS, Sherbrooke, Canada)

There are still questions about the rider_category.txt table fields, but we believe the rider_category_id field in fare_products.txt is stable. It could take months before we adopt Rider Categories in GTFS, based on the priorities list we've defined with the community.

Proposition

Adopt fare_products.rider_category_id right now, and adopt rider_categories.txt in a further iteration.
rider_category_id is currently produced at least by:

• Interline (source)
• San Diego Metropolitan Transit System (dataset)
• Maryland DOT (source)
• Cal-ITP (50+ agencies)

... and consumed by Open Trip Planner (cc @leonardehrenfried to confirm).

Advantages

It might sound like it doesn't add much value to add this field alone without further information about what the rider category is, but there are still some pros:

1. Make the fare_products.txt design more clear (see Improve definition of Fare Products #367 for more context).
2. Increase the "usefulness" of the adopted portion of Fares v2, make producers aware that it exists and this is the way to represent it.
3. Mitigate the risk of ending up with this type of data that would need to be updated when we adopt Rider Categories. This is not technically invalid data, but it's not how the fare_products.txt was designed and forces to have duplication that could be avoided in fare_leg_rules.txt.

Alternatives considered

Adopt Rider Categories all at once.

I'd like to have general thoughts there; if we collectively think this is useful, I can open a PR for this.