Place-based crime hotspot forecasting

Police forces and municipal prevention teams want to deploy limited patrol and prevention resources where crime is most likely in the coming days. Place-based forecasting models (near-repeat rules, kernel density, gradient boosting, self-exciting point processes) turn historic incident data into risk maps for small areas and short time windows. The evidence for crime reduction is mixed, and bias, transparency and legal limits are the central design topics - not model accuracy alone. Scope is strictly place-based: predicting the criminal risk of individual persons is a different use case (PRED-045) and largely prohibited in the EU.

Problem & value

• Who: state police forces (in Germany the Landeskriminalämter and Polizeipräsidien), municipal crime-prevention councils, and, in a different form, insurers and security operators.
• Today: analysts draw hotspot maps by hand or with GIS kernel density; patrol planning follows experience, with limited ability to anticipate short-term clustering.
• Why AI/statistics helps: burglary shows near-repeat patterns - after an offence, neighbouring properties are at elevated risk for a short period. Models formalise this together with seasonal, weather and context effects. German police deployments documented in public sources include PRECOBS (Nuremberg 2016 until October 2021, Munich since 2017, a Stuttgart/Karlsruhe pilot in 2015 costing EUR 220,000), SKALA (North Rhine-Westphalia, statewide from January 2018, built with IBM SPSS Modeler), KrimPro (Berlin, citywide in October 2016) and PreMAP (Lower Saxony) [1].
• Honest value statement: an evaluation of the Baden-Wuerttemberg PRECOBS pilot (Freiburg, 2017) concluded that the effect on burglary numbers was hard to judge despite positive indications [1]. Nuremberg discontinued PRECOBS in 2021 [1]. A journalistic audit of the US vendor Geolitica (ex-PredPol) found fewer than 0.5 % of ~23,600 predictions in Plainfield, NJ matched a reported crime of the predicted type; the company then shut down at end of 2023 [2]. Treat vendor claims of crime reduction with scepticism and demand a controlled evaluation.

Variants

• Residential burglary near-repeat forecasting (the most common German use; low-volume, clustered).
• Vehicle crime / theft from vehicles, bike theft, vandalism hotspots for municipal prevention.
• Municipal safety and non-police prevention: lighting, street design and social-work deployment based on aggregated incident statistics rather than patrol targeting.
• Private-sector variants: insurer location risk for household/commercial burglary (see PRED-010, PRED-036); retail chains and logistics operators forecasting theft and cargo-crime risk by site or route.
• Not in scope / not implementable in the EU: forecasting which persons will offend (PRED-045), person-based "heat lists", or hotspot systems that quietly aggregate personal profiles.

How it works

incident data (time, location, offence type; de-identified)
  -> cleaning, geocoding, aggregation to grid cells / street segments (e.g. 200 m, hourly-daily windows)
  -> feature engineering (recent incidents nearby = near-repeat, seasonality, weather, context data)
  -> model: near-repeat rules | kernel density | gradient boosting | self-exciting point process
  -> forecast risk per cell and window + uncertainty
  -> human analyst review -> operational planning (patrol, prevention, information campaigns)
  -> feedback: measures taken, new incidents -> evaluation and bias audit

• Core models: statistical and tabular ML (gradient boosting, point-process models) dominate operational systems; they are transparent enough to audit. Deep spatio-temporal models exist in research but add little in sparse-data settings.
• LLMs play a supporting role only: drafting analyst briefings, documentation and audit reports from model outputs - never producing the forecast.
• Human-in-the-loop: analysts validate maps; commanders decide deployment; no automated action against individuals follows from a map cell. Patrol presence is a preventive measure, not an intervention against a named person.

Data preparation

Needed are historic incident records with time and location, plus open context data (census blocks, land use, street network, weather, holidays, events) and patrol deployment records. Incident data typically live in the police case-handling system or a statistics database, context data in public portals and GIS layers, and patrol records in operational planning tools, sometimes in Excel.

Typical gaps: imprecise or missing coordinates, inconsistent offence coding, delayed reporting (reporting date is not offence date), under-reporting that differs by area, changed recording practice over time, and personal data hidden in free-text fields. Access rights are strict because the source data concern individuals.

Preparation steps: (1) inventory sources and owners (PREP-001, PREP-004); (2) export from the case system (PREP-005); (3) geocode and aggregate to grid cells or street segments, removing person references so that only de-identified aggregates reach the model (PREP-022, PREP-025); (4) harmonise offence codes and time windows (PREP-019); (5) join context layers; (6) build back-test sets by time split (PREP-018). Tools: PostGIS, QGIS, Python (geopandas, scikit-learn, LightGBM).

Rough share of effort: about 30 to 40 percent; evaluation design and bias auditing take at least as much. See GUIDE-003.

Implementation paths

Which path for whom

