Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Verbesserungen im Routing u.a.
#1
Ich habe das NY-Szenario durchgespielt, dabei ist mir das eine oder andere aufgefallen, was man womöglich mit nicht so hohem Aufwand verbessern könnte:

1. Routing
In dem Szenario kommt man - wie auf vielen anderen Karten - kaum umhin, wirklich viele verschiedene Arten des Nah- und Fernverkehrs zu verwenden. Busse, Straßen-, S- und U-Bahnen, Schiffe, Züge, Flugzeuge.

Insbesondere (aber nicht nur) im urbanen Verkehr ist mir dabei aufgefallen: Wenn man S-Bahn-Stationen mit Bussen verbindet (ein m.E. ziemlich gewöhnlicher Aufbau), ist man "gezwungen", solche zu verbinden, die den gleichen "Abstand" (Anzahl Zwischenhalte) zum lokalen HUB (z.B. Fernbahnhof) haben. Da das nicht immer (sinnvoll) geht, weicht man schnell auf Ringlinien aus, die in Simutrans ohnehin die am einfachsten zu managenden Linien sind und wohl deswegen überproportional viel verwendet werden.

Man könnte, wie in Experimental, die Fahrzeit messen, dann würde es sich für die Pax lohnen, den schnelleren Weg zu nehmen. Man kann das m.E. aber auch viel einfacher (dafür natürlich nicht so exakt) bewerkstelligen:

Man könnte in der Routenfindung die Hops verschiedener Verkehrsmittel verschieden gewichten. Etwa so (die konkreten Zahlen sind nur Beispiele): Ein Flugzeug-Hop ist 1 Punkt, ein Zug-Hop 3 Punkte, ein Bus-Hop 4 Punkte und ein Schiffs-Hop 6 Punkte. Dann würden die Pax bevorzugt schnelle Verkehrsmittel verwenden. Die Anzahl der Punkte für ein Verkehrsmittel sollte sich (grob) an der durchschnittlichen/typischen Geschwindigkeit und dem durchschnittlichen/typischen Stationsabstand orientieren (Schiffe sind z.B. langsam und haben üblicherweise einen hohen Stationsabstand, daher viele Punkte; Busse sind zwar viel langsamer als Flugzeuge, haben dafür aber ohnehin üblicherweise engere Stationsabstände = mehr Hops auf der gleichen Strecke, deswegen kein so riesiger Malus gegenüber Flugzeugen). Dass man damit stark pauschalisiert und sich deswegen relativ einfach Beispiele finden lassen, in denen das zu nicht so guten Ergebnissen führt, liegt leider in der Natur der Sache, ich glaube aber, es würde insgesamt bessere Ergebnisse bringen.

Wie sind eigentlich die 8 Punkte für's Umsteigen "berechnet" worden? Mir erscheint der Wert ziemlich hoch. Ich hatte in der Tat mal eine Arbeitsstelle, zu der ich entweder 2x2 Stationen (also 1x Umsteigen) mit der U-Bahn fahren konnte oder ca. 12 Stationen mit dem Bus direkt. U-Bahn war natürlich viel schneller. Vielleicht könnte man nur Umstiege in ein niedrigeres Verkehrsmittel so hoch bestrafen und Umstiege in höhere/gleiche Verkehrsmittel deutlich geringer?

Ich gehe bei alldem davon aus, dass ST bei der Routenberechnung weiß (oder durch Übergabe eines Parameters an die Funktion problemlos wissen könnte), zu welchem Verkehrsmittel die Linie gehört, die bei der Routenberechnung gerade geprüft wird.

2.) Lokale Passagiere
Es soll ja eine Bevorzugung für nahe Ziele von Pax geben. Die ist m.E. noch viel zu gering. Auch, weil sie vermutlich von der Anzahl der insgesamt möglichen Ziele abhängt. Das führt dazu: Man verbindet zwei benachbarte kleinere Orte. Wenn die Karte insgesamt groß (stark besiedelt) ist, fahren trotz wohl theoretischer Bevorzugung nur ganz, ganz wenige Pax zwischen den beiden Orten. Im NY-Szenario sind es vielleicht 1%, wenn man außerhalb Manhattans zwei kleinere Orte verbindet. Wahrscheinlich, weil es einfach zu viele andere Ziele gibt, die trotz Bevorzugung der Nahziele angesteuert werden können. Das könnte man z.B. mit einem statischen (von der Anzahl anderer Ziele unabhängigen) Teil lösen.
Zitieren
#2
1) Fahrzeit messen: Tja, da gibts einen Patch, der aber so seine Probleme hat.

