Crime Hotspot Mapping for Developers: Kernel Density, Hex Grids, and What Makes a Map Meaningful

A pin map is not a hotspot map. Kernel density estimation, hex grid aggregation, and bin selection all produce dramatically different pictures from the same underlying incident data — and most of the crime maps deployed by apps, news organizations, and government agencies are wrong in ways that developers can avoid.

Most crime maps are pin maps. Every incident gets a dot. Zoom out and the dots stack into a dark smear over downtown. Zoom in and you can see individual incidents with enough precision to infer addresses. Neither view is especially useful, and neither is what researchers mean when they talk about crime hotspot analysis.

The distinction matters because developers building on crime data APIs often default to pin maps — they're easy to implement and visually compelling. But for any application where decisions depend on understanding geographic risk (real estate search, family safety alerts, corporate travel risk, insurance underwriting), pin maps mislead more than they inform. They suggest a precision the data doesn't have, create privacy risks around victim location disclosure, and fail to distinguish areas of genuinely elevated risk from areas that simply have more people and more reported activity.

This post walks through the core techniques behind meaningful hotspot maps: what they do, where each fails, and how developers working with address-level crime data can build something more defensible.

What a Hotspot Actually Means

A hotspot is a geographic area where crime rates exceed what would be expected given the distribution of criminogenic opportunity. That last phrase matters. Areas with more people, more commercial activity, and more foot traffic will naturally generate more incidents — not because they're “dangerous” in any absolute sense, but because there's more exposure. A useful hotspot map accounts for opportunity; a misleading one treats raw incident counts as a risk signal.

Most published crime maps do not account for opportunity. They show where incidents happened, not where the rate of incidents per unit of exposure was elevated. The result is that dense urban cores appear dangerous by definition, while low-density areas appear safe — regardless of actual victimization rates. For applications targeting real estate decisions or neighborhood safety comparisons, that framing is close to useless.

Kernel Density Estimation: The Method Behind the Heatmap

Kernel density estimation (KDE) is the most common method used to convert point incident data into a continuous surface. The approach places a kernel — typically a symmetric probability density function — over each incident location and sums the overlapping kernels across a raster grid. The result is a smooth surface showing incident density across space.

KDE is the technique behind the “heat” in crime heatmaps. Most mapping libraries offer it out of the box: Mapbox has a heatmap layer type, Leaflet has the Leaflet.heat plugin, and Google Maps provides HeatmapLayer. All of them implement KDE under the hood.

The user-facing parameter that matters most is bandwidth — the radius of influence each incident exerts. Small bandwidth produces a spiky surface that closely follows individual incidents. Large bandwidth produces a smooth surface that may flatten meaningful differences between high- and low-crime areas. Neither extreme is wrong in an absolute sense, but both require explicit justification that almost no published crime map provides.

A practical default: bandwidth of 400–800 meters works well for city-scale crime mapping. At street level (zoom 15+), 200–300 meters better captures block-level variation. The key is documenting the choice and keeping it stable across zoom levels.

Hex Grid Aggregation: The H3 Alternative

An approach that has gained substantial adoption in spatial analysis is hexagonal grid aggregation — specifically using Uber's H3 geospatial indexing system, which divides the globe into a hierarchy of hexagonal cells at multiple resolutions.

The case for hexagonal grids over square grids or census geometry rests on three properties:

• Equal adjacency. Every hexagon has exactly six neighbors, all equidistant from the center. Square grids have four edge neighbors and four corner neighbors at different distances — an asymmetry that creates directional bias in any spatial analysis that weights neighbors.
• Shape efficiency. Among regular polygons that tessellate a plane, hexagons best approximate circles. This minimizes the edge effects that distort density estimates at cell boundaries.
• Consistent area. Unlike choropleth maps that use census boundaries (counties, tracts, ZIP codes — all different sizes), H3 cells have consistent area at each resolution level. A resolution-8 H3 cell covers approximately 0.74 km² everywhere in the world. That consistency makes comparisons across cities and regions mathematically valid.

For most crime mapping applications, resolution 9 provides meaningful block-level aggregation that preserves geographic privacy while still revealing concentration patterns. Resolution 8 surfaces neighborhood-level trends suitable for city-scale comparisons.

