Tramwayforum
Gesamter öffentlicher Verkehr in Wien => Sonstiges => Thema gestartet von: ULF am 16. März 2014, 14:14:35
-
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.
[attach=1]
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.
[attach=2]
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 ... ;)
-
Als absoluter Laie bezüglich Programmieren und Schreiben, kann ich nur sagen, dass es mir sehr gut gefällt. :up:
Auch die beinhalteten Möglichkeiten finde ich super.
-
Optisch schaut das auf jeden Fall deutlich ansprechender aus als das von F57. 8)
Coole Sache!
-
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? :ugvm:
-
Optisch schaut das auf jeden Fall deutlich ansprechender aus als das von F57. 8)
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.
-
Schaut echt schon sehr super aus! :up:
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!
-
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.
[attach=1]
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.
[attach=2]
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.
[attach=3]
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 ... ;)
-
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).
-
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. :)
-
Deine Software gefällt mir ausgesprochen gut! :up:
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. ;)
-
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.
-
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.
-
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.
-
Das Komme gehört übrigens in die andere Richtung geneigt. ;)
-
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.
[attach=1]
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.
[attach=2]
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 ... ;)
-
Mangels Zeit bekommt ihr heute nur einen kleinen weiteren, wenn auch wahrscheinlich nicht weniger interessanten Teil von TRAM zu Gesicht: Die Webservice Statistik oder Verbindungsstatistik. Nachdem es mich irgendwann selbst interessiert hat, wie lange der Server braucht, um auf Anfragen zu antworten und wie viele Daten vom Programm so angefordert werden, wurde von mir eine Statistik implementiert, die die Performance der Schnittstelle misst.
[attach=1]
TRAM.constats in Version 0.5.4
Wie man sieht, kann das ganze von Programmstart an oder als Gesamtstatistik (seit dem letzten Zurücksetzen) angezeigt werden. Die Daten im obigen Screenshot zeigen übrigens eine Messung über mehrere Wochen Implementierungszeit hinweg an. Die maximale Antwortzeit resultiert im Übrigen durch einen Timeout als der Server einmal nicht erreichbar war (40 Sekunden sind im Programm so voreingestellt).
Mehr gibt's dann wieder morgen... ;)
-
Die maximale Antwortzeit resultiert im Übrigen durch einen Timeout als der Server einmal nicht erreichbar war (40 Sekunden sind im Programm so voreingestellt).
Da müsstest du für die Statistik nur die erfolgreichen Verbindungen mitzählen und einen eigenen Zähler für die Anzahl der Timeouts einführen.
-
Da müsstest du für die Statistik nur die erfolgreichen Verbindungen mitzählen und einen eigenen Zähler für die Anzahl der Timeouts einführen.
Der Fehler wurde bereits behoben. Ich hatte nur noch die Statistik nicht zurückgesetzt. ;)
Mit etwas Verspätung möchte ich heute noch einen weiteren Teil von TRAM zeigen: Die Auslaufanalyse. Wie im Eingangspost eh zu sehen, kann das Programm über die Ankunftszeiten an den Haltepunkten einer Linie den Aufenthaltsort der Kurse extrapolieren. Der dafür verwendete Algorithmus ist mittlerweile recht ausgeklügelt und komplex. Die dafür zuständigen rund 500 Zeilen Programm-Code benutzen nicht nur die Ankunftszeiten von Fahrzeugen sondern auch archivierte Fahrzeiten und eine Fahrzeug-Typ-Analyse, um die Verortung stabiler zu machen. Die Darstellung orientiert sich - wie bereits erwähnt - am RBL der Wiener Linien.
[attach=1]
Auslaufanalyse in Version 0.5.4
Die hier gezeigte Oberfläche wird komplett dynamisch vom Programm generiert und gezeichnet (dafür werden rund 1000 Zeilen Java-Code benötigt). Gleichzeitig ist auch noch eine Listendarstellung der verorteten Fahrzeuge verfügbar, sowie eine kurze statistische Analyse der Intervalle und ähnlicher Daten des Auslaufs. Auch wurden vor kurzem von mir einige Heuristiken implementiert, die vollautomatisch "Schwächen" im Fahrzeugauslauf erkennen können und hinweisen. Im Bild ist beispielsweise erkennbar, dass das Programm auf eine schlechte Verteilung von Hoch-/Niederflurfahrzeugen hinweist (alle 4 Hochflurer befinden sich in einem "Block").
Das war's soweit von den einzelnen Teilen, die ich euch präsentieren wollte. Derzeit wird TRAM von mir noch auf einen öffentlichen Release vorbereitet. Die Arbeiten laufen gut und neigen sich schon dem Ende zu. Sprich: Sofern nix dazwischen kommt, wird's bald schon soweit sein und ihr könnt euch selbst damit spielen. ;)
-
Dieses Programm ist echt genial! :up:
Was ich mir aber noch wünschen würde: Dass man bei der Linienübersicht (z.B. Screenshot oben, Linie 26) gleich erkennt, welcher Zug NF ist und welcher nicht.
-
Ist es möglich, aus diesen Daten die Züge in Google-Maps darzustellen?
Zumindest die Position in der letzten Haltestelle?
-
Dieses Programm ist echt genial! :up:
Was ich mir aber noch wünschen würde: Dass man bei der Linienübersicht (z.B. Screenshot oben, Linie 26) gleich erkennt, welcher Zug NF ist und welcher nicht.
Das habe ich mir auch gedacht. Da die Information ja vorhanden ist, könnte man NF-Züge einfach durch eine andere Farbe darstellen.
-
Farblich hinterlegen ist optisch sicher eindeutiger als ein zartes Häkchen.
-
Dieses Programm ist echt genial! :up:
Danke erstmal. :)
Was ich mir aber noch wünschen würde: Dass man bei der Linienübersicht (z.B. Screenshot oben, Linie 26) gleich erkennt, welcher Zug NF ist und welcher nicht.
Wenn du damit die (graphische) Linienübersicht meinst, dann ist es bereits so, dass die Niederflurfahrzeuge (die Dreieckchen) blau dargestellt werden und die Hochflurer schwarz. Aber wenn das zu undeutlich ist, kann ich mich ja da noch mit den Farben ein wenig spielen bzw. auch noch die Fahrzeug-Anzeiger farblich hervorheben. Was generell für mich (von Anfang an schon) das Problem war: Wie weiß jemand, dass z.B. das Blau niederflurig bedeutet? Eine Legende kommt mir da sicher nicht hin und ein Camping-Klo auch nicht. Und "NF" oder so was hinschreiben würde ich nur ungern. Eine Lösung dafür gibt es im RBL meines Wissens auch nicht, da es maximal die Fahrzeugnummern darstellt (die ich aber nicht habe).
In der Listenansicht mit den Checkboxen ist die Niederflurdarstellung aber mMn völlig ausreichend. Ich hoffe ich hab' euch da richtig verstanden, dass ihr die graphische Darstellung meint.
Ist es möglich, aus diesen Daten die Züge in Google-Maps darzustellen?
Zumindest die Position in der letzten Haltestelle?
Wie im Eingangspost erwähnt ist eine Kartenansicht des Straßenbahnnetzes mit darauf georteten Fahrzeugen (linienunabhängig) zukünftig geplant. Das erfordert aber ziemlich viel Arbeit, da auch das Backend dafür angepasst werden muss. Und dafür fehlt mir zur Zeit die Zeit. Aber kommen wird es - ich will das Feature ja auch haben. ;)
-
Ich würde besser die Hochflurer kennzeichnen, weil dies in der Zukunft so übersichtlicher wird. Außerdem sind (zumindest für gehbehinderte Menschen) nicht die ULFe sondern die Ex das Problem.
-
Mein Vorschlag für die Farben der Pfeile wäre ein leicht ins Rot gehendes Schwarz für HF (rot = böse) und ins Grünliche oder Blaue gehend für ULFe. ;D
Edit: Was bei dem Detailfenster zu einer Linie (am Screenshot Linie 26, wo per Kästchen mit/ohne Häkchen NF/HF ennbar ist) eventuell noch interessant wäre: Von welcher Abstellhalle der Zug kommt, wann er ausgerückt ist, wann und wohin er einziehen soll. Vielleicht ist das durch die Fahrpläne eruierbar?
-
Ich hab mich jetzt ein bisschen mit der Darstellung gespielt:
[attach=1]
Fahrzeug-Anzeiger mit speziellen Hintergrund für Hochflurer
[attach=2]
Vom User Hauptbahnhof vorgeschlagene Farben für die Pfeile
Ehrlich gesagt bin ich aber mit beiden Alternativen (mehr oder minder) unzufrieden. Vorerst werde ich es mal beim bisherigen Design belassen, bis mir etwas besseres einfällt und mehr Zeit für solche Sachen ist.
Was bei dem Detailfenster zu einer Linie eventuell noch interessant wäre: Von welcher Abstellhalle der Zug kommt, wann er ausgerückt ist, wann und wohin er einziehen soll. Vielleicht ist das durch die Fahrpläne eruierbar?
Grundsätzlich wäre das natürlich sehr interessant. Praktisch aber nicht eruierbar, da keine dieser Daten über die OGD-Schnittstelle mitgeliefert werden. Die Fahrpläne zu parsen und daraus irgendetwas abzuleiten ist praktisch unmöglich bzw. den (erheblichen!) Aufwand nicht wert, da die ermittelten Daten mit ziemlicher Sicherheit nicht valide wären.
-
Ehrlich gesagt bin ich aber mit beiden Alternativen (mehr oder minder) unzufrieden. Vorerst werde ich es mal beim bisherigen Design belassen, bis mir etwas besseres einfällt und mehr Zeit für solche Sachen ist.
Ich kann mir vorstellen, dass eine farbliche Unterlegung des Fahrzieles oder unterschiedliche Schriftfarben auffälliger wären.
-
Was bei dem Detailfenster zu einer Linie eventuell noch interessant wäre: Von welcher Abstellhalle der Zug kommt, wann er ausgerückt ist, wann und wohin er einziehen soll. Vielleicht ist das durch die Fahrpläne eruierbar?
Grundsätzlich wäre das natürlich sehr interessant. Praktisch aber nicht eruierbar, da keine dieser Daten über die OGD-Schnittstelle mitgeliefert werden. Die Fahrpläne zu parsen und daraus irgendetwas abzuleiten ist praktisch unmöglich bzw. den (erheblichen!) Aufwand nicht wert, da die ermittelten Daten mit ziemlicher Sicherheit nicht valide wären.
Was hierzu wichtig zu wissen wäre:
Wie ist das jetzt, wenn eine Störung ist, Zug 6 kurzgeführt wird und dadurch nun vor Zug 5 ist. Tauschen die beiden dann die Nummer oder fährt dann 1, 2, 3, 4, 6, 5, 7, ...?
-
Wie ist das jetzt, wenn eine Störung ist, Zug 6 kurzgeführt wird und dadurch nun vor Zug 5 ist. Tauschen die beiden dann die Nummer oder fährt dann 1, 2, 3, 4, 6, 5, 7, ...?
Kurz gesagt: Nein, TRAM besitzt (noch?) keine Kurserkennung. Das hat vielerlei Gründe. Das fängt schon dabei an, dass die ODG-Schnittstelle keinerlei Daten liefert, wie man auch nur annähernd Fahrzeuge wirklich identifizieren könnte. Es gibt nur anonyme Abfahrten. Ich bin schon froh, dass man recht gut daraus Fahrzeug-Positionen extrapolieren kann. Eventuell wird von mir irgendwann, irgendwas in diese Richtung gebastelt.
Zur Nummerierung an sich: Zur Zeit werden die Fahrzeuge (vom Programm) einfach durchnummeriert (nach jeder Verortung). Zuerst alle Fahrzeuge in Fahrtrichtung 1, dann alle in Fahrtrichtung 2. Nichts außergewöhnliches, aber das reicht vorerst mal vollkommen.
Ich kann mir vorstellen, dass eine farbliche Unterlegung des Fahrzieles oder unterschiedliche Schriftfarben auffälliger wären.
Hm.. wär' 'ne Idee. Wenn ich dazu mal Zeit und Muße hab, werde ich mich eh mal wieder damit spielen. Auf jeden Fall hab ich euren Input dahingehend aufgenommen. :)
-
Ich bin schon froh, dass man recht gut daraus Fahrzeug-Positionen extrapolieren kann.
Da muss ich dir ein großes Kompliment machen, dass du das so hingebracht hast! Ich hab das schon aufgegeben, weil es mir viel zu umständlich ist. Die Nummer werden sie aber um ihr Leben niemals mitliefern. Außer ab 2030 (wer zweifelt daran, dass dann immer noch die heutige Schnittstelle verwendet wird?).
-
Da muss ich dir ein großes Kompliment machen, dass du das so hingebracht hast!
Ja, danke dir auf jeden Fall. Ich hab' eh öfters das Handtuch geschmissen (die Hintergrundroutinen in dem Teil sind ja zum Teil mehrere Jahre alt - zumindest deren Grundaufbau)... Gott sei Dank, konnte ich aber einiges an Hintergrundwissen sammeln, die mir geholfen haben, den Algorithmus (relativ) stabil zu gestalten. Ein paar aberwitzige Fehler gibt es noch... aber die werden immer weniger. Andere Dinge wiederum werde ich nie lösen können, da manchmal die Schnittstelle recht eigenartige Dinge von sich gibt. Vielleicht mache ich mal dazu ein Special. :D
Die Nummer werden sie aber um ihr Leben niemals mitliefern. Außer ab 2030 (wer zweifelt daran, dass dann immer noch die heutige Schnittstelle verwendet wird?).
Zum ersteren: Ich würde das gar nicht so sehr in den Wind blasen. Bei der derzeitigen kritischen und transparenzorientierten Bewegung (angefangen beim Amtsgeheimnis das abgeschafft werden soll) kann ich mir gut vorstellen, dass da nur die richtigen Leute (der neuen Generation) an den richtigen Hebeln sitzen müssten (und halt über ein paar Würmer drüberfahren müssten) und dann schaut schnell vieles anders aus. Aber grundsätzlich hast du recht... Bis dahin wird wohl noch viel Wasser die Donau runtergeronnen sein. Und ja, zwecks Zukunftsträchtigkeit der Schnittstelle enthalte ich mich jetzt einmal - TRAM ist zumindest so gebaut, dass ich so ziemlich alles mit vertretbaren Aufwand anstöpseln kann. 8)
-
Bei der derzeitigen kritischen und transparenzorientierten Bewegung (angefangen beim Amtsgeheimnis das abgeschafft werden soll)
Abschaffung des Amtsgeheimnisses ist zu wenig, in Deutschland gibt es die Informationspficht.
-
Genau das ist auch angedacht - so wie ich das gelesen habe. Aber wir kommen vom Thema ab.
-
Hallo,
Um noch einmal zu meiner Frage bezüglich Bahnhofszugehörigkeit zurückzukommen:
Ich kleiner Maxi stelle mir das so vor:
Zug 1 rückt in der Früh von Bhf. X aus und fährt zur Endstation A. Dort wendet er, behält aber die Info, dass er von X gekommen ist. Dann fährt er zur Endstation B, wendet wieder und gibt seine Herkunft wieder weiter und so weiter, bis der Zug wieder einzieht.
Das sollte auch bei Kurzführungen/Umleitung funktionieren, nur stelle ich mir die Unterscheidung problematisch vor, wenn in der Endstation mehrere Züge gleichzeitig stehen.
-
Hallo,
Um noch einmal zu meiner Frage bezüglich Bahnhofszugehörigkeit zurückzukommen:
Ich kleiner Maxi stelle mir das so vor:
Zug 1 rückt in der Früh von Bhf. X aus und fährt zur Endstation A. Dort wendet er, behält aber die Info, dass er von X gekommen ist. Dann fährt er zur Endstation B, wendet wieder und gibt seine Herkunft wieder weiter und so weiter, bis der Zug wieder einzieht.
Das sollte auch bei Kurzführungen/Umleitung funktionieren, nur stelle ich mir die Unterscheidung problematisch vor, wenn in der Endstation mehrere Züge gleichzeitig stehen.
Außerdem gibt es Fälle, wo ein Zug aus einem anderen Bahnhof ausfährt, als er einzieht.
-
Zug 1 rückt in der Früh von Bhf. X aus und fährt zur Endstation A. Dort wendet er, behält aber die Info, dass er von X gekommen ist. Dann fährt er zur Endstation B, wendet wieder und gibt seine Herkunft wieder weiter und so weiter, bis der Zug wieder einzieht.
Das sollte auch bei Kurzführungen/Umleitung funktionieren, nur stelle ich mir die Unterscheidung problematisch vor, wenn in der Endstation mehrere Züge gleichzeitig stehen.
Da TRAM clientseitig läuft (und nicht serverseitig ständig) und nicht alle Linien gleichtzeitig beobachtet werden (das würde bedeuten, jeder Client schmeißt ständig Abfragen für Abfahrten von allen Haltestellen netzweit raus), ist es nicht möglich bzw. praktikabel eine solche "Historie" eines Kurses zu implementieren. Noch dazu, wo es - wie gesagt - das Konzept eines Fahrzeuges nicht an der OGD-Schnittstelle gibt. Das heißt, es kann passieren, dass Fahrzeugstandorte durch die reinen Abfahrtszeiten nicht interpoliert werden können und dadurch verschwinden. Eine konsistente Verarbeitung nach Kursen ist somit praktisch unmöglich.
Was du dir wünscht ist eine vollständige RBL-Nachbildung. Das ist mit den derzeit vorhandenen Daten schlicht und ergreifend nicht möglich (und sicherlich von den Wiener Linien nicht gewollt).
-
Ok danke für die Aufklärung! :D
-
Nun, ich mach's kurz und bündig: Die erste öffentliche Alpha-Version von TRAM gibt's nun zum Download. :)
Auch wenn man länger nichts von meinem Projekt gehört hat, ist einiges - vieles im Hintergrund für die Zukunft - weiter gegangen (leider hatte ich oft auch schlichtweg keine Zeit - manchmal auch kein Interesse - dafür). Zur Zukunft: Da möchte ich noch nicht zu viel verraten. Ich werde dazu in absehbarer Zeit Einblicke geben.
Ich möchte hier nochmal darauf hinweisen, dass TRAM sich noch in Entwicklung befindet. Das Programm ist weder fertig noch fehlerfrei!
So weit, so gut. Mehr dazu findet ihr auf der Projekthomepage (https://www.assembla.com/spaces/tram/messages/4909993), die ich bei assembla.com (http://assembla.com) eingerichtet habe. Vormals nur Repository für den Code, sollte es in Zukunft als einfach verwaltbare Plattform zu TRAM dienen.
Viel Spaß! ;)
-
Habe mir das Programm schon gestern heruntergeladen. Tolle Arbeit! Läuft bis auf ein paar kleinere Bugs (die du sicher kennst) sehr stabil, habe es einige Zeit laufen lassen und beobachtet. Hätte eine Frage: funktioniert die automatische Benachrichtigung bei Updates schon?
Eine Idee hätte ich noch - ja ich weiß wir sind im Tramwayforum! - eventuell auch einbindung der Autobus- U-Bahn Linien. Ich finde es nämlich praktisch - bevor ich von der Arbeit etc weggehe schaue ich auf TRAM und sehe gleich ob irgendwo eine Störung anliegt und kann mich dementsprechend anpassen.
Bin mir sicher, dass das einige Arbeit war! Tolle gemacht!! Danke ;)
-
Großartig! 8) :up:
-
Danke erstmal an euch beiden für euer Lob! :)
Natürlich gibt es noch genug Ecken und Kanten, mit denen ich zum Teil recht unzufrieden bin... Gerade der Lokalisierung-Algorithmus für die Fahrzeuge ist sehr fehleranfällig. Beispiel gefällig? Der 5er wird ja dieses Wochenende geteilt geführt (http://www.tramwayforum.at/index.php?topic=5394.0). TRAM weiß davon selbstverständlich nix (die Arbeit tu' ich mir für 2 Tage nicht an) - genauso wenig wie die Open Government-Datenbasis von Seiten der Wiener Linien. Der Algorithmus geht also von Normalbetrieb aus, was dann so aussieht:
[attach=1]
- Der ULF bei der Laudongasse kann ja offensichtlich nicht sein. Aber warum bildet sich TRAM den dort ein? Ganz einfach. Im ganzen Netz gibt es eine Reihe von Haltepunkten, die über die OGD-Schnittstelle nicht abgefragt werden können - manche nicht mal von qando (zumindest nicht mit Echtzeitdaten - um ein Beispiel zu nennen: Fickeystraße stadtauswärts) - offensichtlich wurden diese Haltepunkte nicht richtig eingepflegt. Deshalb versucht TRAM bei diesen Haltepunkten die Fahrzeugposition zu interpolieren. Da der Algorithmus rekursiv ist, bedeutet das, dass das selbst über mehrere Haltepunkte hinweg möglich ist. Um auf unser Beispiel zurück zukommen: Der erste Haltepunkt bei dem eine Abfrage auf der normalen Strecke möglich ist, ist die Lerchenfelder Straße (siehe Screenshot). TRAM versucht nun über die nicht abfragbaren Haltepunkte hinweg zu interpolieren. Durch einen Programmfehler wird nun vor dem ersten nicht abfragbaren Haltepunkt der ULF angezeigt. Voilà! In der Baustelle in der Laudongasse steht ein 43-Tonnen-ULF! :D
- Zudem versucht TRAM an Endhaltestellen Fahrzeuge zu orten. Das geschieht über zwei Wege: Durch Fahrzeitüberprüfung (das nächste ankommende Fahrzeug schafft die nächste Abfahrt an der Endstation fahrzeitmäßig nicht) und durch Fahrzeugüberprüfung (die Fahrzeugtypen (niederflur/hochflur) der nächsten Abfahrt unterscheiden sich). Letztere Möglichkeit greift bei dem obigen Screenshot einer Ortung: Am Westbahnhof wird laut Schnittstelle nach zwei Niederflurfahrzeugen als drittes ein Hochflurer abfahren. Nachdem letzterer nicht vorher auf der Strecke "entdeckt" werden konnte, geht derzeit TRAM davon aus, dass er sich am Westbahnhof "versteckt hält" (sprich noch nicht abgefahren ist). In Wahrheit gibt es aber gar keinen Hochflurer am Südabschnitt des heutigen 5er. Der dritte ULF im Bunde ist schlichtweg noch nicht für die Abfahrt am Westbahnhof im RBL eingebucht. Es werden also Fahrplandaten übergeben und mangels Wissen ein Hochflurer ausgewiesen.
Für beide Fehler gibt es natürlich unterschiedlichste Behandlungsstrategien. Aber ums kurz zu machen: Um den Frust nicht überhand nehmen zu lassen, kann ich Fehler nur in sehr geringen Dosen im Lokalisierung-Algorithmus ausmerzen. ;) Letztlich ist es ein Kampf gegen die Schnittstelle der Wiener Linien (das heißt primär oft Fehler - manchmal auch nicht nachvollziehbare - ausbügeln, die eigentlich gar nicht da sein sollten). Früher oder später hoffe ich aber den Algorithmus soweit zu haben, dass er selbst solche Extremfälle wie dieses Wochenende am 5er selbstständig zufriedenstellend meistert.
Wer einen kleinen, wenngleich vermutlich etwas kryptischen Einblick in die Fahrzeugortung haben möchte: Über "Ansicht" -> "Letzte Fahrzeugortung prüfen" kann man das Protokoll der jeweils letzten Ortung sich ansehen.
Hätte eine Frage: funktioniert die automatische Benachrichtigung bei Updates schon?
Wenn du Programmupdates meinst: Ja, sowohl für die Datenbank als auch für die Anwendung selbst sucht TRAM bei Programmstart (oder manuell im Hilfe-Menü) nach Updates. Ein Datenbankupdate kann bei laufenden Programm durch das Programm selbst ausgeführt werden (im Hintergrund wird einfach die lokale Datenbank neu gefüllt). Für ein Programmupdate muss die gesamte Anwendung neu heruntergeladen werden.
Eine Idee hätte ich noch - ja ich weiß wir sind im Tramwayforum! - eventuell auch einbindung der Autobus- U-Bahn Linien.
Hier möchte ich auf die FAQ (https://www.assembla.com/spaces/tram/wiki/FAQ) verweisen. Nur so viel: Irgendwann. Aber vorerst steht das Funktionelle im Vordergrund. Wenn ich sofort alle Linien in TRAM aufnehmen würde, wäre ich die nächste Zeit nur noch mit Datenaufbereitung beschäftigt - dazu habe ich keine Lust. TRAM wird sich also noch sehr lange nur mit der Wiener Straßenbahn beschäftigen, auch wenn ich grundsätzlich in (ferner) Zukunft für mehr bereit wäre.
-
Schade, ein .exe :(
-
Schade, ein .exe :(
Unter Wine startet es leider nicht! :'(
-
Ich muss auch erst einmal mein Virtualbox-Windows starten, ein echtes Binary für Linux sollte aber kein Problem sein, wenn unser ULF es so baut ;)
-
Womit ist das geschrieben? .net, java?
-
Laut dem 1. Satz im 1. Beitrag ist es Java. ;)
-
Da braucht man ja nicht einmal ein echtes Binary.
@ULF: Verwendest Du irgendwelche speziellen Windows-Libraries oder kannst Du das prinzipiell auch als .jar freigeben?
-
Haha... ich habe schon faktisch darauf gewartet, dass die Frage kommt. ;)
Kurzum: TRAM wird von mir in Java auf Windows 7 programmiert (und dafür dementsprechend optimiert). Die EXE ist keine Binary, sondern einfach ein gewrapptes JAR (wer jetzt ausgestiegen ist, braucht gar nicht mehr weiter zu lesen :D ;) ). Dieser Wrapper unterstützt offiziell auch Linux und Mac OS. Ich habe aber schon einmal das JAR auf einer Linux-Maschine ausprobiert. Da hat sich das Ding innerhalb kürzester Zeit verabschiedet. Warum? Ich kann grundsätzlich nur mutmaßen, da ich damals keine Möglichkeit zur Fehleranalyse hatte und auch der Logger nicht korrekt startete. Vermutlich sind im Code einige systemspezifische Teile (z.B. Pfadangaben). Hier muss ich dezidiert sagen, dass ich nie eine Plattformunabhängigkeit im derzeitigen Stadium im Auge gehabt hätte - schlicht aus Bequemlichkeit. Support wird es dafür ohnehin nie geben - mangels stetiger Testmöglichkeiten meinerseits. Prinzipiell bin ich aber bereit - ohne Unterstützung - entsprechende Dateien in Zukunft anzubieten - keine Frage. Solange das Ding aber ohnehin nicht wo anders laufen will, hat es aber keinen Sinn. Ich sollte aber irgendwann Zeit haben, TRAM mal zumindest soweit zu bringen, dass es unter anderen Plattformen startet. Mangels Zeit hätte ich das aber erst in einer etwaigen Beta-Phase im Sinn gehabt. Da der Wunsch aber jetzt geäußert wurde, habe ich ein entsprechendes Ticket (https://www.assembla.com/spaces/tram/support/tickets/29) angelegt, damit das Thema nicht untergeht und in einem Alpha-Release gelöst wird. Entsprechende Neuigkeiten dazu werden im Ticket stehen.
-
Mit Java und Linux kenne ich mich ein bißchen aus, also wenn du Unterstützung beim Portieren/Testen brauchst, sags mir einfach!
-
Es würde ja reichen, wenn es unter Wine läuft. Aber da verlangt es nach Java 1.7.0, das es irgendwie nicht findet, obwohl es (in Wine) installiert ist! :-\
-
Mit Java und Linux kenne ich mich ein bißchen aus, also wenn du Unterstützung beim Portieren/Testen brauchst, sags mir einfach!
Danke für das Angebot! :)
Wie gesagt, wenn ich Zeit habe, werde ich mal schauen, wo im Code der Hund begraben ist, wovon ich jetzt mal ausgehe. Dann schau' ma weiter.. Aber das kann halt - wie gesagt - noch dauern. Priorität hat das halt keine für mich.
Es würde ja reichen, wenn es unter Wine läuft. Aber da verlangt es nach Java 1.7.0, das es irgendwie nicht findet, obwohl es (in Wine) installiert ist! :-\
Wie gesagt, da es sich ja um ein Java-Programm handelt, ist ja eine native Unterstützung grundsätzlich möglich. Zu Wine: Damit kenne ich mich als Windows-Nützer faktisch gar nicht aus (ich weiß, dass es existiert). Kurze Recherche hat aber ergeben, dass der JAR-Wrapper unter Wine oder Wine selbst eine Windows JRE benötigt (im "wineprefix" - was immer das auch sein mag :D ) und nix mit einer Linux JRE anfangen kann.
-
Ein Java-Programm, das unter Wine nicht läuft wine-tauglich zu machen, ist meiner Einschätzung nach mühsamer als es direkt auf eine unixoide JVM zu portieren.
-
Ein kurzer Hinweis: Durch eine Änderung bzw. Verringerung der Fahrzeiten am Ring und in der Wiedner Hauptstraße kam es heute zu einem Update der Datenbank. TRAM reagiert unter Umständen nach dem Update ziemlich fehlerhaft. Ein Neustart vom Programm verschafft Abhilfe. Dieser heute entdeckte Bug in der Synchronisations-Routine wird mit dem kommenden Release beseitigt.
-
Änderung bzw. Verringerung der Fahrzeiten am Ring und in der Wiedner Hauptstraße
Das Wort, das du gesucht hast, ist "Verlängerung" :)
-
Interessanterweise wurden sie eben wirklich gekürzt. Vor einigen Tagen wurden noch zwischen Parlament und Oper 1-2 Minuten bei den Ankunftszeiten drauf gelegt, auch bei der Johann-Strauß-Gasse war ein Aufschlag messbar. Diese Aufschläge sind nun offenbar nicht mehr im FGI-System vorhanden. Warum auch immer.
-
Interessanterweise wurden sie eben wirklich gekürzt. Vor einigen Tagen wurden noch zwischen Parlament und Oper 1-2 Minuten bei den Ankunftszeiten drauf gelegt, auch bei der Johann-Strauß-Gasse war ein Aufschlag messbar. Diese Aufschläge sind nun offenbar nicht mehr im FGI-System vorhanden. Warum auch immer.
Merkwürdig - am Gleiszustand hat sich ja nix zum Positiven verändert...
-
Ich kann mir gut vorstellen, dass alles irgendwann wieder mal gecrasht ist, dann ein Backup reingespielt wurde und die Änderungen auf der Strecke geblieben sind. Hab' mich auf jeden Fall selbst gewundert, aber es ist so. Mit dem Tool mit dem ich die Daten für TRAM pflege, lässt sich das per Knopfdruck überprüfen.
-
Ich kann mir gut vorstellen, dass alles irgendwann wieder mal gecrasht ist, dann ein Backup reingespielt wurde und die Änderungen auf der Strecke geblieben sind.
Ja, das kann gut sein! In letzter Zeit (die letzte Woche) gab es auch auf vielen FGIs Probleme. Zum Beispiel auf einigen Linien nur Planzeiten usw. Der Profitüftler hat schon so oft Scheiße gebaut, dass es auf einmal mehr eh nicht mehr ankommt.
-
Verhindern, dass ich die Fahrzeugpositionen extrapoliere und Intervalle errechne, kann er damit sowieso nicht. :D
-
Auch von mir ein Danke für das supertolle Programm!
Ein Vorschlag, was vielleicht für eine spätere Version super wäre: Wenn auf einer Linie eine offene Störung ist, dass irgendwo ein rotes Rufzeichen blinkt (oder so ein gelbes Warndreieck mit schwarzem Rufzeichen), und wenn der Fahrbetrieb wieder aufgenommen wurde, aber die einigermaßen regelmäßigen Intervalle noch nicht wiederhergestellt sind, dieses Symbol in grau (nicht blinkend).
-
Eine Integration der Störungsmeldungen ist ohnehin bereits angedacht und wird sicherlich noch in der Alpha-Phase kommen. ;)
Und danke! :)
-
Es gibt eine neue Alpha-Version von TRAM zum Download (https://www.assembla.com/spaces/tram/messages/4923593). Primär wurden mit ihr einige der dringendsten Bugs beseitigt. Neue Features gibt es in dieser Version keine.
-
Wäre es bitte möglich, dass bei Gelegenheit die "neue" Endstation Alfred-Adler-Straße vom D-Wagen eingearbeitet wird? Danke! :)
-
Nimm ich gern auf. Zum letztmaligen Zeitpunkt eines Updates der Haltepunkte wurde leider der Haltepunkt der Station Alfred-Adler-Straße nicht
korrekt über die OGD-Schnittstelle übertragen. Kann leicht sein, dass sich das mittlerweile geändert hat (vielleicht auch zum Schlimmeren). Sofern ich aber wiedermal Zeit habe, werde ich mir das näher ansehen... dafür hatte ich ja auch ein paar Skripts. ;)
-
Ich weiß nicht ob das schon angesprochen wurde, aber wäre es rein theoretisch möglich, auch die Fahrzeugnummern anzuzeigen? Werden ja an ausgewählten Haltestellen auch auf den FGI's angezeigt. Oder gibt es die nicht "öffentlich"?
-
Ich weiß nicht ob das schon angesprochen wurde, aber wäre es rein theoretisch möglich, auch die Fahrzeugnummern anzuzeigen? Werden ja an ausgewählten Haltestellen auch auf den FGI's angezeigt. Oder gibt es die nicht "öffentlich"?
Es gibt werden die Fahrzeug, noch die Kursnummern
-
Ich weiß nicht ob das schon angesprochen wurde, aber wäre es rein theoretisch möglich, auch die Fahrzeugnummern anzuzeigen? Werden ja an ausgewählten Haltestellen auch auf den FGI's angezeigt. Oder gibt es die nicht "öffentlich"?
Es gibt werden die Fahrzeug, noch die Kursnummern
Davor werden sie sich auch hüten, so viel wie sie da zu verbergen haben :)
-
Ich weiß nicht ob das schon angesprochen wurde, aber wäre es rein theoretisch möglich, auch die Fahrzeugnummern anzuzeigen? Werden ja an ausgewählten Haltestellen auch auf den FGI's angezeigt. Oder gibt es die nicht "öffentlich"?
Es gibt werden die Fahrzeug, noch die Kursnummern
Davor werden sie sich auch hüten, so viel wie sie da zu verbergen haben :)
Und was würde es dir bringen, wenn du diese Info auch noch bekommst. Selbst wenn ein Zug abgestellt iist, weist du ja noch immer nicht wieso er abgestellt ist. Und was machst du mit den Kursnummern.
Wenn es darum geht, die Kürzungen nach einer Störung zu analysieren. Da sage ich nur, im Nachhinein ist man immer schlauer.
Aber für den Duchschnittsfahrgast bringen mMn diese beiden Infoquellen gar nichts. Denn wenn ich meine Route mit Niederflurfahrzeuge planen muss, dann ist es mir egal, ob da ein Klima oder nicht Klima daher kommt.
-
Ich weiß nicht ob das schon angesprochen wurde, aber wäre es rein theoretisch möglich, auch die Fahrzeugnummern anzuzeigen? Werden ja an ausgewählten Haltestellen auch auf den FGI's angezeigt. Oder gibt es die nicht "öffentlich"?
Es gibt werden die Fahrzeug, noch die Kursnummern
Davor werden sie sich auch hüten, so viel wie sie da zu verbergen haben :)
Und was würde es dir bringen, wenn du diese Info auch noch bekommst. Selbst wenn ein Zug abgestellt iist, weist du ja noch immer nicht wieso er abgestellt ist. Und was machst du mit den Kursnummern.
Die Kursnummern sind weniger wichtig, aber mit den Wagennummern könnte man einen täglichen Auslauf zusammenfassen - und wenn man da dokumentiert, dass Tag für Tag um die 70 ULFe nicht eingesetzt werden, weil sie entweder kaputt sind oder man kilometersparen muss, dann wäre das ein Fressen für die Medien.
Aber für den Duchschnittsfahrgast bringen mMn diese beiden Infoquellen gar nichts. Denn wenn ich meine Route mit Niederflurfahrzeuge planen muss, dann ist es mir egal, ob da ein Klima oder nicht Klima daher kommt.
Klima wäre schon auch ein Punkt. Wenn ich heute am Ring gewusst hätte, dass hinter dem Backbox-71er gleich ein B1 kommt, dann hätte ich die paar Minuten gewartet. Aber das würde dann höchstens zu ungleichmäßiger Auslastung der Züge führen, wenn man das bekannt macht.
-
Gerade runter geladen, ein wirklich tolles Programm, nur weiter so! :up: :up: :up:
-
Dankeschön. Freut mich zu hören! :)
Ich hätte in letzter Zeit gerne mehr Zeit dafür das Programm etwas voranzubringen, aber leider wird das noch mindestens ein halbes Jährchen warten müssen, bis ich da wieder "einsteigen" werde... Also keine Panik, falls sich wer fragt, warum sich nix tut. Gestorben ist nix. Zeit habe ich derzeit einfach leider keine. Das sollte sich aber früher oder später zumindest bessern. ;)
-
Lieber ULF – lässt du dich vielleicht überreden, dein Programm an die neuen Linienführungen (und Haltestellennamen) anzupassen? :)
-
Leider musste ich derzeit bzw. schon länger ziemliche Abstriche machen (versuche neben einer Diplomarbeit, auch die geldbringende Arbeit und das übrige Leben nicht zu vernachlässigen ;)), dabei stehen derzeit einige Privatprojekte (noch immer) still - darunter dieses hier (sowie auch der Gleisplan).. Das sollte sich, wie es derzeit aussieht zu Beginn nächsten Jahres endgültig auflösen, wenn ich mein Unileben hinter mir lasse.
Es tut mir wirklich leid, dass ich wirklich vertrösten muss. Dafür möchte ich, sobald ich dazu komme, das Teil auch (zumindest) in einer webbasierten Form anbieten - das hatte ich dazumals schon geplant, bin aber (leider) nicht mehr wirklich dazu gekommen.
-
Diese App leistet derzeit gute Dienste, wenn es darum geht sichtbar zu machen, wie krass die Kursausfälle sind.
Lieber User ULF, danke für deine Mühen! Wenn es deine Zeit und Muße zulassen, würde ich mich über ein Update bei den Linenführungen (Verlängerung D und O, Adaptionen 6/11/71, Linienkreuz 2/44, Anpassung 10/58/60) sehr freuen. :D
-
Habe von diesem Programm erst jetzt erfahren. Ist echt super was da auf die Beine gestellt wurde!
Die veralteten Routenpläne sind das einzige Manko... Auch wenn's ein gewisses Nostalgiefeeling hergibt, den 67er anzuwählen... oder den 49er mit Halt "Bahnhofstrasse" :D
-
Habe von diesem Programm erst jetzt erfahren. Ist echt super was da auf die Beine gestellt wurde!
Die veralteten Routenpläne sind das einzige Manko... Auch wenn's ein gewisses Nostalgiefeeling hergibt, den 67er anzuwählen... oder den 49er mit Halt "Bahnhofstrasse" :D
Dem kann ich mich nur anschließen. Kann man da eventuell einmal ein Update der Haltestellen machen, bzw auch die Linie 11 einpflegen?