# Detecting Traffic Incidents Using Persistence Diagrams
## 4 Results
### Data with Sensor Locations  
In Phase 2 we were given the locations of the sensors in terms of latitude and longitude. Tables 10 and 11 display the nine incidents reported in Phase 2-Train and the largest percentile recorded for each summary statistic in windows starting within half an hour of the starting time of each incident at the sensor where the incident was reported. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Incident Timestamp** & **Percentile by Avg** & **Percentile by SD** & **Percentile by Median** \\ \hline
06-Feb-2017 08:10 & 0.98538 & 0.96114 & 0.99159 \\
24-Jul-2017 12:12 & 0.61599 & 0.76042 & 0.73127 \\
29-Mar-2017 08:25 & 0.98438 & 0.98438 & 0.99319 \\
18-Jan-2017 14:23 & 0.99359 & 0.97716 & 0.89433 \\
15-Nov-2017 17:15 & 0.08974 & 0.86058 & 0.06971 \\
06-Apr-2017 20:34 & 0.84856 & 0.89423 & 0.84816 \\
16-Jun-2017 06:34 & 0.94124 & 0.97276 & 0.93884 \\
27-Jan-2017 20:34 & 0.91594 & 0.98883 & 0.79404 \\
07-Oct-2017 17:47 & 0.84491 & 0.84739 & 0.93145 \\ \hline \hline \end{tabular}
\end{table} 
Table 10: Percentiles of Phase 2-Train incidents when sorted by sensor, day of week, and time of day. Figure 4: ROC curves for 4 different anomaly scores: (**a**) uses average bottleneck distance percentile when sorted by day of week; \(\text{AUC}=0.72526\). (**b**) uses standard deviation bottleneck distance percentile when sorted by day of week; \(\text{AUC}=0.65658\). (**c**) uses median bottleneck distance percentile when sorted by day of week; \(\text{AUC}=0.71332\). (**d**) uses the standard normal deviations; \(\text{AUC}=0.66754\). Depending on the severity of the incident, it is possible that a traffic incident occurring near one sensor will cause some abnormal behavior in the counts of the adjacent sensors. For example, in the network of sensors used in the Phase 2-Train data, traffic flows directly from \(S314402\) to \(S318593\). A map of all the sensor locations in this data set is provided in Figure 1. If one of the lanes is obstructed near \(S318593\) it is likely to slow down traffic between the two sensors. This might cause the counts from \(S314402\) to look fairly large when compared to \(S318593\). On the other hand, if a motorist was able to anticipate this problem in the traffic a mile ahead, they might deviate their route before even passing \(S314402\). If enough cars did this, there would be a lower count at the first sensor, but the count at \(S318593\) might still be higher because of all the unfortunate cars that got caught between the sensors at the time of the incident. In either scenario, we would expect some unusual behavior when we compare the counts of both sensors together. Not knowing if the difference should be large or small, we apply the random bagging algorithm to the sequence of differences between the counts, with the intuition that if an incident occurred during a particular hour, especially one with lots of traffic, the mean bottleneck distance for that time window would also be large. We refer to the summary statistics obtained from this procedure as adjacency statistics. In Tables 12 and 13 we provide the highest rankings near the reported incidents based on the adjacency statistics. The most noticeable difference made by the adjacency statistics can be observed by the percentile of the July incident when windows are sorted by sensor, day of year, and time of day. The highest any window near that time ranks by average bottleneck distance of raw counts is in the 66 th percentile of _Mid Day_ counts for that day, but if we consider the differences in counts between the two adjacent sensors, we find the highest ranking _Mid Day_ window for July 24 th starts within half an hour of the July incident. With the addition of the adjacency statistics, we had 12 percentiles to consider for each window. Table 14 presents the 12 thresholds determined from the incidents in the data for Phase 2-Train.