The study was a comprehensive analysis of felonious killings of officers. The purposes of the study were (1) to analyze the nature and circumstances of incidents of felonious police killings and (2) to analyze trends in the numbers and rates of killings across different types of agencies and to explain these differences. For Part 1, Incident-Level Data, an incident-level database was created to capture all incidents involving the death of a police officer from 1983 through 1992. Data on officers and incidents were collected from the Law Enforcement Officers Killed and Assaulted (LEOKA) data collection as coded by the Uniform Crime Reporting (UCR) program. In addition to the UCR data, the Police Foundation also coded information from the LEOKA narratives that are not part of the computerized LEOKA database from the FBI. For Part 2, Agency-Level Data, the researchers created an agency-level database to research systematic differences among rates at which law enforcement officers had been feloniously killed from 1977 through 1992. The investigators focused on the 56 largest law enforcement agencies because of the availability of data for explanatory variables. Variables in Part 1 include year of killing, involvement of other officers, if the officer was killed with his/her own weapon, circumstances of the killing, _location of fatal wounds, distance between officer and offender, if the victim was wearing body armor, if different officers were killed in the same incident, if the officer was in uniform, actions of the killer and of the officer at entry and final stage, if the killer was visible at first, if the officer thought the killer was a felon suspect, if the officer was shot at entry, and circumstances at anticipation, entry, and final stages. Demographic variables for Part 1 include victim's sex, age, race, type of assignment, rank, years of experience, agency, population group, and if the officer was working a security job. Part 2 contains variables describing the general municipal environment, such as whether the agency is located in the South, level of poverty according to a poverty index, population density, percent of population that was Hispanic or Black, and population aged 15-34 years old. Variables capturing the crime environment include the violent crime rate, property crime rate, and a gun-related crime index. Lastly, variables on the environment of the police agencies include violent and property crime arrests per 1,000 sworn officers, percentage of officers injured in assaults, and number of sworn officers.

Sadly, the trend of fatal police shootings in the United States seems to only be increasing, with a total 1,173 civilians having been shot, 248 of whom were Black, as of December 2024. In 2023, there were 1,164 fatal police shootings. Additionally, the rate of fatal police shootings among Black Americans was much higher than that for any other ethnicity, standing at 6.1 fatal shootings per million of the population per year between 2015 and 2024. Police brutality in the U.S. In recent years, particularly since the fatal shooting of Michael Brown in Ferguson, Missouri in 2014, police brutality has become a hot button issue in the United States. The number of homicides committed by police in the United States is often compared to those in countries such as England, where the number is significantly lower. Black Lives Matter The Black Lives Matter Movement, formed in 2013, has been a vocal part of the movement against police brutality in the U.S. by organizing “die-ins”, marches, and demonstrations in response to the killings of black men and women by police. While Black Lives Matter has become a controversial movement within the U.S., it has brought more attention to the number and frequency of police shootings of civilians.

Version 4 release notes: Add data for 2016.Order rows by year (descending) and ORI.Version 3 release notes: Fix bug where Philadelphia Police Department had incorrect FIPS county code. The LEOKA data sets contain highly detailed data about the number of officers/civilians employed by an agency and how many officers were killed or assaulted. Each data set contains over 2,200 columns and has a wealth of information about the circumstances of assaults on officers. All the data was downloaded from NACJD as ASCII+SPSS Setup files and read into R using the package asciiSetupReader. It was then cleaned in R. The "cleaning" just means that column names were standardized (different years have slightly different spellings for many columns). Standardization of column names is necessary to stack multiple years together. Categorical variables (e.g. state) were also standardized (i.e. fix spelling errors). About 7% of all agencies in the data report more officers or civilians than population. As such, I removed the officers/civilians per 1,000 population variables. You should exercise caution if deciding to generate and use these variables yourself. I did not make any changes to the numeric columns except for the following. A few years of data had the values "blank" or "missing" as indicators of missing values. Rows in otherwise numeric columns (e.g. jan_asslt_no_injury_knife) with these values were replaced with NA. There were three obvious data entry errors in officers killed by felony/accident that I changed to NA. In 1978 the agency "pittsburgh" (ORI = PAPPD00) reported 576 officers killed by accident during March.In 1979 the agency "metuchen" (ORI = NJ01210) reported 991 officers killed by felony during August.In 1990 the agency "penobscot state police" (ORI = ME010SP) reported 860 officers killed by accident during July.No other changes to numeric columns were made.Each zip file contains all years as individual monthly files of the specified data type It also includes a file with all years aggregated yearly and stacked into a single data set. Please note that each monthly file is quite large (2,200+ columns) so it may take time to download the zip file and open each data file.For the R code used to clean this data, see here. https://github.com/jacobkap/crime_data.The UCR Handbook (https://ucr.fbi.gov/additional-ucr-publications/ucr_handbook.pdf/view) describes the LEOKA data as follows:"The UCR Program collects data from all contributing agencies ... on officer line-of-duty deaths and assaults. Reporting agencies must submit data on ... their own duly sworn officers feloniously or accidentally killed or assaulted in the line of duty. The purpose of this data collection is to identify situations in which officers are killed or assaulted, describe the incidents statistically, and publish the data to aid agencies in developing policies to improve officer safety."... agencies must record assaults on sworn officers. Reporting agencies must count all assaults that resulted in serious injury or assaults in which a weapon was used that could have caused serious injury or death. They must include other assaults not causing injury if the assault involved more than mere verbal abuse or minor resistance to an arrest. In other words, agencies must include in this section all assaults on officers, whether or not the officers sustained injuries."If you have any questions, comments, or suggestions please contact me at jkkaplan6@gmail.com