8 Punkte fuers Umsteigen: die sind ad-hoc festgelegt wurden.

Du musst bedenken, dass es moeglich ist, Linien mit verschiedenen Typen zu betreiben. Wie will man da Gewichte verteilen?

2) Lokale Passagiere: da gibts eine Einstellung zu, die das beeinflusst. Mal in simuconf.tab schauen.
Zitieren
#3
Zitat:Original von Dwachs
Du musst bedenken, dass es moeglich ist, Linien mit verschiedenen Typen zu betreiben. Wie will man da Gewichte verteilen?

Wie ist das möglich? Wenn ich eine Tram-Linie habe und auf der gleichen Linie Züge oder Busse einsetzen will, muss ich eine neue Linie anlegen, oder? Klar, die Pax würden dann auch die andere Linie nehmen, aber das tun sie derzeit ja auch: Wenn man zwei Orte mit mehreren Linien mit verschiedener Anzahl Zwischenhalte verbindet, müsste fürs Routing die "kürzeste" Linie zählen, die Pax nehmen dann aber auch die andere. Dieses Problem (wie viele andere) ließen sich nur beheben, wenn man nicht nur die Zwischenhalte, sondern die Route mit den Pax/Warenpaketen speicherte (aber das ist ein anderes Thema).

Freilich kann es pak-abhängig total unterschiedliche Fahrzeuge des gleichen Typs geben, etwa einen 400 km/h Schnellzug und eine 80 km/h S-Bahn (die fast eher ins Lightrail-Menü gehören würde; die hat allerdings typischerweise auf der gleichen Strecke auch mehr Zwischenhalte). Ein 130km/h-Bus kann auch schneller sein als ebenjene 80 km/h-Bahn. Man müsste das eben ziemlich grob nach typischen/durchschnittlichen Werten schnitzen und dann vielleicht den Effekt sogar noch verkleinern. Dafür würde das - anders als die Messung von Fahrzeiten - mit statischen Faktoren praktisch gar keine Ressourcen fressen.

Die 8 fürs Umsteigen erscheinen mir (viel) zu hoch. 8 ist ja eine Zahl, die man mit den wenigsten Linien erreicht. Könnte man die vielleicht als Simuconf-Einstellung machen, damit man mal ein bisschen rumprobieren kann? Aus dem Bauch würde ich sagen, irgendwas bei 1 oder 2 würde vermutlich genügen.

Ja, man kann die lokal reisensen Passagiere hochdrehen. Wie das letztlich in der Engine umgesetzt ist, weiß ich nicht, aber vermutlich (die Bezeichnung "factor" legt das nahe) werden lokale Ziele eben mit einem gewissen Bonus versehen. Das hieße aber eben, dass dennoch die Anzahl der Nahreisenden sinkt, wenn es mehr Fernziele gibt - das dürfte eigentlich nicht passieren, die Leute müssen ja zur Arbeit, auch wenn die Stadt am anderen Ende der Karte wächst/neu gegründet wird. Und sind "lokale" Ziele nur solche in der gleichen Stadt?
Zitieren
#4
local-Faktor: Die Ziel-Staedte werden gewichtet nach

Einwohnerzahl * Faktor / (Faktor + Entfernung)
Zitieren
#5
Hallo Dwachs
wie würden sich die Passagier verhalten wenn für das Umsteigen nur ein Punkt berechnet würde?
:!: Mein Festnetz Internet ist leider etwas langsam. :!:
:!: Deshalb werde ich gelegendlich Eine Simutranspause machen. :!:
:!: Um dann am Meine Simutransprojekte arbeiteten und neu Ordnen zu Können! :!:
Zitieren
#6
@Dwachs
Danke. Kommt mir auf den ersten Blick komisch vor, den Faktor einmal als Faktor und einmal als Summanden im Nenner zu nehmen. Muss ich aber nochmal insgesamt drüber nachdenken. Jedenfalls bleibt das mit dieser Formel ja abhängig von der Gesamt-Einwohnerzahl auf der Karte, und davon sollte es m.E. unabhängig(er) sein.

