Codecov Report

❌ Patch coverage is 96.22642% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.16%. Comparing base (9aa668b) to head (106cdf9).
⚠️ Report is 1 commits behind head on dev-2.x.

@@              Coverage Diff              @@
##             dev-2.x    #7139      +/-   ##
=============================================
+ Coverage      72.12%   72.16%   +0.03%     
- Complexity     20837    20884      +47     
=============================================
  Files           2268     2273       +5     
  Lines          84338    84470     +132     
  Branches        8415     8424       +9     
=============================================
+ Hits           60827    60955     +128     
- Misses         20538    20542       +4     
  Partials        2973     2973              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I was trying to set up a "free fare Sunday afternoons for cash customers" rule but was not able to make it work smoothly. I'm attaching excerpts below. Basically, in order to override the regular cash fare that would normally apply, I have to populate rule_priority, however, right now, applying rule_priority hides other fare products, unless the corresponding fare leg rules also have the same priority value.

In trying to make fare products appear in the trip response, I also found an issue where leg rules with the default timeframe_regular timeframe were skipped altogether, and that needs to be fixed as well.

Happy to discuss further during the dev call.

Relevant GTFS data:

timeframes.txt (fare_regular is a calendar entry that applies 7 days, FallSunday only applies Sundays)

timeframe_group_id,start_time,end_time,service_id
timeframe_regular,,,fare_regular
timeframe_free_sundays_afternoons,12:00:00,18:00:00,FallSunday

fare_products.txt

fare_product_id,fare_product_name,fare_media_id,amount,currency
prod_free_fare_sundays_afternoons_cash,Free fare Sundays Afternoons Cash,cash,0.00,USD
prod_rapid_transit_cash,Subway cash fare,cash,2.40,USD
prod_rapid_transit_quick_subway,Subway Quick Ticket,charlieticket,2.40,USD

fare_leg_rules.txt (without priorities)

leg_group_id,network_id,from_area_id,to_area_id,fare_product_id,from_timeframe_group_id,to_timeframe_group_id,transfer_only
leg_rapid_transit_cash,rapid_transit,,,prod_rapid_transit_cash,,,1
leg_rapid_transit_cash,rapid_transit,,,prod_free_fare_sundays_afternoons_cash,timeframe_free_sundays_afternoons,,1
leg_rapid_transit_quick_subway,rapid_transit,area_bl,,prod_rapid_transit_quick_subway,,

I wrote some tests today to make sure, but I believe that this is how the priorities are supposed to work.

So lets say you have three rules (I'm condensing the entities for brevity):

• Rule 1: Sundays from 12:00-18:00, regular, priority 2
• Rule 2: Every day from 00:00-23:59, regular, priority 1
• Rule 3: Every day from 00:00-23:59, youth, priority 1

If rule 1 matches, then both rule 2 and 3 will be excluded. Is this what you made you scratch your head?

If so then I believe that this is the correct behaviour, according to the spec: https://gtfs.org/documentation/schedule/reference/#fare_leg_rulestxt

In particular:

rule_priority: Defines the order of priority in which matching rules are applied to legs, allowing certain rules to take precedence over others. When multiple entries in fare_leg_rules.txt match, the rule or set of rules with the highest value for rule_priority will be selected.
An empty value for rule_priority is treated as zero.

So I believe that you need to increase the rule priority of rule 3 to 2, if you want both 1 and 3 to show up on Sundays.

Let's discuss this because I do think it's a little surprising how this works.

So lets say you have three rules (I'm condensing the entities for brevity):

* Rule 1: Sundays from 12:00-18:00, regular, priority 2

* Rule 2: Every day from 00:00-23:59, regular, priority 1

* Rule 3: Every day from 00:00-23:59, youth, priority 1

If rule 1 matches, then both rule 2 and 3 will be excluded. Is this what you made you scratch your head?

Yes, because in this example, I don't think the youth fare should not be affected by what is happening to the regular fare.

rule_priority: Defines the order of priority in which matching rules are applied to legs, allowing certain rules to take precedence over others. When multiple entries in fare_leg_rules.txt match, the rule or set of rules with the highest value for rule_priority will be selected.
An empty value for rule_priority is treated as zero.

The spec is indeed vague about this. How I interpreted was "When multiple entries in the same leg_group_id in fare_leg_rules.txt match" (emphasis mine), because it makes sense to not mess with unrelated rules, but that's up for debate.

@binh-dam-ibigroup I'm currently asking about this in the MobilityData Slack: https://mobilitydata-io.slack.com/archives/C01KL7PR170/p1766060365033259

@binh-dam-ibigroup I don't think that we will get a definitive answer on our spec question. I believe the best way forward is to come up with our own definition and then remain flexible should the spec become clearer.

Binh and I had a private chat and we came to conclusion that we will keep the current rule priority logic as is. We are aware that the spec is not precise enough and you could definitely produce conflicting data when combining priorities and timeframes.

However, CTRAN, the only feed that we know of that produces timeframes, handles this problem by producing non-overlapping timeframes. We might have to revisit this when we see this problem re-appear in real-world data.

Binh and I had a private chat and we came to conclusion that we will keep the current rule priority logic as is. We are aware that the spec is not precise enough and you could definitely produce conflicting data when combining priorities and timeframes.

However, CTRAN, the only feed that we know of that produces timeframes, handles this problem by producing non-overlapping timeframes. We might have to revisit this when we see this problem re-appear in real-world data.

After our discussion, it should be noted that in order for the timeframe_free_sundays_afternoons Sundays rule to hide the regular cash fare in the example I provided, timeframes for the other Sunday hours must be provided, and those other timeframes must be also referenced in fare_leg_rules.txt. Leg rules that don't have timeframes listed will always apply.

timeframes.txt:

timeframe_group_id,start_time,end_time,service_id
timeframe_regular,00:00:00,11:59:59,FallSunday
timeframe_free_sundays_afternoons,12:00:00,18:00:00,FallSunday
timeframe_regular,18:00:01,23:59:59,FallSunday

fare_leg_rules.txt:

leg_group_id,network_id,from_area_id,to_area_id,fare_product_id,from_timeframe_group_id,to_timeframe_group_id,transfer_only
leg_rapid_transit_cash,rapid_transit,,,prod_rapid_transit_cash,timeframe_regular,,1
leg_rapid_transit_cash,rapid_transit,,,prod_free_fare_sundays_afternoons_cash,timeframe_free_sundays_afternoons,,1
leg_rapid_transit_quick_subway,rapid_transit,,,prod_rapid_transit_quick_subway,,