For a comprehensive guide to this data and other UCR data, please see my book at ucrbook.comVersion 12 release notes:Adds 2021 data.Version 11 release notes:Adds 2020 data. Please note that the FBI has retired UCR data ending in 2020 data so this will (probably, I haven't seen confirmation either way) be the last LEOKA data they release. Changes .rda file to .rds.Version 10 release notes:Changes release notes description, does not change data.Version 9 release notes:Adds data for 2019.Version 8 release notes:Fix bug for years 1960-1971 where the number of months reported variable was incorrectly down by 1 month. I recommend caution when using these years as they only report either 0 or 12 months of the year, which differs from every other year in the data. Added the variable officers_killed_total which is the sum of officers_killed_by_felony and officers_killed_by_accident.Version 7 release notes:Adds data from 2018Version 6 release notes:Adds data in the following formats: SPSS and Excel.Changes project name to avoid confusing this data for the ones done by NACJD.Version 5 release notes: Adds data for 1960-1974 and 2017. Note: many columns (including number of female officers) will always have a value of 0 for years prior to 1971. This is because those variables weren't collected prior to 1971. These should be NA, not 0 but I'm keeping it as 0 to be consistent with the raw data. Removes support for .csv and .sav files.Adds a number_of_months_reported variable for each agency-year. A month is considered reported if the month_indicator column for that month has a value of "normal update" or "reported, not data."The formatting of the monthly data has changed from wide to long. This means that each agency-month has a single row. The old data had each agency being a single row with each month-category (e.g. jan_officers_killed_by_felony) being a column. Now there will just be a single column for each category (e.g. officers_killed_by_felony) and the month can be identified in the month column. This also results in most column names changing. As such, be careful when aggregating the monthly data since some variables are the same every month (e.g. number of officers employed is measured annually) so aggregating will be 12 times as high as the real value for those variables. Adds a date column. This date column is always set to the first of the month. It is NOT the date that a crime occurred or was reported. It is only there to make it easier to create time-series graphs that require a date input.All the data in this version was acquired from the FBI as text/DAT files and read into R using the package asciiSetupReader. The FBI also provided a PDF file explaining how to create the setup file to read the data. Both the FBI's PDF and the setup file I made are included in the zip files. Data is the same as from NACJD but using all FBI files makes cleaning easier as all column names are already identical. Version 4 release notes: Add data for 2016.Order rows by year (descending) and ORI.Version 3 release notes: Fix bug where Philadelphia Police Department had incorrect FIPS county code. The LEOKA data sets contain highly detailed data about the number of officers/civilians employed by an agency and how many officers were killed or assaulted. All the data was acquired from the FBI as text/DAT files and read into R using the package asciiSetupReader. The FBI also provided a PDF file explaining how to create the setup file to read the data. Both the FBI's PDF and the setup file I made are included in the zip files. About 7% of all agencies in the data report more officers or civilians than population. As such, I removed the officers/civilians per 1,000 population variables. You should exercise caution if deciding to generate and use these variables yourself. Several agency had impossible large (>15) officer deaths in a single month. For those months I changed the value to NA. The UCR Handbook (https://ucr.fbi.gov/additional-ucr-publications/ucr_handbook.pdf/view) describes the LEOKA data as follows:"The UCR Program collects data from all contributing agencies ... on officer line-of-duty deaths and assaults. Reporting agencies must submit data on ... their own duly sworn officers feloniously or accidentally killed or assaulted in the line of duty. The purpose of this data collection is to identify situations in which

Since 1930, the Federal Bureau of Investigation has compiled the Uniform Crime Reports (UCR) to serve as a periodic nationwide assessment of reported crimes not available elsewhere in the criminal justice system. Each year, this information is reported in four types of files: (1) Offenses Known and Clearances by Arrest, (2) Property Stolen and Recovered, (3) Supplementary Homicide Reports (SHR), and (4) Police Employee (LEOKA) Data. The Police Employee (LEOKA) Data provide information about law enforcement officers killed or assaulted (hence the acronym, LEOKA) in the line of duty. The variables created from the LEOKA forms provide in-depth information on the circumstances surrounding killings or assaults, including type of call answered, type of weapon used, and type of patrol the officers were on.

Version 3 release notes:

• Fix bug where Philadelphia Police Department had incorrect FIPS county code.

The LEOKA data sets contain highly detailed data about the number of officers/civilians employed by an agency and how many officers were killed or assaulted. Each data set contains over 2,200 columns and has a wealth of information about the circumstances of assaults on officers.

All the data was downloaded from NACJD as ASCII+SPSS Setup files and read into R using the package asciiSetupReader. It was then cleaned in R. The "cleaning" just means that column names were standardized (different years have slightly different spellings for many columns). Standardization of column names is necessary to stack multiple years together. Categorical variables (e.g. state) were also standardized (i.e. fix spelling errors).

About 7% of all agencies in the data report more officers or civilians than population. As such, I removed the officers/civilians per 1,000 population variables. You should exercise caution if deciding to generate and use these variables yourself.

I did not make any changes to the numeric columns except for the following. A few years of data had the values "blank" or "missing" as indicators of missing values. Rows in otherwise numeric columns (e.g. jan_asslt_no_injury_knife) with these values were replaced with NA. There were three obvious data entry errors in officers killed by felony/accident that I changed to NA.

In 1978 the agency "pittsburgh" (ORI = PAPPD00) reported 576 officers killed by accident during March.
In 1979 the agency "metuchen" (ORI = NJ01210) reported 991 officers killed by felony during August.
In 1990 the agency "penobscot state police" (ORI = ME010SP) reported 860 officers killed by accident during July.

No other changes to numeric columns were made.

Each zip file contains all years as individual monthly files of the specified data type It also includes a file with all years aggregated yearly and stacked into a single data set. Please note that each monthly file is quite large (2,200+ columns) so it may take time to download the zip file and open each data file.

For the R code used to clean this data, see here. https://github.com/jacobkap/crime_data.

The UCR Handbook (https://ucr.fbi.gov/additional-ucr-publications/ucr_handbook.pdf/view) describes the LEOKA data as follows:

"The UCR Program collects data from all contributing agencies ... on officer line-of-duty deaths and assaults. Reporting agencies must submit data on ... their own duly sworn officers feloniously or accidentally killed or assaulted in the line of duty. The purpose of this data collection is to identify situations in which officers are killed or assaulted, describe the incidents statistically, and publish the data to aid agencies in developing policies to improve officer safety.

"... agencies must record assaults on sworn officers. Reporting agencies must count all assaults that resulted in serious injury or assaults in which a weapon was used that could have caused serious injury or death. They must include other assaults not causing injury if the assault involved more than mere verbal abuse or minor resistance to an arrest. In other words, agencies must include in this section all assaults on officers, whether or not the officers sustained injuries."

If you have any questions, comments, or suggestions please contact me at jkkaplan6@gmail.com

The 2014 killing of Michael Brown in Ferguson, Missouri, began the protest movement culminating in Black Lives Matter and an increased focus on police accountability nationwide.

Since Jan. 1, 2015, The Washington Post has been compiling a database of every fatal shooting in the US by a police officer in the line of duty. It's difficult to find reliable data from before this period, as police killings haven't been comprehensively documented, and the statistics on police brutality are much less available. As a result, a vast number of cases go unreported.

The Washington Post is tracking more than a dozen details about each killing - including the race, age and gender of the deceased, whether the person was armed, and whether the victim was experiencing a mental-health crisis. They have gathered this information from law enforcement websites, local new reports, social media, and by monitoring independent databases such as "Killed by police" and "Fatal Encounters". The Post has also conducted additional reporting in many cases.

There are four additional datasets. These are US census data on poverty rate, high school graduation rate, median household income, and racial demographics.

Source of census data: https://factfinder.census.gov/faces/nav/jsf/pages/community_facts.xhtml

Abstract (en): For any questions about this data please email me at jacob@crimedatatool.com. If you use this data, please cite it.Version 7 release notes:Add data from 2018Version 6 release notes:Adds data in the following formats: SPSS and Excel.Changes project name to avoid confusing this data for the ones done by NACJD.Version 5 release notes: Adds data for 1960-1974 and 2017. Note: many columns (including number of female officers) will always have a value of 0 for years prior to 1971.Removes support for .csv and .sav files.Adds a number_of_months_reported variable for each agency-year. A month is considered reported if the month_indicator column for that month has a value of "normal update" or "reported, not data."The formatting of the monthly data has changed from wide to long. This means that each agency-month has a single row. The old data had each agency being a single row with each month-category (e.g. jan_officers_killed_by_felony) being a column. Now there will just be a single column for each category (e.g. officers_killed_by_felony) and the month can be identified in the month column. This also results in most column names changing. As such, be careful when aggregating the monthly data since some variables are the same every month (e.g. number of officers employed is measured annually) so aggregating will be 12 times as high as the real value for those variables. Adds a date column. This date column is always set to the first of the month. It is NOT the date that a crime occurred or was reported. It is only there to make it easier to create time-series graphs that require a date input.All the data in this version was acquired from the FBI as text/DAT files and read into R using the package asciiSetupReader. The FBI also provided a PDF file explaining how to create the setup file to read the data. Both the FBI's PDF and the setup file I made are included in the zip files. Data is the same as from NACJD but using all FBI files makes cleaning easier as all column names are already identical. Version 4 release notes: Add data for 2016.Order rows by year (descending) and ORI.Version 3 release notes: Fix bug where Philadelphia Police Department had incorrect FIPS county code. The LEOKA data sets contain highly detailed data about the number of officers/civilians employed by an agency and how many officers were killed or assaulted. All the data was acquired from the FBI as text/DAT files and read into R using the package asciiSetupReader. The FBI also provided a PDF file explaining how to create the setup file to read the data. Both the FBI's PDF and the setup file I made are included in the zip files. About 7% of all agencies in the data report more officers or civilians than population. As such, I removed the officers/civilians per 1,000 population variables. You should exercise caution if deciding to generate and use these variables yourself. Several agency had impossible large (>15) officer deaths in a single month. For those months I changed the value to NA. See the R code for a complete list. For the R code used to clean this data, see here. https://github.com/jacobkap/crime_data.The UCR Handbook (https://ucr.fbi.gov/additional-ucr-publications/ucr_handbook.pdf/view) describes the LEOKA data as follows:"The UCR Program collects data from all contributing agencies ... on officer line-of-duty deaths and assaults. Reporting agencies must submit data on ... their own duly sworn officers feloniously or accidentally killed or assaulted in the line of duty. The purpose of this data collection is to identify situations in which officers are killed or assaulted, describe the incidents statistically, and publish the data to aid agencies in developing policies to improve officer safety."... agencies must record assaults on sworn officers. Reporting agencies must count all assaults that resulted in serious injury or assaults in which a weapon was used that could have caused serious injury or death. They must include other assaults not causing injury if the assault involved more than mere verbal abuse or minor resistance to an arrest. In other words, agencies must include in this section all assaults on officers, whether or not the officers sustained injuries." Law enforcement agencies in the United States.Smallest Geographic Unit: Police agency jurisdiction

Version 5 release notes: Adds data for 1960-1974 and 2017. Note: many columns (including number of female officers) will always have a value of 0 for years prior to 1971.Removes support for .csv and .sav files.Adds a number_of_months_reported variable for each agency-year. A month is considered reported if the month_indicator column for that month has a value of "normal update" or "reported, not data."The formatting of the monthly data has changed from wide to long. This means that each agency-month has a single row. The old data had each agency being a single row with each month-category (e.g. jan_officers_killed_by_felony) being a column. Now there will just be a single column for each category (e.g. officers_killed_by_felony) and the month can be identified in the month column. This also results in most column names changing. As such, be careful when aggregating the monthly data since some variables are the same every month (e.g. number of officers employed is measured annually) so aggregating will be 12 times as high as the real value for those variables. Adds a date column. This date column is always set to the first of the month. It is NOT the date that a crime occurred or was reported. It is only there to make it easier to create time-series graphs that require a date input.All the data in this version was acquired from the FBI as text/DAT files and read into R using the package asciiSetupReader. The FBI also provided a PDF file explaining how to create the setup file to read the data. Both the FBI's PDF and the setup file I made are included in the zip files. Data is the same as from NACJD but using all FBI files makes cleaning easier as all column names are already identical. Version 4 release notes: Add data for 2016.Order rows by year (descending) and ORI.Version 3 release notes: Fix bug where Philadelphia Police Department had incorrect FIPS county code. The LEOKA data sets contain highly detailed data about the number of officers/civilians employed by an agency and how many officers were killed or assaulted. All the data was acquired from the FBI as text/DAT files and read into R using the package asciiSetupReader. The FBI also provided a PDF file explaining how to create the setup file to read the data. Both the FBI's PDF and the setup file I made are included in the zip files. About 7% of all agencies in the data report more officers or civilians than population. As such, I removed the officers/civilians per 1,000 population variables. You should exercise caution if deciding to generate and use these variables yourself. Several agency had impossible large (>15) officer deaths in a single month. For those months I changed the value to NA. See the R code for a complete list. For the R code used to clean this data, see here. https://github.com/jacobkap/crime_data.The UCR Handbook (https://ucr.fbi.gov/additional-ucr-publications/ucr_handbook.pdf/view) describes the LEOKA data as follows:"The UCR Program collects data from all contributing agencies ... on officer line-of-duty deaths and assaults. Reporting agencies must submit data on ... their own duly sworn officers feloniously or accidentally killed or assaulted in the line of duty. The purpose of this data collection is to identify situations in which officers are killed or assaulted, describe the incidents statistically, and publish the data to aid agencies in developing policies to improve officer safety."... agencies must record assaults on sworn officers. Reporting agencies must count all assaults that resulted in serious injury or assaults in which a weapon was used that could have caused serious injury or death. They must include other assaults not causing injury if the assault involved more than mere verbal abuse or minor resistance to an arrest. In other words, agencies must include in this section all assaults on officers, whether or not the officers sustained injuries."If you have any questions, comments, or suggestions please contact me at jkkaplan6@gmail.com

List of every shooting incident that occurred in NYC during the current calendar year.

This is a breakdown of every shooting incident that occurred in NYC during the current calendar year. This data is manually extracted every quarter and reviewed by the Office of Management Analysis and Planning before being posted on the NYPD website. Each record represents a shooting incident in NYC and includes information about the event, the location and time of occurrence. In addition, information related to suspect and victim demographics is also included. This data can be used by the public to explore the nature of police enforcement activity. Please refer to the attached data footnotes for additional information about this dataset.

This dataset contains individual-level homicide and non-fatal shooting victimizations, including homicide data from 1991 to the present, and non-fatal shooting data from 2010 to the present (2010 is the earliest available year for shooting data). This dataset includes a "GUNSHOT_INJURY_I " column to indicate whether the victimization involved a shooting, showing either Yes ("Y"), No ("N"), or Unknown ("UKNOWN.") For homicides, injury descriptions are available dating back to 1991, so the "shooting" column will read either "Y" or "N" to indicate whether the homicide was a fatal shooting or not. For non-fatal shootings, data is only available as of 2010. As a result, for any non-fatal shootings that occurred from 2010 to the present, the shooting column will read as “Y.” Non-fatal shooting victims will not be included in this dataset prior to 2010; they will be included in the authorized-access dataset, but with "UNKNOWN" in the shooting column. Each row represents a single victimization, i.e., a unique event when an individual became the victim of a homicide or non-fatal shooting. Each row does not represent a unique victim—if someone is victimized multiple times there will be multiple rows for each of those distinct events. The dataset is refreshed daily, but excludes the most recent complete day to allow the Chicago Police Department (CPD) time to gather the best available information. Each time the dataset is refreshed, records can change as CPD learns more about each victimization, especially those victimizations that are most recent. The data on the Mayor's Office Violence Reduction Dashboard is updated daily with an approximately 48-hour lag. As cases are passed from the initial reporting officer to the investigating detectives, some recorded data about incidents and victimizations may change once additional information arises. Regularly updated datasets on the City's public portal may change to reflect new or corrected information. A version of this dataset with additional crime types is available by request. To make a request, please email dataportal@cityofchicago.org with the subject line: Violence Reduction Victims Access Request. Access will require an account on this site, which you may create at https://data.cityofchicago.org/signup. How does this dataset classify victims? The methodology by which this dataset classifies victims of violent crime differs by victimization type: Homicide and non-fatal shooting victims: A victimization is considered a homicide victimization or non-fatal shooting victimization depending on its presence in CPD's homicide victims data table or its shooting victims data table. A victimization is considered a homicide only if it is present in CPD's homicide data table, while a victimization is considered a non-fatal shooting only if it is present in CPD's shooting data tables and absent from CPD's homicide data table. To determine the IUCR code of homicide and non-fatal shooting victimizations, we defer to the incident IUCR code available in CPD's Crimes, 2001-present dataset (available on the City's open data portal). If the IUCR code in CPD's Crimes dataset is inconsistent with the homicide/non-fatal shooting categorization, we defer to CPD's Victims dataset. For a criminal homicide, the only sensible IUCR codes are 0110 (first-degree murder) or 0130 (second-degree murder). For a non-fatal shooting, a sensible IUCR code must signify a criminal sexual assault, a robbery, or, most commonly, an aggravated battery. In rare instances, the IUCR code in CPD's Crimes and Victims dataset do not align with the homicide/non-fatal shooting categorization: In instances where a homicide victimization does not correspond to an IUCR code 0110 or 0130, we set the IUCR code to "01XX" to indicate that the victimization was a homicide but we do not know whether it was a fi

The Counted is a project by the Guardian – and you – working to count the number of people killed by police and other law enforcement agencies in the United States throughout 2015 and 2016, to monitor their demographics and to tell the stories of how they died.

The database will combine Guardian reporting with verified crowdsourced information to build a more comprehensive record of such fatalities. The Counted is the most thorough public accounting for deadly use of force in the US, but it will operate as an imperfect work in progress – and will be updated by Guardian reporters and interactive journalists as frequently and as promptly as possible.

Analysis of ‘🚓 Fatal Police Shootings’ provided by Analyst-2 (analyst-2.ai), based on source dataset retrieved from https://www.kaggle.com/yamqwe/fatal-police-shootingse on 13 February 2022.

--- Dataset description provided by original source is as follows ---

About this dataset

The Washington Post has tracked fatal police shootings in the US since 2015, using news and police reports as well as social media and databases like Killed by Police and Fatal Encounters.

The collected data include the race, gender, and age of the deceased, the circumstances of the shooting, and whether the person was armed or experiencing a mental-health crisis.

The Washington Post updates visualizations of the data and provides more information about methodology on the Fatal Force page.

Source: https://github.com/washingtonpost/data-police-shootings
Updated: synced daily
License: CC BY-NC-SA

This dataset was created by Data Society and contains around 7000 samples along with Is Geocoding Exact, Armed, technical information and other features such as: - Body Camera - State - and more.

How to use this dataset

• Analyze Latitude in relation to Manner Of Death
• Study the influence of Name on Age
• More datasets

Acknowledgements

If you use this dataset in your research, please credit Data Society

Start A New Notebook!

--- Original source retains full ownership of the source dataset ---

A. SUMMARY This table contains all fatalities resulting from a traffic crash in the City of San Francisco. Fatality year-to-date crash data is obtained from the Office of the Chief Medical Examiner (OME) death records, and only includes those cases that meet the San Francisco Vision Zero Fatality Protocol maintained by the San Francisco Department of Public Health (SFDPH), San Francisco Police Department (SFPD), and San Francisco Municipal Transportation Agency (SFMTA). Injury crash data is obtained from SFPD’s Interim Collision System for 2018 to YTD, Crossroads Software Traffic Collision Database (CR) for years 2013-2017 and the Statewide Integrated Transportation Record System (SWITRS) maintained by the California Highway Patrol for all years prior to 2013. Only crashes with valid geographic information are mapped. All geocodable crash data is represented on the simplified San Francisco street centerline model maintained by the Department of Public Works (SFDPW). Collision injury data is queried and aggregated on a quarterly basis. Crashes occurring at complex intersections with multiple roadways are mapped onto a single point and injury and fatality crashes occurring on highways are excluded. The fatality table contains information about each party injured or killed in the collision, including any passengers. B. HOW THE DATASET IS CREATED Traffic crash injury data is collected from the California Highway Patrol 555 Crash Report as submitted by the police officer within 30 days after the crash occurred. All fields that match the SWITRS data schema are programmatically extracted, de-identified, geocoded, and loaded into TransBASE. See Section D below for details regarding TransBASE. This table is filtered for fatal traffic crashes. C. UPDATE PROCESS After review by SFPD and SFDPH staff, the data is made publicly available approximately a month after the end of the previous quarter (May for Q1, August for Q2, November for Q3, and February for Q4). D. HOW TO USE THIS DATASET This data is being provided as public information as defined under San Francisco and California public records laws. SFDPH, SFMTA, and SFPD cannot limit or restrict the use of this data or its interpretation by other parties in any way. Where the data is communicated, distributed, reproduced, mapped, or used in any other way, the user should acknowledge the Vision Zero initiative and the TransBASE database as the source of the data, provide a reference to the original data source where also applicable, include the date the data was pulled, and note any caveats specified in the associated metadata documentation provided. However, users should not attribute their analysis or interpretation of this data to the City of San Francisco. While the data has been collected and/or produced for the use of the City of San Francisco, it cannot guarantee its accuracy or completeness. Accordingly, the City of San Francisco, including SFDPH, SFMTA, and SFPD make no representation as to the accuracy of the information or its suitability for any purpose and disclaim any liability for omissions or errors that may be contained therein. As all data is associated with methodological assumptions and limitations, the City recommends that users review methodological documentation associated with the data prior to its analysis, interpretation, or communication. TransBASE is a geospatially enabled database maintained by SFDPH that currently includes over 200 spatially referenced variables from multiple agencies and across a range of geographic scales, including infrastructure, transportation, zoning, sociodemographic, and collision data, all linked to an intersection or street segment. TransBASE facilitates a data-driven approach to understanding and addressing transportation-related health issues, informed by a large and growing evidence base regarding the importance of transportation system design and land u

This dataset contains aggregate data on violent index victimizations at the quarter level of each year (i.e., January – March, April – June, July – September, October – December), from 2001 to the present (1991 to present for Homicides), with a focus on those related to gun violence. Index crimes are 10 crime types selected by the FBI (codes 1-4) for special focus due to their seriousness and frequency. This dataset includes only those index crimes that involve bodily harm or the threat of bodily harm and are reported to the Chicago Police Department (CPD). Each row is aggregated up to victimization type, age group, sex, race, and whether the victimization was domestic-related. Aggregating at the quarter level provides large enough blocks of incidents to protect anonymity while allowing the end user to observe inter-year and intra-year variation. Any row where there were fewer than three incidents during a given quarter has been deleted to help prevent re-identification of victims. For example, if there were three domestic criminal sexual assaults during January to March 2020, all victims associated with those incidents have been removed from this dataset. Human trafficking victimizations have been aggregated separately due to the extremely small number of victimizations.

This dataset includes a " GUNSHOT_INJURY_I " column to indicate whether the victimization involved a shooting, showing either Yes ("Y"), No ("N"), or Unknown ("UKNOWN.") For homicides, injury descriptions are available dating back to 1991, so the "shooting" column will read either "Y" or "N" to indicate whether the homicide was a fatal shooting or not. For non-fatal shootings, data is only available as of 2010. As a result, for any non-fatal shootings that occurred from 2010 to the present, the shooting column will read as “Y.” Non-fatal shooting victims will not be included in this dataset prior to 2010; they will be included in the authorized dataset, but with "UNKNOWN" in the shooting column.

The dataset is refreshed daily, but excludes the most recent complete day to allow CPD time to gather the best available information. Each time the dataset is refreshed, records can change as CPD learns more about each victimization, especially those victimizations that are most recent. The data on the Mayor's Office Violence Reduction Dashboard is updated daily with an approximately 48-hour lag. As cases are passed from the initial reporting officer to the investigating detectives, some recorded data about incidents and victimizations may change once additional information arises. Regularly updated datasets on the City's public portal may change to reflect new or corrected information.

How does this dataset classify victims?

The methodology by which this dataset classifies victims of violent crime differs by victimization type:

Homicide and non-fatal shooting victims: A victimization is considered a homicide victimization or non-fatal shooting victimization depending on its presence in CPD's homicide victims data table or its shooting victims data table. A victimization is considered a homicide only if it is present in CPD's homicide data table, while a victimization is considered a non-fatal shooting only if it is present in CPD's shooting data tables and absent from CPD's homicide data table.

To determine the IUCR code of homicide and non-fatal shooting victimizations, we defer to the incident IUCR code available in CPD's Crimes, 2001-present dataset (available on the City's open data portal). If the IUCR code in CPD's Crimes dataset is inconsistent with the homicide/non-fatal shooting categorization, we defer to CPD's Victims dataset.

For a criminal homicide, the only sensible IUCR codes are 0110 (first-degree murder) or 0130 (second-degree murder). For a non-fatal shooting, a sensible IUCR code must signify a criminal sexual assault, a robbery, or, most commonly, an aggravated battery. In rare instances, the IUCR code in CPD's Crimes and Victims dataset do not align with the homicide/non-fatal shooting categorization:

1. In instances where a homicide victimization does not correspond to an IUCR code 0110 or 0130, we set the IUCR code to "01XX" to indicate that the victimization was a homicide but we do not know whether it was a first-degree murder (IUCR code = 0110) or a second-degree murder (IUCR code = 0130).
2. When a non-fatal shooting victimization does not correspond to an IUCR code that signifies a criminal sexual assault, robbery, or aggravated battery, we enter “UNK” in the IUCR column, “YES” in the GUNSHOT_I column, and “NON-FATAL” in the PRIMARY column to indicate that the victim was non-fatally shot, but the precise IUCR code is unknown.

Other violent crime victims: For other violent crime types, we refer to the IUCR classification that exists in CPD's victim table, with only one exception:

1. When there is an incident that is associated with no victim with a matching IUCR code, we assume that this is an error. Every crime should have at least 1 victim with a matching IUCR code. In these cases, we change the IUCR code to reflect the incident IUCR code because CPD's incident table is considered to be more reliable than the victim table.

Note: All businesses identified as victims in CPD data have been removed from this dataset.

Note: The definition of “homicide” (shooting or otherwise) does not include justifiable homicide or involuntary manslaughter. This dataset also excludes any cases that CPD considers to be “unfounded” or “noncriminal.”

Note: In some instances, the police department's raw incident-level data and victim-level data that were inputs into this dataset do not align on the type of crime that occurred. In those instances, this dataset attempts to correct mismatches between incident and victim specific crime types. When it is not possible to determine which victims are associated with the most recent crime determination, the dataset will show empty cells in the respective demographic fields (age, sex, race, etc.).

Note: The initial reporting officer usually asks victims to report demographic data. If victims are unable to recall, the reporting officer will use their best judgment. “Unknown” can be reported if it is truly unknown.

The Uniform Crime Reporting Program Data, Police Employee Data, 2015 file contains monthly data on felonious or accidental killings and assaults upon United States law enforcement officers acting in the line of duty. The Federal Bureau of Investigation (FBI) assembled the data and processed them from UCR Master Police Employee (LEOKA) data tapes. Each agency record in the file includes the following summary variables: state code, population group code, geographic division, Metropolitan Statistical Area code, and agency name. These variables afford considerable flexibility in creating subsets or aggregations of the data. Since 1930, the Federal Bureau of Investigation has compiled the Uniform Crime Reports (UCR) to serve as a periodic nationwide assessment of reported crimes not available elsewhere in the criminal justice system. Each year, this information is reported in four types of files: (1) Offenses Known and Clearances by Arrest, (2) Property Stolen and Recovered, (3) Supplementary Homicide Reports (SHR), and (4) Police Employee (LEOKA) Data. The Police Employee (LEOKA) Data provide information about law enforcement officers killed or assaulted (hence the acronym, LEOKA) in the line of duty. The variables created from the LEOKA forms provide in-depth information on the circumstances surrounding killings or assaults, including type of call answered, type of weapon used, and type of patrol the officers were on.

This dataset includes all criminal offenses reported to the Colorado Springs Police Department. Each case report (incident) may have several offenses. Each offense may have multiple suspects and/or victims.

Important: This dataset provided by CSPD does not apply the same counting rules as official data reported to the Colorado Bureau of Investigations and the Federal Bureau of Investigation. This means comparisons to those datasets would be inaccurate.

This data serves two primary purposes: (1) to report the number of employees in each law enforcement agency, categorized by sworn officers and civilian employees, as well as by sex; and (2) to track the number of officers assaulted or killed each month. Employee counts are reported annually, providing agency-level totals without intra-year fluctuations. Assault data includes details on shift type (e.g., alone, with a partner, on foot, in a vehicle), the offender’s weapon, and the type of call (e.g., robbery, disturbance, traffic stop). Fatality data distinguishes between felonious deaths (i.e., murders) and accidental deaths.

Note: Due to a system migration, this data will cease to update on March 14th, 2023. The current projection is to restart the updates within 30 days of the system migration, on or around April 13th, 2023Incidents of Officers assaulted by individuals since 2010.Data Dictionary:ID - the row numberDATE_REPORTED - the date the incident was reported to LMPDDATE_OCCURED - the date the incident actually occurredCRIME_TYPE - the crime type category (assault or homicide)NIBRS_CODE - the code that follows the guidelines of the National Incident Based Reporting System. For more details visit https://ucr.fbi.gov/nibrs/2011/resources/nibrs-offense-codes/viewUCR_HIERARCHY - hierarchy that follows the guidelines of the FBI Uniform Crime Reporting. For more details visit https://ucr.fbi.gov/ATT_COMP - Status indicating whether the incident was an attempted crime or a completed crime.LMPD_DIVISION - the LMPD division in which the incident actually occurredLMPD_BEAT - the LMPD beat in which the incident actually occurredPREMISE_TYPE - the type of location in which the incident occurred (e.g. Restaurant)BLOCK_ADDRESS - the location the incident occurredUOR_DESC - Uniform Offense Reporting code for the criminal act committedLEOKA_APPLIES - whether or not the incident is reported to the Center for the Study of Law Enforcement Officers Killed and Assaulted (LEOKA). For more information visit https://leoka.org/OFFICER_KILLED - whether or not an officer was killed due to the incidentTYPE_OF_ASSIGNMENT - how the officer was assigned at the time of the incident (e.g. ONE-MAN VEHICLE ALONE (UNIFORMED OFFICER))TYPE_OF_ACTIVITY - the type of activity the officer was doing at the time of the incident (e.g. RESPONDING TO DISTURBANCE CALLS)OFFENSE_CITY - the city associated to the incident block locationOFFENSE_ZIP - the zip code associated to the incident block location

This dataset reflects reported incidents of crime (with the exception of murders where data exists for each victim) that occurred in the City of Chicago from 2001 to present, minus the most recent seven days. Data is extracted from the Chicago Police Department's CLEAR (Citizen Law Enforcement Analysis and Reporting) system. In order to protect the privacy of crime victims, addresses are shown at the block level only and specific locations are not identified. Should you have questions about this dataset, you may contact the Research & Development Division of the Chicago Police Department at 312.745.6071 or RandD@chicagopolice.org. Disclaimer: These crimes may be based upon preliminary information supplied to the Police Department by the reporting parties that have not been verified. The preliminary crime classifications may be changed at a later date based upon additional investigation and there is always the possibility of mechanical or human error. Therefore, the Chicago Police Department does not guarantee (either expressed or implied) the accuracy, completeness, timeliness, or correct sequencing of the information and the information should not be used for comparison purposes over time. The Chicago Police Department will not be responsible for any error or omission, or for the use of, or the results obtained from the use of this information. All data visualizations on maps should be considered approximate and attempts to derive specific addresses are strictly prohibited. The Chicago Police Department is not responsible for the content of any off-site pages that are referenced by or that reference this web page other than an official City of Chicago or Chicago Police Department web page. The user specifically acknowledges that the Chicago Police Department is not responsible for any defamatory, offensive, misleading, or illegal conduct of other users, links, or third parties and that the risk of injury from the foregoing rests entirely with the user. The unauthorized use of the words "Chicago Police Department," "Chicago Police," or any colorable imitation of these words or the unauthorized use of the Chicago Police Department logo is unlawful. This web page does not, in any way, authorize such use. Data is updated daily Tuesday through Sunday. The dataset contains more than 65,000 records/rows of data and cannot be viewed in full in Microsoft Excel. Therefore, when downloading the file, select CSV from the Export menu. Open the file in an ASCII text editor, such as Wordpad, to view and search. To access a list of Chicago Police Department - Illinois Uniform Crime Reporting (IUCR) codes, go to http://data.cityofchicago.org/Public-Safety/Chicago-Police-Department-Illinois-Uniform-Crime-R/c7ck-438e