Filtering fare_products to agency

[RideSchedules]

Hello,

I am wondering what people contemplated about how to narrow version 2 fares to a single agency in agency.txt?

The GTFS specification allows for multiple agencies per .zip file, but agency_id is not an attribute in fares v2. Multiple agencies in the same file set, often completely unrelated, is common.

It does appear to be possible, but it would require networks.txt and route_networks.txt to map route_id to agency_id in routes.txt, which in turn would require a dependency on fare_leg_rules.txt.

I don't see a problem with that other than it is not obvious and prone to error if the required multiple mappings are not present.

A simple solution would be to include specific instructions in Best Practices or Data examples in the documentation area on how to a limit fare products to a single agency in a multi-agency file set.

With the specific instructions in the documentation, we could then rely on route_networks.txt and fare_leg_rules.txt to avoid publishing fare products for the wrong agency.

In practical terms, the inability to narrow fares to a specific agency is a big hole in the current Fares v2 scheme.

[skalexch]

@RideSchedules there have been attempts to include mechanisms that would limit fare products, mainly fare product/fare media behaviour.

Currently, there is no direct attribute that would filter fares by agency only. What I can think of is the following:

• Since route_id is the primary key in routes.txt, no two routes will have the same route_id.
• Starting from there, we can 1) map routes to networks using networks.txt and route_networks.txt, making sure to put routes from different agencies in different networks, then 2) associating each fare product with fare leg rules that are only relevant to the network, and finally 3) making sure that transfer rules are only defined for legs of the same networks under that agency.

In all cases, there always is a dependence on fare_leg_rules.txt, as it is a central file to Fares v2, linking everything together.

The Fares Implementation Guide is a good resource for how to define these fares. We can also improve the spec examples at some point.

[RideSchedules]

How about this?

fare_leg_rules..network_id conditionally required if fare_product_id references a fare product not accepted by all agency..agency_ids.

routes.network_id conditionally required if fare_leg_rules includes a fare_product_id for a product not accepted by all agency.agency_ids.

What is the need to require networks.txt and route_networks.txt?

[skalexch]

@RideSchedules that is a nice proposal to add to the spec.

For the requirement of networks.txt and route_networks.txt, they are just the same as routes.network_id but more put together for the context of Fares, we actually recommend it more.

So the rules could become:

"fare_leg_rules..network_id conditionally required if fare_product_id references a fare product not accepted by all agency..agency_ids.

routes.network_id or both networks.txt and route_networks.txt conditionally required if fare_leg_rules includes a fare_product_id for a product not accepted by all agency.agency_ids."

If you like, you can start a GitHub issue for this topic and see how the community reacts. Which will eventually lead to a proposal.