Taktpunkt: Fahrziele nach Abfahrtszeit zuordnen

[ST4]

Hallo,

wäre es möglich, an Taktpunkten das Fahrziel (und ggf. die Liniennummer) zur Abfahrtszeit zuzuordnen?

Beispielhaft eine Abfahrtszeile:
2(L=3,Ziel="A"), 15(L=5,Ziel="B"), 22(L=3,Ziel="A"), 35(L=5,Ziel="C"), ...

Das würde es ermöglichen, beispielsweise an Endstellen wechselnde Fahrziele nach Abfahrtszeit zuzuordnen. Bisher geht das nur recht umständlich über Datenwechselpunkte, wo dann auch alle Zeiträume einzeln einzugeben sind und man idealerweise auch die Umlaufnummern berücksichtigt.

Wenn man das Thema nun noch etwas weiterdenkt, wären auch Bedingungen für die Fahrten möglich. So könnte sich der ankommende Zug die nächste zu seinen Eigenschaften passende Abfahrtszeit suchen. Insbesondere an großen Bahnhöfen könnte dann ein kombinierter Taktpunkt vorgesehen werden, in dem sämtliche Abfahrten drin sind und die Züge könnten sich frei Gleise aussuchen (z.B. im Güterverkehr ja üblich).

Das Thema ist ein wenig mit diesem verwand: http://www.das-bahn-forum.de/bahnforum/ ... f=3&t=4391
Auch das würde helfen, das eigentliche Problem mit den komplizierten Zeitabhängigkeiten jedoch nicht lösen.

Vieleicht gibt es ja die Möglichkeit, Bedingungen und Datenschreiben in den Abfahrtslisten aufzunehmen. Ich würde mich sehr darüber freuen!

Gruß
ST4

[Seb144]

Hallo,

so ganz habe ich die Frage nicht verstanden.

Beispielhaft eine Abfahrtszeile:
2(L=3,Ziel="A"), 15(L=5,Ziel="B"), 22(L=3,Ziel="A"), 35(L=5,Ziel="C"), ...

Eine solche Eintragung ist doch jetzt schon möglich.

Das würde es ermöglichen, beispielsweise an Endstellen wechselnde Fahrziele nach Abfahrtszeit zuzuordnen. Bisher geht das nur recht umständlich über Datenwechselpunkte, wo dann auch alle Zeiträume einzeln einzugeben sind und man idealerweise auch die Umlaufnummern berücksichtigt.

Nach meiner Kenntnis kann man sehr viel, was an Datenwechselpunkten eintragbar ist, auch bei Taktpunkten eintragen. Bspw. würde eine Eintragung "2(z=15:00-16:00,n=1,L=3,Ziel="A"), 2(z=15:20-16:20,n=2,L=5,Ziel="B")" im Taktpunkt möglich sein.

Grüße,


Sebastian
_________________
Berlin und Umgebung im Jahr 1989

http://www.bahn1989.berlin

[Jan Bochmann]

Guten Tag,

Hallo,

so ganz habe ich die Frage nicht verstanden.

Beispielhaft eine Abfahrtszeile:
2(L=3,Ziel="A"), 15(L=5,Ziel="B"), 22(L=3,Ziel="A"), 35(L=5,Ziel="C"), ...

Eine solche Eintragung ist doch jetzt schon möglich.

Nur oben in der Linienliste, aber nicht in den Abfahrtszeiten. Dieser Irrtum zeigt aber wieder, daß die Taktpunkte schon heute viel zu kompliziert sind. Es hat wenig Sinn, sie noch komplizierter zu machen.

Grüße,
Jan B.

[Jan Bochmann]

Guten Tag,

Hallo,

wäre es möglich, an Taktpunkten das Fahrziel (und ggf. die Liniennummer) zur Abfahrtszeit zuzuordnen?

Es wäre wenig sinnvoll. Die Daten werden am Taktpunkt bei der Ankunft des Zugs gesetzt. Solange er dort steht, führt jede Änderung am Zug oder am Taktpunkt zu unklaren Situationen.

