Über das ewige Scheitern der Fahrgastinformation

[Klingelfee]

Bei anderen Verkehrsbetrieben ist dynamische Wegführung bei Störungen jedenfalls schon lange Standard, die Ausrede, dass manche Störungen nur kurz dauern halte ich für etwas albern. Natürlich werden nie alle Störungen berücksichtigt werden können, aber längerfristige spontane Umleitungen sollten definitiv auch bei der Wegfindung berücksichtigt werden. Erst recht in einer von so vielen Touristen besuchten Stadt wie Wien, denn denen fehlt nähere Netzkenntnis sicher.

Wie Tatra83 erwähnt hat, geht das auch in Wien. Was ich nicht gewusst habe.

Mir stellt sich nur die Frage, ab wann das auch wirklich sinnvoll ist. Denn bei vielen Störungen ist es, überhaupt für netzunkundige Fahrgäste, besser die Störung abzuwarten, als eine Alternativroute zu suchen.

Nochmals zur Erklärung. Das System kann Abweichungen vom Fahrplan erst dann wirklich wahrnehmen, wenn Züge/Busse abgelenkt werden. Eine manuelle Information gibt es nicht. Und dann stellt sich mir die Frage, selbst wenn man eine manuelle Info einpflegen kann, wie lange soll man diese in die Zukunft einpflegen. Denn was nützt mir ein Störung jetzt, wenn ich eine Fahrplanauskunft in 30 min brauche. Da ist die Störung vielleicht schon wieder beseitigt und ich kann die Route ganz normal benutzen.

Und bei vielen Störungen kann man nicht immer gleich abschätzen, wie lange eine Störung dauert.

[Kanitzgasse]

Ach, der 49er bekommt eine neue Schleife über Bellariastraße – Hansenstraße – Volksgartenstraße – Museumstraße? 

[U4]

Wann beginnen denn die Gleisbauarbeiten in der Museumstraße   

[Tatra83]

Vorausgesetzt die Abstimmung zwischen der RBL-Nummer der Wiener Linien und den Haltestellennummern des nachgelagerten Systems wurden abgestimmt und passen zusammen. Leider war es beim letzten Mal, als der 71er bis zum Schottenring verlängert wurde nicht der Fall.

Das Problem ist dabei, dass die entsprechenden RBL-Nummern WL-seitig (im Hastus, m.W.n.) nicht statisch gehalten werden. Man recycled da gerne, wie z.B. als eine RBL-Nummer von der Hst. Kärntner Ring/Oper in Hausfeldstraße U wieder verwendet wurde. Das darf nicht passieren, wenn man eine entsprechende Umschlüsselung auf den Haltestellen-ID nutzt.

Mir stellt sich nur die Frage, ab wann das auch wirklich sinnvoll ist. Denn bei vielen Störungen ist es, überhaupt für netzunkundige Fahrgäste, besser die Störung abzuwarten, als eine Alternativroute zu suchen.

Es macht jedenfalls Sinn, weil du im Moment deiner Routen-Abfrage die Information erhälst, dass du dein Ziel nicht direkt erreichen kannst, weil eine Störung vorliegt. Stattdessen bietet dir das System gemäß der aktuellen Betriebslage einen Routen-Vorschlag an, der im konkreten Fall auch umgeleitete Züge beinhalten kann. Ein Klassiker wäre die Umleitung der Linie D über den Schwedenplatz. Wenn du von Norden kommend bspw. zum Rathaus willst, wird die neue Route mit einem Umstieg auf die U2 am Schottenring angeboten.

[Alex]

Wann beginnen denn die Gleisbauarbeiten in der Museumstraße   

Apropos Gleisbauarbeiten … laut den Unterlagen aus der Pressemeldung finden im Zuge der Umbauarbeiten der Neubaugasse auch Gleisbauarbeiten am 49er statt und zwar im April/Mai 2020.

[Tunafish]

Wie Tatra83 erwähnt hat, geht das auch in Wien. Was ich nicht gewusst habe.

Das ist aber eine ziemlich weite Definition von "geht auch in Wien", wenn die technische Möglichkeit zwar bestünde, die Daten dem Nutzer aber nie angezeigt werden. Als Fahrgast habe ich von irgendwelchen theoretischen Möglichkeiten im Backend nichts.

[64/8]

Vorausgesetzt die Abstimmung zwischen der RBL-Nummer der Wiener Linien und den Haltestellennummern des nachgelagerten Systems wurden abgestimmt und passen zusammen. Leider war es beim letzten Mal, als der 71er bis zum Schottenring verlängert wurde nicht der Fall.

Das Problem ist dabei, dass die entsprechenden RBL-Nummern WL-seitig (im Hastus, m.W.n.) nicht statisch gehalten werden. Man recycled da gerne, wie z.B. als eine RBL-Nummer von der Hst. Kärntner Ring/Oper in Hausfeldstraße U wieder verwendet wurde. Das darf nicht passieren, wenn man eine entsprechende Umschlüsselung auf den Haltestellen-ID nutzt.

Ist mir bekannt. Das war ja auch der Grund, weshalb der 71er in den zuvor genannten Medien leider bei einer falschen Station gelandet ist. Eine recyclete Nummer und eine fehlende Kommunikation zum VOR, denn ich glaube kaum, das so etwas kommuniziert wird, denn das wurde ja noch nie gemacht.

[Donaufelder]

Wann beginnen denn die Gleisbauarbeiten in der Museumstraße   

Da müssen sie sich aber sputen, wenn die Schleife im nächsten Monat fertiggestellt und befahrbar sein soll, bei dem Bautempo in Wien ist das durchaus ambitioniert!
Den Wiener Linien ist in Sachen Öffentlichkeitsarbeit scheinbar überhaupt nichts mehr peinlich!!

[Tatra83]

Wie Tatra83 erwähnt hat, geht das auch in Wien. Was ich nicht gewusst habe.

Das ist aber eine ziemlich weite Definition von "geht auch in Wien", wenn die technische Möglichkeit zwar bestünde, die Daten dem Nutzer aber nie angezeigt werden. Als Fahrgast habe ich von irgendwelchen theoretischen Möglichkeiten im Backend nichts.

Werden sie doch, nur nicht in den Apps der Wiener Linien! Probiere es in der Routen-App vom VOR aus.

[haidi]

Mir stellt sich nur die Frage, ab wann das auch wirklich sinnvoll ist. Denn bei vielen Störungen ist es, überhaupt für netzunkundige Fahrgäste, besser die Störung abzuwarten, als eine Alternativroute zu suchen.

Nochmals zur Erklärung. Das System kann Abweichungen vom Fahrplan erst dann wirklich wahrnehmen, wenn Züge/Busse abgelenkt werden. Eine manuelle Information gibt es nicht. Und dann stellt sich mir die Frage, selbst wenn man eine manuelle Info einpflegen kann, wie lange soll man diese in die Zukunft einpflegen. Denn was nützt mir ein Störung jetzt, wenn ich eine Fahrplanauskunft in 30 min brauche. Da ist die Störung vielleicht schon wieder beseitigt und ich kann die Route ganz normal benutzen.

Und bei vielen Störungen kann man nicht immer gleich abschätzen, wie lange eine Störung dauert.

Ich denke die beste Lösung wäre, dass die normale Route vorgeschlagen wird mit dem Zusatz in etwa so: "Derzeit gibt es eine Störung zwischen den Haltestellen...., die voraussichtlich bis X Uhr besteht/über die Dauer können derzeit keine Angaben gemacht werden/Die Störung wird länger als 30 Minuten/1Stunde dauern. Wollen Sie eine Alternativroute wählen?"

[denond]

Und was ich nicht gewusst habe, dass Ablenkungen mit hinterlegten Fahrplan auch im Routing berücksichtigt wird. Was allerdings Fakt ist, dass eine Ablenkung erst dann berücksichtigt werden kann, wenn diese auch vom Disponenten in das System eingepflegt wird. Und das wird oft erst 5-10 min bevor die Ablenkung relefant ist, gemacht. Sprich 2-3 Haltestellen vor dem Ablenkungspunkt. Und was nützt mir jetzt eine Abfrage, wenn  mir auf Grund dieser Tatsache das Routing  vom nächsten Zug/Bus angezeigt wird, weil eben der Disponent diesen noch nicht manipuliert hat.

