predicting indicators of social inequality with highway...
TRANSCRIPT
Predicting Indicators of Social Inequality with Highway Data
Lynne Burks†∗ Mahalia Miller†∗ Daniel Wiesenthal‡∗Stanford University, Stanford, CA 94305 USA
†{lynne.burks, mahalia}@stanford.edu‡[email protected]
Abstract
Social inequality is an important contemporary issue, andthere is high demand for better information about its govern-ing dynamics. Indicators of social inequality may include un-employment, crime rates, number of welfare recipients, andnumber of homeless people receiving assistance. In this pa-per, we apply supervised learning methods to predict suchsocio-economic metrics. We train on data from a large net-work of highway sensors throughout the San Francisco BayArea —3,000 sensors gathering car speed and flow in eachhighway lane every 30 seconds for 10 years. To make use ofthis large amount of data, we develop a novel machine learn-ing system capable of efficiently working with large datasetsusing commodity hardware by leveraging a database backendand parallel cloud computing services. We use the machinelearning package, Weka, to train classification models. Ul-timately, we are able to predict with high accuracy severalsocio-economic indicators of social inequality using highwaytraffic data: percent of Californians on welfare, number ofCalifornians on food stamps, unemployment rates, and crimein Oakland.
IntroductionAn increasingly relevant and popular metric for the health ofa culture or community is the degree to which the populationexhibits social inequality. While concept of social inequal-ity is not well-defined, more familiar and concrete measure-ments of the population–such as unemployment and crimerates, or welfare and food stamp usage–are metrics which,in aggregate, can present a reasonably clear picture of thedisparities between different socio-economic strata (Jenkinsand Micklewright 2007). Unfortunately, these metrics aresometimes available only after a significant delay, at whichpoint the information is informative but not actionable. If itwere possible to access these metrics in real time, it mightbe feasible to proactively address problems before they fullyform–for example, by deploying more patrol cars to loca-tions that are likely to see an increase in crime rates.
Other metrics of a population are much more readilyavailable. For example, the State of California has a networkof over 25,000 highway traffic sensors, which gather highvolumes of data automatically and have been doing so forthe past 10 years. These data, which may seem far removed
∗The first three authors contributed equally to this work.
from issues such as social inequality, may nonetheless cap-ture subtle trends in a community. For example, researcherssuch as Hadayeghi et al. (2003) have noted correlation oftraffic and unemployment.
In this paper, we propose to use machine learning on au-tomatically gathered and readily available data such as high-way traffic to predict vital population metrics–such as crimerate and unemployment–in real time, in order to both betterunderstand the health of a population and to provide action-able information about current concerns.
Machine Learning System DesignWe built a custom machine learning system from scratchin Python, leveraging MongoDB as a database backend andAmazon Web Services (AWS) for parallel cloud computing.Our Python package offers submodules to create, manage,and evaluate datasets, featuresets (sets of feature extractingfunctions), and classifiers (see Figure 1 for a flow chart).We take an object-oriented approach, and strive to provide asimple high-level interface:
ds = Dataset("our dataset")fs = Featureset("our featureset")p = Projection(ds, fs, "our projection")c = Classifier("NaiveBayes")c.train(p.projected datums())e = Evaluator(c, p.projected datums())e.split dataset(dev percent=80,cv percent within dev=25)e.report cv performance()e.learning curve(intervals=10, folds=10)
We found that the most constraining step in our workflowwas the creation of feature vectors from our data. Hence,the primary goal of our system was to make this process fastand easy. We use a metaphor of projecting a dataset througha featureset to create feature vectors; this can all be done inone line of code. The feature projection process takes placein parallel across either all local cores, or, optionally, AWSmachines. This is made possible by our database backend(and friendly abstraction layer), which offers simultaneousand indexed access to our dataset, made efficient by care-fully tuning our MongoDB indexes. Using this system, weare able to easily and efficiently create feature vectors fromour raw data.
Raw Data Dataset Datum List
*.txt *.txt
*.txt*.txt
*.txt *.txt
PeMS Tra�c
y1 y2 yn. . .
Target Variables
yn
all t
ime
perio
ds fo
r w
hich
ther
e ex
ists
a y
all sensor data recorded within given time period
total �owavg speed
datetimesensor ID
delay
avg occupancy
y
x1 x2 xm. . .
hourly sensor readings
Database
Feature Functions
Classi�er
Naive-Bayes
Logistic Regression
WekaNaive-Bayes
Our Implementation
Figure 1: Flow chart of our machine learning Python package
Our package also offers a creative approach to a Naı̈veBayes classifier that is particularly well-suited for environ-ments in which new datums are frequently added to the train-ing set. Our approach has three interesting characteristics:instant training, parallel classification, and real-valued fea-ture support.
The classifier stores all datums in its training set in a sep-arate database collection and, when asked to classify an un-known datum, it queries the database holding these trainingdatums to gather the information needed. (For example, tocalculate the likelihood that a particular feature has a par-ticular value given some class c, one step is to query for alldatums in the training set that have class c.) This means thatrather than have a load → train → classify cycle in whichthe training phase loops over all datums gathering counts,we have a load→ classify cycle, in which the counting workis done for us by the database. The result is that we have es-sentially instantaneous training since the real work is doneduring classification, and yet the classification step is stillrelatively efficient, because by leveraging database indexes,we essentially have the database do the bookkeeping for us.In addition to instant training, we can instantly re-train ourclassifier by simply associating it with a new set of train-ing datums (which may be a super- or sub-set of the originaltraining set); new classifications will immediately take ad-vantage of this additional datum.
Because we do lose some speed when classifying unseendatums by not counting and caching in a training phase andthen simply applying the cached counts, we try to make upfor it in other ways. One way is through nested paralleliza-tion. When given a list of datums to classify, we parallelizeat no fewer than three levels: first, we classify each datumin parallel. Second, when classifying each datum, we evalu-ate the prior ∗ likelihood for each class in parallel. Third,we evaluate the likelihood that a feature has a certain valuegiven the class for each feature in parallel. This high de-gree of parallelism means that individual datum classifica-
tions are relatively slow due to the overhead of spawningso many parallel calls, but when classifying a large num-ber of datums, we are able to use practically limitless CPUpower (via AWS), so speed becomes directly dependent onour database performance. We found this to be an interest-ing characteristic of our classifier; rather than being CPU-bound, our system is IO-bound.
Vanilla Naı̈ve Bayes classifiers do not support real-valuedfeatures, which we found to be less than ideal. We thereforebuilt real-valued feature support into our classifier. Whencalculating the likelihood that a feature has a particular valuegiven some class, we model all observed values with thesecharacteristics as a Gaussian distribution, and calculate thelikelihood that a value would fall into a small interval sur-rounding the particular value of interest.
Because we wished to smooth our data, we extended thisGaussian approach in a way inspired by Laplace smoothing–we increased the σ used in our model by multiplying it by afixed constant (since adding some k would not respect thediffering variations of our feature values). This constantis roughly equivalent to an add-k approach in a traditionalNaı̈ve Bayes classifier, as it takes probability mass from themost likely values and spreads it out across less likely val-ues, such that no value gets a probability of 0–because, ofcourse, it’s a bad idea to estimate the probability of someevent to be 0 just because we haven’t seen it in our finitetraining set.
We found it to not be immediately clear theoretically whatshould happen if in the training set, we have never seen thefeature take on any value (given the class). Empirically,what we settled on was just offering a hand-coded very smalllikelihood. This corresponds theoretically to arguing that ifgiven some class we have never seen this feature take on anyvalue (perhaps due to sensor malfunction, as happened inour data), then the likelihood that we will see any value isvery low.
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
! !
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
! !
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
! !
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
! !
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!!
!
!
!
!!!
!
!
!
!
!
!
!
!!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
! !!!
!
!
!!
!
!
!
!
!
!
!
!
!!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!!
!
!!!!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
! !
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!
!
!
!
!!!!
!
!
!
!!
!
!
!
!
!
!
!
!
! !!
!
!
!
!!
!
!
!
!
!
!!
!
!
!
!!
!
!
!
!
!!!
! ! !
!
!
!
!
!
!
!
!
!
!
!!!
!
!
!
!
!!
!
!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!
!!
!
!
!!!!
!!
!! !!
!!
!
! !!
!!
!!
!!
!!
!
!!
!!!
!
!!!!!
!!
!
!
!!
!!
!!!!
!!
!
!!
!
!
!!
!!
!
!
!!
!!
!!
!!
!!
!
!!
!!
!!!!
!
!
!
!! !!!
!!!!
!! !!
!!!!
!!
!
!
!!!!
!
!!
!
!!
!
!
!
!
!!!!
!!!!!!!!
!
!!!!
!
!!!!
!!!
!!!!!
!!!!
!!
!!!!!!!!
!!
!
!!!!!!!!!
!!
!!!!
!!
!!!!!!
!!
!!!!!
!!!
!!!
!!!!!
!!!
!
!!
!
!!!!!!!!!!!!!!!!!!
!!!!
!
!!!!
!
!!!
!!!!!!!!!
!!!!
!!
!
!! !!!!
!!!!!
!!!!!!
!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!
!!
!!!!!!!!!!!!
!!!!
!!
!!!!!
!!
!!
!!!!!!
!!!!!!!
!
!!
!! !!
122°0'0"W
122°0'0"W
122°10'0"W
122°10'0"W
122°20'0"W
122°20'0"W
122°30'0"W
122°30'0"W
38°0'0"N 38°0'0"N
37°50'0"N 37°50'0"N
37°40'0"N 37°40'0"N
37°30'0"N 37°30'0"N
37°20'0"N 37°20'0"N±0 6 12 18 243
Miles
Figure 2: Map of all road sensors in the San Francisco BayArea, with key locations of interest to this project shown asred dots
Data
Dataset Description
For this project, we used two types of data: highway trafficdata as predictor variables and socio-economic data as tar-get variables. The highway data comes from the CaltransPerformance Measurement System (PeMS), which is publi-cally available at pems.dot.ca.gov (Choe, Skabardonis, andVaraiya 2001). PeMS consists of over 25,000 road sensorslocated on major highways throughout the state of Califor-nia that have recorded the speed and flow of passing cars inall lanes every 30 seconds for the past decade. We used aversion of this data aggregated by the hour in order to makethe data more manageable without losing too much granular-ity. For this project, we focused on sensors located around15 key locations in the San Francisco Bay Area, includingbridges, airports, and metropolitan areas. Figure 2 shows amap of all road sensors in the Bay Area, with chosen keylocations marked by red dots.
Choosing measures of inequality is a difficult problem,which has been a topic of open discussion in the field ofeconometrics and economic theory over the last few decades(Atkinson 1970). Motivated by interest from economics toanswer questions regarding poverty and wealth distribution,we selected relevant features related to unemployment andpublic assistance from different public data sources. Specif-ically, we examined eight socio-economic factors: (1) BARTridership, (2) number of Californians on food stamps (gov-ernmental assistance to buy food), (3) gas prices in Cali-fornia, (4) number of homeless families that are receivingassistance from the State of California, (5) crime rates inOakland, (6) percent of the California population that is onwelfare, (7) crime rates in San Francisco, and (8) unemploy-ment rates in California. Each of these statistics are reportedmonthly, and Table 1 shows the number of data points ineach set with the data source as a footnote.
Table 1: Size of socio-economic datasetsEconomic Factor Dataset SizeBART ridership1 12Food stamps2 118Gas price3 118Homeless4 117Oakland crime5 21Welfare6 116San Francisco crime7 43Unemployment8 116
Dataset PreparationDefining data points for the purpose of classification in thisapplication is a non-trivial task. Our dataset has multipledimensions, namely space (the sensor recordings were geo-graphically distributed across the San Francisco Bay Area),time, and recording dimensions (flow, occupancy, and veloc-ity for each lane). In addition, the number of data points ofthe target variables are limited to once per month for the lastten years, so we expect limitations on how many featureswill be optimal to train our model. Thus, we investigateddifferent choices for defining predictor variables.
We define a data point as corresponding to selected mea-surements from a given month as well as the correspond-ing target variable. Since we have nearly a decade of data,we have 118 data points. As previously described, we fo-cus on data from 15 key locations across the San FranciscoBay Area and we aggregate data from about 50 relevant sen-sors, which is a subsample of our entire dataset, as shown inFigure 2. For each month-long time period, we separatelyaverage the flow, speed, and delay recordings during morn-ing and afternoon rush hour for each day of the week at eachchosen location. We could easily increase the number of fea-tures by including data from more sensors or using flow fromevery day of the month rather than averaged across days ofthe week. We could also reduce the number of features byaggregating over an entire month, but we notice that the rushhour time periods and the weekly variation offer more pre-dictive power, perhaps because rush hour dynamics are intu-itively more related to socio-economic factors.
The schema for our data points is shown here:
<loc1 avgflow am Monday,loc1 avgspeed am Monday,loc1 delay am Monday,...loc15 delay pm Sunday, y>
1http://www.bart.gov/about/reports/ridership.aspx2http://www.dss.cahwnet.gov/research/PG353.htm3http://www.eia.gov/oil gas/petroleum/data publications/wrgp/
mogas history.html4http://www.cdss.ca.gov/research/PG283.htm5http://www2.oaklandnet.com/Government/o/OPD/s/
CrimeReportArchives/DOWD0061696http://www.cdss.ca.gov/research/PG370.htm7http://sf-police.org/index.aspx?page=7348http://www.labormarketinfo.edd.ca.gov/cgi/dataanalysis/
labForceReport.asp?menuchoice=LABFORCE
0.2 0.4 0.6 0.8 10
10
20
30
40
50
60
70
training set size (% of total data)
% c
lass
ificat
ion
erro
r
BART ridershipFood stampsGas priceOakland crimeUnemploymentWelfareHomelessSF crime
Figure 3: Learning curves of all socio-economic factors,computed using logistic regression in Weka
Our real-valued target variables are each mapped to twoclasses in order to use common machine learning classifica-tion algorithms. We initially tried two different mappingsto classes: one corresponding to whether the given pointin time had values higher or lower than the average overour whole dataset, and another corresponding to whether thevalue increased or decreased relative to the previous month.Unfortunately, the first of these mappings gave us unrea-sonably high predictive performance, and the second gaveus very low performance (see discussion in the Results sec-tion).
ResultsPreliminary ResultsAs a first pass analysis of our data, we took the feature vec-tors computed using our machine learning system and an-alyzed them in Weka with Naı̈ve-Bayes and logistic regres-sion classifiers (Hall et al. 2009). The resulting classificationerror for each socio-economic factor calculated using bothlearning algorithms and 10-fold cross validation is shown inTable 2. Based on these results, it appears that highway traf-fic data is a relatively good predictor of how much the pop-ulation of California is a) using welfare, b) on food stamps,and c) receiving unemployment assistance.
We also used Weka to compute a learning curve, whichshows how the classification error changes as the trainingsize increases (see Figure 3). For most socio-economic fac-tors, the testing error does not change with increased trainingset size, indicating that obtaining more data will not increaseaccuracy. Based on this observation, we decided to try im-proving our models using feature selection.
Feature SelectionWe performed feature selection for each socio-economicfactor in Weka by computing the information gain for all630 features, which is a measure of the reduction in uncer-tainty of the target variable given an observation of the fea-ture of interest. Then for each socio-economic factor, wechose only the features with the largest information gainsand retrained our model. For most socio-economic factors,the error is significantly reduced by using this optimized set
of features (see Table 2). Classification of BART ridershipactually has an error of 0, probably because this dataset onlycontains 12 data points and is being overfit.
See Table 3 for a list of the most important features forsome socio-economic factors. Half of the features that areimportant for predicting crime in Oakland come directlyfrom sensors located in Oakland or around the Oaklandaiport, which makes intuitive sense. For unemploymentrates, most of the important features are related to delay overbridges.
Table 2: Classification error using logistic regression andNaı̈ve-Bayes with 10-fold cross validation
All features Feature subsetLogistic Naı̈ve Logistic Naı̈ve
Indicator Reg. Bayes Reg. BayesBART ridership 8.3 58.3 0.0 8.3Food stamps 1.7 9.3 8.5 5.1Gas price 17.8 17.8 16.9 13.6Homeless 37.6 30.8 31.4 34.2Oakland crime 52.4 61.9 23.8 14.3Welfare 5.2 8.6 12.1 6.0SF crime 27.9 14.0 23.3 14.0Unemployment 7.8 6.0 6.9 1.7
InterpretationGiven the incredibly high accuracy in our classificationmodels, we re-examined our choice of target variables. Wenoted the common dependence on time of some of our pre-dictor and target variables. For example, in the first imple-mentation we separated percent of the population on wel-fare into two classes: one being below average over the lastdecade and one being above. However, welfare was aboveaverage for 2 years, then below for 4 years, then above untilpresent, showing very limited variability with time (see Fig-ure 4). Similarly, traffic flow in some locations followed ageneral increase with time. Thus, the high accuracy in clas-sification can be argued to be a trivial result for some socio-economic factors. But we were able to predict crime rates inOakland with only 14.3% error, even though this data showsa large variability with time as shown in Figure 4.
Because of this common dependence on time, we investi-gated other choices of determining classes, such as using amoving average with a bin width of 6 months or two years.The resulting model had high classification error near 50%,indicating the model was not better than randomly predict-ing a class. Future work could investigate the proper choiceof classes so as to make the moving average concept mean-ingful.
Another consideration was to use traffic data from a givenmonth to predict the class of the social indicator for the up-coming month. For target variables that rarely changed frommonth to month (like welfare), the predictive ability of ourmodels was about the same as classifying social indicatorsusing traffic data from the same month. However, for crime
Table 3: Features with highest information gain for crime rates in Oakland and unemploymentOakland crime Unemployment
Info Gain Feature Name Info Gain Feature Name0.615 OAK AIRPORT AVGSPEED AM FRI 0.810 BRIDGES AVGDELAY PM SAT0.499 PALOALTO AVGFLOW AM THU 0.653 BRIDGES AVGDELAY AM TUE0.411 OAK AVGFLOW PM WED 0.650 BRIDGES AVGDELAY PM THU0.401 SANJOSE AVGSPEED PM WED 0.618 SF AVGDELAY AM THU0.401 OAK AIRPORT AVGDELAY AM WED 0.614 OAK AVGSPEED PM SAT0.401 SANTAROSA AVGSPEED PM TUE 0.586 BRIDGES AVGDELAY PM SUN0.401 OAK AVGSPEED PM SAT 0.505 OAK AIRPORT AVGSPEED PM SAT0.342 SANJOSE AVGDELAY AM SUN 0.501 OAK AIRPORT AVGSPEED PM MON0.342 OAK AIRPORT AVGSPEED PM TUE 0.470 FREMONT AVGDELAY PM MON0.240 PALOALTO AVGSPEED AM THU 0.467 SANJOSE AVGFLOW AM MON
2002 2003 2004 2005 2006 2006 2007 2008 2009 20106.5
7
7.5
8
year
% p
opul
atio
n on
wel
fare
ClassDataAverage
2010 2011600
800
1000
1200
1400
1600
1800
2000
year
crim
es re
porte
d in
Oak
land
ClassDataAverage
Figure 4: Inequality indicator vs. time, shown as both actualcontinuous data and our classification of above or below av-erage where the indicator is percentage of Californians onwelfare and crime in Oakland.
in Oakland, for example, we had 30% classification errorpredicting the future month as compared to 15% when pre-dicting within the same month.
ConclusionsIn this paper, we train classification models to predict socialinequality like the percent of Californians on welfare, thenumber of people in CA receiving food stamps, and crimereports per month. We build the set of features from a largedataset of highway sensor recordings using our custom ma-chine learning system. We apply this framework to historicaldata from highway sensors in the San Francisco Bay Areaand indicators of local social inequality over the last decade.
Common dependence of our predictor and target vari-ables, such as on time, poses challenges for gaining non-trivial results, especially for unemployment rates, number
of Californians on food stamps, and percent of the popula-tion on welfare. Thus, we discuss appropriate choices forbinning target variables.
We show that recordings from highway sensors are goodpredictors of monthly reports of crime in Oakland, CA andwarrant further investigation.
AcknowledgmentsWe would like to thank Andrew Ng for insightful discus-sions and Stanford University for resources.
ReferencesAtkinson, A. 1970. On the measurement of inequality. Jour-nal of Economic Theory 2:244–263.Choe, T.; Skabardonis, A.; and Varaiya, P. 2001. Freewayperformance measurement system (PeMS): an operationalanalyis tool. Transportation Research Board Annual Meet-ing.Hadayeghi, A.; Shalaby, A.; and Persaud, B. 2003.Macrolevel accident prediction models for evaluating safetyof urban transportation systems. Transportation ResearchRecord 1840(1):87–95.Hall, M.; Frank, E.; Holmes, G.; Pfahringer, B.; Reutemann,P.; and Witten, I. H. 2009. The WEKA data mining software.ACM SIGKDD Explorations Newsletter 11(1):10.Helpman, E.; Itskhoki, O.; and Redding, S. 2010. Inequal-ity and unemployment in a global economy. Econometrica78(4):1239–1283.Jenkins, S., and Micklewright, J. 2007. Inequality andPoverty Re-examined. Oxford, UK: Oxford UniversityPress.Khattak, A. J.; Wang, X.; and Zhang, H. 2010. Spatialanalysis and modeling of traffic incidents for proactive in-cident management and strategic planning. TransportationResearch Record: Journal of the Transportation ResearchBoard 2178(-1):128–137.