Fahrzeuge zu schnell II

Fortsetzung der Diskussion von Fahrzeuge sind viel zu schnell unterwegs:

Hallo zusammen,

ich würde gerne dieses Ticket nochmal eröffnen und Bezug auf die prozentuale Einstellung in der Administration nehmen. Das bestehende Ticket konnte ich leider nicht mehr kommentieren.

Ich denke nicht, dass die prozentuale Anpassung in der Administration Abhilfe schafft.
Grund: Ich kann zwar die Berechnung beeinflussen und anpassen, bin aber auf eine korrekte Grundberechnung / Routenplanung angewiesen.

Ich persönlich behaupte, dass die Grundberechnung / Routenplanung als solche fehlerhaft ist. Denn während einige meiner Wachen und Fahrzeuge in der Simulation korrekte Fahrzeiten aufweisen, sind andere Fahrzeuge, welche z. T. entfernter sind, teilweise schneller vor Ort und fliegen gefühlt über die Karte, unahängig davon wie ich die prozentuale Anpassung setze.

Dies spricht für mich dafür, dass die Berechnung von Abfahrts- zum Zielpunkt im externen Kartenanbieter selbst ggf. nicht korrekt funktioniert und deswegen ggf. dieser Fehler auftritt. Auf Basis dieser Berechnung mag es aber sein, dass die prozentuale Anpassung in der Administration auf Basis der fehlerhaften Berechnung natürlich funktioniert. :slight_smile:

Kann man bei dem Anbieter, welcher genutzt wird, auch Routenplanung online eingeben, ähnlich wie bei Google und Bing? So könnte man Testversuche starten, mit der Simulation und Google/Bing vergleichen sowie prozentuale Anpassungen versuchen.

Arbeitet der Anbieter als Startpunkt mit der Koordinate des Fahrzeuges, mit der hinterlegten Adresse der Wache (bei S2) oder z.B. mit der nächstmöglichen Adresse im Umkreis des Einsatzmittels, oder wie muss ich mir den Startpunkt vorstellen, wenn die SIM an den Routenplaner übergibt?

VG Jan

4 Likes

Added open

Eine weitere Idee oder Fragestellung die ich habe ist, tritt der Fehler immer auf, nur aus S2 heraus oder nur bei aller erster Alarmierung eines Einsatzmittels.

Hintergrund:
Mir ist mal aufgefallen, wenn ich ein Einsatzmittel aus S2 heraus erstmalig alarmiereund es wieder einrückt, dass die Distanz ggf. leicht verändert ist, z. B. um 0,1 km. So war es zu mindest in der Simulation eine Zeit lang, damals. Ich gehe also davon aus, dass es bei erster Alarmierung auf der Koordinate der Wache startet, und bei Rückfahrt die nächstmögliche Adresse anfährt, welche das Routing dazu findet.

Vlt wird beim Start-Routing (aller erster Alarm) oder grundlegend von der Wache aus also immer ein Routing-Fehler generiert, sofern die Koordinate der Wache nicht gut genug gesetzt ist? Vlt. würde es hier Abhilfe schaffen, wenn man einer Wache Routing-Start-Punkte in Form einer Adresse zuweisen kann. Gleich würde es weitere Vorteile bringen, wenn eine Wache mehrere Ausfahrten hätte. So könnte immer die beste Ausfahrt inkl. Routing genutzt werden und von dort aus gestartet werden (win-win für die, welche Hinterausfahrten mit bedeutendem Zeitvorsprung nicht umsetzen können).

Dies wäre aber nurmöglich, wenn dies wirklich der Fehler ist und bei S1 dann der Punkt genutzt wird, auf welchem das Rettungsmittel derzeit wirklich steht.

3 Likes

Ich möchte einmal einige Beispiele darstellen. Vlt. helfen diese, dem Fehler auf den Grund zu gehen.

Grundparameter der Leitstelle:

  • Fahrzeuggeschwindigkeit PKW in %: 127
  • Fahrzeuggeschwindigkeit PKW mit Sonder-/ Wegerechten %: 106
  • Fahrzeuggeschwindigkeit LKW in %: 135
  • Fahrzeuggeschwindigkeit LKW mit Sonder-/ Wegerechten %: 107

Aufgrund der Angaben muss ich davon ausgehen, dass die Fahrzeuge in jedem Fall länger bräuchten, als das Routing im Original berechnet, selbst mit Sondersignal, da ich bei über 100% arbeite. Dies ist eine gute Grundlage, um das Poblem zu testen.

Düsseldorfer Straße 130, Saarn/Mintard, Mülheim an der Ruhr

  • Start: Karlsruher Str. 11, Speldorf, Mülheim an der Ruhr
  • Sondersignal: NEIN
  • GoogleMaps: 9 Minuten
  • BingMaps: 9 Minuten
  • Tatsächliche Eintreffzeit im Spiel: 4 Minuten

Dimbeck 8, Holthausen, Mülheim an der Ruhr

  • Start: Aktienstr. 58, Mitte, Mülheim an der Ruhr
  • Sondersignal: NEIN
  • GoogleMaps: 7 Minuten
  • BingMaps: 6 Minuten
  • Tatsächliche Eintreffzeit im Spiel: 3 Minuten

Am Bahnhof Broich 2, Broich, Mülheim an der Ruhr

  • Start: Aktienstr. 58, Mitte, Mülheim an der Ruhr
  • Sondersignal: NEIN
  • GoogleMaps: 7 Minuten
  • BingMaps: 9 Minuten
  • Tatsächliche Eintreffzeit im Spiel: 4 Minuten

Kaiserstraße 50, Mitte, Mülheim an der Ruhr

  • Start: Aktienstr. 58, Mitte, Mülheim an der Ruhr
  • Sondersignal: NEIN
  • GoogleMaps: 5 Minuten
  • BingMaps: 5 Minuten
  • Tatsächliche Eintreffzeit im Spiel: 2 Minuten
2 Likes

Nachdem mir bei einer Sitzung auch wieder die Fahrzeiten sehr flott vorkamen, habe ich die Flugzeit eines RTHs unter die Lupe genommen.

375 km/h… viel zu flott

Ich beobachte auch weiterhin immer wieder “fliegende” Fahrzeuge. Nicht im Sinne des Fahrweges (Luftlinie vs. Route) sondern einfach im Sinne der Zeit, wie oben schon durch mich beschrieben.

Ich befürworte die Einführung eines Schiebereglers, damit jeder bedingt seine Zeiten anpassen kann, aber dafür muss die Grundberechnung halt stimmen. Hier liegt seit kurzem irgendetwas im Argen, vor Einführung des Reglers habe ich dieses Problem in meinem Leitstellenbereich nicht beobachtet, da kam alles besser hin…

VG

@taito kann man hier schon etwas zu sagen?

Die Beispielberechnung und die Schieberegler-Funktion in der Administration klappt ja und passt sich an, nur die reale Berechnung um Spielablauf läuft viel zu schnell…

VG