G-factor Speed Calculation Model QC

[thehanggit]

This issue follows on #386 to check generated speed data quality for the clearinghouse model int_clearninghouse__detector_g_factor_based_speed.

The goal is to ensure that the developed speed algorithm aligns with the current PeMS system to some extent.

[thehanggit]

The hourly average speed performance comparison between my output and current PeMS system on GP lane is shown below. (HOV lane data is sparse) The findings are listed below

1. The speed calculation is purely based on normalized flow values volume_sum and occupancy_avg. If there is no data for the two columns, speed would consider as null. I assume if the detector is not working, there will be no values for both. In that case, would it be more accurate than using detector status as Boolean values to filter out the data?
2. Overall, it is more diverse with relatively high variance than the current PeMS's speed. Not too worry about this difference since PeMS speed is post-processed. We will continue speed QC after smoothing through the imputation model.
3. For each lane, I set up an upper bound to avoid outliers as PeMS did after diving into their datasets. We can talk about this settings to determine whether it should be included in this model or not.
4. The average speed for lane 3-6 is slightly higher than PeMS speed. Not sure what happened and may need your feedbacks.

[jkarpen]

Next steps on this: @thehanggit to do additional analysis/comparisons, but waiting on comparison data to be brought over from the old PeMS system. Per @pingpingxiu-DOT-ca-gov that data should come early next week.