Das Ändern von Daten am Taktpunkt ist ein konzeptioneller Fehler, den ich vor über 20 Jahren gemacht habe. Seitdem ist das in BAHN drin, es sollte aber nicht benutzt werden. Ich wollte es schon lange entfernen, aber es gibt leider viele Netze, die das verwenden. Schon vor über 10 Jahren habe ich aber alles dazu aus der Dokumentation gelöscht.

Zum Ändern von Daten sind die Datenwechselpunkte viel besser geeignet. Dort gibt es nur die klaren Situationen "Zug ist noch vor dem Datenwechselpunkt" (= "er hat noch die alten Daten") und "Zug hat den Datenwechselpunkt passiert" (= "er hat die geänderten Daten"). Es gibt kein "Zug steht am Datenwechselpunkt".

Beispielhaft eine Abfahrtszeile:
2(L=3,Ziel="A"), 15(L=5,Ziel="B"), 22(L=3,Ziel="A"), 35(L=5,Ziel="C"), ...

Eine solche Zeile in einem Fahrplan ist doch alles andere als übersichtlich. Außerdem sollten neue Fahrziele und andere Daten bereits bei Erreichen der Haltestelle gesetzt sein, damit die Fahrgäste sehen, wohin der Zug weiter fährt. Viele IBIS/IFIS-Systeme machen das auch so, d.h. sie ändern die Daten zwischen der letzten Haltestelle und dem Endpunkt.

Gruß,
Jan B.

[micha88]

Vieleicht gibt es ja die Möglichkeit, Bedingungen und Datenschreiben in den Abfahrtslisten aufzunehmen. Ich würde mich sehr darüber freuen!

Die Notwendigkeit habe ich jedoch noch nicht verstanden. Solange ein planmäßiger Betrieb ohne Verspätungen simuliert wird, kann das ganz problemlos über die Einträge in der Linienliste auch abgebildet werden.
Wenn du Verspätungen und die dynamische Verteilung der Züge auf die Gleise betrachten möchtest, dann bräuchte es ja dann auch individuelle Verspätungszähler, oder? Denn mit deinem Vorschlag könnte sich ja die Reihenfolge der Abfahrten ändern...

[S-Bahn-Freund Stgt]

Guten Abend,

wenn ST4 das gleiche meint, wie ich vor einigen Jahren, dann wären das "einfach" mehrere eigenständige Taktpunkte an einem Punkt. Dann hätte man für jeden Taktpunkt an diesem Punkt einen eigenständigen Zähler, Linienliste, Abfahrten etc.
Der Vorteil, weswegen ich den Wunsch damals auch geäußert hatte, wäre, dass man bei großen Bahnhöfen bei verschiedenen Linien mit möglichen Verspätungen nicht viele TPs hintereinander bauen muss. Viel komplizierter in der Bedienung stelle ich mir das nicht vor. Man könnte eine Option einbauen, dass man beim Anklicken des Elements auswählen muss, welchen TP (mit Namen unterschieden) man bearbeiten möchte, ähnlich zu Zugverbänden, wo man dies bei Klick auf den Zug ebenfalls muss.
Der Wunsch meinerseits besteht zwar immer noch, wenn auch nicht mit sehr hoher Priorität, aber ich verstehe aber gut, wenn das Einbauen dieser Funktion viel Arbeit ist.

Grüße,
Hosea

[Seb144]

Guten Abend,

wenn ST4 das gleiche meint, wie ich vor einigen Jahren, dann wären das "einfach" mehrere eigenständige Taktpunkte an einem Punkt. Dann hätte man für jeden Taktpunkt an diesem Punkt einen eigenständigen Zähler, Linienliste, Abfahrten etc.

Hallo,

diesem Wunsch schließe ich mich weiterhin an.

Grüße,

Sebastian
_________________
Berlin und Umgebung im Jahr 1989

http://www.bahn1989.berlin

[Bahnsimulant]

