TRAM - Tram Routes Analysis Module

[ULF]

Manch einer von euch wird sich wohl daran erinnern: Ich schreibe schon länger an einem Java-Programm, dass auf der Echtzeitschnittstelle der Wiener Linien aufsetzt. Das ganze begann eher als Proof-of-Concept-Projekt, hat sich aber mittlerweile zu einem ausgewachsenen Programm entwickelt. Zur Zeit steckt das Ding zwar noch tief in der Alpha-Phase (und wird es auch noch länger so bleiben mangels ausreichend Zeit und Lust an diesem Hobbyprojekt), dennoch hab' ich mir gedacht, ich stelle mein kleines aber feines Programm der hiesigen Forumgemeinde einmal vor.
Das Tram Routes Analysis Module als solches nimmt die Daten von der Echtzeitschnittstelle und bereitet sie in einer Form von RBL-Ansicht auf.

[ Für Gäste keine Dateianhänge sichtbar]
RBL-Ansicht aus dem Hause F57 (sorry, für die schlechte Bildqualität - habe ich beim Vorbeigehen aufgenommen)

Dabei werden die Standorte der Fahrzeuge einer Linie über die Ankunftszeiten der entsprechenden Haltepunkte extrapoliert und entsprechend (mit weiteren Daten von der OGD-Schnittstelle) dargestellt. Des Weiteren kann TRAM Abfahrtsmonitore als solches für jeden Haltepunkt für eine spezielle oder alle dort haltenden Linien darstellen.

[ Für Gäste keine Dateianhänge sichtbar]
Screenshot aus TRAM (v0.5.3)

Funktionsfähig ist zur Zeit auch eine Art "Analyse der letzten Planabfahrten", wobei es hier um die Pünktlichkeit als auch die Art (Niederflur versus Hochflur) der Blauen geht. Auch hier gibt es eine entsprechende Oberfläche und Statistiken. Zur Zeit streikt aber regelmäßig die OGD-Schnittstelle nach Mitternacht, sodass ich davon Screenshots erst nachliefern werde sobald das Ding mal anständig durchgelaufen ist.
Falls es jemanden interessiert: Im Hintergrund werkelt eine eigene Datenbank mit entsprechenden (im Programm integrierten) Editor, da sowohl die Schnittstelle als auch die Datenbasis von den Wiener Linien zum Teil inkonsistent sind beziehungsweise falsche Daten liefern. In dieser Datenbank sind sowohl die Linien, Haltepunkte, Fahrzeiten und dergleichen abgelegt, als auch so manche vom Programm erstellte Statistik zur späteren Analyse.
Zukünftig angedacht ist noch eine funktionsfähige Kartenansicht des Straßenbahnnetzes mit darauf georteten Fahrzeugen (linienunabhängig) als auch eine vollautomatische Gesamtauslaufanalyse. Aber das ist alles noch ferne Zukunftsmusik. Was wohl ein bisschen kurzfristiger kommen wird, ist die Veröffentlichung einer Alpha-Version, da der bisherige Stand eigentlich schon guten Nutzen bringt sowie relativ stabil ist. Zur Zeit bin dran ein paar bestehende Ecken dahingehend abzurunden. Sofern das Projekt irgendwann einmal soweit fertig sein sollte, ist auch eine Veröffentlichung des Source Codes angedacht - solange aber alles im Wandel begriffen ist, hat das keinen Sinn - es existieren einfach noch zu viele Baustellen. Grundsätzlich ist das Programm aber dafür recht modular aufgebaut. So kann das clientseitige Backend (zum Bespiel für Anfragen an die Echtzeitschnittstelle) vollkommen separat vom restlichen Programm verwendet werden - gleichzeitig könnte auch mit vergleichsweise wenig Aufwand eine beliebig andere Schnittstelle angedockt werden.

Mehr Informationen gibt's beizeiten ...

[roadrunner]