Es liegt das Scheitern im Auffassungsunterschied zwischen Disponent und Leitstellentisch-Mitarbeiter.
Der Leitstellenmitarbeiter ist unter "Druck von Oben" darin gezwungen, auf eine Störung so schnell wie möglich zu reagieren, Ablenkungen anzuordnen und dies nach einiger Zeit - nämlich dieser Zeitspanne, die der Leitstellenmitarbeiter für sein eigenes Aufgabengebiet selbst braucht um seine eigene Tätigkeitsaufgabe abzuarbeiten - dem Disponenten weitergibt, da dieser nicht selbsttätig tätig werden darf um auf eine Störung zu reagieren obwohl der Disponent vielleicht die anstehende Störung schon für sich realisiert hat und auch bereits Ideen für die Störung entwickelt hat. Aber: Er liegt in Hierarchie eine Stufe unterhalb des Leitstellenmitarbeiters und ist auf diese Anweisungen gebunden.
Und dadurch verpaßt dann der Liniendisponent eben die Möglichkeit, für einen Kurs die entsprechenden Daten einzugeben. Und somit entsteht eine nicht kurskonforme Anzeige im System. Es enteilt im sozusagen der Kurs in der Störung. Gleiches Problem haben ja auch die ÖBB bei ihren BFZen, wo durch die vielflut an notwendigen Dateneingaben im Störungsfalle oftmals ein Zug dem Disponenten davonfährt und eine nachträgliche Dateneingabe nicht mehr möglich ist.

Der Disponent kann nicht gleichzeitig Störungsmanagement auf der Strecke betreiben und gleichzeitig Störungsmanagement im System leisten. Das ist der wahre Grund, warum oft manches nicht funktioniert. Daran gehörte schon seit der Implementierung des RBL bei den WL oder der BFZ bei den ÖBB gearbeitet. Das kostet aber oftmals mehr Geld als ursprünglich, erfordert zusätzliches Personal, aber man will in so manchem BWL-Köpfen ja einsparen. Nur so funktioniert es eben nicht...

[Signalabhängigkeit]

Gleiches Problem haben ja auch die ÖBB bei ihren BFZen, wo durch die vielflut an notwendigen Dateneingaben im Störungsfalle oftmals ein Zug dem Disponenten davonfährt und eine nachträgliche Dateneingabe nicht mehr möglich ist.

Aha, ist das so?

Und "welche" ÖBB?

[Tatra83]

Es liegt das Scheitern im Auffassungsunterschied zwischen Disponent und Leitstellentisch-Mitarbeiter. [..]

@denond, das geht jetzt nicht gegen dich, aber ich habe noch nie in einem anderen Verkehrsbetrieb (in D, A, CH) eine derart sich selbst behindernde Struktur in der Betriebsaufsicht gesehen wie in Wien.

[denond]

Aha, ist das so?

Und "welche" ÖBB?

Muß so sein, aus den Schilderungen heraus, von betroffenen Mitarbeitern einer BFZ. Die werden sich das sicher nicht aus dem Finger saugen. Auch bist du ganz sicher darüber informiert, wo eine BFZ in der Hierarchie der Eisenbahn in Österreich eingebettet ist...  Aber nochmals:
Ein Disponent kann nicht gleichzeitig Störungsmanagement auf der Strecke betreiben und gleichzeitig Störungsmanagement im System leisten.

@Tatra83
Ist schon o.K., ich fühle mich davon auch nicht betroffen.
Aber leider lebt eine solche sich selbst behindernde Struktur in Wien auch im Jahr 2019 an maßgeblicher Stelle, und ich kann deine Beobachtungen von anderen Verkehrsbetrieben nur bestätigen.

[Signalabhängigkeit]

Von welchen "Daten" redest du?