Rota Sapmasından Gecikmeyi Nicelleştirmek (Rota Sapmasindan Gecikme)

Rota Sapmasından Gecikmeyi Nicelleştirmek

Gecikme KPI’sı sefer UI’sine bağlanır. Delay is not only traffic: preferred-path detours create measurable ETA error for dispatchers.

ETA baseline vs actual arrival

Gecikme KPI’sı sefer UI’sine bağlanır.

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.

Bu katmanları karıştırmak, hem analitikte hem frontend haritada yanlış gerçeğe yol açar.

Problemin şekli

Delay is not only traffic: preferred-path detours create measurable ETA error for dispatchers.

ETA baseline vs actual arrival

Çalışan ayrım

Gecikme KPI’sı sefer UI’sine bağlanır.

ETA baseline vs actual arrival
        ↓
   explicit contract → frontend

Frontend ile bağ

Ops haritası, bekleme geofence UI’si ve MFE’ler bu okuma modellerini tüketir; ham ERP/MySQL’e bağlanmaz.

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

❌ ERP MySQL = analitik veritabanı
✓ ERP yazma store’udur; analitik PostGIS’te yaşar

❌ Harita doğrudan vendor/public router’a güvensin
✓ Üretimde kendi API/OSRM kenarınız olmalı

❌ ML çıktısı PII ile birlikte loglansın
✓ Değerlendirme ve serving gizlilik sınırına uyar

Kendi sisteminizi denetleme listesi

1. Bu yüzey hangi store’u source of truth sayıyor?
2. Frontend hangi API kontratını çağırıyor?
3. Cluster’da tek node kaybında ne olur?
4. Lag operatöre nasıl gösteriliyor?
5. Deny-list: içerikte müşteri domain/vendor sızıntısı var mı?

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

1. Polyglot store’lar farklı iş yükleri içindir; tek DB hayali kırılgandır.
2. Frontend temiz read model tüketir, ERP’yi değil.
3. ML ve OSRM çıktıları API kontratı olmadan haritaya dökülmez.

Kirli kaynaktan çizilen harita, güzel bir yalandır.