Zitat:Original von a0001
wie würden sich die Passagier verhalten wenn für das Umsteigen nur ein Punkt berechnet würde?

Die Routenplanung erfolgt so, dass diejenige Route genommen wird, die die wenigsten "Hops" hat.

Wenn man den Wert von 8 absenkt, würden die Pax eher einmal öfter umsteigen (d.h. unter Umständen auch einen geografischen Umweg in Kauf nehmen), wenn sie dadurch Reisezeit sparen (unter der Annahme weniger Hops = geringere Reisezeit). Da höherwertige/schnellere Verkehrsmittel i.d.R. größere Entfernungen mit weniger Zwischenhalten fahren, würden die Pax eher diese nehmen (also Flugzeuge, Schnellzüge usw., im urbanen Netz auch S-Bahnen).

Andersrum: Je höher der Wert ist, desto unattraktiver wird das Umsteigen und die Pax bleiben eher in einem Verkehrsmittel. Wert 8 bedeutet eben: Ein Pax steigt nur dann um, wenn er dadurch 9 Hops sparen kann (bei genau 8 Ersparnis ist es wohl mehr oder weniger Zufall, was er macht).

Ich bezweifle, dass man den Wert am Reißbrett sinnvoll diskutieren kann. Daher ja der Vorschlag, den in die Simuconf zu nehmen, dann kann man mal ein wenig rumprobieren.

Wahrscheinlich ist ein hoher Wert besser (d.h. wirtschaftlich rentabler), wenn man nur die direkte Entfernung bezahlt bekommt.
Zitieren
#7
Zitat:Original von dennosius

Ich bezweifle, dass man den Wert am Reißbrett sinnvoll diskutieren kann. Daher ja der Vorschlag, den in die Simuconf zu nehmen, dann kann man mal ein wenig rumprobieren.

Da wäre ich auch sehr dafür, 8 finde ich eindeutig zu hoch, wer läßt in Simutrans schon einen Schnellzug bei 9 Stationen hintereinander durchfahren?
Zitieren
#8
Dwachs,'index.php?page=Thread&postID=89831#post89831' schrieb:local-Faktor: Die Ziel-Staedte werden gewichtet nach


Einwohnerzahl * Faktor / (Faktor + Entfernung)
Wenn am Ende etwas um 8 rauskommen soll, muss Faktor<<1 sein, daher verstehe ich die Summenbildung auch nicht... Entfernung=0 trifft ja nicht zu.

Die Idee mit verschiedenen Werten für die Verkehrsmittel klingt eigentlich gut. Zumal ich U-Bahnen mit Zügen baue gelingt schon eine gute Austarierung aller Möglichkeiten innerstädtisch. Aber den Wert für Flieger würde ich sehr hoch setzen, es fliegen mir so schon zu viele Big Grin Wäre sowas ohne Riesenaufwand umsetzbar?
Zitieren
#9
Dwachs,'index.php?page=Thread&postID=89831#post89831' schrieb:local-Faktor: Die Ziel-Staedte werden gewichtet nach

Einwohnerzahl * Faktor / (Faktor + Entfernung)

Der Faktor war mir bisher auch immer ein Rätsel Wink
Ich hab mir mal die Mühe gemacht und hier eine Tabelle erstellt - siehe Anhang.

Das sollten dann die gewichtungen laut deiner Formel sein hab aber da noch Fragen dazu; was bewirkt nun eine Gewichtung von 9000 im Vergleich zu einer von 900 konkret?
Heißt das nun, daß 10 mal soviel Fahrgäste zu dem Ziel mit der Gewichtung 9000 fahren?


Angehängte Dateien Thumbnail(s)
               
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste