Fan Yang - MUSA 5080
  • Home
  • Weekly Notes
    • Week 1
    • Week 2
    • Week 3
    • Week 4
    • Week 5
    • Week 6
    • Week 7
    • Week 9
    • Week 10
    • Week 11
    • Week 12
  • Labs
    • Lab 1: Setup Instructions
    • Lab 2: Getting Started with dplyr
    • Lab 3: Data Visualization and EDA
    • Lab 4: Spatial Operations with Pennsylvania Data
  • Assignments
    • Assignment 1: Census Data Quality for Policy Decisions
    • Assignment 2: Spatial Analysis and Visualization
    • Assignment 4: Spatial Predictive Analysis
    • Assignment 5: Space-Time Prediction of Bike Share Demand
  • Final
    • Final Slides
    • Technical Appendix
    • README

On this page

  • Overview
    • Key Learning Objectives
  • The Critical Question
  • The Dirty Data Problem
    • What Is “Dirty Data”?
    • The Feedback Loop
    • Why “Cleaning” Data Isn’t Enough
  • Technical Foundations
    • Modeling Workflow
  • Local Moran’s I
    • Global vs. Local
    • Implementation
  • Count Regression
    • Why Not OLS?
    • Poisson Regression
    • Overdispersion
    • Negative Binomial
  • Spatial Cross-Validation
    • Why Standard CV Fails
    • LOGO-CV (Leave-One-Group-Out)
  • Comparison to KDE Baseline
    • Kernel Density Estimation
    • Hit Rate Evaluation
  • Critical Evaluation Framework
    • Questions to Ask
    • The Fundamental Question
    • What If We Predicted Differently?
  • Key Takeaways
    • Technical Skills
    • Critical Thinking
    • Remember

MUSA 5080 Notes #9

Week 9: Critical Perspectives on Predictive Policing

Author

Fan Yang

Published

November 3, 2025

Note

Week 9: Critical Perspectives on Predictive Policing
Date: 11/03/2025

Overview

This week we critically examined predictive policing systems, learning both the technical methods (count regression, KDE, spatial features) and the ethical concerns they raise. We explored the “dirty data” problem, learned Local Moran’s I for identifying hotspots, and discussed frameworks for evaluating whether such systems should be deployed.

Key Learning Objectives

  • Understand technical methods: count regression, KDE, spatial features
  • Critically evaluate the “dirty data” problem
  • Learn Local Moran’s I for identifying hotspots
  • Understand Poisson and Negative Binomial regression
  • Apply spatial cross-validation (LOGO-CV)
  • Develop frameworks for ethical evaluation

The Critical Question

“A statistically ‘good’ model can still be socially harmful.” - Richardson, Schultz & Crawford (2019)

Before asking HOW to build predictive policing systems, ask: SHOULD we?

The Dirty Data Problem

What Is “Dirty Data”?

Extended definition (Richardson et al. 2019): > “Data derived from or influenced by corrupt, biased, and unlawful practices, including data that has been intentionally manipulated or ‘juked,’ as well as data that is distorted by individual and societal biases.”

Forms: 1. Fabricated/Manipulated: False arrests, downgraded classifications 2. Systematically Biased: Over-policing → more recorded “crime” 3. Missing/Incomplete: Unreported crimes, ignored complaints 4. Proxy Problems: Arrests ≠ crimes, calls ≠ actual need

The Feedback Loop

Confirmation Bias Loop: - Algorithm learns: “Crime happens in neighborhood X” - Police sent to X → More arrests in X - Algorithm “confirmed”: “We were right!” - Cycle intensifies

Why “Cleaning” Data Isn’t Enough

Crime data is ALWAYS: - Socially constructed - Selectively enforced - Organizationally filtered - Politically shaped - Technically mediated

There is no “view from nowhere” - Crime data reveals policing patterns, not just crime

Technical Foundations

Modeling Workflow

  1. Setup: Create fishnet (500m × 500m grid), aggregate burglaries
  2. Baseline: Kernel Density Estimation (KDE)
  3. Features: Count, k-NN, Local Moran’s I, distance to hotspots
  4. Models: Poisson → Negative Binomial (if overdispersed)
  5. Validation: Spatial cross-validation (LOGO-CV)
  6. Comparison: Model vs. KDE baseline

Local Moran’s I

Global vs. Local

Global Moran’s I: One value for entire area (doesn’t tell WHERE)

Local Moran’s I: One value per location (shows WHERE clusters are)

Implementation

library(spdep)

