Warum wartende Fahrzeuge Geofence-Wahrheit brauchen (Warum Wartende Fahrzeuge Geofence Wahrheit Brauchen)

Warten ist eine Region, kein Punkt

Ein Operator sieht einen Pin und sagt 'wartet'. Die echten Fragen: Ist das Fahrzeug in der Zone, was macht Zündung, ist der Wartegrund klassifiziert?

Telematics point  →  inside circle?  →  wait reason?
       lat/lng              km_metric             ops taxonomy
                              ↓
                     Waiting truth on map

Diese Serie baut Wartewahrheit aus Telemetrie, Geofence und Taxonomy.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Waiting Truth
Kartenwarte, die operational verteidigbar ist.

📦 Circle Geofence
Grenze aus Zentrum und Radius.

📦 Ignition Signal
Telemetrie wie Motor an/aus.

📦 False Wait
Falscher Warteeintrag durch Rauschen oder fehlende Klasse.

Ein Punkt ist Evidenz; ohne Kreis und Taxonomy keine Ops-Entscheidung.

Warum ein Pin nicht reicht

Eine Koordinate sagt nicht, ob das Fahrzeug noch im Hof ist. Beispiel: in einem km-Radius (z. B. 5 km) bleiben.

Zwei Wahrheiten

Telemetrie sagt wo; Ops sagt warum.

Telemetry evidence ≠ Wait decision

Aufgabe der Karte

Die Karte zeichnet Evidenz; Taxonomy speichert die Entscheidung.

Die am häufigsten verwechselten Zuordnungen

❌ Letzter GPS-Punkt = Warten
✓ Warten = Grenze + Dauer + Grundklasse

❌ Radius immer 5 km hardcoded
✓ Radius aus API/Config (km_metric)

❌ Vendor-UI ist das Ops-System
✓ Vendor-Feed ist Integrationskante

Checkliste zur Prüfung des eigenen Systems

1. Welche Felder machen einen Warteeintrag 'wahr'?
2. Woher kommt der Radius: Code oder API?
3. Kann Warten ohne Ignition öffnen?
4. Wer schließt False Waits?
5. Welche Metriken im Map-Popup?

Was aus diesem Teil bleiben sollte

1. Warten ist eine regionale Entscheidung, kein Pin.
2. Telemetrie ist Evidenz; Ops-State ist Entscheidung.
3. Radius muss ein expliziter Vertrag sein.

Einen Pin sehen heißt nicht, Warten zu steuern.