Hi,
ich finde die Idee an sich auch gut.
Glaube aber das es programmtechnisch schwierig/aufwändig wird bis zu 5000 Linien an 7 Tagen zu verwalten.
Des Weiteren sind dann noch mögliche Varianten zu berücksichtigen (z.B. siehe in der Hilfe "Platzhalter bei Liniennamen und Zugnamen")

Wie schon von Jan B. beschrieben sind da Datenwechselpunkte besser/eindeutiger.
Ich behelfe mir dann mit mehreren Taktpunkten an einer Haltestelle oder wenn es platztechnisch schwierig wird, verlagere ich den Taktpunkt eine(n) Bahnhof/Haltestelle vorher und halte am eigentlichen Taktpunkt nur "normal".

[ST4]

Guten Tag,

Hallo,

wäre es möglich, an Taktpunkten das Fahrziel (und ggf. die Liniennummer) zur Abfahrtszeit zuzuordnen?

Es wäre wenig sinnvoll. Die Daten werden am Taktpunkt bei der Ankunft des Zugs gesetzt. Solange er dort steht, führt jede Änderung am Zug oder am Taktpunkt zu unklaren Situationen.

Bei Ankunft eines Zuges erhält dieser doch eine neue Eigenschaft: die Abfahrtszeit. Ich stelle mir die weiteren neuen Eigenschaften einfach als Ergänzung dieser Eigenschaft vor.

Zum Ändern von Daten sind die Datenwechselpunkte viel besser geeignet. Dort gibt es nur die klaren Situationen "Zug ist noch vor dem Datenwechselpunkt" (= "er hat noch die alten Daten") und "Zug hat den Datenwechselpunkt passiert" (= "er hat die geänderten Daten"). Es gibt kein "Zug steht am Datenwechselpunkt".

Das Problem an Datenwechselpunkten ist, dass man deutlich mehr Inputdaten benötigt.

Die Situation, die ich darstellen möchte, datiert auf 1939 in Darmstadt (eigentlich wollte ich den Fahrplan von 1926 umsetzen, dafür fehlen mir nur leider die Gleisnetzdaten).

