Tag Archives: ASDM

Collision Manner

[Warning/correction not yet made: in the table below where it says MV-only, that’s not quite correct, it’s really incidents where no pedalscylists are involved. The MV-only calculations should also exclude pedestrians; this can be accomplished by saying u.eUnitType LIKE ‘PED%’  In the query below i corrected it but didn’t correct the table; the percentages don’t really change since there are relatively few ped crashes ]

Here is a breakdown of Collision Manner, and rates, for MV collisions (i.e. one or more MV, and not involving a ped or bicyclists) compared to bike-MV collisions.

The megatrends are that rear end collisions are, by far, the predominant manner of collision for MVonly crashes; wheres for bike-MV crashes this manner is quite infrequent — almost twelve times more frequent. For bike-MV crashes, the predominant manner is angle, i.e. so called “turning and crossing” movements (although left turn is broken out as a separate manner).

The 38% rate of REAR END crashes for MVs actually understates the rate — if you back out the number of SINGLE VEHICLE crashes; you see that nearly half of all multi-car collisions are REAR END(!). 38,499/(101,055 – 18,647) = 47%. Inattention? Does this mean that motorists actually are more attentive to same-direction traffic when it’s a bicyclist, compared to another motorist? hmmm.

| eCollisionManner             | MVonly| MVrate |bikeMV|bikerate|MV:bike ratio|
| REAR_TO_REAR                 |   287 | 0.0028 | NULL |   NULL |        NULL |
| UNKNOWN_99                   |   859 | 0.0085 |   40 | 0.0189 |  0.44973545 |
| REAR_TO_SIDE                 |   895 | 0.0089 |   11 | 0.0052 |  1.71153846 |
| SIDESWIPE_OPPOSITE_DIRECTION |  1244 | 0.0123 |   46 | 0.0217 |  0.56682028 |
| HEAD_ON                      |  1438 | 0.0142 |   45 | 0.0212 |  0.66981132 |
| OTHER_97                     |  3160 | 0.0313 |  404 | 0.1905 |  0.16430446 |
| SIDESWIPE_SAME_DIRECTION     | 10727 | 0.1062 |  124 | 0.0585 |  1.81538462 |
| LEFT_TURN                    | 11888 | 0.1176 |  189 | 0.0891 |  1.31986532 |
| ANGLE_FRONT_TO_SIDE          | 13411 | 0.1327 | 1194 | 0.5629 |  0.23574347 |
| SINGLE_VEHICLE               | 18647 | 0.1845 | NULL |   NULL |        NULL |
| REAR_END                     | 38499 | 0.3810 |   68 | 0.0321 | 11.86915888 |
total num of MVonly crashes = 101,055.  total num of bike-MV crashes = 2,121
source: 2012 ASDM

Continue reading Collision Manner

Motorcyclist killed after crash in Phoenix

This appears to be highly typical mode of motorcyclist fatality

A motorist makes a bad left at intersection, striking oncoming motorcyclist.

Had this been a bicyclist-MV collision, it would be a crash type 212 – Motorist Left Turn—Opposite Direction, commonly called a “left hook”. This is a relatively uncommon fatal crash type, just 12 of 617 bicyclist fatalities nationwide in 2010 according to FARS. One supposes that the relative speeds involved make this far more likely to be deadly for motorcyclists than for bicyclists.

One wonders how the police handle such cases; from the description, it appears the motorist should be cited for 28-772 making a bad left, and charged with 28-672. since a death resulted.

Motorcyclist, 20, killed when driver, 84, failed to yield

By Yihyun Jeong
The Arizona Republic-12 News Breaking News Team
Thu Apr 11, 2013 4:03 PM

A motorcyclist died after a car tried to make a left turn in front of the motorcyclist at Cave Creek Road and Union Hills Drive in Phoenix Wednesday, officials said. Police responded to a serious injury collision at the intersection of Cave Creek Road and Union Hills Drive around 4 p.m., Sgt. Steve Martos, a spokesman for the Phoenix Police Department said. Police were told that a motorcyclist was down and his motorcycle was on fire. The motorcyclist, Angelo Wright, 20, was taken to a nearby hospital where he died of injuries, Martos said. The police department’s Vehicular Crimes Unit responded to the scene and determined that an 84-year-old female driver of a Volkswagen Rabbit, was heading east on Union Hills and tried to make a left turn at Cave Creek Road to travel north, Martos said. The driver failed to yield to Wright, who was riding a Harley Davidson motorcycle, and collided with him. Wright was not wearing a helmet.


