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.
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?
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.
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
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…
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…
Keine Reaktion, Status immernoch “offen” -.-
Auch eben in der Simulation meiner Leitstelle wieder entdeckt, dass Fahrzeuge sehr (zu) schnell die Einsatzstelle erreichen. Teilweise auf Autobahnen auch über die Mittelleitplanke hinweg.
Akutbeispiel nach Beobachtung: RTW + NEF ohne SoSi innerstädtisch 1,9 km in unter 2 Minuten (Google Maps schlägt 6 Minuten vor)…
Das ist ja nicht das Problem. Das Problem ist - wie hier ja auch schon seit längerem beschrieben -, dass die Fahrzeuge trotz Veränderung der Einstellungen noch zu schnell sind und damit die Vermutung eines Fehlers im Routing naheliegt. Vgl. dazu auch meine Meldung zur Nutzung benutzerdefinierter Map Tiles: Fehlverhalten GIS bei Deaktivierung benutzerdefinierter Kartenebene
Irgendwie kommt mir die Vermutung, dass es da Zusammenhänge geben könnte.
Genau seit dieser Einführung besteht bei mir der Fehler.
Beispiel:
Routing in echt bzw Abfrage bei Google Maps und Bing, 10-12 Minuten.
Routing im Spiel: Einsatzmittel trifft in 2 Minuten ein. Betrifft aber nicht alle Fahrzeuge bzw Wachen.
Erhöhe ich die von Dir angesprochene Funktion, meinetwegen zum testen massiv signifikant, sind es vlt. 3-4 Minuten Eintreffzeit bei gewissen Fahrzeugen, obwohl weit über 15 Minuten errechnet werden. An anderen Wachen bzw Fahrzeugen funktioniert es dann aber wiederum, was dann zu unfassbar langen Anfahrten führt.
Hierbei ist unabhängig, ob mit oder ohne SoSi alarmiert wird.
Ich habe mal etwas rumgespielt mit den Prozenten.
Ich habe das Gefühl, dass 200% die realistischen 100% sind.
Ein RTW hat bei mir für eine Strecke von 7 km ganze 11 Minuten gebraucht.
Google Maps hatte es ebenfalls so berechnet.
Also vielleicht mal ausprobieren, ob 200% als normal Wert gilt und ggf. 185% oder so als SoSi Wert.
Es ist in dieser Konfiguration auf jeden Fall deutlich besser und realistischer, danke für den Hinweis. Nur in einigen wenigen Fällen kommt es jetzt zu unrealistisch kurzen Fahrzeiten.
Danke, dass ihr die besseren Konfigurationsmöglichkeiten zur Verfügung gestellt habt. Ich würde auch behaupten, wir setzen dies als Standardwerte für alle fest. Jedoch bekommt v4 eine neue Routing-Engine; ich fürchte, dass es da zu Abweichungen kommt
