Crime-Analysis Use Case & Discovery
This document will follow a need discovered in
KDE (Kernel Density Estimation) has become the mainstay in crime analysis to determine clusters of events. There are many other tools that serve a similar need, but KDE is pervasive and what is commonly thought of as ‘hotspot mapping’. In the SARA model of community policing (Scan, Analyze, Respond, Assess), KDE fills the roll of Scanning and Assessment.
This tool is available in our Spatial Analyst extension, and it’s fairly simple.
When this tool is run on a point feature class (Assaults, Burglaries, IED’s, positive field identifications), a bell-shaped curve is draped over each point. The overall volume is summed and a raster surface is generated. This surface can be a component of a weighted overlay analysis (where many crime surfaces or other intelligence layers are complied) or the surface can be symbolized and stand on its own as an analysis result.
Figure 1 Profile View Explaining KDE
The tool has 2 variables that matter. Search Radius defines how wide the bell curves go from the point they’re draped over. The other is called ‘population’, but it means ‘weight’. There are potentially thousands of points, and it may be that some should have a higher weight. Auto thefts being worth 2 Auto burgs, for example.
Here’s a quick example- This is the Residential Burglary problem in Redlands right now. The surface is symbolized so that density peaks pop out in red. Pretty clear data product and depiction of the problem. Actionable in a briefing. This is made from 27 residential burglaries in a 3 month period. Some are individual points that aren’t depicted, but these clusters are the areas that immediately translate as problems.
Figure 2 Use of KDE to identify 'hotspots' of Residential Burglary
Any crime analysts create creates dozens of data products and discover actionable trends in only a few. The goal is to pick out a trend, and then try to determine a root cause for that trend. The clusters lead the conversation and then proves functional needs to incorporate more resources. Other know locational data to support investigation can be:
Home addresses of Arrestees
License-plate reader data
Animation is important in scanning as well. Hourly or monthly animations help scan and compare how big a problem is to past problems.
This is based on the Near-repeat phenomenon which states that ‘if the location is the target of a crime, such as burglary, nearby locations within the immediate vicinity have an increased chance of being burgled for a limited period of time’. A burglar feels confident around their surroundings, and the process of scoping out a house during a burglary helps them feel confident enough to repeat in that same house or one close to it.
The script that generated this video uses the weight field in new ways. When we make a KDE, we assume Tobler’s first law of geography: Everything is related to everything else, but near things are more related than distant things. The same can and should apply to time.
This script weights events that have occurred recently higher and allows the user to pick how the weight decays. Additionally, the script generates KDE’s from a start to an end date for animation to show the problem up to this point.
These densities can easily be brought into a time-enabled mosaic. The result is a series of ‘blooming’ problems that dissipate and occur somewhere else.
Applied to Fleet Tracking
This is 2.2 million points of an AVL dataset. Analysts are trying to understand police presence, and AVL data consists of a point every 5-15 seconds per officer (this varies). This rapidly produces a database that can be a little unwieldy (millions of records a month). Fleet presence becomes clearer through this tool.
Figure 3 Tool Variables
This tool provides the user with the opportunity to select the input feature layer, the Output Workspace, specify a query for an incident type, specify a start and end date, time span (in days), fall off type (either exponential, none or linear), a KDE cell size, search radius and AOI.
Figure 4 Date Range Selection
The script will perform the incident query and select incidents that range from Start Date to Start Date + Time Span (in days). The weight field is calculated for each selection, and does so according to a ‘fall off’ weighting model.
Figure 5 - Fall Off Types
After weighting, the script then produces a KDE surface using the calculated weight field as a ‘population’ variable in KDE. This places a higher weight for incidents that occur closer to Start Date + Time Span when using the Linear and Exponential Fall Off models. The surface is then saved with a name that reflects the Start Date, query type, fall off type and time span.
The tool then moves on to query Start Time+1 (day) to Start Time + Time Span+1(day), recalculate the weight and produce another surface to be stored in the Output Workspace. The script repeats this task until the End Date is reached by the Time Span (End Date-Time Span).
Depending on the variables, this can produce hundreds of surfaces. This can be a time-intensive geoprocessing task, but it’s reasonable to assume that individual surfaces can be added on a nightly basis to maintain an ongoing collection of surfaces.
Time-Enabled Mosaic for Surface Group Symbolization and Animation
Bringing hundreds of surfaces into a project and attempting to apply a common symbology to each can be a painful process. A Mosaic allows one common symbology to be applied to the group of surfaces.
Naming the surfaces with the date in the name allows an easy method to calculate the date for Time-Enabling the Mosaic. This allows a user to use the desktop time-slider to browse surfaces and visually inspect duration and placement of hotspots. Other workflows specific to law enforcement can be derived from this, but there’s a lot of potential use cases for other industries.