Was the driver cited and/or charged? Dunno. Would have to get police report and get driver’s name, since police didn’t say, and then do a lookup.


It’s like a war zone out there…

Walk in the crosswalk; get hit with flying debris from a red-light-runner? Seriously, how often does this happen? (note to self — check ASDM for 2013, whenever that becomes available, and see if the peds show up in the collision — my guess is no but i really don’t know what the story is)

azcentral.com: …At about 9a.m. Sunday (3/10/2013), Kaylynn Ruth Kayanie, 25, was driving west on Broadway “at a high rate of speed” when she ran a red light and struck another vehicle that was traveling south on Priest Drive… The driver of the southbound vehicle, a 45-year-old woman, was ejected and taken to the hospital with life-threatening injuries…  Two pedestrians who were in the crosswalk heading south on Priest at the time of the collision were hit by flying debris and taken to the hospital, where they were treated for cuts and bruises and released the same day, she said. Impairment does appear to be a factor in that case and investigators are awaiting drug-test results

The same story notes that the suspected impaired driver Veronica Muckerman made a bad left, killing a motorcyclist Elsa Tovar last week; was apparently driving without a license, due to being revoked in 2011 for another dui.

ADOT Traffic Collision Database

It turns out (who knew?) that ADOT sells their crash database for a nominal sum. I purchased the 2010 version, the latest full-year available (2011 is supposed to be ready in July). This data is either similar to (or synonmyous with) something referred to as the Arizona (or ADOT?) Safety Data Mart — thus the acronym asdm sprinkled throughout.

The data is delivered on a DVD which contains three large text files; corresponding to Incident, Person, and Crash -level data. It is also accompanied with 5 photocopied pages of “Column Headings”, and about two-dozen pages of photocopied “Definitions”. [it is really strange that they would distribute this information on paper!?]. I was surprised to find out that very little of the data aligns with FARS/GES, which seems quite strange to me.

Anyway, I pieced together most of the info using those photocopies and assembled it for ready-reference in a spreadsheet adsm.xls , there is one worksheet for columns (fields) and another for defintions (ENUM). I don’t have all the definitions there, some i didn’t care about and were very lenghy, like vehicle color, state abbreviations, and so forth; nearly all of that is avaible at the referece material

Reference Material

  • Background info on the ALISS database,  and related terms: AIDW (Adot Information Data Warehouse), and Safety Data Mart.
  • My spreadsheet adsm.xls; provides a unifying list of fields, and enumerations

If the document links, above, go dead; there are local copies in asdm/.

The Database

azbikelaw.org is making this data available publicly via a MySQL database accessible via the internet. Special thanks to Justin Pryzby for completing this work.

Years 2001-2003, and 2009-Newest
hostname:     mysql.azbikelaw.org
databasename: asdm
username:     asdmuser
password:     Contact us
access via myPhpAdmin currently not available

Crash Map 
See crashmap-data

The tables were loaded from raw text files into tables and then re-processed with to create 3 tables: 2010_incident, 2010_person, and 2010_unit.

Interactive (e.g. myPhpAdmin, or MySQL Query Browser) users will want to refer to views: pretty_2010_incident, pretty_2010_person, and pretty_2010_unit which substitute enumerated fields for the original data fields, and leaves out the description-only fields. For example there are 3 fields all carrying the same information: TravelDirection = 1 (int), TravelDirectionDesc = “NORTH” (text), and a synthetic field eTravelDirection=’NORTH’ (enum). The first two are not in the pretty_unit view, while the unit2 table has all three. The table unit should not be used, and is likely to be dropped to save space.

Furthermore, all database users should rely on the enumerated field, eTravelDirection in the above example, and not on the integer values, as they are liable to change in subsequent years, whereas the enumerations can be kept consistent when subsequent data from a new year is imported.

