Statistik der Blauen Hochflurer

[13er]

Ich habe gestern wieder mal meine Auswertung zur Blauen laufen lassen. Auf folgenden Linien war mindestens einer der letzten Züge (also entweder komplette Strecke oder halbe Strecke+Einziehen) ein Hochflurer: 1, 18, 26, 40, 41, 49, 60, 67, 71, D.

Ich werde das wieder mal über ein paar Tage beobachten.

[95B]

Ich habe gestern wieder mal meine Auswertung zur Blauen laufen lassen. Auf folgenden Linien war mindestens einer der letzten Züge (also entweder komplette Strecke oder halbe Strecke+Einziehen) ein Hochflurer: 1, 18, 26, 40, 41, 49, 60, 67, 71, D.

Du weißt doch: Das ist so beabsichtigt, weil niemand an verantwortlicher Stelle daran glaubt, dass es heutzutage wirklich notwendig ist, einem Verkehrsunternehmen explizit vorzuschreiben, dass es seine Niederflurzüge möglichst kundenorientiert einzusetzen hat.

[Inventar]

Du siehst das zu eng. Gibt ja keine Blaue mehr. Kommt eh da Nachtbus 

[B. S. Agrippa]

Du siehst das zu eng. Gibt ja keine Blaue mehr. Kommt eh da Nachtbus 

Tatsächlich gibt es für jede angeführte Linie - oder zumindest eine wichtige Teilstrecke jeder Linie - einen Nachtbusersatz, böse Zungen könnten da ja direkt einen früheren Betriebsbeginn der Nachtbusse (bei frühzeitigem Betriebsschluss der Bim) fordern. 

[13er]

Heutige Statistik (keine Angst, ich mach das jetzt nicht jeden Tag) der Hochflurer: 9, 10, 18, 38, 40, 41, 60.

Das ist allerdings nur das Minimum, da heute wieder einmal die Zuverlässigkeit der Echtzeitdaten niederschmetternd war: Von ca. 100 Einzelanfragen wurden nur 46 mit Echtzeitdaten versorgt und das, obwohl mein Algorithmus inzwischen recht ausgefeilt ist und bei Serverproblemen oder Planzeitdaten alle möglichen Tricks nutzt, um doch noch an Echtzeitdaten zu kommen. Aber das entspricht ungefähr dem Ergebnis, das man auch im Qando am Handy hat. Verständlich, warum man so viel Angst vor der Freigabe der Echtzeitdaten hat.

Zum Vergleich. Auf folgenden Linien waren - aufgrund der empfangenen Echtzeitdaten - auf jeden Fall alle Blauen Niederflur: 6, 42, 44, 52, O.

[Linie 41]

Am Handy brauche ich jetzt übrigens zwischen 3 und 5 Abfragen, um an die vollständigen Echtzeitdaten einer Station mit mehreren Linien zu kommen. Das ist an Peinlichkeit eigentlich nicht mehr zu überbieten.

[95B]

Am Handy brauche ich jetzt übrigens zwischen 3 und 5 Abfragen, um an die vollständigen Echtzeitdaten einer Station mit mehreren Linien zu kommen. Das ist an Peinlichkeit eigentlich nicht mehr zu überbieten.

Am Desktop-PC wird die Auswahl vom Eidibb immer wieder zurückgesetzt (Startseite wird geladen) oder es erscheint eine leere Abfahrtstabelle (mit Haltestelle, aber ohne Linie) oder man bekommt überhaupt Daten zu einer ganz anderen Haltestelle...

[Linie 41]

Ah, fast so super wie die EFA, die seit Neuestem die Formulardaten nicht in die erweiterte Ansicht übernimmt.

[ULF]

Das ist allerdings nur das Minimum, da heute wieder einmal die Zuverlässigkeit der Echtzeitdaten niederschmetternd war...

Ich bin sowieso der Meinung (insbesondere nach ein paar Aussagen von Insidern und meiner eigenen Herumdokterei an der Schnittstelle), dass die Datenqualität (bzgl. Erhalt von Echtzeitdaten) absichtlich beschränkt wird. So kann man sich dann zum Beispiel auch erklären, warum man ein und derselben Haltestelle in die eine Fahrtrichtung Echtzeitdaten erhält und die andere Planzeiten. Beim nächsten Aufruf kann es dann genau umgekehrt, alles Planzeiten und im glücklichen Fall sogar beides Echtzeitdaten sein. Die Regelmäßigkeit in der alleine dieses Phänomen auftritt und der rouletteartigen Verteilung der Ergebnisse lassen eigentlich gar keinen anderen Schluss zu.
Die restlichen Probleme sind einzig und allein der mangelnden Ausbildung von irgendwelchen dahergelaufenen Schwachstromtechnikern zu IT-Spezialisten zuverdanken, die Geld dafür bekommen an einem Produktivsystem herumzutüfteln. Das verwundert also auch nicht weiter...

