Von EDA (Exploratory Data Analysis) zu Flotten-Warte-Hotspots (Von Eda Zu Flotten Warte Hotspots)

Verteilung sehen, dann modellieren

Ein Warte-Hotspot wirkt wie ein Dashboard-Wunsch — zuerst EDA: Dauerverteilung, Tag/Nacht, Hofdichte. scikit-learn/PyTorch kommen danach.

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

Diese Serie verbindet OSRM-Baseline, Preferred Paths, Kraftstoff/km/Delay und die Karten-UI.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 OSRM
Open-Source Shortest-Path-Engine als empfohlene Routen-Baseline.

📦 Preferred Path
Tatsächlich gefahrene Route — aus Telemetrie rekonstruiert.

📦 Km Extension
Zusätzliche Kilometer der Preferred Path gegenüber OSRM.

📦 Wait Hotspot
Geocluster mit konzentrierten Warteereignissen.

OSRM ist Open-Source Shortest-Path; Preferred Paths kommen aus Telemetrie.

Pflicht-EDA

Null-Geometrie, unmögliche Speed, Doppel-Pings — vor dem Modell weg.

Hotspot als Produkt

Cluster und Dichte-Scores per Django-API zur Heatmap.

Frontend-Brücke

Control-Plane-Heatmap zeichnet Scores — nicht Raw-Mongo.

Die am häufigsten verwechselten Zuordnungen

❌ Modell zuerst
✓ Ohne EDA täuscht das Modell

❌ Hotspot = Zufallsgrid
✓ Hotspots brauchen Telemetrie + Taxonomy

❌ Karte zeigt Raw-Pings
✓ Karte zeigt produktisierte Scores

Checkliste zur Prüfung des eigenen Systems

1. Warte-Dauerverteilung geplottet?
2. Outlier-Speed-Schwelle?
3. Felder im Hotspot-DTO?
4. Welche UI besitzt die Heatmap?
5. Wie werden Koordinaten gerundet?

Was aus diesem Teil bleiben sollte

1. EDA ist das Tor zu Fleet-ML.
2. Hotspot ist Produkt, nicht nur Notebook.
3. Heatmaps konsumieren saubere Scores.

Ein Modell vor der Verteilung ist teures Vorurteil.