There are some additional helper tables, such as LOVCity, LOVCounty and county which are handy for looking up things like city codes (e.g. Phoenix has a CityID of 241).

Data Completeness

A word about data completeness: As explained in more detail in this comment below. The data received from ADOT represents data frozen in time mid-year (currently the cutoff date appears to be May 31 of the following year). Data does continue to trickle in, however, and for unknown reasons (why shouldn’t 6 months be enough time for PD’s to send all their corrected data from the preceding year?). ADOT initially releases a version of Crash Facts based on the May 31 data; and then subsequently re-publishes an update a few months later. My dataset is frozen in time at the May 31st (or June 1st) version; which doesn’t make me happy but tends to be statistically insignificant.

Trickling example: The number of pedalcyclist crashes in 2012: 2121 / 2134 / 2141 as of May 31 2013 / Oct 28 2013 / Late Nov 2013. I.e. 2012 crash reports continue to trickle in in Late November of the next year!

GIS issues: a widely varying (from year-to-year) number of incidents have a lat/long of zero. More about that at crashmap-data.

I have noted in a few cases (only fatals?) where the data in asdm seems to be massaged relative to the acr, see comment below about “fiddling” (also called “fudgery”) with the CollisionManner and PostedSpeed.


The first dataset available is 2010, which is the most recent full year available from ADOT.


I went backwards and purchased the 2009 data; I believe this is the oldest dataset available under the current schema — which kindof makes sense as the ACR form was re-vamped for 2009.


2011 data became available in mid-July 2012 ( I received it in the mail from ADOT Risk Management 7/27); and is now ready for querying. This year the data was distributed all on a CD, so thankfully no photocopies of headings and definitions hanging around.

As might be supposed, the tables are named 2011_incident, 2011_person, and 2011_unit ; along with the pretty views. The table structure is identical to 2010.


2012 data became available June 10, 2013, according to an email report. It once again was $15, and a CD was delivered very promptly upon mailing ADOT Risk Management a check. This year the contact was Sarah Greener, Litigation & Public Records Supervisor. The data fields were identical to last (and in fact, all previous) year. I only needed to edit the .sql’s to substitute in 2012_ instead of 2011_ or whatever.


