Include service window in Summary report

[emmambd]

Describe the problem

Currently, the summary section of the validation report shares the feed_start_date and feed_end_date when it's provided. However, many feeds don't include feed_info.txt, which makes it difficult to know the service window at a glance.

Proposed solution

• Add majority service window section to the summary report: Calculation here

We find the max amount of trips per day (MAX_TPD), then find the first and last days that demonstrate more than 0.75 * MAX_TPD trips per day. That is the majority service window. This captures the date range when a significant number of trips are running, relative to the max number of trips on a single day in the feed. This helps detect when a single trip has caused a feed to appear "active" even though the bulk of service is no longer running.

• Include this description of how we calculate the majority service window as a tooltip.

Design considerations

• The summary report is getting busy (example here). How do we make sure this info fits and is intuitive?
• Is "majority service window" too jargon-y? How can we make what we mean by this clear to the user?

Alternatives you've considered

No response

Additional context

• Include both feed date range and service range
• In the future, calculate based on majority of dates
• Look at other validators' approach to calendar dates, e.g Google Partner Dashboard No response

[qcdyx]

Hello @emmambd I started evaluating this issue, could you add more use cases like when calendar.txt and calendar_dates.txt coexists, which one is preferred?

[emmambd]

In terms of how to display this in the validator, as a simple starting point I'd suggest:

Under Feed Info: • Service date range • Majority service window range with a tool tip to clarify what this is. E.g. "The date range when a significant number of trips are running. This helps detect when a single trip makes a feed appear "active" even though the bulk of service is no longer running."

[Alessandro100]

Focus on the Service date range. Majority service window later

Split ticket

1. Service date range
2. Majority service window
3. Add service date range to API
4. service date range 'expired' state

Tasks [] Calculate the service date range [] Unit test [] Add service date range for UI and JSON report [] Acceptance test review