• Public (police, municipal prevention): Path C, because incident data are sensitive, a statutory basis and audit rights are required, and simple open-source spatio-temporal models (near-repeat, kernel density, gradient boosting) run on HW1 under the authority's own control.
• Enterprise: Path B, because security service providers or utilities working on aggregated, non-personal data can use EU-region cloud analytics and managed time-series tools.
• Developer: Path C, because open-source geospatial and forecasting libraries on a laptop-class machine give transparent, auditable models and full control over bias audits.

Path A - Buy (off-the-shelf)

• Police-specific products: PRECOBS (Institut fuer musterbasierte Prognosetechnik, Oberhausen, German), IBM-based SKALA components in NRW (state-owned configuration), KrimPro in Berlin (in-house system with police-owned models) [1]. Commercial vendors outside the EU (Geolitica/PredPol, now closed) are a cautionary example [2].
• GIS-based crime analysis: Esri ArcGIS / Crime Analysis solutions, Palantir-type analysis platforms (US; note the Federal Constitutional Court limits on automated data analysis [3]), plus Hexagon and Motorola Solutions offerings. Prefer EU-hosted, auditable models with open documentation.
• Choose A when: you are a police authority with a statutory basis and a procurement process; the vendor must deliver logic documentation, audit rights and data-protection impact assessment support.

Path B - Build on cloud APIs

• Sensible for analysis and reporting, not for the model itself: EU-region cloud (e.g. STACKIT, Azure EU, IONOS) for geodata processing, with managed forecasting (Azure/Google/AWS time-series services) only on aggregated, non-personal data. Use an EU-hosted LLM (Mistral, Aleph Alpha-class provider, or a frontier model in an EU region) solely to draft analyst reports.
• For police data, sovereign-cloud or government-cloud requirements normally rule out public SaaS; for municipal prevention on public statistics this path is realistic.

Path C - Self-host (open source)

• Stack: PostGIS, H3 or square-grid tiling, Python (GeoPandas, PySAL, scikit-learn, LightGBM/XGBoost, statsmodels), point-process libraries, time-series toolkits (Nixtla StatsForecast; foundation models such as Chronos/TimesFM for baselines), MLflow for experiment and audit trails.
• Hardware: HW1 - a CPU server is enough; data volumes are small.
• Ops effort: one data scientist plus one crime analyst; most effort is data quality and evaluation design.

Path D - Custom training

• This is the default for operational use: train and calibrate models on the force's own historic incidents (typically several years of burglary data per region; sparse for rare offences). Use rolling-origin backtests, report hit rate against the share of area covered, compare with a naive "last month's hotspots" baseline, and run a randomised or staggered rollout to measure real effect. Bias audit (see below) is mandatory before every release.

State of the art (2026)

• Methods: near-repeat rules and risk-terrain / gradient-boosting models remain the practical workhorses; self-exciting (Hawkes-type) point processes and spatio-temporal graph networks are active research. Time-series foundation models help as baselines but do not fix sparse, noisy crime data.
• Evidence: reduction effects are inconsistent between evaluations [1][2]; the strongest evidence in the literature supports focused, visible, problem-oriented policing in hotspots, not the specific algorithm.
• Key failure mode - feedback loops and bias: a 2016 study applied PredPol-type logic to Oakland drug-crime data and found patrols directed disproportionately to Black and low-income neighbourhoods although survey data indicated more even drug use; the authors attributed this to bias in recorded arrests, not to the algorithm [4]. Reported crime reflects policing intensity and reporting behaviour. Mitigate by modelling only crime types with high reporting rates (burglary, vehicle theft), excluding proactive-policing-driven categories (drug offences), and monitoring displacement.
• Legal shift: the German Federal Constitutional Court (1 BvR 1547/19, 16 Feb 2023) held that automated analysis of stored police data needs a sufficiently high intervention threshold; lower thresholds can be acceptable only if law strictly limits data and methods, for example by targeting places rather than persons [3]. Place-based, aggregated forecasts are therefore the legally better-placed variant - but still need a statutory basis and published rules [3].
• Limits: low base rates, small numbers, unobserved crime, displacement, and a hit rate that must be judged against a naive baseline.

Shared resources & combinations

• Same building blocks (tabular-ml + time-series): PRED-001 demand forecasting, PRED-019 traffic and mobility demand, PRED-017 weather impact (weather features), PRED-036 climate and nat-cat risk (spatial risk scoring), PRED-010 insurance risk pricing. One GIS plus feature store plus MLflow stack serves all.
• Boundary to neighbours: PRED-045 (recidivism, person-based - high-risk or prohibited), PRED-029 (client profiling in public services), PRED-028 (risk-based audit selection; also person/entity-based). Do not join place-based forecasts with person-level data.
• Upstream/downstream: CONV-021 (emergency-call triage) as an incident source; VIS-051 (geospatial imagery analysis) for context data only. Municipal dashboards and reporting reuse a shared BI layer.
• Hardware: HW1 CPU server; no GPU required.

Effort, cost & KPIs