2013 became available in mid-June as usual and the Adot risk mgmt people got it promptly mailed out to me for $17 (2 charge for mail, which apparently was waived or forgotten in previous years. See also arizona-crash-facts-2013 and

One area where data quality has degraded noticeably is with the number of incidents listing a geo-location of 0,0. Many of these also have no OnRoad nor CrossingFeature. This year there are almost 3,000 such incidents; last year there were only 663; and prior years were 2,679, 2,017, and 9,048(! 2009 was a bad year for much inconsistency) respectively. I don’t really see a pattern, e.g. as to particular agencies, in other words they’re sprinkled around the state. The 3,000 include about 50 bicyclist incidents including some with incapacitating injury. I am also pretty shocked to find among the 3,000 forty fatalities and over a hundred incapacitating injuries — this just seems horribly lax.

select count(*) from 2013_incident where Latitude=0 OR Longitude=0;


Everything seemed fine until discovering there’s something wrong with UnitID this year; Up until this year, UnitID (as well as PersonID and IncidentID) have all been unique, even year-over-year. This year, however, there are many (~ 30,000?) “reused” UnitIDs. It’s not clear if this is a bug, or just what… Is the data ok otherwise? who knows. What’s clear is ADOT traffic records people prefer to toil in anonymity and don’t deign to bless us (the general public) with any explanations of their work.

e.g. UnitID=4976526 appears in both 2012 and 2014. Boo. You can test for this condition by running the following (long, it takes over a minute) query; the result should be 0 rows, but it returns some 30,000!:

SELECT UnitID, count(1) c FROM (SELECT * FROM 2014_unit UNION SELECT * FROM 2013_unit UNION SELECT * FROM 2012_unit UNION SELECT * FROM 2011_unit UNION SELECT * FROM 2010_unit UNION SELECT * FROM 2009_unit) x GROUP BY 1 HAVING c>1 ORDER BY 2;

This seems rather odd; I expect to be able to use any of those IDs as a primary key, regardless of year, so that can no longer work. In any event to cover up adot’s short-comings; I’ve added XX0,000,000 where XX is the last two digits of the year to UnitID. For now, just did it to the 2014 tables…

UPDATE 2014_unit SET UnitID = UnitID + 140000000;
UPDATE 2014_person SET UnitID = UnitID + 140000000;

Also, there is an error incident=2935635, is incorrectly listed as 2 bicycle crash; it should be bike-MV (there is no such thing a crash not involving any motor vehicle).


I had failed to notice at the time, but in 2014 four fields were added to the tables (this means, by inference, the Arizona Crash Form was updated, also):

  • incident table: Offset Direction , Secondary Crash Flag (The latter seems to not have a def’n?)
  • unit table: Distracted Driving and Distracted Driving Desc

These fields are added to the “end” (i.e. the far right-hand side) of the respective .csv files. As such, they can be safely ignored, as is presently done for 2014.

I would have thought this would break the “ADOTALL” tables, but it still seems to work, albeit without the new fields…

All Years, 2009-2015

I found it was becoming a drag to re-run queries across year; so in Oct 2014 I created three tables, incident, person, unit that hold all contiguous year in 3 big tables. As new years come by I will add them as well. Complicated queries to these tables need to be somewhat judicious as the amount of data gets larger and larger; mysql.azbikelaw.org is hosted on my home server and is an old laptop!

There is a shell script to build all year’s tables at once, build-asdm-all.sh which is in the ADOTALL folder (analogous to ADOT20xx folders). SEE ABOVE, 2014 FOR A PROBLEM with this approach — unfortuantely UnitID is no long unique, so it can’t be a primary key.

See note, just above, about year 2015 data and new fields.


Justin got these discs from Adot in September 2013 (i.e. these are way out of chronological order)… in any event they still have exactly the same columns/tables layout. The only exception was the values STOP and YIELD in ControlType in the Unit table are reversed; so the definition of eControlType had to be adjusted. (so they are the reverse of 2009-2012 values).


[warning: the table referred to below, farsxref, has fallen out of date] : As of now, FARS (federal, fatality-only data) for years 2010 and 2011 is available with full PBCAT crash typing, see 2010 FARS contains PBCAT data for more info on PBCAT. There’s a somewhat hand-crafted table called farsxref which contains an adot IncidentID, Year, and Fars identifier (the adot IncidentID is unique, for fars, the year and identifier have to be combined to uniquely identify an incident). Anyway, in the table is row for pedalcyclists only (at the moment; there’s not particular reason it shouldn’t have all fatals). Anyways, FARS data will eventually be added to the incident dump query.

Database improvements?

See comment below for a list of suggestions.

Shell Scripts

There are shell scripts to build the databases from raw text input files; build-asdm.sh build-fars.sh and there are also classifying scripts which produce sometimes interesting snapshot views of the tables; classify-asdm.sh and classify-fars.sh

See azbikelaw-gets-its-own-server (the slug is now just azbikelaw) which is password protected; actually it’s a “private” post, it’s invisible (not found) unless logged in.


In no particular order, here are some examples for routine lookups.

By Street Name(s), use OnRoad and/or CrossingFeature.  This finds incidents near Catalina Hwy and Houghton Rd.

select * from 2013_incident where (OnRoad LIKE "Catalina%" and CrossingFeature LIKE "Hough%") OR (OnRoad LIKE "Hough%" and CrossingFeature LIKE "Catalina%");
or to get a feel for dangerousness level, instead select things like:
SUM(TotalMotoristsInjuries), SUM(TotalNonMotoristsInjuries), SUM(TotalMotoristsFatalities), SUM(TotalNonMotoristsFatalities)

By Street Name and Latitude/Longitude:

This example was to find any crashes along Park Ave, in Tucson, between Park Ave and Irvington (on the North) and Valencia (to the south), where a road diet was done sometime in 2014.  Since it’s a north/south road, use Latitude to discriminate. To find Latitudes/Longitudes use a tool such as latlong.net. You can, by the way, form a google maps url if you know lat/long like so:  maps.google.com/?q=32.16334,-110.95618 . In any event, the Latitudes in the query are “opened up” a bit to catch more crashes near the begin/endpoints:

SELECT eCollisionManner, count(*)
FROM 2012_incident AS i WHERE 
(OnRoad LIKE "Park Ave%" OR CrossingFeature LIKE "Park Ave%") AND 
(Latitude > 32.13410 AND Latitude < 32.16334 ) AND
(IncidentYear > 2008 AND IncidentYear < 2013) AND
CityId = 310 GROUP BY 1;

An example of an east/west road, University Drive in Tempe, between Priest Drive and ~ Ash Ave can be found here; (which is more complicated because it only selects MV-Bike crashes, by the way).

Arizona Agency NCIC Numbers

This info will be only of interest for those working with the ADOT Data Safety Mart database.

There are a couple of places on the ACR form for NCIC numbers. That stands for National Crime Information Center; and the actual number in question apparently is called an Originating Agency Identifier (ORI) and it’s keeper is the FBI. Below I will refer to this number only as the “NCIC number”.

I found it surprisingly difficult to find a list. The only place I found it was in a 12 year old(!) AZ Crash Manual (“Manual of Instructions for use with State of Arizona Traffic Accident Report Forms” published by ADOT dated December 2000), so the info regarding Agency name should be suspect.

It is plain to see that some of it is easily verifyable  and correlates to any of the “big” cities/jurisdictions: Phoenix PD is 0723, DPS is 0799, Tucson PD is 1003, etc. Beyond a couple of dozen, though, things get pretty sketchy.

Of more interest is the meaning of the distinction between data fields ExtendedNcic, and OfficerNcic — the field on the ACR is marked simply NCIC No. (Block 1e), which i imagine maps to ExtendedNcic; however I can’t find a block on the ACR that might correspond to OfficerNcic. They are usually, but by no means always, the same. There’s another thing called Officer ID No., Block 1f, but that maps to OfficerID in table incident.

This info is also in my famous catch-all spreadsheet adsm.xls; and will undoubtedly either turn into enumerations, or probably its own table.


Arizona NCIC Numbers
National Crime Information Center number is a code that uniquely identifies each law enforcement agency. Numbers are assigned by the Federal Bureau of Investigation. (See pages 66 through 68 [of the year 2000 version of AZ Crash Manual] for a complete list of Arizona NCIC Numbers.)
ExtendedNcic, OfficerNcic’s value/count data from ADOT safety data mart year 2010. Agency name list from pages 66 -68 of the year 2000 version of AZ Crash Manual
ExtendedNcic OfficerNcic From 2000 AZ Crash Manual
value count value count agency name value
100 474 100 40 Apache County S.O. 100
101 28 101 28 Eagar 101
103 18 103 18 St. Johns 103
105 12 105 10 Springerville 105
Whitemountain Apache Res. (Apache) 162
189 73 Navajo Reservation (Apache) 189
200 693 200 224 Cochise County S.O. 200
201 89 201 55 Benson 201
203 4 203 1 Bisbee 203
205 41 205 37 Douglas 205
207 7 207 8 Huachuca City 207
209 756 209 763 Sierra Vista 209
211 1 Tombstone 211
213 39 213 32 Willcox 213
300 1539 300 223 Coconino County S.O. 300
301 1909 301 1762 Flagstaff 301
302 1 Hualapai Reservation (Coconino) 302
303 6 Fredonia 303
307 97 307 43 Williams 307
308 21 308 21 Page 308
310 195 310 197 Sedona 310
Hopi Reservation (Coconino) 365
389 34 Navajo Reservation (Coconino) 389
Northern Arizona University 397
400 484 400 134 Gila County S.O. 400
401 172 401 178 Globe 401
403 2 403 1 Hayden 403
405 13 405 13 Miami 405
406 142 406 139 Payson 406
407 1 489 4 Winkelman 407
Whitemountain Apache Res. (Gila) 465
San Carlos Reservation (Gila) 489
500 124 500 38 Graham County S.O. 500
501 3 Pima 501
503 105 503 95 Safford 503
505 45 505 49 Thatcher 505
San Carlos Reservation (Graham) 562
600 60 600 13 Greenlee County S.O. 600
601 6 601 3 Clifton 601
603 4 Duncan 603
700 5242 700 3036 Maricopa County S.O. 700
701 1044 701 890 Avondale 701
703 405 703 256 Buckeye 703
704 56 Cave Creek 704
705 3516 705 3007 Chandler 705
707 321 707 311 El Mirage 707
709 20 Gila Bend 709
711 2378 711 2250 Gilbert 711
713 4822 713 4492 Glendale 713
715 939 715 635 Goodyear 715
Ft. McDowell Reservation 716
717 6130 717 4744 Mesa 717
719 193 719 131 Paradise Valley 719
721 2237 721 1855 Peoria 721
723 29065 723 21442 Phoenix 723
725 3529 725 3329 Scottsdale 725
727 1027 727 904 Surprise 727
729 6659 729 4084 Tempe 729
731 366 731 237 Tolleson 731
733 93 733 89 Wickenburg 733
735 13 Youngtown 735
739 300 Guadalupe 739
744 3
753 41
755 116
756 97 Fountain Hills 756
760 15 Carefree 760
Gila Bend Reservation 762
Tohono O’Odham Res. (Maricopa) 763
Gila River reservation (Maricopa) 764
789 1 Salt River Reservation 789
Arizona State University 797
799 25587 Dept. of Public Safety 799
800 1140 800 326 Mohave County S.O. 800
801 537 801 478 Kingman 801
804 629 804 632 Hualapai Reservation (Mohave) 802
805 683 805 684 Lake Havasu City 804
806 18 806 18 Bullhead City 805
Colorado City 806
Kaibab-Paiute Reservation 860
862 3 Ft.Mohave Reservation 862
900 647 900 141 Navajo County S.O. 900
901 60 901 41 Holbrook 901
902 19 Hopi Reservation (Navajo) 902
903 164 903 167 Show Low 903
905 64 905 81 Snowflake 905
907 19 Taylor 907
909 134 909 117 Winslow 909
913 118 913 124 Pinetop/Lakeside 913
962 72 Navajo Reservation (Navajo) 962
989 2 Whitemountain Apache Res. (Navajo) 989
1000 4424 1000 3324 Pima County S.O. 1000
1001 70 1001 69 South Tucson 1001
1003 9718 1003 9058 Tucson 1003
1004 192 1004 157 Sahuarita / Green Valley (both same code??) 1004
1007 454 1007 462 Oro Valley 1007
1009 916 1009 679 Marana 1009
San Xavier Reservation 1062
1089 220 Tohono O’Odham Res. (Pima) 1089
1097 117 University of Arizona 1097
1100 1779 1100 703 Pinal County S.O. 1100
1101 853 1101 796 Casa Grande 1101
1103 172 1103 179 Coolidge 1103
1105 149 1105 97 Eloy 1105
1107 81 1107 111 Florence 1107
1109 5 1109 4 Kearney 1109
1111 4 1111 4 Mammoth 1111
1112 2 1112 1 Superior 1112
1113 417 1113 377 Apache Junction 1113
1117 215 1117 211
1164 7 Tohono O’Odham Res. (Pinal) 1164
Maricopa Reservation 1165
1189 345 Gila River Reservation (Pinal) 1189
Central Arizona College 1197
1200 294 1200 75 Santa Cruz County S.O. 1200
1201 342 1201 313 Nogales 1201
Patagonia 1203
1300 1378 1300 283 Yavapai County S.O. 1300
1301 1 1301 1 Clarkdale 1301
1303 244 1303 237 Cottonwood 1303
1305 6 1305 5 Jerome 1305
1307 760 1307 749 Prescott 1307
1311 539 1311 536 Prescott Valley 1311
1312 87 1312 87 Chino Valley 1312
1313 92 1313 72 Camp Verde 1313
1314 1
1358 11
Hualapai Reservation (Yavapai) 1363
1400 716 1400 484 Yuma County S.O. 1400
1403 26 1403 31 Somerton 1403
1405 1891 1405 1849 Yuma 1405
1407 7 Wellton 1407
1408 137 1408 139 San Luis 1408
1410 5
1497 1 Arizona Western College 1497
1500 330 1500 32 La Paz County S.O. 1500
1501 33 1501 31 Parker 1501
1503 35 1503 18 Quartzite 1503
Colorado River Reservation 1506
Sums → 106301 106301
Below are listed Federal Parks and Monuments, and US Military – it is not clear how, or even if, these codes (from 2000) map to the Adot data, which is all numeric; and perhaps doesn’t even cover “federal” investigations?
Canyon De Chelly National Monument I007
Casa Grande Ruins National Monument I012
Chiricauha National Monument I013
Glen Canyon National Monument I003
Montezuma Castle National Monument I014
Navajo National Monument I009
Organ Pipe Cactus National Monument I015
Petrified Forest National Park I004
Saguaro National Monument I005
Sunset Crater National Monument I010
Tonto National Monument I016
Tumacacori National Monument I017
Tuzigoot National Monument I018
Walnut Canyon National Monument I019
Wupatki National Monument I011
Davis Monthan AFB F001
Ft. Huachuca Army Base USA0
Luke AFB F003
Yuma Proving Grounds Army Base SA02 SA02


Most at Fault vs. NCIC

(The stats quoted can be found in this comment below)
It can be illuminating to study who, the bicyclist or the motorist, was most at fault (MaF) in a Bike-MV collision. All things being equal, we would expect a 50:50 split, because in the vast majority of collisions there is one bicycle operator, and one MV operator.

The MaF data is available in the yearly collision database from ADOT, a.k.a. the ASDM; the vehicle/person/bicyclist listed as Unit #1 is always the MaF, in the determination of the investigating officer.

Reassuringly, overall the MaF rates are indeed fairly close to 50:50 — for example, the seven year period 2009-2015 the split was 51:49, indicating bicyclists were every so slightly more likely to be found at fault that the driver they collided with. Deviations from this nominal rate might indicate something is amiss; perhaps bicyclists in one community are more likely to break the law, or perhaps police are misinterpreting laws in someone’s favor…

The NCICs associated with the city of Phoenix has a particularly high bicyclist MaF rate: e.g. 68% in 2010 — compare this to, e.g. Scottsdale where it was only 48%. I find it pretty unlikely that bicyclists in Phoenix behave significantly different than Scottsdale; though without looking at a lot of ACRs it’s not possible to tell. On the other hand, 2010 seems to have been anomalously high that year, 2011 and 2012 were 61 and 60%, respectively; so perhaps just a data glitch. On the other hand Tempe, at 68% in 2012, and seems persistantly somewhat high. Yuma, a small city, had a persistently very high bicyclist MaF rate, as high as 80%!, this may be changing after the local ordiance restricted & clarified sidewalk use rules in 2015.

Here are some queries; note that similar results are used using either OfficerNcic as ExtendedNcic. The first is very fancy, computing the percentages and everything!

SELECT sum(atfault)/count(1), Name, sum(atfault), count(1) FROM LOVNcic, (SELECT ExtendedNcic, u.eUnitType='PEDALCYCLIST' atfault FROM 2012_incident i, 2012_unit u WHERE i.IncidentID=u.IncidentID AND EXISTS (SELECT 1 FROM 2012_unit u2 WHERE u2.IncidentID=i.IncidentID AND u2.eUnitType='PEDALCYCLIST') AND UnitNumber=1) x WHERE ID=ExtendedNcic GROUP BY ExtendedNcic HAVING count(1)>20 ORDER BY 1;

Here is how to select the total number of bike crashes by ncic, and then the number of those where bicyclist is MaF

SELECT ExtendedNcic,count(1) FROM 2012_incident i WHERE EXISTS (SELECT 1 FROM 2012_unit u WHERE u.IncidentID=i.IncidentID AND u.eUnitType IN ('PEDALCYCLIST')) GROUP BY 1 ORDER BY 1 ASC;
SELECT ExtendedNcic,count(1) FROM 2012_incident i WHERE EXISTS (SELECT 1 FROM 2012_unit u WHERE u.IncidentID=i.IncidentID AND u.eUnitType IN ('PEDALCYCLIST') AND u.UnitNumber=1 ) GROUP BY 1 ORDER BY 1 ASC;