Als absoluter Laie bezüglich Programmieren und Schreiben, kann ich nur sagen, dass es mir sehr gut gefällt. 
Auch die beinhalteten Möglichkeiten finde ich super.

[martin8721]

Optisch schaut das auf jeden Fall deutlich ansprechender aus als das von F57. 
Coole Sache!

[95B]

Sehr saubere Arbeit!

Zur Zeit streikt aber regelmäßig die OGD-Schnittstelle nach Mitternacht, sodass ich davon Screenshots erst nachliefern werde sobald das Ding mal anständig durchgelaufen ist.

Ob das wohl Absicht ist, um die vielen Hochflurblauen zu verschleiern?

[Klingelfee]

Optisch schaut das auf jeden Fall deutlich ansprechender aus als das von F57. 
Coole Sache!

Mag sein, das es für dich ansprechender ist, als die Linienleiter von den WL. Ob es zum disponieren der Linie besser ist, stelle ich jetzt einmal in den Raum. Übersichtlicher finde ich dafür die WL-Version.

[13er]

Schaut echt schon sehr super aus!

Ich werd mich in nächster Zeit hoffentlich auch wieder ein bißchen dem Programmieren zuwenden können, dann kommt von mir auch noch ein kleines Projekt, das in eine andere Richtung geht.

Wenn du noch ein paar verschiedene Bilder vom RBL haben willst, meld dich einfach per PN!

[ULF]

Erstmal danke an euch alle für euer Lob!

Ob es zum disponieren der Linie besser ist, stelle ich jetzt einmal in den Raum. Übersichtlicher finde ich dafür die WL-Version.

Kleine Anmerkung dazu: Das Design ist noch lange nicht endgültig und kann von mir leicht noch verändert werden. Ich habe mich aber damals einfach von den gewöhnlichen Haltestellen-Perlschnüre inspirieren lassen, da mir diese Darstellung von Linien am besten gefällt. Andere Darstellungsarten können ohne weiteres noch kommen (ist aber im derzeitigen Alpha-Stadium einfach nicht prioritär).

Wie auch immer. Ich werde in den nächsten Tagen für jeden, den es interessiert, einzelne Teile des Programms näher vorstellen - quasi als kleiner Vorgeschmack. Bald danach sollte eigentlich schon die erste Alpha-Version zum Ausrollen bereit stehen.

Heute möchte ich mit den Abfahrtsmonitoren beginnen. Intern schlicht als Display bezeichnet, sind sie die ältesten Teile des Programms (sie wurden von mir beim Anbinden an die WL-Schnittstellen nebenbei implementiert), zugleich jedoch auch die neuesten. Zuletzt wurde die Darstellung von mir vollkommen auf den Kopf gestellt und sie erhielten ihr jetziges Aussehen als simulierte LED-Dotmatrix.

[ Für Gäste keine Dateianhänge sichtbar]
TRAM.monitor aus der Programmversion v0.5.4

Alles was man hier sieht wird vom Programm selbst gezeichnet - die Schrift ist im Programm eingebettet und bis auf das Rollstuhlsymbol sind keinerlei Grafiken involviert. Das blinkende Camping-Klo gab es im Übrigen zu keiner Zeit im Programm.
Das Display aktualisiert sich as-it-is regelmäßig von selbst (Frequenz und ob überhaupt ist im Programm separat einstellbar), informiert selbstständig über Störungen (auch Betriebsschluss udgl.) und ist relativ autark - kann als an jedes beliebige Backend angedockt und in andere Programme integriert werden. Grundsätzlich zeigt so ein Monitor zur Zeit immer nur die Abfahrten eines bestimmten Haltepunkts an. Was an dieser Stelle vielleicht noch interessant sein mag, der Abfahrtsmonitor erzwingt grundsätzlich Echtzeitdaten (falls keine geliefert wurden, versucht er selbstständig erneut welche anzufordern) - aber auch dieses Verhalten lässt sich selbstverständlich abstellen.
In der jüngsten Zeit wurde den Displays auch beigebracht mehrere Linien gleichzeitig anzuzeigen, was eher als Vorarbeit für zukünftige Zwecke zu verstehen ist (als Einsatz in einer (linienunabhängigen) Kartenansicht), da zur Zeit keinerlei großer Nutzen daraus zu ziehen ist - aber nice-to-have ist es ohnehin.

