Aggregating Metrics on the Operator Grain

[amandaha8]

• Calculating some of the metrics on the operator grain starting from vp_trip_metrics.
• Incorporated changes into scripts/MAKEFILE.
• Using this new dataset to create the charts within the GTFS Digest portfolio.

[github-actions]

nbviewer URLs for impacted notebooks:

• gtfs_digest/03_report.ipynb
• gtfs_digest/33_agg_by_agency_portfolio.ipynb
• gtfs_digest/35_agg_by_agency2.ipynb
• rt_scheduled_v_ran/11_agency_agg.ipynb
• rt_scheduled_v_ran/12_agency_agg2.ipynb

[tiffanychu90]

Can you make a follow-up PR that handles this:

In gtfs_analytics_data.yml: there are a lot many operator grains being created in merge_operator_data.py.

operator_metrics should be not be a 3rd one added, it should belong in one of the first 2.

 operator_profiles: "digest/operator_profiles"
 operator_sched_rt: "digest/operator_schedule_rt_category"
 operator_metrics: "digest/operator_metrics"

These can be consolidated in merge_operator_data.py. It should follow the pattern in merge_data.py, where these are the steps:

1. concatenate_schedule_by_route_direction (grab all dates for schedule by route-dir grain)
2. concatenate_speeds_by_route_direction (grab all dates for speeds by route-dir grain)
3. concatenate_rt_vs_schedule_by_route_direction (grab all dates for rt vs schedule by route-dir grain)
4. concatenate_crosswalk_organization (grab all dates for crosswalk by operator)
5. merge_data_sources_by_route_direction (this is essentially a 1:1 merge of [1, 2, 3] and a m:1 merge to [4].

In your follow-up PR, the operator grain should replicate the relevant portions of that. The operator files in gtfs_analytics_data.yml should only show unique grains.

• operator_profiles (operator grain)
• operator_metrics (operator grain, should be worked into profiles)
• operator_sched_rt_category (check the grain, it might be able to be worked into the above too)
• operator_routes_map (operator-route grain)