# Create spatial weights (Queen contiguity)
neighbors <- poly2nb(fishnet_sp, queen = TRUE)
weights <- nb2listw(neighbors, style = "W")

# Calculate Local Moran's I
local_moran <- localmoran(fishnet$abandoned_cars, weights, zero.policy = TRUE)

# Identify High-High clusters (hotspots)
fishnet$hotspot <- ifelse(
  standardized_value > 0 & 
  standardized_lag > 0 & 
  p_value < 0.05, 1, 0
)

Critical interpretation: Are these “high crime” areas or “high reporting” areas?

Count Regression

Why Not OLS?

Problems with linear regression for counts: - Can predict negative values (impossible!) - Assumes constant variance (counts don’t) - Assumes continuous (counts are discrete)

Poisson Regression

Model: \[\log(\lambda_i) = \beta_0 + \beta_1 X_{1i} + ...\]

Key assumption: Mean = Variance = \(\lambda\)

In R:

model_pois <- glm(countBurglaries ~ Abandoned_Cars + ..., 
                  data = fishnet, family = poisson(link = "log"))

Overdispersion

Check: Dispersion = Residual Deviance / DF - If > 1: Overdispersion (common with crime data!) - If > 2-3: Use Negative Binomial

Negative Binomial

Relaxes variance = mean assumption: \[\text{Var}(Y_i) = \mu_i + \alpha \mu_i^2\]

In R:

library(MASS)
model_nb <- glm.nb(countBurglaries ~ Abandoned_Cars + ..., data = fishnet)

Compare: Lower AIC = better fit

Spatial Cross-Validation

Why Standard CV Fails

Standard k-fold CV: Training set includes cells adjacent to test → spatial leakage

LOGO-CV (Leave-One-Group-Out)

Principle: Hold out entire spatial groups (districts), not individual cells

for (dist in districts) {
  train <- fishnet %>% filter(District != dist)
  test <- fishnet %>% filter(District == dist)
  
  model_cv <- glm.nb(countBurglaries ~ ..., data = train)
  test$prediction <- predict(model_cv, test, type = "response")
}

Why better: Tests generalization to truly new areas, no spatial leakage

Comparison to KDE Baseline

Kernel Density Estimation

Simplest spatial prediction: Place smooth “bump” over each crime location, sum all bumps

library(spatstat)
kde_surface <- density.ppp(burglary_ppp, sigma = 1000)

Why compare? If our model doesn’t beat KDE, we’re wasting complexity

Hit Rate Evaluation

Goal: Capture maximum crimes with minimum resources

Example: Highest-risk 20% of cells - Model: Captures 55% of burglaries - KDE: Captures 48% of burglaries - Random: ~20% (by chance)

But ask: Which neighborhoods are classified as “highest risk”? Who experiences increased surveillance?

Critical Evaluation Framework

Questions to Ask

  1. Data Provenance: What time period? Any civil rights investigations? Data manipulation?
  2. Variable Selection: What’s included/excluded? How might each embed bias?
  3. Validation: How is accuracy measured? Error rates by neighborhood?
  4. Deployment: How do predictions translate to action? What are outcomes?
  5. Transparency: Is methodology public? Can people challenge predictions?
  6. Alternatives: What non-punitive interventions were considered?

The Fundamental Question

Before “Does It Work?”, Ask: “Should We Be Doing This At All?”

  • A system that accurately predicts where over-policing will occur is “accurate”
  • A system that reinforces inequalities can be “validated”
  • But: Is it just? Equitable? Does it make communities safer?

What If We Predicted Differently?

Instead of: Where will crimes occur? → Deploy police

Consider: - Where is social services need highest? → Deploy resources - Where is community trust lowest? → Invest in legitimacy - Where is opportunity lowest? → Economic development

Same technical methods, different normative goal

Key Takeaways

Technical Skills

  1. Local Moran’s I: Identify spatial clusters and hotspots
  2. Count Regression: Poisson and Negative Binomial for crime counts
  3. Spatial Cross-Validation: LOGO-CV for geographic data
  4. KDE Baseline: Simple spatial smoothing for comparison

Critical Thinking

  1. Data Provenance: Always question where data comes from
  2. Bias Recognition: Data reflects policing, not just crime
  3. Feedback Loops: Predictions become self-fulfilling
  4. Ethical Evaluation: Ask “should we?” not just “can we?”

Remember

  • All crime data is socially constructed
  • Historical harms persist in data
  • Feedback loops amplify inequality
  • Technical accuracy ≠ social justice
  • Alternatives exist (predict need, not threat)