[ Für Gäste keine Dateianhänge sichtbar]
Abfahrtsanzeige im TRAM.monitor für mehrere Linien (sortiert nach Abfahrszeit)

Der Abfahrtmonitor zeigt dabei für jede Linie die nächste Abfahrt an. Die Sortierung kann über die Abfahrtszeit aber auch nach Linien erfolgen.

[ Für Gäste keine Dateianhänge sichtbar]
Abfahrtsanzeige im TRAM.monitor für mehrere Linien (sortiert nach Linien)

Für den Fall, dass es wen interessiert: Dieses kleine Teil besteht aus einer mageren Klasse mit 19 Attributen, 23 Methoden und insgesamt rund 400 Codezeilen, sowie einer inneren Klasse.

Das war's soweit dazu ...

[W_E_St]

Mehrere Linien pro Anzeige finde ich nicht nur nice to have wenn man zum Beispiel an einer der Währinger Linien wohnt und dein Projekt als itip-Ersatz missbraucht (zum Beispiel um sich vom Aumannplatz alle Abfahrten Richtung Schottentor in den nächsten Minuten anzuzeigen).

[ULF]

Da hast du natürlich vollkommen recht. Ich habe meine Aussage lediglich auf den Programm internen Einsatz bezogen. Dort kann man derzeit nur pro Linie die Fahrzeuge verorten und daneben die Anzeige mit mehreren Linien zu haben macht nicht viel Sinn. Als i.tip-Ersatz, kann ich mir vorstellen, das später ein wenig angepasster (personalisiert, als Desktop-Widget, o.ä.) im Programm anzubieten - aber das ist zum derzeitigen Stand noch etwas weit hergeholt. Aber wie gesagt, funktionieren tut es jetzt schon so oder so.

[benkda01]

Deine Software gefällt mir ausgesprochen gut!

Einen gut gemeinten Kritikpunkt hätte ich aber trotzdem:

und sie erhielten ihr jetziges Aussehen als simulierte LED-Dotmatrix.

...warum genau hast du das gemacht? Das Prinzip (Nachteile/Beschränkungen eines Objektes aus dem realen Leben, die sich aus den physischen Gegebenheiten ergeben, absichtlich in eine simulierte Version mit viel besseren Möglichkeiten zu übernehmen) erinnert mich an die neuen U-Bahn-Bahnsteigsdisplays, die an sich eine recht hochauflösende Dot-Matrix sind, aber trotzdem die alten Segmentanzeigen imitieren... Das ist genau die Weise, auf die man Skeuomorphismus besser nicht einsetzen sollte.

[ULF]

Du sprichst da nichts an, was ich mir schon selbst einmal gedacht habe.
Eigentlich ist das eher "gewachsen", wenn man so will. Ich wollte dem Teil eigentlich von Beginn an (wo es praktisch noch nix anderes gab) nur ein gefälliges Aussehen geben. Das vorläufige Endprodukt ist welches mir eigentlich am meisten gefallen hat - alles davor war auf seine eigene Weise schrecklich. Und zu guter Letzt war da - wie generell bei vielem in dem Programm - einfach der Reiz ob ich es so machen könnte.
Geplant war eigentlich den Abfahrtsmonitor auf die eine oder andere Art und Weise (schlichter, in die Richtung wie du es meinst) in die Auslaufanzeige zu integrieren. Irgendwann hab ich das dann auf Eis gelegt, weil ich keinen zusätzlichen Nutzen im Vergleich zum erheblichen Mehraufwand und der verringerten Übersicht sah.

[95B]