The limitation is that aggregation always loses information. If you need to display individual incidents — for legal, journalistic, or compliance reasons — hex grid aggregation is the wrong tool. If you need to show patterns of risk for decision-making, it is almost always the right one.

Three Ways Maps Mislead Even When the Math Is Right

Technical correctness in the aggregation method is necessary but not sufficient. Three presentation choices routinely produce misleading crime maps from technically sound underlying analysis:

1. Area Inflation

Choropleth maps — where geographic areas are colored by incident count or rate — inflate the apparent crime problem in large rural areas. A county covering 400 square miles with 18 homicides will dominate a choropleth map of a metro region, even if a 3-square-mile urban neighborhood has a rate four times higher. Area is not risk. At minimum, normalize by residential population. For commercial applications, normalizing by daytime population estimates or foot traffic proxies produces a more accurate risk surface.

2. Bin Selection

Most choropleth maps divide data into color bins using equal-interval or quantile classification. Neither is universally correct, and the choice dramatically changes the visual message. Equal-interval bins applied to a skewed crime distribution (which most are) will show nearly all areas in the lowest category, with one or two extreme outliers. The same data with quantile bins will show apparent variation everywhere. The appropriate classification depends on what question you're asking — but almost no published crime map discloses which method was used, making the output unverifiable.

3. Temporal Stasis

Many maps display incidents from the past 12 months as if they represent current risk. A neighborhood with 20 robberies last year and 2 this year looks identical to one with 20 and 20. Time-weighting — giving more recent incidents higher weight in the density calculation — produces a surface that better represents current conditions. Exponential decay functions are standard, with a half-life parameter (typically 90–180 days) that controls how quickly old incidents lose influence. A 90-day half-life means an incident from 6 months ago contributes roughly 25% of the weight of a current incident — a defensible and easily explained methodology.

What the Underlying Data Determines

All of the above is irrelevant if the underlying incident data has systematic errors. Three problems appear frequently enough to require explicit handling before any visualization work begins:

Reporting bias. Crime maps reflect reported crime, not crime. Underreporting rates vary substantially by incident type — sexual assault is severely underreported; auto theft is reported at high rates because insurance requires it — and by geography. Neighborhoods with lower institutional trust in police report at lower rates, which depresses incident counts in ways that have nothing to do with actual victimization. Maps that present raw incident density as a risk signal without acknowledging this limitation imply a precision the data cannot support.

Geocoding artifacts. Many crime data feeds — including several major public feeds — geocode incidents to block centroids, intersection midpoints, or in some cases the police station address. The police station artifact is a well-documented problem: it shows up as an anomalous spike at the address of the precinct or headquarters in feeds that route ungeocoded incidents to a default location. Developers should verify the geocoding methodology of their data source before publishing any map that implies address-level precision.

Coverage gaps. Jurisdictions participate in crime data reporting at variable rates. A map that appears to show low crime in a region may show low data coverage. The 2021 transition to NIBRS reporting caused approximately 37% of the U.S. population to fall temporarily out of coverage in national datasets as agencies migrated. Local feeds have their own participation gaps, often undisclosed. Any application that displays a crime map owes its users a disclosure of which jurisdictions are and are not covered.

A Practical Checklist for Developers

For teams building on crime data APIs, a consistent set of implementation choices produces more defensible outputs:

When You Don't Need to Build the Map at All

For applications where the destination is a safety signal rather than a map — real estate search, route optimization, travel risk assessment, insurance underwriting — the methodology decisions described above can be delegated to the data layer rather than implemented at the application layer.

The SpotCrime API returns address-level incident data with consistent taxonomy across 22,000+ U.S. cities, normalized and verified to eliminate the geocoding artifacts and classification inconsistencies that distort raw feeds. The SpotScore™ neighborhood safety rating aggregates 36 months of incident history into block-level scores, applying time-weighting and opportunity normalization that would require significant engineering to replicate independently.

For teams that need to display spatial patterns rather than just consume risk scores, the incident API provides the source data; the mapping choices described here determine whether the output informs or misleads. The methodology is not optional — it is the product.