Verständlich, warum man so viel Angst vor der Freigabe der Echtzeitdaten hat.

Die Angst vor öffentlichen Echtzeitdaten liegt sicher nicht in deren Qualität begründet (die Wiener Linien wissen sehr wohl zu jeder Zeit wo sich ihre Fahrzeuge befinden)... Wenn man wirklich wollen würde, könnte man sie auch ohne weiteres allesamt veröffentlichen. Man will nur ganz offenkundig nicht, was man auch einmal an anderer Stelle in einer Pressemitteilung mehr oder minder direkt ausgesprochen hat. Warum? Damit findige Entwickler und Beobachter nicht auf die Idee kommen unabhängig die Servicequalität der Wiener Linien zu analysieren. Das liegt nicht im Interesse der Veranwortlichen und der Mitarbeiter und nicht mal im Interesse der Politik. Das ist auch der Grund, warum ich da in nächster Zeit schwarz sehe, solange die breite Öffentlichkeit (insbesondere die Medien) nicht die Finger in die Wunde legen und den Druck massiv erhöhen...

[13er]

dass die Datenqualität (bzgl. Erhalt von Echtzeitdaten) absichtlich beschränkt wird.

Das absichtlich würde ich eher so auslegen: Die Kapazitäten der Server (ob das jetzt Hardware oder Lizenzen sind) sind zu gering und man macht auch nichts, um sie zu erhöhen, da das zu teuer wäre.

[ULF]

Das glaube ich eben eher nicht... Wenn der Server schon Zeit hat mir zu antworten, dann kann er mir auch eine vollständige Echtzeitantwort schicken oder eine reine Planzeit (falls das RBL grad keine Echtzeitantworten zulässt) - das würde ich ja verstehen. Aber der Qandoserver/itip-Server/FGI-Server packt das eigenlich - relativ - gut (kein Wunder... wir sprechen ja von keiner Serverlast à la Google, Facebook & co.). Insbesondere diese Halbe-Halbe-/Echtzeit-Planzeit-Antworten lassen sich nicht alleine mit Kapazitätsengpässen am Server erklären.
Du kennst ja die Ergebnisse: Das ist reinstes Roulette, was man von der Schnittstelle erhält... Komplett unabhängig von Zeit und Ort. Mich würde ja nicht mal wundern, wenn da ein Math.random() im Hintergrund eigentlich über die Datenqualität entscheidet. Zutrauen würde ich es ihnen jedenfalls: "Fraunz, bau' do wos ei, damit de net imma uns ausspioniern kennan mit eanan Spüzeig..!" - "Wie suit i des austöhn?" - "Schick eana heut net imma di Woaheit!". 
Und natürlich stehen da noch Aussagen von Insidern im Raum, die genau eben das behaupten... Ich will den Wiener Linien hierbei nichts per se unterstellen... Vielleicht stimmt ja das alles nicht und im Endeffekt ist alles dem Schwachstromtechniker und Geldflüssen in die falschen Ecken zu verdanken... Aber das glaube ich (fast) nicht..

[E2]

dass die Datenqualität (bzgl. Erhalt von Echtzeitdaten) absichtlich beschränkt wird.

Das absichtlich würde ich eher so auslegen: Die Kapazitäten der Server (ob das jetzt Hardware oder Lizenzen sind) sind zu gering und man macht auch nichts, um sie zu erhöhen, da das zu teuer wäre.

.... abschalten. DANN stimmts immer.

[13er]

ULF, zutrauen würd ich ihnen eh auch alles Bin halt nur kein Verschwörungstheoretikerfan, allerdings haben sie schon oft genug bei diversen Dingen gelogen, also warum nicht auch hier.

[hema]

Am Desktop-PC wird die Auswahl vom Eidibb immer wieder zurückgesetzt (Startseite wird geladen) oder es erscheint eine leere Abfahrtstabelle . . . .

Jetzt weißt du auch, warum die FGI-Displays immer wieder ausffallen oder nicht (richtig) aktualisiert werden. Wenn zu viele Leute gleichzeitig draufschauen, ist das System überlastet und stürzt ab oder friert ein!


Ist wahrscheinlich auch mit dem RBL so, sind zufällig zu viele korrekte Lenker und Fahrer gleichzeitig unterwegs, welche gewissenhaft (zu) häufig aufs IBIS schauen, bringen sie das RBL wegen zu vieler Augenzugriffe zum Absturz.

[95B]

Jetzt weißt du auch, warum die FGI-Displays immer wieder ausffallen oder nicht (richtig) aktualisiert werden. Wenn zu viele Leute gleichzeitig draufschauen, ist das System überlastet und stürzt ab oder friert ein!

Jaja, Blicke können bekanntlich töten!