From EDA (Exploratory Data Analysis) to Fleet Waiting Hotspots (From Eda To Fleet Waiting Hotspots)

See the distribution before you fit a model

A wait hotspot looks like a dashboard ask; it is really EDA first — duration distributions, day/night drift, yard density. scikit-learn / PyTorch only matter after that map exists.

Telemetry + wait events
        ↓ EDA
 distributions / outliers
        ↓ clustering
 wait hotspots
        ↓ API
 heatmap UI (control plane)

This series connects OSRM baselines, preferred routes, fuel/km/delay, and the map UI bridge.

Concepts, defined where they first appear

📦 OSRM
Open-source road-network shortest-path engine used as the recommended-route baseline.

📦 Preferred Path
The path drivers actually take — recovered from telemetry traces.

📦 Km Extension
Extra kilometers of the preferred path versus the OSRM baseline.

📦 Wait Hotspot
Geographic cluster where waiting events concentrate.

OSRM is an open-source shortest-path engine; preferred paths are learned from telemetry.

Mandatory EDA steps

Null geometry, impossible speeds, duplicate pings — remove trash before models.

Hotspot as product

Cluster centers and density scores reach the heatmap via the Django API.

Frontend bridge

The Logistics Ops Control Plane heatmap draws these scores — not raw Mongo.

The mappings that get confused most often

❌ Model first, EDA later
✓ Models without EDA mislead operations

❌ Hotspot = random grid
✓ Hotspots need telemetry + wait taxonomy

❌ Map shows raw pings
✓ Map shows productized scores

A checklist for auditing your own system

1. Have you plotted wait-duration distributions?
2. What is your outlier speed threshold?
3. Which fields are in the hotspot API DTO?
4. Which frontend surface owns the heatmap?
5. How are PII coordinates rounded?

What to take away from this part

1. EDA is the gateway to fleet ML.
2. A hotspot is a product, not only a notebook.
3. Control-plane heatmaps consume clean scores.

A model fit before you see the distribution is expensive prejudice.