EN 
Українська
Polski
Español
Deutsch
日本語
Italiano
Português (BR)
Français
العربية
Nederlands
中文
한국어
हिन्दी
Türkçe
Tiếng Việt
Русский
Bahasa Indonesia
فارسی
বাংলা
ไทย
Filipino
Kiswahili
اردو
Bahasa Melayu
தமிழ்
עברית
Ελληνικά
ਪੰਜਾਬੀ
አማርኛ
မြန်မာဘာသာ
ខ្មែរ
ქართული
नेपाली
Монгол хэл
Հայերեն
සිංහල
ລາວ
Čeština
Română
Magyar
Български
Svenska
Dansk
Suomi
Norsk
Slovenčina
Hrvatski
Српски
Slovenščina
Lietuvių
Latviešu
Eesti
Íslenska
Shqip
Македонски
Bosanski
Malti🚑 Emergency Resource Allocator — Demand-Driven Dispatch
Ambulances reposition across a city grid as a demand-forecasting model predicts where calls are likely next — watch average response time drop compared to static staging.
About Demand-Driven Emergency Resource Allocation
Where an ambulance sits while idle matters almost as much as how fast it drives once dispatched. Emergency medical services agencies have long relied on "system status management" — repositioning units throughout a shift based on time-of-day demand curves — but most smaller agencies still use static, fixed posts chosen from a single historical average. The gap between those two approaches is exactly what modern predictive-dispatch software is built to close: instead of a handful of fixed street corners, a continuously updated spatial demand model tells the fleet where coverage gaps are opening up right now, and idle units drift toward them before the next 999 or 911 call even happens.
This simulation renders a 10×10 city grid with three synthetic demand hotspots (population centers, transit hubs, nightlife districts) layered on a low background rate, and draws emergency calls from that density as a genuine Poisson arrival process. Six ambulances can be run under two real dispatch policies — fixed posts that only leave to respond and return, or predictive repositioning that continuously recomputes a distance-weighted coverage score across the grid and nudges the least useful idle unit toward the biggest gap. Every dispatched call's response time (grid distance ÷ speed, plus any queueing delay) is logged as a running average for both strategies so you can watch predictive dispatch pull ahead.
Frequently Asked Questions
What is demand-driven dispatch and how does it differ from static staging?
In static staging (also called fixed-post deployment), ambulances are parked at a small number of predetermined locations — often based on historical average call density — and only leave to respond to a call, returning to the same post afterward. Demand-driven (or predictive) dispatch continuously recomputes where units should sit while idle, using a model of where calls are statistically likely to occur next, so the fleet reforms into better coverage between calls rather than sitting still. The core difference is adaptivity: static staging optimizes for the long-run average, while demand-driven dispatch tries to track short-run fluctuations in where demand is concentrated.
What does the demand density map represent, and how is it built in real EMS systems?
The demand density map is a 2D probability surface over the service area describing how likely an emergency call is to originate from each location, per unit time. In this simulation it's a fixed synthetic surface built from a small number of Gaussian hotspots (representing dense population centers, major roads, nightlife districts, etc.) layered on a low uniform baseline so no cell has literally zero risk. Real EMS agencies build these maps from years of computer-aided dispatch (CAD) records, weighted by time of day and day of week, often refreshed with kernel density estimation or spatiotemporal forecasting models.
How does predictive repositioning actually decide where to move an idle ambulance?
At regular intervals, the simulation scores every grid cell by multiplying its demand density by its distance to the nearest ambulance, including busy ones, since they still provide slower backup coverage. Cells that are both high-demand and far from any unit score highest — these are the coverage gaps. The engine then finds the idle ambulance that currently contributes the least to total coverage (the one whose removal would barely change the coverage score), and moves that unit toward the highest-scoring gap. This greedy, distance-weighted coverage optimization is a simplified version of the "maximum expected coverage location problem" (MEXCLP) used in real system-status-management software.
Why does predictive repositioning outperform static staging, and by how much in practice?
Static posts are optimal only for the average demand pattern; as soon as one unit is dispatched, the remaining fleet's coverage becomes lopsided until that unit returns. Predictive repositioning closes those gaps immediately by nudging idle units toward the newly uncovered high-density areas, so the next call — which is more likely to occur near a hotspot — has a closer available unit. Published system-status-management studies report response-time improvements in the range of 15–30% versus fixed-post deployment for the same fleet size; this simulation's own running-average chart typically shows a similar gap once enough calls accumulate.
What are the costs and tradeoffs of frequently repositioning units?
Repositioning isn't free: every move burns fuel, adds vehicle wear, and — most importantly — keeps crews working (driving, staging in unfamiliar areas) rather than resting, which contributes to crew fatigue and turnover in real EMS systems. Overly aggressive repositioning can also cause "thrashing," where units chase a demand forecast that shifts before they arrive, wasting the very time savings the strategy is meant to produce. Real deployments cap how often a unit can be moved and only reposition a fraction of the idle fleet at once; this simulation models a single repositioning interval and does not include those secondary costs.
How is response time computed here, and how does it map to real dispatch metrics?
Response time in this simulation is Manhattan (grid) distance from the responding unit's position at dispatch to the call location, divided by the ambulance speed setting, plus any time the call spent queued waiting for a unit to free up. Real-world response time additionally includes call-processing time at the dispatch center, crew turn-out time, and actual road-network travel time rather than straight grid distance — this simulation strips those out to isolate the effect of positioning strategy, the variable predictive dispatch actually controls.
Does this approach generalize to police and fire resource allocation?
Yes — the underlying math (a spatial demand density estimate plus a coverage-maximizing assignment and repositioning rule) is shared across public-safety domains. Police patrol allocation uses similar hotspot-based patrol routing, and fire departments use comparable system-status-management software to reposition engines and ladder trucks based on time-of-day risk models. The main difference is the response model: fire and police calls often require specific unit types rather than any interchangeable unit, turning the assignment problem into a more constrained matching problem than the single-unit-type model shown here.
Ambulances reposition across a city grid as a demand-forecasting model predicts where calls are likely next.
3D · Three.js / WebGL renderer · 60 FPS target · runs fully client-side, no install