Dabei hat beispielsweise die Linie 3 fünf Umläufe, die grundsätzlich alle 10 Min verkehrt, aber auf dem letzten Abschnitt (für die Ortskundigen: vom Hauptbahnhof weiter bis Rodensteinweg) nur alle 20 Min. Allerdings gibt es davon auch Ausnahmen, die nicht wirklich regelmäßig sind, und zwar sowohl in Form ausfallender Fahrten (stündlich von 8 bis 10), als auch zusätzlichen Fahrten (jede Fahrt zwischen 7 und und einzelnen Fahrten (z.B. um 13:26 Uhr).

Das Ändern von Daten am Taktpunkt ist ein konzeptioneller Fehler, den ich vor über 20 Jahren gemacht habe. Seitdem ist das in BAHN drin, es sollte aber nicht benutzt werden. Ich wollte es schon lange entfernen, aber es gibt leider viele Netze, die das verwenden. Schon vor über 10 Jahren habe ich aber alles dazu aus der Dokumentation gelöscht.

Das Ändern von Daten im Kopf (also der Linienliste) des Taktpunkts ist sicherlich nicht erforderlich, da das genauso gut an einem Datenwechselpunkt funktioniert. das von mir angesprochene Problem hingegen ließe sich über die vorgeschlagene Lösung jedoch wirklich deutlich einfacher umsetzen, siehe weiter unten.

Beispielhaft eine Abfahrtszeile:
2(L=3,Ziel="A"), 15(L=5,Ziel="B"), 22(L=3,Ziel="A"), 35(L=5,Ziel="C"), ...

Eine solche Zeile in einem Fahrplan ist doch alles andere als übersichtlich.

Das ist mit Datenwechselpunkten echt schwierig darzustellen, da für jeden Umlauf zwei Einträge fällig sind, mit mehreren Zeiten. Das ist natürlich sehr fehleranfällig und unübersichtlich. Das sieht dann bei mir aktuell so aus, obwohl ich das Fahrziel beim Datenwechselpunkt davor bereits einheitlich auf "Hauptbahnhof" festsetze:

3(sl=3,z=6:00-8:00 +10:30-11:00 +12:00-14:30 +15:30-16:00 +17:00-17:30 +18:45-19:15,n=11,Ziel="Rodensteinweg"), 3(sl=3,z=23:30-23:59,n=11,Ziel="Schloß"), 3(sl=3,z=6:00-8:30 +11:30-13:30 +14:45-15:15 +16:30-17:00 +18:10-18:40 +20:40-23:30,n=12,Ziel="Rodensteinweg"), 3(sl=3,z=6:30-8:00 +9:00-10:00 +11:30-13:00 +14:00-14:30 +15:50-16:30 +17:30-18:00 +19:00-20:00,n=13,Ziel="Rodensteinweg"), 3(sl=3,z=23:45-0:30,n=13,Ziel="Schloß"), 3(sl=3,z=6:50-7:30 +8:30-9:00 +10:00-11:00 +11:50-12:30 +13:30-14:00 +15:00-17:30 +18:30-19:00,n=14,Ziel="Rodensteinweg"), 3(sl=3,z=7:00-8:30 +9:30-10:00 +11:00-13:30 +14:30-15:00 +16:00-17:00 +17:50-18:30 +19:30-20:00,n=15,Ziel="Rodensteinweg")

Unübersichtlicher als das stelle ich es mir nicht vor, wenn jede Abfahrtszeit um die Eigenschaft "Ziel="Rodensteinweg"" oder "Ziel="Hauptbahnhof"" ergänzt wird.

Das ist auch nicht die einzige Situation im Netz ist, wo das so auftritt.

Der zweite Fall sind die Linien 6 und 7, wobei die Linie 6 grundsätzlich Moosbergstraße bis Ausweiche fährt, außer in der Fahrplanlage vor einer 7, dann nur bis Taunusstraße, während die Linie 7 nachmittags halbstündlich, vormittags stündlich verkehrt. Dabei ist immerhin die Linie 7 umlaufrein (wobei mittags ein Umlauf der Linie 6 auf die 7 übergeht), auf der Linie 6 rollieren die Ziele jedoch durch.

Das Problem tritt grundsätzlich immer dann auf, wenn eine ungerade Anzahl Umläufe auf einer Linie mit zwei (unregelmäßig) wechselnden Zielen verkehrt. Bei Regelmäßgkeit könnten natürlich noch Via-Bedingungen genutzt werden, aber das ist auch keine schöne Lösung.

Außerdem sollten neue Fahrziele und andere Daten bereits bei Erreichen der Haltestelle gesetzt sein, damit die Fahrgäste sehen, wohin der Zug weiter fährt. Viele IBIS/IFIS-Systeme machen das auch so, d.h. sie ändern die Daten zwischen der letzten Haltestelle und dem Endpunkt.

In meinem Beispiel kamen die Straßenbahnen an einem Taktpunkt an, wo die manuellen Rollbandanzeigen dann umgestellt wurden.

Außerdem wechseln die Zielanzeigen beispielsweise in Berlin oftmals an der Betriebshaltestelle, ehe die Straßenbahn weiter zur Abfahrtshaltestelle fährt. Der Taktpunkt muss also nicht gleich die Abfahrtshaltestelle sein.

Gruß
ST4

[ST4]

Guten Abend,

wenn ST4 das gleiche meint, wie ich vor einigen Jahren, dann wären das "einfach" mehrere eigenständige Taktpunkte an einem Punkt. Dann hätte man für jeden Taktpunkt an diesem Punkt einen eigenständigen Zähler, Linienliste, Abfahrten etc.
Der Vorteil, weswegen ich den Wunsch damals auch geäußert hatte, wäre, dass man bei großen Bahnhöfen bei verschiedenen Linien mit möglichen Verspätungen nicht viele TPs hintereinander bauen muss. Viel komplizierter in der Bedienung stelle ich mir das nicht vor. Man könnte eine Option einbauen, dass man beim Anklicken des Elements auswählen muss, welchen TP (mit Namen unterschieden) man bearbeiten möchte, ähnlich zu Zugverbänden, wo man dies bei Klick auf den Zug ebenfalls muss.

Das ist ein verwandtes Problem von dem, was ich meine, und macht Taktpunkte mit mehreren Linien übersichtlicher. Es würde mein akutes Problem jedoch nicht lösen.

Dennoch würde ich es auch begrüßen, wenn das eines Tages Teil von BAHN werden würde

[Seb144]

3(sl=3,z=6:00-8:00 +10:30-11:00 +12:00-14:30 +15:30-16:00 +17:00-17:30 +18:45-19:15,n=11,Ziel="Rodensteinweg"), 3(sl=3,z=23:30-23:59,n=11,Ziel="Schloß")

Hallo ST4,

dein Netzvorhaben klingt sehr interessant. Bezüglich der gewünschten Funktionserweiterung für Taktpunkte kann ich leider nichts sagen.

Nur zwei Anmerkungen zur Eintragung im Datenwechsel:
1. Die Überprüfung auf die Stammlinie (sl=3) scheint mir nicht notwendig zu sein, da es anscheinend keinen Fall gibt, bei dem eine "3" eine andere Stammlinie als "3" hat - jedenfalls gibt es keine Eintragung in deinem Zitat dazu. Daher könnte ggf. "sl=3," wegfallen.
2. Anscheinend hast du davor noch einen Datenwechsel, bei dem Du das Ziel auf "Hauptbahnhof" setzt. Den könntest Du mit folgender Eintragung (hier nur für Umlauf 11) einsparen:
3(z=6:00-8:00 +10:30-11:00 +12:00-14:30 +15:30-16:00 +17:00-17:30 +18:45-19:15,n=11,Ziel="Rodensteinweg"), 3(z=23:30-23:59,n=11,Ziel="Schloß"), 3(n=11,Ziel="Hauptbahnhof")
BAHN prüft die Bedingungen in der Eintragsreihenfolge. Wenn keine Bedingung für "Rodensteinweg" oder "Schloß" erfüllt ist, wird "Hauptbahnhof" gesetzt. Die Infomeldung beim Schließen des Datenwechsels, dass sich Bedingungen überschneiden, kannst Du ignorieren.

Im Grunde kannst Du auch genau das in die Linienliste beim Taktpunkt hineinkopieren, dann wird das Fahrziel genau dort geändert.
Ich nutze das sehr oft und bin Jan dankbar dafür, dass er diese Funktion einmal eingeführt hatte (auch wenn er das selbst als Fehler bezeichnet).

Grüße,


Sebastian
_________________
Berlin und Umgebung im Jahr 1989

http://www.bahn1989.berlin

[Jan Bochmann]

Guten Tag,

Das Problem an Datenwechselpunkten ist, dass man deutlich mehr Inputdaten benötigt.

Die Situation, die ich darstellen möchte, datiert auf 1939 in Darmstadt..

Das ist wirklich ein krasses Beispiel. In der Regel hat man Fahrpläne, die entweder in dichtem Takt, aber regelmäßig sind, oder sie sind unregelmäßig, dafür aber dünn - letzteres typisch beim Regionalbus, früheren Überlandbahnen oder klassischer Eisenbahn.
Den Fall "viele Fahrten, aber unregelmäßig" löse ich meistens mit einem Datenwechsel vor und einem nach dem Taktpunkt. Vor dem Taktpunkt wird das häufigste Fahrziel gesetzt. Nach dem Taktpunkt werden dann die Sonderfälle bearbeitet, und zwar nur nach der Bedingung Uhrzeit, ohne Rücksicht auf Kursnummern. An dieser Stelle kann man sich auf die Einhaltung der Fahrplanzeiten am meisten verlassen und kann oftmals auch Intervallangaben verwenden, z.B. wenn so etwas vorkommt wie "jede 2.Fahrt mit anderem Ziel".

Solange die Züge am Taktpunkt stehen, haben sie dabei alle das selbe Fahrziel. Diesen Kompromiß halte ich aber für akzeptabel, erst recht, wenn der Taktpunkt nur eine Betriebshaltestelle ist.

Beispiel: Netz Darmstadt_2003 (in der bearbeiteten Version von 2021), Hst. Mathildenplatz der Buslinie U. Da bekommen erstmal alle Fahrten das Ziel "Messel". Nach der Abfahrt wird dann bei Bedarf auf "Urberach" umgeschildert, und an einem weiteren Datenwechselpunkt wird via "Landeszentralbank" ergänzt. An dieser Stelle sind das nicht viele Daten, aber die Fahrpläne betreffen hier auch nur Mo-Fr, d.h. zusätzliche Einträge für Sa+So fehlen.

Unübersichtlicher als das stelle ich es mir nicht vor, wenn jede Abfahrtszeit um die Eigenschaft "Ziel="Rodensteinweg"" oder "Ziel="Hauptbahnhof"" ergänzt wird.

Wenn jemand nur die Zeiten wissen will oder den Takt erkennen möchte, dann stören diese zusätzlichen Einträge sehr.

In meinem Beispiel kamen die Straßenbahnen an einem Taktpunkt an, wo die manuellen Rollbandanzeigen dann umgestellt wurden.

Auch früher hat man Anzeigen schon gerne vor dem Endpunkt umgestellt, wenn sie von innen erreichbar waren, also z.B. Rollbänder mit Kurbelantrieb oder innen angebrachte Steckschilder. Typisch z.B. auf eingleisigen Strecken, wenn man vor dem Endpunkt sowieso noch auf den Gegenzug warten mußte. Dann hat man als Fahrer inzwischen das neue Ziel eingekurbelt. Als die Bahnen noch mit Schaffnern fuhren (z.B. 1939), haben es die Schaffner in ihren Wagen genauso gemacht. So hatten sie schließlich mehr Pausenzeit am Endpunkt.

Außerdem wechseln die Zielanzeigen beispielsweise in Berlin oftmals an der Betriebshaltestelle, ehe die Straßenbahn weiter zur Abfahrtshaltestelle fährt. Der Taktpunkt muss also nicht gleich die Abfahrtshaltestelle sein.

Wenn es extra Betriebshaltestellen und Ankunftshaltestellen gibt, dann gibt es viele Möglichkeiten. Man sollte dann in BAHN die nutzen, die am zweckmäßigsten erscheint. Das muß nicht unbedingt eine exakte Nachbildung des Vorbilds sein.

Gruß,
Jan B.

Edit: Beispiel ergänzt

[ST4]

Guten Morgen,

3(sl=3,z=6:00-8:00 +10:30-11:00 +12:00-14:30 +15:30-16:00 +17:00-17:30 +18:45-19:15,n=11,Ziel="Rodensteinweg"), 3(sl=3,z=23:30-23:59,n=11,Ziel="Schloß")

1. Die Überprüfung auf die Stammlinie (sl=3) scheint mir nicht notwendig zu sein, da es anscheinend keinen Fall gibt, bei dem eine "3" eine andere Stammlinie als "3" hat - jedenfalls gibt es keine Eintragung in deinem Zitat dazu. Daher könnte ggf. "sl=3," wegfallen.

Das ist richtig, dabei handelt es sich um eine gedankliche Altlast. Ich hatte zunächst überlegt, allen Fahrzeugen dieselben Umlaufnummern zu geben, und E-Wagen dann später über die Stammlinie zu filtern.

2. Anscheinend hast du davor noch einen Datenwechsel, bei dem Du das Ziel auf "Hauptbahnhof" setzt. Den könntest Du mit folgender Eintragung (hier nur für Umlauf 11) einsparen:
3(z=6:00-8:00 +10:30-11:00 +12:00-14:30 +15:30-16:00 +17:00-17:30 +18:45-19:15,n=11,Ziel="Rodensteinweg"), 3(z=23:30-23:59,n=11,Ziel="Schloß"), 3(n=11,Ziel="Hauptbahnhof")
BAHN prüft die Bedingungen in der Eintragsreihenfolge. Wenn keine Bedingung für "Rodensteinweg" oder "Schloß" erfüllt ist, wird "Hauptbahnhof" gesetzt. Die Infomeldung beim Schließen des Datenwechsels, dass sich Bedingungen überschneiden, kannst Du ignorieren.

Das ist ein guter Hinweis, das hatte ich bisher noch nicht versucht. Vielen Dank!

Den Fall "viele Fahrten, aber unregelmäßig" löse ich meistens mit einem Datenwechsel vor und einem nach dem Taktpunkt. Vor dem Taktpunkt wird das häufigste Fahrziel gesetzt. Nach dem Taktpunkt werden dann die Sonderfälle bearbeitet, und zwar nur nach der Bedingung Uhrzeit, ohne Rücksicht auf Kursnummern. An dieser Stelle kann man sich auf die Einhaltung der Fahrplanzeiten am meisten verlassen und kann oftmals auch Intervallangaben verwenden, z.B. wenn so etwas vorkommt wie "jede 2.Fahrt mit anderem Ziel".

Solange die Züge am Taktpunkt stehen, haben sie dabei alle das selbe Fahrziel. Diesen Kompromiß halte ich aber für akzeptabel, erst recht, wenn der Taktpunkt nur eine Betriebshaltestelle ist.

Beispiel: Netz Darmstadt_2003 (in der bearbeiteten Version von 2021), Hst. Mathildenplatz der Buslinie U. Da bekommen erstmal alle Fahrten das Ziel "Messel". Nach der Abfahrt wird dann bei Bedarf auf "Urberach" umgeschildert, und an einem weiteren Datenwechselpunkt wird via "Landeszentralbank" ergänzt. An dieser Stelle sind das nicht viele Daten, aber die Fahrpläne betreffen hier auch nur Mo-Fr, d.h. zusätzliche Einträge für Sa+So fehlen.

Das habe ich derzeit auch so gelöst. Aktuell bekommen die Fahrzeuge am Taktpunkt selbst das Ziel "Hauptbahnhof" und dahinter steht der oben zitierte Datenwechselpunkt. Die Auswertung nach Kursnummern habe ich eingeführt, weil ich beim Erstellen der Simulation auch immer mal Fehler habe. Ansicht würden Intervalle auch genügen, damit wäre es übersichtlicher. Dafür erzeugen Verspätungen größer 9 Minuten dann direkt einen Fehler. Ich versuche es mal mit den Intervallen.

Unübersichtlicher als das stelle ich es mir nicht vor, wenn jede Abfahrtszeit um die Eigenschaft "Ziel="Rodensteinweg"" oder "Ziel="Hauptbahnhof"" ergänzt wird.

Wenn jemand nur die Zeiten wissen will oder den Takt erkennen möchte, dann stören diese zusätzlichen Einträge sehr.

Das ist natürlich richtig. Allerdings sorgt es umgekehrt für eine höhere Übersichtlichkeit, wenn jemand die Details des Fahrplans (z.B. eben die Fahrziele) wissen möchte. Das ist in meinen Augen eine Abwägungsfrage.

Auch früher hat man Anzeigen schon gerne vor dem Endpunkt umgestellt, wenn sie von innen erreichbar waren, also z.B. Rollbänder mit Kurbelantrieb oder innen angebrachte Steckschilder. Typisch z.B. auf eingleisigen Strecken, wenn man vor dem Endpunkt sowieso noch auf den Gegenzug warten mußte. Dann hat man als Fahrer inzwischen das neue Ziel eingekurbelt. Als die Bahnen noch mit Schaffnern fuhren (z.B. 1939), haben es die Schaffner in ihren Wagen genauso gemacht. So hatten sie schließlich mehr Pausenzeit am Endpunkt.

Das ist natürlich richtig. In Woltersdorf bei Berlin geht man ja noch etwas weiter und lässt das Fahrziel komplett stehen, auch heute noch.

Wenn es extra Betriebshaltestellen und Ankunftshaltestellen gibt, dann gibt es viele Möglichkeiten. Man sollte dann in BAHN die nutzen, die am zweckmäßigsten erscheint. Das muß nicht unbedingt eine exakte Nachbildung des Vorbilds sein.

Das ist am Ende natürlich das ausschlaggebene Argument: es ist eine Simulation, keine Modellbahn. Simulationsbedingte Fehler sind also zulässig

Ich fände es dennoch schön, wenn die Funktion eines Tages auftauchen würde, zumindest wenn der programmiertechnische Aufwand überschaubar ist.

Gruß,
ST4

[Indi]

Hi ST4

Das ist mit Datenwechselpunkten echt schwierig darzustellen, da für jeden Umlauf zwei Einträge fällig sind, mit mehreren Zeiten. Das ist natürlich sehr fehleranfällig und unübersichtlich. Das sieht dann bei mir aktuell so aus, obwohl ich das Fahrziel beim Datenwechselpunkt davor bereits einheitlich auf "Hauptbahnhof" festsetze:

3(sl=3,z=6:00-8:00 +10:30-11:00 +12:00-14:30 +15:30-16:00 +17:00-17:30 +18:45-19:15,n=11,Ziel="Rodensteinweg"), 3(sl=3,z=23:30-23:59,n=11,Ziel="Schloß"), 3(sl=3,z=6:00-8:30 +11:30-13:30 +14:45-15:15 +16:30-17:00 +18:10-18:40 +20:40-23:30,n=12,Ziel="Rodensteinweg"), 3(sl=3,z=6:30-8:00 +9:00-10:00 +11:30-13:00 +14:00-14:30 +15:50-16:30 +17:30-18:00 +19:00-20:00,n=13,Ziel="Rodensteinweg"), 3(sl=3,z=23:45-0:30,n=13,Ziel="Schloß"), 3(sl=3,z=6:50-7:30 +8:30-9:00 +10:00-11:00 +11:50-12:30 +13:30-14:00 +15:00-17:30 +18:30-19:00,n=14,Ziel="Rodensteinweg"), 3(sl=3,z=7:00-8:30 +9:30-10:00 +11:00-13:30 +14:30-15:00 +16:00-17:00 +17:50-18:30 +19:30-20:00,n=15,Ziel="Rodensteinweg")

Nun es gibt hier noch weitere Möglichkeiten, ich nutze meistens die umgekehrte Eintragung nach Zeitintervallen statt nach Zugnummern

Code: Alles auswählen

S40(z=Mo-Fr:16:45-17:30, n=5+6+10, Ziel="South Avenue"),
S40(z=Mo-Fr:17:30-18:15, n=5+10, Ziel="South Avenue"),
S40(z=Mo-Fr:20:15-21:15, n=1+3+5, Ziel="South Avenue"),
S40(z=Mo-Fr:21:45-22:15, n=4, Ziel="South Avenue") 

Dabei trage ich den Umlauf 5, mit Ankunft zwischen 17:20 und 17:40 in beiden Intervallen ein um sicherzustellen, dass die Zuweisung funktioniert.

Zudem habe ich auch schon eine andere Methode versucht: wenn Verspätungen teilweise grösser sind als Taktintervalle, zum Beispiel im 3-Minuten Takt. Die Lösung ist dann den Fahrten bereits an der vorherigen Endstation eine um 100 erhöhte Umlaufnummer zu geben, wenn Sie an der nächsten Endhaltestelle ein abweichendes Fahrziel erhalten sollen. Für ein drittes Fahrziel um 200 erhöht. Der Umlauf 3 wird also zu 103 oder 203. An der besagten Endhaltestelle, wo die Fahrziele unterschiedlich werden, kann ich dann einfach folgendes eingeben:

Code: Alles auswählen

10(n=100-114, Ziel="Rodensteinweg"), 3(n=200-214, Ziel="Schloß") 

Das ist etwas weniger fehleranfällig, weil die Fahrten in der Regel nach Taktpunkten pünktlicher sind als vor Taktpunkten, der Aufwand ist vergleichbar.

Gruss Indi