Keşifsel Veri Analizi (EDA) ile Filo Bekleme Hotspot’larına (Eda Dan Filo Bekleme Hotspotlarina)

Önce dağılımı gör, sonra modeli kur

Bekleme hotspot’u bir dashboard isteği gibi durur; aslında EDA: süre dağılımı, gece/gündüz sapması, sahaya göre yoğunluk. scikit-learn / PyTorch ancak bu haritadan sonra anlamlıdır.

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

Bu seri OSRM referansı, tercih edilen rota, yakıt/km/gecikme ve harita UI köprüsünü bağlar.

Kavramlar ilk geçtiği yerde

📦 OSRM
Açık kaynak yol ağı shortest-path motoru; önerilen rota için referans.

📦 Preferred Path
Sürücülerin fiilen seçtiği yol — telemetri izinden çıkarılır.

📦 Km Extension
Tercih edilen yolun OSRM referansına göre fazla kilometresi.

📦 Wait Hotspot
Bekleme olaylarının yoğunlaştığı coğrafi bölge kümesi.

OSRM açık kaynak shortest-path motorudur; tercih edilen yol telemetriden öğrenilir.

EDA zorunlu adımları

Null geometri, imkânsız hız, tekrar ping — modelden önce çöpü ayıkla.

Hotspot ürünü

Küme merkezleri ve yoğunluk skorları Django API üzerinden heat map’e gider.

Frontend bağı

Logistics Ops Control Plane ısı haritası bu skorları çizer; ham Mongo’yu değil.

Bu bölümde en çok karışan eşleştirmeler

❌ Model önce, EDA sonra
✓ EDA’sız model operasyonu yanıltır

❌ Hotspot = rastgele grid
✓ Hotspot telemetri + bekleme taxonomy ister

❌ Harita ham ping göstersin
✓ Harita ürünleşmiş skoru gösterir

Kendi sisteminizi denetleme listesi

1. Bekleme süresinin dağılımını çizdiniz mi?
2. Outlier hız eşiğiniz ne?
3. Hotspot API DTO’sunda hangi alanlar var?
4. Heatmap hangi frontend yüzeyinde?
5. PII koordinatları nasıl yuvarlanıyor?

Bu bölümden aklında kalması gerekenler

1. EDA, filo ML’inin kapısıdır.
2. Hotspot bir üründür, sadece notebook değildir.
3. Control plane heatmap temiz skoru tüketir.

Dağılımı görmeden eğittiğiniz model, pahalı bir önyargıdır.