Abgesehen davon, dass "HERBECKSTRABE" grauslich ausschaut: Da der Text ja als solcher vorliegt, sollte es doch kein Problem sein, nach benutzerdefinierter Einstellung entweder das Matrixmuster zu verwenden oder eine beliebige andere Systemschrift.

[ULF]

Mit dem scharfen S hast du natürlich recht, das habe ich bereits vernichtet.
Und ja, ich notiere mir das gerne und werde es beizeiten einfließen lassen.

[Linie 41]

Das Komme gehört übrigens in die andere Richtung geneigt.

[ULF]

Das Komme gehört übrigens in die andere Richtung geneigt.

Die Kommata sind leider bei der Schriftart so dabei (verstehe selber nicht wie man auf die Idee kommt). Da das aber für die Benutzung des Programms komplett powidl ist, wird sich daran erst einmal nix ändern.

Zu einem anderen Teilstück von TRAM: Heute will ich euch hier die Analysefunktion für die Blauen/letzten Planabfahrten vorstellen. Intern schlicht als LDA bzw. LDS bezeichnet (Last Departure Analysis/Statistics), ist das eigentlich noch ein relativ junger Teil von TRAM. Es geht hier schlicht darum: Ist der letzte Wagen auf einer Linie hoch- oder niederflurig und ist dieser pünktlich? Dafür werden die letzten Abfahrten an den jeweiligen Endstellen einer Linie betrachtet (also die Wagen, die zuletzt den gesamten Linienverlauf in eine Fahrtrichtung abfahren) - das reicht in den allermeisten Fällen. Nachdem die OGD-Schnittstelle sich gestern keine großen Späße erlaubt hat, kann ich euch Screenshots von einem vollständigen (und interessanterweise recht passenden) Probelauf gestern anbieten.

[ Für Gäste keine Dateianhänge sichtbar]
Die Analyse für die letzten Planabfahrten eines Tages (vom 17.03.) in Version 0.5.4

Grundsätzlich erklärt sich das Dargestellte eh von selbst, jedoch ist im Hintergrund viel Arbeit nötig damit es anständig läuft. Zuallererst verläuft die Analyse (normalerweise) vollautomatisch, das heißt man gibt TRAM den Befehl und zur gespeicherten Planabfahrtszeit der Blauen (genauer gesagt fünf Minuten davor) wird eine Abfrage an der jeweiligen Endstation getätigt - auch wenn das Programm nur im Hintergrund läuft. Schlägt diese erste Abfrage fehl, wird ein weiterer Versuch etwas später getätigt. Manuell eingreifen in all diese Prozesse und Daten lässt sich über die oben gezeigte Tabelle per Kontextmenü. Das ist leider manchmal nötig, wenn die OGD-Schnittstelle zickt (und man manuell Abfragen auslösen muss) - die meiste Zeit funktioniert es aber sonst eigentlich ohne Probleme. Schließlich werden die Ergebnisse allesamt in der internen Datenbank gesammelt und zur späteren Analyse gespeichert.
Man kann hier TRAM auch anweisen nach getaner Arbeit den Computer automatisch herunterzufahren, falls nötig.

[ Für Gäste keine Dateianhänge sichtbar]
Die Statistik für die letzten Planabfahrten eines Tages (vom 17.03.) in Version 0.5.4

Die angesprochenen gespeicherten Ergebnisse lassen sich schließlich filtern und so weiter und so fort. Ich könnte mir hier übrigens vorstellen, die Ergebnisse (wo auch immer) online zu lagern (sobald irgendwer sie hochladen will), dann allen Nutzern zukommen zu lassen (sofern sie nicht selbst eine Analyse laufen ließen). Aber solange das Programm nicht draußen ist, hat das natürlich noch keinen Sinn.

Zu guter Letzt wieder einmal ein bisschen Statistik: Die oben gezeigte GUI alleine besteht aus 12 Java-Klassen, benötigt rund 90 Methoden, 70 Attribute und fast 1500 Zeilen Code - und da ist das ganze Backend noch nicht mitgerechnet.

Mehr folgt dann wieder morgen ...