• Path A: months for procurement, legal basis and data-protection impact assessment; the PRECOBS pilot in Baden-Wuerttemberg cost EUR 220,000 for six months [1].
• Path C/D: 3-6 months for a first auditable model; the cost is mostly data engineering, evaluation and governance, not compute.
• KPIs: predictive accuracy index / hit rate vs. area covered against a baseline; effect on offence numbers in a controlled comparison; displacement; analyst usage; audit KPIs - disparity of patrol allocation relative to population and to survey-based victimisation; share of forecasts with documented rationale.

People & change

Begin with the authority's leadership and the head of the prevention or analysis unit, who own purpose and legal basis. IT and IT security provide the isolated environment; the data protection officer is involved from day one, because even aggregated place data can allow indirect person inference, and a DPIA is likely (GUIDE-005). Legal review of the statutory basis and of the Federal Constitutional Court limits on automated analysis is essential. Patrol officers and analysts are the end users and should help define useful outputs.

Works council: yes. For public bodies the staff council (Personalrat) under the BPersVG or state law is the counterpart. Patrol-planning tools and feedback loops can log the activity and performance of officers and are suited to monitor behaviour, which triggers co-determination analogous to §87(1) no. 6 BetrVG; §90(1) no. 3 BetrVG equivalents require timely information when work processes are planned with AI (GUIDE-004).

Support AI literacy (Art. 4 AI Act) with short training on hit rate versus area covered, feedback-loop bias and displacement (GUIDE-006). Run a pilot in one district with a documented evaluation (GUIDE-009). Typical concerns: discrimination, over-policing of certain areas, and loss of professional judgement. Address them with place-only modelling, regular bias audits, public transparency, and the rule that maps inform but never replace officers' decisions (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: Art. 5(1)(d) prohibits AI risk assessments of natural persons to predict the risk of a criminal offence based solely on profiling or personality traits; an exception covers systems that support human assessment of involvement in a criminal activity already based on objective, verifiable facts [5]. Pure place-based forecasts without person-level data fall outside this wording, but any version that scores or lists persons, or uses person-level attributes (e.g. profiles of known offenders), moves into the prohibited or high-risk area. Annex III point 6 lists law-enforcement high-risk systems (e.g. risk of offending or re-offending, profiling in investigations) [6]. Hence eu_ai_act_risk: depends - place-based, aggregated, non-personal systems are typically not listed, but must be assessed case by case; check the current application dates of high-risk obligations (subject to amendment proposals in the EU Digital Omnibus), and AI literacy (Art. 4) applies in any case.
• Police law and constitution: statutory basis in the Land police law; BVerfG requirements on thresholds, data limits and published administrative rules [3]. Coordinate with the data protection officer and Landesdatenschutzbeauftragte; the Law Enforcement Directive (EU) 2016/680 applies to police processing, GDPR to municipal and private actors.
• GDPR: incident records can contain personal data (victims' addresses); aggregate and de-identify early; small-cell suppression; DPIA required.
• Discrimination: do not use ethnicity, nationality or proxies at area level to rank neighbourhoods; run disparity audits; publish model documentation.
• Not implementable in the EU: person-level "heat lists", predicting who will offend, or covert profiling - documented here only as limits.
• Mitigations: published methodology, independent evaluation, sunset clauses, analyst override, logging of every forecast and resulting measure.

Getting started

1. Clarify the legal basis and purpose; involve the data protection officer before any data work.
2. Select one high-reporting offence (e.g. residential burglary) and assemble 3-5 years of de-identified, geocoded incident data aggregated to grid cells.
3. Build baselines first (last period's hotspots, kernel density), then near-repeat and gradient-boosting models; evaluate with rolling-origin backtests and hit rate vs. area covered.
4. Design the pilot as a controlled or staggered rollout with a bias and displacement audit.
5. Publish the methodology and decide up front under which evidence the system is stopped.

Sources

1. German Wikipedia - Predictive Policing (German deployments PRECOBS, SKALA, KrimPro, PreMAP; Baden-Wuerttemberg evaluation) - https://de.wikipedia.org/wiki/Predictive_Policing
2. The Markup - Predictive policing software terrible at predicting crimes (Geolitica, Plainfield NJ; shutdown) - https://themarkup.org/prediction-bias/2023/10/02/predictive-policing-software-terrible-at-predicting-crimes
3. Bundesverfassungsgericht - Press release on judgment of 16 Feb 2023, 1 BvR 1547/19 and 1 BvR 2634/20 (automated data analysis) - https://www.bundesverfassungsgericht.de/SharedDocs/Pressemitteilungen/DE/2023/bvg23-018.html
4. Wikipedia - Predictive policing (Lum & Isaac 2016 feedback-loop study, Santa Cruz ban) - https://en.wikipedia.org/wiki/Predictive_policing
5. EU AI Act, Article 5 (prohibited practices) - https://artificialintelligenceact.eu/article/5/
6. EU AI Act, Annex III (high-risk systems, point 6 law enforcement) - https://artificialintelligenceact.eu/annex/3/
7. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj