Tramwayforum
Gesamter öffentlicher Verkehr in Wien => Sonstiges => Thema gestartet von: 13er am 04. Juni 2013, 11:29:57
-
Im WL-Blog gibt es ein nicht uninteressantes Interview mit dem OpenData-Verantwortlichen Stefan Kriz: http://blog.wienerlinien.at/2013-das-jahr-der-verkehrsdaten/ (http://blog.wienerlinien.at/2013-das-jahr-der-verkehrsdaten/)
Die Geo- und Statistikdaten werden demnach Anfang Juli freigegeben, die Fahrplan- und auch Echtzeitdaten (das war bisher für mich noch nicht 100% sicher, dass sie die rausrücken) dann im September folgen. Dafür wird offenbar auch endlich die Serverfarm aufgestockt - das wird wohl auch Qando zugute kommen.
Insgesamt von dieser Front also durchaus positive Neuigkeiten - hoffentlich bauen sie nicht noch irgendeinen Pferdefuß ein, vor allem von rechtlicher Seite.
-
Insgesamt von dieser Front also durchaus positive Neuigkeiten - hoffentlich bauen sie nicht noch irgendeinen Pferdefuß ein, vor allem von rechtlicher Seite.
Einer wird auf jeden Fall eingebaut "Alle Angaben ohne Gewähr". :P
-
hoffentlich bauen sie nicht noch irgendeinen Pferdefuß ein, vor allem von rechtlicher Seite.
Schon passiert:
Wiener Linien: Kein Open Data für Google?
7. Juni 2013, 11:53
Angeblich viele interne Befürworter für Ausschluss kommerzieller Nutzung
Nach langem Vorfühlen arbeiten die Wiener Linien nun offiziell an der Freigabe ihrer Daten. Im Juli sollen diverse Geo- und Statistikdaten offengelegt werden, später sollen Echtzeitdaten mit entsprechender Schnittstelle folgen.
Eine Unbekannte baumelt jedoch über dem Datenprojekt des Verkehrsbetreibers, wie die Initiative "Offene Öffis" berichtet: Die Lizenz. Diese legt die Bedingungen fest, unter welchen die freigegebenen Daten in Apps und für andere Zwecke verwendet werden können.
Kommt eine restriktive Lizenz?
Wie der WebStandard nun aus gut informierten Kreisen erfahren hat, dürfte es unter den Verantwortlichen einige Personen geben, die sich für eine restriktive Lizenz aussprechen, welche eine kommerzielle Verwendung untersagt.
Dies hätte beachtliche Konsequenzen. Eine Reihe von Apps sind zwar für sich gesehen kostenlos, blenden aber Werbung ein. Für diese wäre die Verwendung der Wiener-Linien-Daten unter einer nicht-kommerziellen Lizenz ebenso untersagt, wie für Google Maps.
Abgesehen von eingezeichneten Haltestellen und den dort verkehrenden Linien wären auf Google Kartendienst also weiterhin keine Öffi-Informationen zu finden. Eine Lizenz ohne Ausschluss kommerzieller Verwendung würde hingegen die Einbindung von Echtzeitdaten ermöglichen – und damit auch zeitnahe Informationen über Verspätungen.
Wiener Linien zurückhaltend
Der WebStandard hat bei den Wiener Linien nachgefragt. Dort gibt man sich zurückhaltend. So erklärt Pressesprecher Answer Lang, dass man bis zum Sommer alles Rechtliche in Sachen Lizenz erörtern würde, auch gemeinsam mit VOR und ÖBB, einer Entscheidung könne man nicht vorgreifen. "Ich würde aber nicht so viel auf Gerüchte geben", so Lang abschließend.
Linz erlaubt kommerzielle Verwendung
Hier lohnt sich ein Blick nach Linz. Die Daten des lokalen Verkehrsbetreibers Linz AG stehen am Linz Open Data-Portal zur Verfügung. Dessen Inhalte wiederum sind laut Nutzungsbedingungen mit einer Creative Commons-Lizanz ausgestattet, die lediglich zur Namensnennung des Urhebers verpflichtet (CC BY 3.0). Als Zusatz wird nur verlangt, entsprechende Apps den Linz AG Linien gegenüber bekannt zu geben.
Solange also auf die Stadt Linz bzw. data.linz.gv.at als Datenquelle verwiesen wird, kann also jeder Entwickler ohne Einschränkungen auf die bereitgestellten Informationen zugreifen. Bereitgestellt werden Haltestellen, Echtzeitfahrpläne, Verkehrsstörungen, Linienführungen und eine Reihe weiterer Informationen. (gpi, derStandard.at, 07.06.2013)
Quelle: http://derstandard.at/1369362963121/Wiener-Linien-Kein-Open-Data-fuer-Google (http://derstandard.at/1369362963121/Wiener-Linien-Kein-Open-Data-fuer-Google)
Hervorhebung in rot von mir.
Zwar finde ich es durchaus nicht negativ, Multimilliardenkonzernen die Daten nicht gratis auch noch nachzuwerfen. Aber was man da anstellt, ist schon armselig. Wir geben euch die Daten... nutzen dürft ihr sie halt nicht. :bh:
-
In Linz geht`s! Wien ist eben anders. :fp: :fp:
-
Wie der WebStandard nun aus gut informierten Kreisen erfahren hat, dürfte es unter den Verantwortlichen einige Personen geben, die sich für eine restriktive Lizenz aussprechen, welche eine kommerzielle Verwendung untersagt.
Dies hätte beachtliche Konsequenzen. Eine Reihe von Apps sind zwar für sich gesehen kostenlos, blenden aber Werbung ein. Für diese wäre die Verwendung der Wiener-Linien-Daten unter einer nicht-kommerziellen Lizenz ebenso untersagt, wie für Google Maps.
Dann brauchen die ganzen Graits-App-Programmierer nur auf die nervigen Werbeeinblendungen verzichten und schon ist es nicht mehr kommerzielle.
Ausserdem sage ich auch hier, warten wir ab, wei dieser Vertrag dann wirklich ausschaut
-
Auf Apps mit Werbeeinblendungen verzichte ich sowieso gern, ist also kein Schaden. 8)
-
Auf Apps mit Werbeeinblendungen verzichte ich sowieso gern, ist also kein Schaden. 8)
Hattest du nicht ein Nokia 6200? >:D
Für die Wiener Linien müsste in der Folge eine abweichende Lizenz festgelegt werden, weil derzeit alle Daten aus Wien unter Creative Commons Namensnennung 3.0 Österreich Lizenz fallen: http://data.wien.gv.at/nutzungsbedingungen/ (http://data.wien.gv.at/nutzungsbedingungen/)
-
Nein, ein 6300. Mit dem geh ich aber ohnehin nicht ins Internet. Am Tablet brauche ich aber auch keine Linktipps. :P
-
Dann brauchen die ganzen Graits-App-Programmierer nur auf die nervigen Werbeeinblendungen verzichten und schon ist es nicht mehr kommerzielle.
Dennoch ist "Open Data" unter einer Lizenz, die kommerzielle Nutzung ausschließt, nicht wirklich Open Data. Mit den meisten freien Projekten wie den Wikimedia-Projekten oder OpenStreetMap ist eine solche Lizenz inkompatibel. Ich sehe überhaupt keinen Grund, kommerzielle Nutzung auszuschließen - außer natürlich, man ist kommunistisch eingestellt und hält jeglichen Kommerz für schlecht und nicht unterstützenswert; dann ergibt eine solche Lizenz Sinn.
Gerade aus staatlicher Sicht ist das absurd - wenn jemand etwas kommerziell nutzt, hilft das doch der Wirtschaft und Steuerleistung!
-
Gerade aus staatlicher Sicht ist das absurd - wenn jemand etwas kommerziell nutzt, hilft das doch der Wirtschaft und Steuerleistung!
Naja, das glaube ich nicht, zumal multinationale Konzerne eher Steuern vermeiden: http://www.wiwo.de/finanzen/steuern-recht/unternehmenssteuer-apples-strategie-zur-vermeidung-von-steuern/6573950.html (http://www.wiwo.de/finanzen/steuern-recht/unternehmenssteuer-apples-strategie-zur-vermeidung-von-steuern/6573950.html) Aber das ist ein anderes Thema.
-
Inkompatibel, ein Wort, das auf die WL eine magische Anziehungskraft ausübt.
-
Inkompatibel, ein Wort, das auf die WL eine magische Anziehungskraft ausübt.
>:D >:D
Dabei kann ich nicht nachvollziehen, wovor sie Angst haben: Dass mehr Touristen mit der U-Bahn fahren, weil sie auch in Google Maps eingetragen ist? Dass mehr Leute den ÖV benutzen, weil es kreative neue Apps gibt, deren Autor mit seinem Werk ein paar Euro (mehr ist es meistens eh nicht) Anerkennung möchte? Es kann sich nur um eine Kleinkind-Trotz-Reaktion handeln, wie immer: "Die haben uns zu etwas gezwungen, das wir eigentlich gar nicht wollen, deswegen machen wir es möglichst schlecht" (Rasengleis Tokiostraße).
-
Es gibt ein Update zur Freigabe der Verkehrsdaten:
Unser Open Data-Beauftragter Stefan Kriz hat heute bei der OGD-Plattform unseren weiteren Fahrplan, wann welche Daten veröffentlicht werden, vorgestellt. Bereits Anfang Juli werden weitere Statistikdaten, wie die Gleislänge, die Anzahl der Linien, Anzahl der Weichen etc. veröffentlicht. Mit August geben wir unsere Echtzeitdaten frei, dafür müssen sich interessierte Entwicklerinnen und Entwickler unter www.data.wien.gv.at (http://www.data.wien.gv.at) registrieren. Zusammen mit den Echtzeitdaten, wird eine neue modifizierte Haltestellenliste mit GPS-Koordinaten den Entwicklern zur Verfügung stehen. Nach den Sommerferien wird dann zusätzlich zu den Echtzeitdaten, das Routing freigeben. Aus heutiger Sicht sind allerdings nur die Daten der Wiener Linien enthalten. Alle Daten der Wiener Linien werden unter der CC BY-Lizenz veröffentlicht.
Höchst erfreulich! :up: :up: :up: Ich glaube, jetzt hat man's wirklich verstanden. Ich freu mich jedenfalls drauf!
-
Wenn das (http://www.flightradar24.com/) mit allen Fliegern weltweit geht, sollte so was doch auch mit den paar Straßenbahnen in Wien zu machen sein. Wäre äußerst attraktiv! :lamp:
-
Mal ganz eigennützig: Am besten noch mit Wagennummer 8)
-
Mal ganz eigennützig: Am besten noch mit Wagennummer 8)
:up:
-
Mal ganz eigennützig: Am besten noch mit Wagennummer 8)
:up:
Sofern es wirklich die gleichen Daten nach VDV-Standard (wie am Create Camp) sind, dann kommt sowohl die Wagennummer mit als auch das Merkmal Niederflur.
-
Wenn das (http://www.flightradar24.com/) mit allen Fliegern weltweit geht, sollte so was doch auch mit den paar Straßenbahnen in Wien zu machen sein. Wäre äußerst attraktiv! :lamp:
Wobei hinter flightradar ziemlich viel Aufwand von privaten Enthusiasten steht, die eigene Empfänger für die Transponderdaten betreiben. Wobei das vielleicht auch ein Projekt wäre, selbst irgendwo IR-Baken oder VDV-R09.xx-Empfänger hinzustellen :-)
Sofern es wirklich die gleichen Daten nach VDV-Standard (wie am Create Camp) sind, dann kommt sowohl die Wagennummer mit als auch das Merkmal Niederflur.
Ich hoffe mal, dass sie sich nicht wieder extra ein neues ID-System einfallen lassen. Irgendeine eindeutige Kennzeichnung brauchen die Fahrzeuge ohnehin - da ist die Wagennummer durchaus sinnvoll und auch am naheliegendsten.
-
Irgendeine eindeutige Kennzeichnung brauchen die Fahrzeuge ohnehin
Nicht unbedingt, die haben sie in der jetzigen Qando-Schnittstelle auch nicht.
Bezüglich Wagennummer hab ich eher ein schlechtes Gefühl - da lassen sie sich ja ganz offen in die Karten schauen. Das passt überhaupt nicht zu F5.
-
Irgendeine eindeutige Kennzeichnung brauchen die Fahrzeuge ohnehin
Nicht unbedingt, die haben sie in der jetzigen Qando-Schnittstelle auch nicht. Bezüglich Wagennummer hab ich eher ein schlechtes Gefühl - da lassen sie sich ja ganz offen in die Karten schauen. Das passt überhaupt nicht zu F5.
Geht man danach, dürfte auch das Servicemerkmal NF oder HF nicht mitgeliefert werden. :D
-
Es genügt ja die Liniennummer. Die Wagennummern werden sie nicht gern herzeigen, um es notorischen "Beschwerdeführern" nicht zu leicht zumachen, vom Lehstuhl aus Beschwerden zu verfassen! >:D
Die Kursnummer könnte man auch noch anfügen, das macht den Hobby-Fahrplanbeobachtern sicher Spaß! ;)
-
Irgendeine eindeutige Kennzeichnung brauchen die Fahrzeuge ohnehin
Nicht unbedingt, die haben sie in der jetzigen Qando-Schnittstelle auch nicht. Bezüglich Wagennummer hab ich eher ein schlechtes Gefühl - da lassen sie sich ja ganz offen in die Karten schauen. Das passt überhaupt nicht zu F5.
Geht man danach, dürfte auch das Servicemerkmal NF oder HF nicht mitgeliefert werden. :D
Eh, aber das muss man wegen der "Normalkunden" auf jeden Fall machen, unser Glück :D
@hema: Ich glaub nicht, dass sie mehr hergeben als unbedingt nötig. Bin schon gespannt, ob die Störungsmeldungen überhaupt in der Echtzeitauskunft vorhanden sein werden.
-
Es genügt ja die Liniennummer. Die Wagennummern werden sie nicht gern herzeigen, um es notorischen "Beschwerdeführern" nicht zu leicht zumachen, vom Lehstuhl aus Beschwerden zu verfassen! >:D
Das könnte man sogar automatisiert machen! :lamp: C:-)
-
Es genügt ja die Liniennummer. Die Wagennummern werden sie nicht gern herzeigen, um es notorischen "Beschwerdeführern" nicht zu leicht zumachen, vom Lehstuhl aus Beschwerden zu verfassen! >:D
Notorische Beschwerdeführer interessieren sich eh großteils nur für Hochflur vs. Niederflur, und die Daten sind sowieso da.
-
Wenn das (http://www.flightradar24.com/) mit allen Fliegern weltweit geht, sollte so was doch auch mit den paar Straßenbahnen in Wien zu machen sein.
Das mag einfacher klingen, als es tatsächlich ist.. ;)
Aber für jedes Problem gibt es eine Lösung. 8)
-
Irgendeine eindeutige Kennzeichnung brauchen die Fahrzeuge ohnehin
Nicht unbedingt, die haben sie in der jetzigen Qando-Schnittstelle auch nicht.
Ja, und wir kennen ja alle deren Qualität.
Da kann man nicht mehr unterscheiden, ob ein Zug einfach nur eine größere Verspätung aufgerissen hat, unerwartet schneller wurde und schon an der Haltestelle vorbei ist, oder aus dem RBL gefallen ist und man gerade die Zeit des Folgezuges betrachtet.
Glaub mir: eindeutige Bezeichner für die Objekte machen das Leben für jeden Softwareentwickler leichter (sowohl auf Server- wie auf Clientseite).
Die Kursnummer könnte man auch noch anfügen, das macht den Hobby-Fahrplanbeobachtern sicher Spaß! ;)
Linie+Kurs ist auch ok, da ebenfalls eindeutig.
-
Glaub mir: eindeutige Bezeichner für die Objekte machen das Leben für jeden Softwareentwickler leichter (sowohl auf Server- wie auf Clientseite).
Na eh klar, ich wollte ausdrücken, dass die WL die Daten nicht unbedingt mitliefern müssen, da man sie für normale Anwendungszwecke (z.B. "wann kommt der nächste 5er in Richtung Praterstern" oder "Auskunft von Spitalgasse zu Tokiostraße") nicht braucht. Natürlich wäre es für statistische Auswertungen und z.B. Live-Karten super, wenn es die Daten geben würde.
-
Irgendeine eindeutige Kennzeichnung brauchen die Fahrzeuge ohnehin
Nicht unbedingt, die haben sie in der jetzigen Qando-Schnittstelle auch nicht. Bezüglich Wagennummer hab ich eher ein schlechtes Gefühl - da lassen sie sich ja ganz offen in die Karten schauen. Das passt überhaupt nicht zu F5.
Geht man danach, dürfte auch das Servicemerkmal NF oder HF nicht mitgeliefert werden. :D
Eh, aber das muss man wegen der "Normalkunden" auf jeden Fall machen, unser Glück :D
@hema: Ich glaub nicht, dass sie mehr hergeben als unbedingt nötig. Bin schon gespannt, ob die Störungsmeldungen überhaupt in der Echtzeitauskunft vorhanden sein werden.
Nach derzeitigen Stand nein, weil die Daten aus einem ganz anderen Programm kommen und zumindest derzeit gibt es nur eine Schnittstelle, die die Daten ausschließlich zu Fluidtime/Qando weitergibt.
Inwieweit die VFGI-Störungsanzeigen weitergegeben werden - Keine Ahnung
-
Auch wenn diese Daten wohl nicht von primären Interesse sind: Es wurden ja bereits vor mehr als einer Woche Geo- und Statistikdaten freigegeben. Ich hab jetzt endlich Zeit gefunden mir diese anzusehen.
Die Statistikdaten hauen mich zwar erst mal jetzt nicht vom Hocker (die hätten ruhig linienbezogen veröffentlicht werden können und nicht irgendwelche Aggregate).. Aber die Geodaten sind schon wesentlich nützlicher. Wieso? Die Haltstellenliste wurde endlich aktualisiert (man mag es kaum glauben: es gibt nun einen Hauptbahnhof im Datensatz) und - viel erstaunlicher - das Liniennetz wurde veröffentlicht. Was hat es mit letzteren auf sich? Alle Strecken (mit all ihren Schnörkeln) sind so eindeutig verort- und - vor allem für Anwendungen wichtig - korrekt auf einer Karte darstellbar. Das heißt, nicht nur die geographische Position der einzelnen Haltestellen sind nun frei abrufbar sondern auch die Wege der Öffis dazwischen. Weiters wird offenbar für jede dieser Strecken angegeben welche Linien darauf verkehren (z.B. 1, 18, 62 zwischen Kliebergasse und Matzleinsdorfer Platz). Selbiges gilt übrigens nun auch endlich für die Haltestellenpunkte: Endlich werden alle Linien die an einem Punkt anhalten auch im Datensatz wiedergegeben. All diese Daten waren bisher nicht frei verfügbar. Übrigens sind Regionalbus- als auch Privatbuslinien sowie auch Schnellbahnlinien und die WLB mit von der Partie. Eine automatisch generierte Visualisierung der Daten kann hier (http://data.wien.gv.at/daten/wms?request=GetMap&version=1.1.1&width=1600&height=1200&layers=OEFFHALTESTOGD&styles=&format=image/gif&bbox=-11179,331050,18258,353820&srs=EPSG:31256) für die Haltstellenpunkte und hier (http://data.wien.gv.at/daten/wms?request=GetMap&version=1.1.1&width=1600&height=1200&layers=OEFFLINIENOGD&styles=&format=image/gif&bbox=-11179,331050,18258,353820&srs=EPSG:31256) für das Liniennetz als GIF abgerufen werden.
Fazit: Auch wenn die Statistikdaten ruhig ausbaufähig wären (und bitte jetzt lasst die Scherze, man hätte diese Daten nicht oder man könne sie aus sieben Milliarden Gründen nicht veröffentlichen - Schwachsinn!) sind gerade die Geodaten ein echter Schritt in die richtige Richtung! :up:
-
Die Haltstellenliste wurde endlich aktualisiert
Ein paar Relikte, die nie bereinigt wurden, sind nach wie vor enthalten. Etwa die Bushaltestelle AUA-Hauptbüro in Oberlaa, obwohl selbst das Gebäude mittlerweile abgerissen wurde. :D
-
Die Haltstellenliste wurde endlich aktualisiert
Ein paar Relikte, die nie bereinigt wurden, sind nach wie vor enthalten. Etwa die Bushaltestelle AUA-Hauptbüro in Oberlaa, obwohl selbst das Gebäude mittlerweile abgerissen wurde. :D
Ich bin mir allerdings nicht sicher, ob der Datenstamm von den WL stammt. Mir schaut es verdächtigt nach VOR-Daten aus.
-
Ich bin mir allerdings nicht sicher, ob der Datenstamm von den WL stammt. Mir schaut es verdächtigt nach VOR-Daten aus.
Na, und? Hat ja auch niemand behauptet.. ::)
Richtiger werden diese Fehler deswegen genauso wenig...
PS: Die Daten sind anscheinend eine Aggregation von VOR und WL-Daten...
-
PS: Die Daten sind anscheinend eine Aggregation von VOR und WL-Daten...
Das ist richtig, sie stammen aus dem Bestand des Wien Stadtplans und werden durch die MA14 gepflegt. VOR und WL haben dazu nur indirekt etwas beigetragen.
-
Jetzt ist es tatsächlich so weit:
Open Data: Wiener Linien erlauben ab sofort Zugriff auf Echtzeitdaten
29. August 2013, 16:05
Live-Abfahrtszeiten für Öffis können am Open Data Portal der Stadt Wien abgefragt werden
Die Wiener Liniensetzen den nächsten Schritt im Rahmen ihrer Open-Data-Initiative. Wie das Unternehmen mitgeteilt hat, ist ab sofort der Zugriff auf Echtzeitdaten möglich. Die Schnittstellendokumentation sowie die dazugehörigen csv-Dateien stehen am Open Government Portal der Stadt Wien zur Verfügung.
Enthalten sind darin die jeweils aktuellen Abfahrtszeiten aller von dem Verkehrsunternehmen betreuten Öffis – also Straßenbahnen, Bussen und U-Bahnen. Ebenso soll es bald eine Schnittstelle geben, über welche Störungen der Linienführung durch Verkehrsprobleme sowie defekte von Stationsaufzügen abgefragt werden können.
Störungsdaten folgen im September
Voraussetzung für den Abruf ist die Registrierung beim Open-Data-Portal der Stadt Wien. Im September sollen schließlich auch die Fahrplandaten als Routing-Service für die Umsetzung von Echtzeit-Fahrtberechnungen bereit stehen. Schon vorher veröffentlicht waren Geodaten, Liniennetz und verschiedene Statistiken.
Nach eigenen Angaben belaufen sich die Kosten für Infrastruktur und Datenharmonisierung auf einen fünfstelligen Eurobetrag. (red, derStandard.at, 29.08.2013)
Quelle: http://derstandard.at/1376535047077/Wiener-Linien-erlauben-ab-sofort-Zugriff-auf-Echtzeitdaten (http://derstandard.at/1376535047077/Wiener-Linien-erlauben-ab-sofort-Zugriff-auf-Echtzeitdaten)
Fünfstellig ist eigentlich eh sehr wenig, wenn man bedenkt, dass der größte Teil davon ohnehin der Erweiterung der Serverkapazität dient, die auch Qando zugute kommt.
Ich freue mich jedenfalls und werde hoffentlich am Wochenende auch mal alles ausprobieren können!
-
Ich freue mich jedenfalls und werde hoffentlich am Wochenende auch mal alles ausprobieren können!
Und dann gibts die erste Anwendung? ;-)
-
Ich freue mich jedenfalls und werde hoffentlich am Wochenende auch mal alles ausprobieren können!
Und dann gibts die erste Anwendung? ;-)
Bisher wurde nicht einmal meine gestrige Registrierung freigeschaltet. Hoffentlich sind die Datenpakete nicht auch so langsam ;)
-
Es wären nicht die WL, wenn irgendwas mal auf Anhieb funktionieren würde.
Nachdem ich mich gestern auf wien.gv.at für die Wiener Linien-Echtzeitdaten mit Name und Anschrift registriert habe, bekomme ich heute eine Mail, ich möge ihnen doch meinen Namen und Anschrift schicken, damit sie mich freischalten können. Im Anhang der Mail das ausgefüllte Formular von gestern.
-
Es wären nicht die WL, wenn irgendwas mal auf Anhieb funktionieren würde.
Nachdem ich mich gestern auf wien.gv.at für die Wiener Linien-Echtzeitdaten mit Name und Anschrift registriert habe, bekomme ich heute eine Mail, ich möge ihnen doch meinen Namen und Anschrift schicken, damit sie mich freischalten können. Im Anhang der Mail das ausgefüllte Formular von gestern.
Nunja, Formular von gestern ausdrucken und schicken, nicht senden. So richtig altmodisch mit Briefmarke drauf und so >:D
-
Es wären nicht die WL, wenn irgendwas mal auf Anhieb funktionieren würde.
Nachdem ich mich gestern auf wien.gv.at für die Wiener Linien-Echtzeitdaten mit Name und Anschrift registriert habe, bekomme ich heute eine Mail, ich möge ihnen doch meinen Namen und Anschrift schicken, damit sie mich freischalten können. Im Anhang der Mail das ausgefüllte Formular von gestern.
Nunja, Formular von gestern ausdrucken und schicken, nicht senden. So richtig altmodisch mit Briefmarke drauf und so >:D
Nein, ich hab ihnen höflich (so gut ich kann) geantwortet, dass sich mein Name und Anschrift seit gestern nicht geändert haben und sie die eingegebenen Daten ruhig verwenden können >:D
-
Es wären nicht die WL, wenn irgendwas mal auf Anhieb funktionieren würde.
Vergiss nicht, dass du auf der schwärzesten aller Blacklists stehst! :o :P
-
Vergiss nicht, dass du auf der schwärzesten aller Blacklists stehst! :o :P
Ah, hängt sein Konterfei schon in allen Diensträumen mit der Aufschrift "Wanted. Dead or alive"?
-
Es wären nicht die WL, wenn irgendwas mal auf Anhieb funktionieren würde.
Vergiss nicht, dass du auf der schwärzesten aller Blacklists stehst! :o :P
Habe ich zuerst auch vermutet, aber meinen - völlig unverdächtigen - Freunden, die auch alle um "Genehmigung" angesucht haben, ist es gleich ergangen.
@Revisor: Ich hoff, die auf mich ausgesetzte Summe ist wenigstens relativ hoch. Ist ja auch irgendwie ein Zeichen von Wertschätzung :D
-
Vergiss nicht, dass du auf der schwärzesten aller Blacklists stehst! :o :P
Ah, hängt sein Konterfei schon in allen Diensträumen mit der Aufschrift "Wanted. Dead or alive"?
Sie wollen ihn lebend, dann sperren sie ihn entweder in den Narrenturm (wo er an den Disponententisch der U5 gekettet wird), in ein dunkles Verließ (inkl. Soundboarding mit der Schneiderin) in der Tintenburg oder zur Strafarbeit in die U-Bahnwerkstatt, wo unser lieber, lieber 13er Rattenreste aus den Drehgestellen fitzeln muss. >:D
-
Vergiss nicht, dass du auf der schwärzesten aller Blacklists stehst! :o :P
Ah, hängt sein Konterfei schon in allen Diensträumen mit der Aufschrift "Wanted. Dead or alive"?
Sie wollen ihn lebend, dann sperren sie ihn entweder in den Narrenturm (wo er an den Disponententisch der U5 gekettet wird), in ein dunkles Verließ (inkl. Soundboarding mit der Schneiderin) in der Tintenburg oder zur Strafarbeit in die U-Bahnwerkstatt, wo unser lieber, lieber 13er Rattenreste aus den Drehgestellen fitzeln muss. >:D
Bei dem Nick: An Samstagen Disponent für den 13A >:D >:D
-
So, jetzt hört's aber auf mit diesen Ideen, wird ja langsam schlimmer als in Guantanamo!
-
Habe ich zuerst auch vermutet, aber meinen - völlig unverdächtigen - Freunden, die auch alle um "Genehmigung" angesucht haben, ist es gleich ergangen.
Hast du nicht die Snowdon-Enthüllungen studiert? Es reicht schon die loseste Connection zu deiner Person, ein Anruf, ein E.Mail oder eine zufällige Bestellung beim selben Pizza-Lieferanten! :o
-
Ist ja auch irgendwie ein Zeichen von Wertschätzung :D
Zuneigung bekommt man geschenkt, Abneigung muß man sich schwer erarbeiten. ;D
Übrigens bist du dir sicher, dass sich dein Name und die Anschrift seit gestern nicht geändert hat?
Wenn dem so sei, bestell bewaffnetes Sicherheitspersonal vor deine Tür, denn jetzt wissen sie wo du dich aufhälst. :))
-
Es wären nicht die WL, wenn irgendwas mal auf Anhieb funktionieren würde.
Nachdem ich mich gestern auf wien.gv.at für die Wiener Linien-Echtzeitdaten mit Name und Anschrift registriert habe, bekomme ich heute eine Mail, ich möge ihnen doch meinen Namen und Anschrift schicken, damit sie mich freischalten können. Im Anhang der Mail das ausgefüllte Formular von gestern.
Ist doch ganz logisch: Du hast deine Daten auf wien.gv.at preisgegeben, die wurden aber sicher nicht an die WL weitergeleitet (des geht ned so aafoch, wissn S' eh, Datenschutz).
Ich frage mich allerdings, wieso man Name und Anschrift kundtun muss, um zu angeblich freien Daten zu kommen.
-
Es wären nicht die WL, wenn irgendwas mal auf Anhieb funktionieren würde.
Nachdem ich mich gestern auf wien.gv.at für die Wiener Linien-Echtzeitdaten mit Name und Anschrift registriert habe, bekomme ich heute eine Mail, ich möge ihnen doch meinen Namen und Anschrift schicken, damit sie mich freischalten können. Im Anhang der Mail das ausgefüllte Formular von gestern.
Ist doch ganz logisch: Du hast deine Daten auf wien.gv.at preisgegeben, die wurden aber sicher nicht an die WL weitergeleitet (des geht ned so aafoch, wissn S' eh, Datenschutz).
Ich frage mich allerdings, wieso man Name und Anschrift kundtun muss, um zu angeblich freien Daten zu kommen.
Weil die Daten angeblich ja nur zu nicht kommerziellen Zwecke verwendet werden dürfen. Vielleicht deshalb.
-
Weil die Daten angeblich ja nur zu nicht kommerziellen Zwecke verwendet werden dürfen. Vielleicht deshalb.
Dann sollen sie die Daten unter passender Lizenz (http://creativecommons.org/licenses/by-nc-sa/3.0/) hergeben, da steht nix von Preisgabe persönlicher Daten. Ich halte das für einen schlichten Einschüchterungsversuch: Waaßt eh, mir ham deine Daten, oiso pass auf, Burscherl!
-
Weil die Daten angeblich ja nur zu nicht kommerziellen Zwecke verwendet werden dürfen. Vielleicht deshalb.
Dann sollen sie die Daten unter passender Lizenz (http://creativecommons.org/licenses/by-nc-sa/3.0/) hergeben, da steht nix von Preisgabe persönlicher Daten. Ich halte das für einen schlichten Einschüchterungsversuch: Waaßt eh, mir ham deine Daten, oiso pass auf, Burscherl!
Vielleicht wollen sie es auch deshalb wissen, Wenn jemand etwas beseres als Qando programmiert, damit man diese Leute dann unter Vertrag nimmt. >:D >:D >:D
-
Ist doch ganz logisch: Du hast deine Daten auf wien.gv.at preisgegeben, die wurden aber sicher nicht an die WL weitergeleitet
Doch, das ist es ja gerade: Meine eingegebenen Daten waren im Anhang der Email, die ich von den WL bekommen habe! Die Daten "brauchen" sie, damit sie einem einen Key zusenden, den man immer angeben muss, um Anfragen an den Server zu stellen. Die Dokumentation der API ist übrigens sehr gut gelungen, sehr verständlich. Ich werde dann, sobald ich meinen Key habe, eine Java-Bibliothek dafür schreiben, damit nicht jeder händisch die JSON-Pakete parsen muss.
@Klingelfee: Doch, glücklicherweise ist die Nutzung nicht eingeschränkt worden, auch kommerziell ist sie möglich. Früher oder später wird jemand eine Brücke zwischen WL und GTFS schreiben, dann hat Google die Daten auch wieder und Wien ist für Touristen kein weißer Fleck mehr.
-
Die Daten "brauchen" sie, damit sie einem einen Key zusenden, den man immer angeben muss, um Anfragen an den Server zu stellen.
Vermutlich wollen sie herausfinden, welche Daten Querulanten wie der 13er so abfragen. ;)
-
Die Daten "brauchen" sie, damit sie einem einen Key zusenden, den man immer angeben muss, um Anfragen an den Server zu stellen.
Vermutlich wollen sie herausfinden, welche Daten Querulanten wie der 13er so abfragen. ;)
Also ich würde den 13er absolut nicht als Querulant einordnen. Ich würde ihn einordnen als Mitbürger dessen Ideen aus den unterschiedlichen Gründen seitens der WL nicht wirklich umsetzbar sind.
-
Also ich würde den 13er absolut nicht als Querulant einordnen. Ich würde ihn einordnen als Mitbürger dessen Ideen aus den unterschiedlichen Gründen seitens der WL nicht wirklich umsetzbar sind.
. . . dessen Ideen aus den unterschiedlichen Gründen seitens der WL nicht wirklich umsetzbar willkommen sind. 8)
-
Also ich würde den 13er absolut nicht als Querulant einordnen. Ich würde ihn einordnen als Mitbürger dessen Ideen aus den unterschiedlichen Gründen seitens der WL nicht wirklich umsetzbar sind.
. . . dessen Ideen aus den unterschiedlichen Gründen seitens der WL nicht wirklich umsetzbar willkommen sind. 8)
Das will ich nicht sagen. Denn es werden auch intern viele ähnliche Ideen geboren, die dann aus den unterschiedlichsten Gründen nicht umgesetzt werden. Meistens scheitern Umsetzungen am Geld.
-
Anscheinend werden für Entwickler zwei API-Keys verschickt. Einmal für die Testphase (beschränkt Abfragen auf 100/Minute) und einmal für das Produktivsystem (ohne Beschränkungen). Grundsätzlich keine blöde Idee, wie ich finde... Aber mal sehen, was die Schnittstelle so leistet.
-
Hat jetzt eigentlich schon jemand einen Zugang? Ich könnte mir sonst vorstellen, das man noch bis nächsten Samstag wartet und beim Tramwaytag die Freischaltung zelebriert >:D >:D >:D
-
Hat jetzt eigentlich schon jemand einen Zugang?
Ein einziger Freund hat die Freischaltung schon bekommen, ja.
-
Hat jetzt eigentlich schon jemand einen Zugang?
:up:
-
Hat jetzt eigentlich schon jemand einen Zugang? Ich könnte mir sonst vorstellen, das man noch bis nächsten Samstag wartet und beim Tramwaytag die Freischaltung zelebriert >:D >:D >:D
Ich bin gespannt, ob und wie das am Tramwaytag überhaupt ein Thema sein wird.
-
Und da ist sie, die erste Anwendung: http://www.data.gv.at/anwendungen/willi-wiener-linien/ (http://www.data.gv.at/anwendungen/willi-wiener-linien/)
Schaut unter Android Design-mäßig schon mal besser aus, der Monitor funktioniert schnell und gut, die Fahrplanauskunft erstaunlicherweise auch, obwohl die noch nicht als Open Data verfügbar ist!
-
Naja, bei dem App haperts aber auch noch gewaltig (iOS-Version). Jede angewälte Haltestelle landet in einer Verlaufsliste. Die Aufnahme in die Favoriten soll wohl eine Sprungmarke in dieser Liste bewirken, tut es aber nicht, man landet immer am Anfang. Die Haltestellennamen sind tw. Pfusch, so heißt Spitalgasse#Währinger Straße bspw. Amtshaus Alsergrund. Eine Adreßeingabe ist auch nicht möglich, nur Auswahl naher Haltestellen bei eingeschaltetem GPS (was ich aus Akku- und Datenschutzgründen nicht permanent tue).
-
Bist du dir sicher, dass du von Willi redest? Bei mir wird richtig Sensengasse angezeigt. Überhaupt ist die App sehr schön gemacht, wird bis auf weiteres meine Abfrage-App. Qando habe ich wegen der NSA-Spielerei ja gleich vor dem Update gekübelt.
-
Bei mir wird richtig Sensengasse angezeigt.
Sensengasse ist aber nicht Amtshaus Alsergrund. Linie 41 bezog sich auf Spitalgasse/Währinger Straße/Nußdorfer Straße, [kaidaphon]Amtshaus WILHELM-EXNER-GASSE[/kaidaphon] (bzw. Arne-Carlsson-Park, wie der Haltestellenkomplex in den frühen VOR-Fahrplanbüchern fälschlicherweise hieß).
-
Bei mir wird richtig Sensengasse angezeigt.
Sensengasse ist aber nicht Amtshaus Alsergrund.
Früher, als ich dort noch häufiger fuhr, schon ;)
Aber auch die andere Haltestelle heißt bei mir richtig "Spitalgasse/Währinger Straße".
btw, weil wir grad bei dem Beispiel sind: In den Daten sind übrigens noch die Währingerstraßen-Umleitungen drin :o
-
Bis vor wenigen Jahren lautete die Ansage tatsächlich noch "Sensengasse, Amtshaus Alsergrund". Später kam der Zusatz "Universitätszahnklinik" auch noch dazu. 8)
-
Aber auch die andere Haltestelle heißt bei mir richtig "Spitalgasse/Währinger Straße".
Kann ja sein, dass das bei iOS auftritt und bei Android nicht.
-
Aber auch die andere Haltestelle heißt bei mir richtig "Spitalgasse/Währinger Straße".
Kann ja sein, dass das bei iOS auftritt und bei Android nicht.
Falls Willi im Hintergrund eigentlich den jeweiligen Kartendienst verwendet, könnte das gut daran liegen. Die iOS Maps sind ja der letzte Schrott.
-
Ich wart ja auch noch immer auf meinen Key, aber ich hab die Zeit genutzt und mir mal die cvs Files mit den Haltestellen anzusehen, die man ja - soweit ich die doku verstanden habe - braucht um auf die rbl-ids der einzelnen Stationen zu kommen.
Was natürlich grossartig ist, und das ganze weitestgehend unbrauchbar macht: Diese Daten auf data.gv.at stammen vom 12.8. Damit enthalten sie u.a. keinen 72er, dafür aber den Umleitungsverkehr während der Bauarbeiten in der Währingerstrasse.
Allerdings sind nicht mal die veralteten Daten konsistent, denn Während 37,38,40 und 41 den Umleitungsrouten folgen, fährt der 42er brav zwischen Antonigasse und Schottentor. :bh:
Irgendwie freu ich mich schon auf die Datenqualität des neuen Services. :fp:
-
Man hat ihnen eben nur gesagt, sie sollen den aktuellen Stand extrahieren 8)
-
Man hat ihnen eben nur gesagt, sie sollen den aktuellen Stand extrahieren 8)
Ah und der 41E ist trotzdem nicht dabei. ???
-
Und genau drum - fahr i mitn Auto. Abgesehen davon, dass es nix unzuverlässigers gibt als ÖV in Wien, mach ich mir den eigenen Fahrplan.
-
Paar Tage online, schon nicht mehr erreichbar. Derzeit kommt bei jeder Anfrage "Unsupported media type". Hat mir ein Freund erzählt :)
-
Paar Tage online, schon nicht mehr erreichbar. Derzeit kommt bei jeder Anfrage "Unsupported media type". Hat mir ein Freund erzählt :)
Das liegt mglw. an fehlenden Requestheadern:
Die Ausgabe ist durch die Angabe folgender Request Header Parameter anzugeben:
Accept=application/json, Content-Type=application/json.
ohne die Parameter bekomme ich auch "Unsupported media type", mit den Headern (ermangels key) HTTP Error 400: Bad Request
-
Hat aber mit genau demselben Code vorher funktioniert! Also habens zumindest am Server was geändert.
-
Mag mal jemand, der einen Zugangscode hat einen Tag lang die Durchfahrtszeiten des 13A bei der Neubaugasse und Kirchengasse mitloggen. Da wäre im Zusammenhang mit der Mahü-Diskussion eine Korrelation mal extrem interessant. Ich vermute zwar, dass sich die Durchfahrtszeiten jeweils um einen fixen Betrag unterscheiden werden, aber es wäre doch nett, das mit Datenmaterial untermauern zu können.
-
Mag mal jemand, der einen Zugangscode hat einen Tag lang die Durchfahrtszeiten des 13A bei der Neubaugasse und Kirchengasse mitloggen. Da wäre im Zusammenhang mit der Mahü-Diskussion eine Korrelation mal extrem interessant. Ich vermute zwar, dass sich die Durchfahrtszeiten jeweils um einen fixen Betrag unterscheiden werden, aber es wäre doch nett, das mit Datenmaterial untermauern zu können.
Ich will ja nicht neugierig sein, aber was willst du damit beweisen. Nur bedingt durch die Durchfahrtzeiten kannst du keine Rückschlüsse auf die "Beinahunfälle" rückschließen.
-
Ich will ja nicht neugierig sein, aber was willst du damit beweisen. Nur bedingt durch die Durchfahrtzeiten kannst du keine Rückschlüsse auf die "Beinahunfälle" rückschließen.
Will er auch nicht, weil es nur Beinaheunfälle mit Kriechwürmern gibt.
-
Ich will ja nicht neugierig sein, aber was willst du damit beweisen. Nur bedingt durch die Durchfahrtzeiten kannst du keine Rückschlüsse auf die "Beinahunfälle" rückschließen.
Das natürlich nicht, aber zumindest könnte man mal nachweisen, dass es keinerlei *Behinderungen* gibt.
btw. ich würde zu gern wissen, was der Mitarbeiter der Verkehrsaufsicht heute gegen 14:45 auf seinem Notizblock aufgeschrieben hat - zu einem Zeitpunkt, wo seit einigen Minuten kein 13A gefahren war (und auch die beiden davor keinerlei Probleme hatten). Ich hab irgendwie das dumpfe Gefühl, dass es nicht "alles problemlos" war. Leider hab ich erst daran gedacht ihn zu fragen - kostet ja nix -, als er bereits verschwunden war :-\
-
Nachdem die Qualität der bereitgestellten CSV-Files mehr als nur miserabel ist (dass die Währinger Straßen-Umleitungen drinnen sind und nur der 42er zum Schottentor fährt, ist nur dir Spitze des Eisbergs), habe ich im Zuge eines Projekts von mir die Daten etwas aufbereitet. Auf unnötige Fremdschlüssel wurde verzichtet - alles in einer einzigen CSV-Datei. Mit von der Partie sind dabei lediglich die Straßenbahnlinien (ohne WLB).
Anspruch auf unumstößliche Korrektheit ist nicht gegeben (obwohl alles soweit passen sollte) und jeder darf damit anstellen, was er will. Wenn es Fragen gibt, bitte fragen...
-
(dass die Währinger Straßen-Umleitungen drinnen sind und nur der 42er zum Schottentor fährt, ist nur dir Spitze des Eisbergs)
Ja, leider, nachdem ich nun endlich meinen Key bekommen habe, ist mir das auch gleich aufgefallen. Dabei steht auf der OpenData-Seite der Haltestellenliste extra noch:
Die Daten werden auf Basis der Meldungen der Wiener Linien und des Verkehrsverbundes Ost-Region (VOR) laufend aktualisiert. Temporäre Änderungen der Linienführung werden nicht übernommen.
-
Nachdem die Qualität der bereitgestellten CSV-Files mehr als nur miserabel ist (dass die Währinger Straßen-Umleitungen drinnen sind und nur der 42er zum Schottentor fährt, ist nur dir Spitze des Eisbergs), habe ich im Zuge eines Projekts von mir die Daten etwas aufbereitet. Auf unnötige Fremdschlüssel wurde verzichtet - alles in einer einzigen CSV-Datei. Mit von der Partie sind dabei lediglich die Straßenbahnlinien (ohne WLB).
Anspruch auf unumstößliche Korrektheit ist nicht gegeben (obwohl alles soweit passen sollte) und jeder darf damit anstellen, was er will. Wenn es Fragen gibt, bitte fragen...
Eine Verständnisfrage zu den originalen CSVs hab ich noch. Bei manchen Haltestellen kommen rbl-ids der Form ###:### vor. Hat das noch irgend eine spezielle Bedeutung (abgesehen davon dass ich dann beide Nummern abfragen muss)?
-
Bei manchen Haltestellen kommen rbl-ids der Form ###:### vor. Hat das noch irgend eine spezielle Bedeutung (abgesehen davon dass ich dann beide Nummern abfragen muss)?
Offenbar werden vom System der Wiener Linien einige, wenige Haltepunkte zusammengefasst verwaltet (z.B. 52/58 am Westbahnhof oder 62/WLB bei der Oper), d.h. das System sieht sie als gemeinsame Haltestelle an (bahnsteigtechnisch), kennt aber unterschiedliche Haltepunkte. Beim extrahieren der Daten wurde darauf offensichtlich nicht geachtet (oder ein Tüftler konnte sich selbst keinen Reim darauf machen) und es wurden invalide CSV-Files mit Haltepunkten, die u.a. mehrere IDs haben können, erstellt.
Beide Nummern müssen im Übrigen nicht abgefragt werden. Einer ist der richtige, der andere der falsche - so blöd es klingen mag. Da funktioniert nur ausprobieren und schauen, was von wo wegfährt.
Dabei steht auf der OpenData-Seite der Haltestellenliste extra noch:
Die Daten werden auf Basis der Meldungen der Wiener Linien und des Verkehrsverbundes Ost-Region (VOR) laufend aktualisiert. Temporäre Änderungen der Linienführung werden nicht übernommen.
Nun ja, mit dieser Liste (https://open.wien.at/site/datensatz/?id=f1f6f15d-2faa-4b62-b78b-80599dd1c66e) ist ja grundsätzlich nicht viel anzufangen, da sie keine RBL-IDs enthält. Und auf der Seite der Echtzeitschnittstelle steht lediglich:
Die Daten zu Haltestellen, Linien und Steige werden im Bedarfsfall in Zusammenarbeit mit dem VOR aktualisiert.
Alles andere wäre auch armselig. Denn woher soll ich die RBL-IDs bekommen? Aus der Nase ziehen? Vor Ort auf den Haltestellenreiter schauen (was ich im Übrigen sehr witzig finde, dass das dort überhaupt steht :D)? Man hätte auch einfach eine weitere Methode zur Haltestellensuche zur Verfügung stellen können (wie sie qando auch hat), dann hätte man nicht das Problem mit der Aktualisierung der Daten. Aber wahrscheinlich hat das ihnen keiner explizit angeschafft... ::)
-
Man hätte auch einfach eine weitere Methode zur Haltestellensuche zur Verfügung stellen können (wie sie qando auch hat), dann hätte man nicht das Problem mit der Aktualisierung der Daten. Aber wahrscheinlich hat das ihnen keiner explizit angeschafft... ::)
Ja, mit der Qando-API funktioniert die Haltestellensuche. Ich habe - natürlich ausschließlich zu Testzwecken ;) - aus dieser API früher schon eine eigene Haltestellenliste extrahiert.
Eine dynamische Haltestellenliste ist AFAIK nicht vorgesehen, da auch Qando die Liste statisch enthält. Darüber haben wir ja schon mal diskutiert. Ich fände es sinnvoller, wenn alle Daten dynamisch vom Server kommen, damit ist Aktualität (zumindest von Userseite) immer garantiert.
-
Das neue Qando lädt diese Daten doch dauernd vom Server oder?
-
@ULF: Ist dir schon aufgefallen, dass newsList- und trafficInfoList-Abfragen kein "message"-Attribut in der Antwort haben, wenn die Antwort ok ist? Ich wäre ja versucht, das als normal anzusehen (also Message wird nur dann mitgeliefert, wenn ein Fehler auftritt), allerdings liefert eine monitor-Abfrage sehr wohl auch eine Message mit und zwar, dass alles "OK" ist (Code 1). Scheint mir ein bißchen inkonsistent zu sein (nicht dass es mich überrascht).
-
Das neue Qando lädt diese Daten doch dauernd vom Server oder?
Frei nach Radio Eriwan: Im Prinzip ja.
Ganz durchschaut hab' ich es aber noch nicht. Aber es gibt zumindest einen Webservice, der Qando sagt, was sich am (serverseitigen) Datenbestand geändert hat. Generell hat die App grundsätzlich die Möglichkeit alle relevanten Daten vom Server On-Demand abzufragen. Ob und wann es das tut, das ist die Frage.
@ULF: Ist dir schon aufgefallen, dass newsList- und trafficInfoList-Abfragen kein "message"-Attribut in der Antwort haben, wenn die Antwort ok ist?
Zur Zeit frage ich diese Elemente (newsList und trafficInfo) nicht ab (mir reicht vorerst der Rest und böse Sachen anzustellen :D ). Aber sei froh, dass sie zumindest die Monitor-Responses etwas überarbeitet haben. Die erste Version der neuen Qando-Schnittstelle hat zum Teil die Fahrrichtungen in der Antwort nicht richtig gesetzt (alles fährt z.B. in Fahrtrichtung 1) oder es gab an einer Haltestelle für eine Linie plötzlich 3 (oder mehr) Monitore (einmal in die eine Fahrtrichtung, einmal in die andere und dann nochmal in dieselbe aber mit Einziehern aber ohne Echtzeit).
Generell verstehe ich nicht ganz, warum man die übergebenen JSON-Objekte derartig schlimm zusammenbauen muss.
Alles in allem eine wahre "Freude" für Entwickler. Aber nachdem ich da schon lange herumpfusche, ist man ja schon Gott sei dank einiges gewöhnt. ;)
Ich bin ja schon gespannt, wenn ich jetzt länger an der Schnittstelle arbeite, auf was ich noch alles draufkomme... aber mal abwarten und Tee trinken.
-
Zur Zeit frage ich diese Elemente (newsList und trafficInfo) nicht ab (mir reicht vorerst der Rest und böse Sachen anzustellen :D ).
Und ich brauche eben genau die TrafficInfos - heute kann ich nix machen, aber am Sonntag schaffe ich vielleicht ein erstes Release meiner Java-Bibliothek. Damit nicht jeder von null anfangen muss, der z.B. Android-Apps (das ist auch mein Langzeitziel) oder sonstige Dinge schreiben möchte. Und ganz nebenbei kann ich meine Störungsdatenbank legalisieren sowie täglich die Blaue abfragen.
Bei der Doku merkt man übrigens auch, dass die in Eile oder Faulheit entstanden ist: Verweisfehler, Rechtschreibfehler und schlimmer noch Fehler in der Spezifikation. Einmal ist die Rede von "poi", dann wieder "news" und manche Attributnamen muss man sich selbst korrigieren. Da hätte einmal drüberlesen auch nicht geschadet, aber besser als nix. Bei Qando musste ich alles selbst reverse-engineeren, das war wesentlich mühsamer als wenn man weiß, was man tut.
-
ULF (oder sonst jemand, der sich schon mit der API beschäftigt hat): Bei der Fehlerbehandlung habe ich bisher in der Doku übersehen, dass der Fehlercode optional ist?! WTF? Wirst du aus der ganzen Erklärung unter 2.1.3 schlau? Was bedeuten die Einträge bei "Filter"? Die tauchen nirgends mehr auf. Hast du so ein Datenpaket schon in freier Wildbahn gesehen?
Ich mach's jetzt pragmatisch einfach so, dass ich, wenn keine Message dabei ist, einfach annehme, dass das Paket OK war (Statuscode ist dann 1). Aber ganz wohl fühlt man sich dabei auch nicht. Und warum zum Teufel ein optionaler Fehlercode innerhalb des Objekts? Ist es nicht gerade die Funktion dieses Attributs, den Fehler zu erklären?
Ob es wohl Sinn hat, diese Fehler/Ungereimtheiten in der Dokumentation bzw. Schnittstelle an die OpenData-Leute zu senden? Wenn ich noch einmal "Wir schauen uns das an" höre, renne ich schreiend aus dem Zimmer (abgewandeltes Simpsons-Zitat).
-
ULF (oder sonst jemand, der sich schon mit der API beschäftigt hat): Bei der Fehlerbehandlung habe ich bisher in der Doku übersehen, dass der Fehlercode optional ist?! WTF? Wirst du aus der ganzen Erklärung unter 2.1.3 schlau? Was bedeuten die Einträge bei "Filter"? Die tauchen nirgends mehr auf. Hast du so ein Datenpaket schon in freier Wildbahn gesehen?
Ich glaube das ist schlicht ein Fehler in der Dokumentation. Gesehen hab ich das auf jeden Fall noch nie. Ich muss aber auch zugeben, dass ich mit der Schnittstelle kommuniziere ohne je richtig die Doku angeschaut zu haben... Ich provoziere einfach gewisse Verhaltensweisen und sehe mir den die Reaktion an.
Generell glaube ich, dass das Problem ist, dass das ganze ein gewachsenes Produkt ist. Im Grunde genommen hat sich die Schnittstelle ja nie wirklich verändert. Deshalb glaube ich auch kaum, dass die Rückgaben da in irgendeiner Art und Weise jetzt noch verbessert werden (wie gesagt der Aufbau der Antworten ist zum Teil einfach nicht nachvollziehbar - und keineswegs sauber oder entwicklerfreundlich) - dafür ist es jetzt einfach schon zu spät.
-
Ich muss aber auch zugeben, dass ich mit der Schnittstelle kommuniziere ohne je richtig die Doku angeschaut zu haben... Ich provoziere einfach gewisse Verhaltensweisen und sehe mir den die Reaktion an.
So hätte ich es jetzt im Nachhinein gesehen auch machen sollen.
Generell glaube ich, dass das Problem ist, dass das ganze ein gewachsenes Produkt ist. Im Grunde genommen hat sich die Schnittstelle ja nie wirklich verändert. Deshalb glaube ich auch kaum, dass die Rückgaben da in irgendeiner Art und Weise jetzt noch verbessert werden (wie gesagt der Aufbau der Antworten ist zum Teil einfach nicht nachvollziehbar - und keineswegs sauber oder entwicklerfreundlich) - dafür ist es jetzt einfach schon zu spät.
Ja, ändern wird sich jetzt sicher nichts mehr. Im Überblick sah es eigentlich ganz gut aus, aber je mehr ich mich damit beschäftige (und meine Library ist so gut wie "fertig"), desto mehr Ungereimtheiten tauchen auf. Von elegant ist diese API wirklich kilometerweit entfernt - ganz im Gegenteil kann ich mir jetzt noch besser vorstellen, warum diese Services ständig ausfallen. Da läuft einem ein kalter Schauer den Rücken runter, andererseits kann man nur froh sein, dass diese Leute nicht in einem Krankenhaus oder einem Flughafentower arbeiten ;)
Ich hab hier mal alle Dinge, die mir so aufgefallen sind, zusammengeschrieben: http://f59.at/errata/ (http://f59.at/errata/)
-
Von elegant ist diese API wirklich kilometerweit entfernt
Mal ganz abgesehen, dass da auch öfter mal völliger Bullshit daherkommt:
Von http://www.wienerlinien.at/ogd_realtime/monitor?rbl=4614: (http://www.wienerlinien.at/ogd_realtime/monitor?rbl=4614:)
{ "data" : { "monitors" : [ { "attributes" : { },
"lines" : [ { "barrierFree" : false,
"departures" : { "departure" : [ { "departureTime" : { },
"vehicle" : { "linienId" : 306,
"towards" : " U2 BETRIEBSSCHLUSS ! BENÜTZEN SIE BITTE DIE NIGHTLINE",
"type" : "ptMetro"
}
} ] },
"direction" : "R",
"lineId" : 306,
"name" : "U6",
"platform" : "2",
"realtimeSupported" : true,
"richtungsId" : "1",
"towards" : "U2 BETRIEBSSCHLUSS ! BENÜTZEN SIE BITTE DIE NIGHTLINE",
"trafficjam" : false,
"type" : "ptMetro"
} ],
"locationStop" : { "geometry" : { "coordinates" : [ 16.3313431753648,
48.173791397439501
],
"type" : "Point"
},
"properties" : { "attributes" : { "rbl" : 4614 },
"coordName" : "WGS84",
"gate" : "2",
"municipality" : "Wien",
"municipalityId" : 90000,
"name" : "60201015",
"title" : "Meidling-Philadelphiabrücke",
"type" : "stop"
},
"type" : "Feature"
}
} ] },
"message" : { "messageCode" : 1,
"serverTime" : "2013-09-13T00:08:40.248+0200",
"value" : "OK"
}
}
U2 in Meidling?!
-
Die U-Bahn ist bezügl. Echtzeitinfo speziell: Da wird meiner Beobachtung (bei Störungen) einfach der Text, der auf der Anzeige vor Ort steht, 1:1 übernommen. Also wäre spannend, ob mal jemand in der Nacht zur Phila schauen geht, ob da wirklich U2 steht :D
Edit: Nach einem Eintrag auf der Facebookseite der WL dürfte die U2 heute auf den Anzeigen aller U-Linien stehen 8)
-
Ach, das ist sicher ein Teil der tollen Kampagne zur Ankündigung der U2-Verlängerung. ;)
-
Ach, das ist sicher ein Teil der tollen Kampagne zur Ankündigung der U2-Verlängerung. ;)
Wollt ihr die U2 totaler als ihr sie euch je vorstellen könnt? ???
-
Wie ich erst heute bemerkt habe, gab es am 12. September ein Update der CSV-Dateien. Die Währinger Straße passt jetzt, dafür sind viele Haltestellen jetzt nicht mehr enthalten, etwa jene von Schnellbahn, Regionalbuslinien und Badner Bahn. Die Abfrage der Abfahrtszeiten von den Badner Bahn-Stationen funktioniert aber nach wie vor, wenn man die RBL-Nummern kennt.
-
Also bei mir steht bei den Dateien immer noch 29.8.2013 als Veröffentlichungsdatum? Wo hast du die neuen Dateien gefunden?
-
Also bei mir steht bei den Dateien immer noch 29.8.2013 als Veröffentlichungsdatum? Wo hast du die neuen Dateien gefunden?
Vergiss das Veröffentlichungsdatum, das wird wohl nicht aktualisiert. Die Dateien selbst haben sich aber verändert (bis auf wienerlinien-ogd-linien.csv), als Zeitstempel steht jetzt "2013-09-11 08:48:10".
Weil ich mich bei der Open Data-Mailadresse der Wiener Linien beschwert habe, dass die Daten veraltet sind, habe ich eine Antwort erhalten, die folgenden Satz enthält:
Grundsätzlich ist auch zu sagen, dass der Zeitstempel lediglich dem Zeitpunkt des Exportes entspricht – nicht dem des Datenstandes, welcher auch bereits einem aktuelleren Stand entspricht.
Daraus werde ich aber leider nicht wirklich schlau.
-
Ah, danke, ich versuch noch mal, das in meine libf59 zu bekommen. Sind jetzt die ###:### auch weg? Die stören ganz schön, z.B. bei der Burggasse. Ich hab da auch temporär die Liste von "ULF" verwendet.
-
Sind jetzt die ###:### auch weg?
Die gibt's leider nach wie vor.
-
Sind jetzt die ###:### auch weg?
Die gibt's leider nach wie vor.
Ich habe mir jetzt ein Script geschrieben, das diese Dubletten findet und dann checkt, welche davon stimmt. Leider gibt es sowohl Fälle, wo überhaupt keine RBL-Nummer gegeben ist und andererseits gibt es auch Steige, wo beide Nummern stimmen (= man bekommt zu beiden Steigen Echtzeitdaten von der gegebenen Linie; z.B. 215031375 oder 214691283). Dort habe ich dann einfach die zweite weggeworfen - wer weiß schon so genau, was er da wirklich tut? :D
Das sind die betroffenen Steige:
GATEID: RBL
214690599: 461
214690866: 111
214691208: 508
214691283: 111
214692421: 36
214692474: 36
214692503: 1531
214692556: 1531
214692685: 1710
214692773: 1710
214693979: 39
214694013: 39
214694562: 998
214694613: 998
214694642: 3066
214694710: 3066
214694738: 2668
214694807: 2668
214695004: 2668
214697983: 8
214698052: 8
214699134:
214699166:
214699215:
214699244:
214699261:
214699345:
214699423:
214699426:
214700619:
214700658:
214700772:
214700792:
214700880:
214700917:
214700970:
214701032:
214701138:
214701178:
214701226:
214857880:
214857930:
214927701:
214927706:
215031375: 2545
215031435: 2545
Ich beginne immer mehr, die API zu hassen. Hab schon wieder Fehler in der Spezifikation entdeckt. Es werden immer wieder Attribute nicht mitgeliefert, die als "required" gekennzeichnet sind. Naja, was einen nicht umbringt, macht einen nur härter.
-
Laut den Verkehrsdaten des weltbesten Unternehmens verkehren derzeit offenbar auf allen Straßenbahnlinien Hochflurer (als Echtzeitdatensätze!). Qando (auch die alte Version) sowie die OpenGovernment-Schnittstelle sind davon betroffen. Das iTip präsentiert derweil nur Plandaten für die Straßenbahnlinien.
-
Laut den Verkehrsdaten des weltbesten Unternehmens verkehren derzeit offenbar auf allen Straßenbahnlinien Hochflurer (als Echtzeitdatensätze!). Qando (auch die alte Version) sowie die OpenGovernment-Schnittstelle sind davon betroffen. Das iTip präsentiert derweil nur Plandaten für die Straßenbahnlinien.
Und die Displays auf der Straße zeigen "Fahrplanaushang beachten" - schaut nach Totalcrash aus.
-
Und die Displays auf der Straße zeigen "Fahrplanaushang beachten" - schaut nach Totalcrash aus.
Ja, das ganze RBL hat sich am Abend wieder einmal verabschiedet. Die Fahrzeuge werden laut Gruppenbuch (Fahrplan) geführt.
-
Ja, das ganze RBL hat sich am Abend wieder einmal verabschiedet.
Der Zustand besteht anscheinend heut weiterhin... Zumindest was die Verkehrsdaten angeht.
Was ich mich frage, warum man Fahrplandaten als Echtzeitdaten verkauft. Das ist nicht akzeptabel.
-
Was ich mich frage, warum man Fahrplandaten als Echtzeitdaten verkauft. Das ist nicht akzeptabel.
Weil die UGvM hofft, daß es die meisten Fahrgäste nicht bemerken.
-
Für Leute eine Applikation betreiben, die auf diesen Daten fußt und welche vielleicht sogar noch kommerziell ist oder geschäftlich (warum auch immer) verwendet wird, ist das Affront erster Klasse. Wenn man wenigstens damit ehrlich umgehen würde (sprich - wenn man die Daten schon hat - eine Mail an alle API-Key-Besitzer, sich entschuldigen und den Zeitraum bis zur Behebung der Störung bekannt geben), dann wäre ja alles halb so schlimm. So, wünsche ich mir immer mehr, sie würden die halbherzig gestaltete API einfach wieder einstellen. Sie kann einen Bruchteil von dem, was sie für Qando bereitstellen, funktioniert absolut unzuverlässig - man muss immer erwarten dass die Schnittstelle einem anlügt oder Fehler verschweigt, die Datenbasis ist saumäßig und generell die Definition der Schnittstelle entbehrt jedweder Kritik. Eigentlich müsste man das Büro des Verantwortlichen anzünden und die Serveranlagen sprengen - verloren wäre sicher nichts wichtiges - billiger wäre es auf Dauer allemal.
-
Du weißt ja wie das ist, wenn die Wiener Linien etwas eigentlich nicht wollen und dann gezwungen werden es umzusetzen. Dann wird sabotiert, was das Zeug hält – siehe auch Mariahilfer Straße. Daß wir Bürger Arbeitgeber und Kunden dieser UGvM sind, hat sich noch nicht bis dort herumgesprochen – außer beim Fahrpersonal vielleicht.
-
Ich weiß. Leider. :P
Das Problem ist, ich hab' das alles gelernt, wie man das richtig macht, und dann so etwas zu sehen, wo (eigentlich völlig grundlos) an jeder Ecke Fehler oder komplett undurchsichtige und falsche Entscheidungen von dahergelaufenen "IT"-Leuten getroffen werden, ist einfach nur traurig. Aber gut... Ich bin ja schon gespannt, wie lange der derzeitige Verschleierungs-Modus betrieben wird.
-
Eigentlich müsste man das Büro des Verantwortlichen anzünden und die Serveranlagen sprengen - verloren wäre sicher nichts wichtiges - billiger wäre es auf Dauer allemal.
Im Zweifelsfall würde man dann umgehend daran gehen, die alte Lösung mit allem seit Jahrzehnten herumgeschleppten Murks nachzubauen.
-
Und die Displays auf der Straße zeigen "Fahrplanaushang beachten" - schaut nach Totalcrash aus.
Ja, das ganze RBL hat sich am Abend wieder einmal verabschiedet. Die Fahrzeuge werden laut Gruppenbuch (Fahrplan) geführt.
Wie geht das??! Wie kann das betriebskritischste System in einem Verkehrsbetrieb derart von Wurschtigkeit verwaltet werden?
-
Wie geht das??! Wie kann das betriebskritischste System in einem Verkehrsbetrieb derart von Wurschtigkeit verwaltet werden?
Bei uns ist das RBL kein betriebskritisches System und schon gar kein Betriebssystem, sondern nur ein erweitertes Beobachtungsmittel für den Disponenten, der sich aus den Anzeigen am Bildschirm einen Status quo zusammenreimt und darauf seine Handlungen aufbaut. Möglicherweise dauert es auch deshalb im Störungsfall so ewig lang, bis die Intervalle wiederhergestellt sind.
Und außadem, friara, wia ma no ka RBL ghobt ham, samma aa gfoahrn, oiso za wos brauch ma des?
-
Eigentlich müsste man das Büro des Verantwortlichen anzünden und die Serveranlagen sprengen
Falls sich der Verantwortliche zu dem Zeitpunkt nicht in seinem Büro befindet, wird das auch nichts nützen. Er wird dann einfach alle Linien wieder neu eingeben, so wie beim letzten Mal, als ihm der Server verreckt ist ohne Backup...
Er muss irgendwas gegen einen der Direktoren in der Hand haben (belastende Fotos oder so :D) , anders kann ich mir nicht erklären, wie jemand, der so offensichtlich für seinen Job nicht geeignet ist, sich an dieser Position über Jahre hält. In einer Privatfirma kann man so was normalerweise höchstens bis zu einem halben Jahr verheimlichen, dann fliegt man ohne wenn und aber.
-
Ich glaube eher, dass er die Unwissenheit der anderen und ihre Unfähigkeit, über den Tellerrand hinauszublicken, ausnützt. Wenn gefordert, erklärt er ihnen halt in einem fünfseitigen Bericht, warum das alles genau so sein musste, wie es gekommen ist, und alle werden das brav abnicken und ihn vielleicht noch für seine Umsicht belobigen.
-
Unter den Blinden ist der Einäugige König! ;)
(http://upload.wikimedia.org/wikipedia/commons/thumb/d/d0/Pieter_Bruegel_d._%C3%84._025.jpg/800px-Pieter_Bruegel_d._%C3%84._025.jpg)
Es gibt ein Gerücht, wonach Pieter Bruegel das Motiv für sein Bild in Erdberger Gefilden gefunden hat! :o
-
Mir sind im Übrigen mittlerweile einige Haltepunkte aufgefallen, die sich offenbar nicht per RBL-ID aufrufen lassen (auch nicht über qando). Derzeit habe vier solche "Blindgänger" identifiziert:
- Haltepunkt #3123: Rußbergstraße
- Haltepunkt #5415: Marienbrücke
- Haltepunkt #5637: Fickeysstraße
- Haltepunkt #5726: Edmund-Hawranek-Platz
Für diese Haltepunkte bekommt man einfach leere Antworten von der Schnittstelle (messageCode = OK). Die Nummern stammen aus den veröffentlichten CSV-Files.
Kennt jemand das Phänomen von anderen Haltestellen? Oder vielleicht gar korrigierte RBL-Nummern?
Ich werde das auf jeden Fall bei Zeiten melden. Nachdem auch qando davon betroffen ist, besteht ja Hoffnung...
-
Ich habe noch Probleme mit dem 71er beim 3. Tor. Ich weiß zwar inzwischen, welche RBL-Nummer theoretisch stimmen sollte, aber da kommen keine Echtzeitdaten daher.
-
Bei mir sind das #4733 als Abfahrtshaltepunkt und #7541 als Ankunftshaltepunkt beim 3. Tor. Beide Nummern stammen aus den CSV-Files und funktionieren bei mir.
-
Ich habe noch Probleme mit dem 71er beim 3. Tor. Ich weiß zwar inzwischen, welche RBL-Nummer theoretisch stimmen sollte, aber da kommen keine Echtzeitdaten daher.
Kann das jemand bei der Haltestelle 2593 (Trondheimgasse FR Floridsdorf S U) ausprobieren, ob das daran liegt, dass dort seit Monaten keine Echtzeitdaten im qando sind?
-
Kann das jemand bei der Haltestelle 2593 (Trondheimgasse FR Floridsdorf S U) ausprobieren, ob das daran liegt, dass dort seit Monaten keine Echtzeitdaten im qando sind?
Ich bekomme über qando 4 als auch über die Schnittstelle für diesen Haltepunkt Echtzeitdaten. Über die Schnittstellen der Vorversionen kommt natürlich Schmafu (3 Haltepunkte - Einer mit Echtzeitdaten, Zwei mit Plandaten) - denn hier wurden die damaligen Linienänderungen nie korrekt eingepflegt (auch vom neuen 6/71 oder den neuen Haltestellen vom D-Wagen).
-
Ein interessantes Detail am Verhalten der Schnittelle konnte ich entdecken: Offenbar werden (zumindest bei Straßenbahnlinien) Fahrzeuge nach Fahrtrichtung im System abgebucht und erfasst. Das hat (zumindest) folgende, beobachtbare Auswirkung: Haben wir ein Niederflurfahrzeug auf dem Weg von Endstation B nach Endstation A, wird die entsprechende Abfahrt bei Endstation A als niederflurig erfasst. Bei Endstation B hingegen ist die entsprechende Abfahrt noch als Hochflurer angegeben (offensichtlich kann das System zu diesem Zeitpunkt der Abfahrt kein Fahrzeug zuordnen oder es liegt ein anderer Fehler vor). Erst wenn das Fahrzeug die Endstation A passiert hat, wird die entsprechende Abfahrt ab Endstation B als niederflurig ausgewiesen.
Klingt etwas kompliziert und ist für den reellen Gebrauch jetzt nicht sonderlich schwerwiegend (da die Fahrzeiten in eine Fahrtrichtung in Wien bei 15 Minuten+ bewegen). Dennoch ein interessantes Verhalten, dass man recht gut auf der Linie 42 beobachten kann. Auch die derzeitige und alle bisherigen Qando-Schnittstellen scheinen dieses Verhalten aufzuweisen.
-
Ein interessantes Detail am Verhalten der Schnittelle konnte ich entdecken:
Dieses Verhalten beruht auf dem Fahrt-Handling des IVU.suizid RBL der Wiener Linien. Dem RBL ist der tägliche Fahr- und Umlaufplan für alle Linien bekannt, um also dein Beispiel auszubauen:
C - A - B - A - B - A - [..] - B - A - C
A und B sind die jeweiligen Endhaltestellen, C ist der Betriebshof. Beim morgendlichen Runterfahren vom Hof meldet sich der Fahrer via IBIS am RBL an und das RBL weiß, dass das Fahrzeug nun von C nach A fährt. Um dass die DFI-Anzeiger entlang der Strecke A - B, die er nach C -A erstmals befährt auch diese Fahrt korrekt annoncieren, wird immer die Folgefahrt der jeweils aktuellen Fahrt mit aktualisiert. Angenommen, der Zug hätte auf dem Weg von C-A sieben Minuten Verspätung eingefangen und am Punkt A nur vier Minuten Wendezeit, dann würde diese Verspätung von drei Minuten auf die Fahrt von A-B umgelegt und entsprechend an den DFI-Anzeigern bzw. auch an der Schnittstelle annonciert werden. Hätte man also am 42er an der Hst. Michelbeuern-AKH immer die nächsten drei Abfahrten angezeigt, wären nur zwei davon mit "Echtzeit" und die dritte würde als Planfahrt dargestellt werden, weil die vorhergehende Fahrt noch nicht mal angetreten wurde.
-
Danke für die Erklärung, Tatra! Heißt das also, für das RBL beginnt eine "Fahrt" an einer Endstation und endet einfach an der anderen? Dass die Fahrzeuge tatsächlich ständig einfach im Kreis fahren und man deswegen für jeden Kurs (und dem dazugehörigen Fahrzeug) quasi einen Zyklus annehmen kann, davon geht das RBL also nicht aus? Sprich, das RBL könnte mir nicht sagen, wo Wagen XY in zwei Stunden sein wird, weil für das RBL einzig und allein zählt, wo derzeit der Wagen hinfährt und maximal noch das Fahrziel danach? Oder habe ich jetzt etwas falsch verstanden?
-
Beim 72er ist nicht einmal das aktiviert – da wird der Wagen erst sichtbar, wenn er die Endstation verlassen hat. (Sehr brauchbar, wenn man in Simmering U bei der Haltestelle steht, ewig kein 6er und kein 71er kommen und der ohnehin in wenigen Minuten verfügbare 72er (sie fahren ja nach Plan, auch wenn sie so tun, als täten sie es nicht) dadurch verheimlicht wird.
-
Heißt das also, für das RBL beginnt eine "Fahrt" an einer Endstation und endet einfach an der anderen?
Ja, eine RBL-Fahrt geht (nach dem obigen Beispiel) von A nach B, von B nach A usw. usf. Alles zusammen ist dann ein Umlauf.
Dass die Fahrzeuge tatsächlich ständig einfach im Kreis fahren und man deswegen für jeden Kurs (und dem dazugehörigen Fahrzeug) quasi einen Zyklus annehmen kann, davon geht das RBL also nicht aus? Sprich, das RBL könnte mir nicht sagen, wo Wagen XY in zwei Stunden sein wird, weil für das RBL einzig und allein zählt, wo derzeit der Wagen hinfährt und maximal noch das Fahrziel danach? Oder habe ich jetzt etwas falsch verstanden?
Wie schon erwähnt, das RBL verfügt über den gesamten Umlauf- und Fahrplan eines Betriebstages. Nehmen wir wieder das Beispiel des 42ers, da ist dem RBL bekannt, welche Fahrtfolge der Umlauf 142/1 absolvieren wird, also einmal morgens vom Hof zur Antonigasse und dann das Ringelspiel bis zum Abend, wenn er wieder in GTL einzieht. Wo Wagen XY in zwei Stunden sein wird, ist dem RBL indirekt bekannt, denn es weiß, wo der Umlauf (je nach Betriebs-Slang Kurs) 142/1 in zwei Stunden sein soll. Für das RBL ist aus betrieblicher Sicht nur wichtig, welche Fahrt jetzt und als nächstes von einem Umlauf durchgeführt wird, dafür wird die aktuelle Fahrplanlage erfasst sowie die entsprechende Fahrplanlage der Folgefahrt aktualisiert (allerdings mit einer gewissen Unschärfe => Hysterese).
Dadurch, dass in Wien anhand des Fahrzeugeinsatz auch die Information NF/HF über das RBL an die DFI weitergereicht wird und nur die nächste Folgefahrt berücksichtigt wird, hast du bei der zweiten Folgefahrt keine aktuelle Information zu NF/HF. Mir ist nicht bekannt, inwiefern das NF-Merkmal einer Fahrt des täglichen RBL-Soll-Fahrplans verwendet wird. Daher meine Frage, ob alle Fahrten ab der zweiten Folgefahrt als HF geliefert werden?
-
Nehmen wir wieder das Beispiel des 42ers, da ist dem RBL bekannt, welche Fahrtfolge der Umlauf 142/1 absolvieren wird, also einmal morgens vom Hof zur Antonigasse und dann das Ringelspiel bis zum Abend, wenn er wieder in GTL einzieht. Wo Wagen XY in zwei Stunden sein wird, ist dem RBL indirekt bekannt, denn es weiß, wo der Umlauf (je nach Betriebs-Slang Kurs) 142/1 in zwei Stunden sein soll.
Ok, so ähnlich hab' ich es mir schon gedacht. Sehr interessant auf jeden Fall.
Mir ist nicht bekannt, inwiefern das NF-Merkmal einer Fahrt des täglichen RBL-Soll-Fahrplans verwendet wird. Daher meine Frage, ob alle Fahrten ab der zweiten Folgefahrt als HF geliefert werden?
Anscheinend, ja. Zur Verdeutlichung hab ich ein paar Bilder von qando zu entsprechenden Zeiten gemacht.
Abfahrten ab Antonigasse, bevor der nächste Niederflurkurs das Schottentor erreicht:
[attach=1]
Abfahrten ab Antonigasse, nachdem der Niederflurkurs vom Schottentor abgefahren ist (man vergleiche die dritte Abfahrt mit der im ersten Bild):
[attach=2]
Ein ähnliches Bild gibt es derweil am Schottentor. Der Kurs der derzeit bei der Antonigasse steht (und wie oben angegeben in 5 Minuten abfahren wird), wird hier (als dritte Abfahrt) natürlich richtig als Niederflur ausgezeichnet, hingegen der folgende Niederflurkurs (der der gerade vom Schottentor abgefahren ist - also der Wagen, der hier wieder in 35 Minuten abfahren soll) wird nicht als solcher angezeigt:
[attach=3]
Und danke nochmals an dich, Tatra, für deine ausführliche Erklärung! :)
-
Und so ist das natürlich größtmöglicher Schwachsinn, denn hier wird eine Realität vorgegaukelt, die nicht existiert. Wenn die Daten nicht vollständig gesammelt und bereitgestellt werden können, hat der Kurs nicht als Echtzeit angegeben zu werden.
-
Wenn die Daten nicht vollständig gesammelt und bereitgestellt werden können, hat der Kurs nicht als Echtzeit angegeben zu werden.
Ganz deiner Meinung! :up:
Und wenn ich mich nicht täusche, war dem auch so bevor die neue Schnittstelle online gegangen ist. Damals wurden auch Ausrücker, die noch nicht vom RBL erfasst wurden, als Planzeiten angezeigt, was heute, soweit ich bisher sehen konnte, auch nicht mehr der Fall ist.
-
Es gab früher genügend andere Unstimmigkeiten (wie jetzt auch), aber zumindest gab es keine Inkonsistenzen, dass ein Niederflurzug plötzlich zum Hochflurer mutiert oder vice versa.
-
Und wenn ich mich nicht täusche, war dem auch so bevor die neue Schnittstelle online gegangen ist. Damals wurden auch Ausrücker, die noch nicht vom RBL erfasst wurden, als Planzeiten angezeigt, was heute, soweit ich bisher sehen konnte, auch nicht mehr der Fall ist.
Doch, das ist an den DFI-Anzeigen noch immer so und daher vermute ich, dass das Echtzeit-Faken für alle Abfahrten innerhalb der nächsten 60 Minuten im Qando/itip-Backend geschieht.
-
Doch, das ist an den DFI-Anzeigen noch immer so und daher vermute ich, dass das Echtzeit-Faken für alle Abfahrten innerhalb der nächsten 60 Minuten im Qando/itip-Backend geschieht.
Von den DFI-Anzeiger hab' ich nicht gesprochen (die liegen in der Architektur ja offensichtlich grundsätzlich näher am RBL(-Datenbestand) wie qando & co). Ich hab mich hier mit "früher" nur auf die Verkehrsdaten bezogen, die über die alten qando-Schnittstellen kamen. Aber du hast schon recht. Ich vermute das auch.
-
Ich hab mich hier mit "früher" nur auf die Verkehrsdaten bezogen, die über die alten qando-Schnittstellen kamen.
Ah, sorry, das habe ich so nicht in Zusammenhang gebracht.
Dieses Feature mit der Folgefahrt hat in Betrieben, die ausschließlich Echtzeit anzeigen, wirkliche Konsequenzen. Angenommen, es werden zwei kurze Linien mit einer Umlaufkopplung mit nur einem Fahrzeug betrieben. Beide Linien haben eine gemeinsame Endstation, wo das Fahrzeug automatisch die Linie wechselt. Da kann es eben sein, dass die Fahrt der Linie B noch nicht angezeigt wird, weil das Fahrzeug grad als Linie A weggefahren ist (es ist also nur die Rückfahrt aktuell als Echtzeitfahrt bekannt). Wenn das Fahrzeug dann an der Endstelle der A ankommt und die Folgefahrt quittiert, erscheint die Abfahrt der Linie B am Anzeiger.
-
Heute wurde nun auch die Routing-API freigegeben: http://derstandard.at/1379292699520/Wiener-Linien-stellen-Routing-Daten-zur-Verfuegung (http://derstandard.at/1379292699520/Wiener-Linien-stellen-Routing-Daten-zur-Verfuegung)
-
Das Modell ist identisch mit LinzLinien, die Dokus sind ähnlich: http://data.wien.gv.at/pdf/wiener-linien-routing.pdf (http://data.wien.gv.at/pdf/wiener-linien-routing.pdf)
-
Ist das bei euch auch so, dass seit heute keine Störungsmeldungen mehr mit den Echtzeitdaten mitgeschickt werden? Über die alte Qando-API bekomme ich sie noch, aber nicht über die OGD.
-
Ist das bei euch auch so, dass seit heute keine Störungsmeldungen mehr mit den Echtzeitdaten mitgeschickt werden? Über die alte Qando-API bekomme ich sie noch, aber nicht über die OGD.
Ob man sie bekommt, wenn man Daten zu einzelnen Haltestellen abruft, hab ich nicht überprüft; über "trafficInfoList" bekomme ich sie noch. Die letzte Meldung ist ein Falschparker am 5er ab heute 18:32: https://rueckgr.at/wienerlinien/disruptions/?id=7549
-
Bei mir kommen definitiv keine Störungen mehr über OGD an. Hab ich grad noch mal ausprobiert, eigentlich sollte die Störung vom 1er grad offen sein. Ich habe selbst überhaupt nichts an der Konfiguration oder am Programm geändert. Mehr als seltsam...
-
Heute funktioniert's übrigens auf einmal wieder, obwohl ich nichts geändert habe... :)
-
Heute funktioniert's übrigens auf einmal wieder, obwohl ich nichts geändert habe... :)
Das ist der iterative Problemlösungszugang der Wiener Linien! Moch' ma amoi goa nix, vielleicht geht's eh von sööba wieder weg. :up:
-
Heute funktioniert's übrigens auf einmal wieder, obwohl ich nichts geändert habe... :)
"Schauen wir mal, wie der 13er reagiert, wenn wir ihm den Zugang zu den Störungsinfos abdrehen..."
-
Heute funktioniert's übrigens auf einmal wieder, obwohl ich nichts geändert habe... :)
"Schauen wir mal, wie der 13er reagiert, wenn wir ihm den Zugang zu den Störungsinfos abdrehen..."
"Er ärgert uns ständig, jetzt zahlen wirs ihm heim".
-
Ich glaub ja eher..: Di zaumgschuastate Wäbseitn zagt des bessa au, ois unsa teires Programm... DRAHT'S DES OOOH! Des deaf kana segn! 8)
-
Falls es jemanden interessiert: Seit einiger Zeit kommen in den Störungsmeldungen immer wieder RBL-Nummern vor, die im Haltepunkte-CSV nicht aufscheinen; im Konkreten hab ich mittlerweile herausgefunden:
- 320 - Friedrich Engels-Platz (Schleife 2/33) - neu hinzugekommen
- 341 - Laxenburger Straße, Gudrunstraße (FR Raxstraße, Rudolfshügelgasse) - liefert dieselben Daten wie 342, aber zusätzlich Einziehfahrten in den Bahnhof Favoriten
- 1000 - keine Ahnung
- 2181 - Edmund Hawranek-Platz - statt 5726
- 2182 - Rußbergstraße (FR Hausfeldstraße) - statt 3123
- 3183 - Ziegelhofstraße/Oberfeldgasse (FR Strebersdorf) - statt 3185, was Süßenbrunner Straße/Oberfeldgasse ist
- 3197 - Ziegelhofstraße/Oberfeldgasse (FR Hausfeldstraße) - statt 3193, was Süßenbrunner Straße/Oberfeldgasse ist
- 3998 - keine Ahnung
Ich hab mal wieder an die E-Mail-Hotline geschrieben, dass sie den Krempel gefälligst aktualisieren sollen. Wird wohl eine Weile dauern.
-
Falls es jemanden interessiert: Seit einiger Zeit kommen in den Störungsmeldungen immer wieder RBL-Nummern vor, die im Haltepunkte-CSV nicht aufscheinen; im Konkreten hab ich mittlerweile herausgefunden:
- 320 - Friedrich Engels-Platz (Schleife 2/33) - neu hinzugekommen
- 341 - Laxenburger Straße, Gudrunstraße (FR Raxstraße, Rudolfshügelgasse) - liefert dieselben Daten wie 342, aber zusätzlich Einziehfahrten in den Bahnhof Favoriten
- 1000 - keine Ahnung
- 2181 - Edmund Hawranek-Platz - statt 5726
- 2182 - Rußbergstraße (FR Hausfeldstraße) - statt 3123
- 3183 - Ziegelhofstraße/Oberfeldgasse (FR Strebersdorf) - statt 3185, was Süßenbrunner Straße/Oberfeldgasse ist
- 3197 - Ziegelhofstraße/Oberfeldgasse (FR Hausfeldstraße) - statt 3193, was Süßenbrunner Straße/Oberfeldgasse ist
- 3998 - keine Ahnung
Ich hab mal wieder an die E-Mail-Hotline geschrieben, dass sie den Krempel gefälligst aktualisieren sollen. Wird wohl eine Weile dauern.
1000 = VRT-Hst Schwedenplatz
3998 = Keine Ahnung, ist in der Haltestellendatenbank nicht enthalten. Bei welcher Linie/Örtlichkeit ist sie den eingetragen?
-
1000 = VRT-Hst Schwedenplatz
Hm. Wenn der 2er eine Störung hat, ergibt das Sinn. Aber nicht, wenn die U4 wegen eines Rettungseinsatzes nur zwischen Heiligenstadt und Hietzing fährt.
3998 = Keine Ahnung, ist in der Haltestellendatenbank nicht enthalten. Bei welcher Linie/Örtlichkeit ist sie den eingetragen?
Bei einer Störung am 24A.
-
Bei einer Störung am 24A.
Vielleicht eine der glorreichen neuen Stationsnamen, die man versehntlich nicht der alten Station zugeordnet hat ;)
-
Derzeit kann man wunderschöne Java-Stacktraces an der Echtzeitschnittstelle bewundern.
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Could not open connection
...
javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Could not open connection
...
org.hibernate.exception.GenericJDBCException: Could not open connection
...
org.postgresql.util.PSQLException: FATAL: tut mir leid, schon zu viele Verbindungen
...
Apache Tomcat/7.0.35
Immerhin weiß ich jetzt, was da so an Software läuft.
-
Ja, jetzt am Abend ist alles down... aber auch schon seit einiger Zeit (ein paar Wochen) ist das Service schlechter geworden und liefert immer wieder fehlgeschlagene Anfragen. Schade, entwickelt sich offenbar in Richtung Qando-API, kommt mit den vielen Anfragen nicht mehr klar.
-
Von wegen "am Abend"... bis 08:55 hat's gedauert, bis das wer repariert hat.
-
Von wegen "am Abend"... bis 08:55 hat's gedauert, bis das wer repariert hat.
Und wie schon vor einiger Zeit kommen auch heute keine Störungsmeldungen mehr über OGD raus, sondern nur über Qando. Ich habe den Verdacht, da müsste nach einem Absturz jemand händisch den neuen Server rebooten und vergisst drauf...
-
Gerade einmal zwei Monate hat das OGD-Service ziemlich gut funktioniert, jetzt gibt es schon fast täglich schwere Störungen. Zum Beispiel war es gestern seit Nachmittag bis heute in der Früh wieder komplett unerreichbar. Schade.
-
Sie wissen halt, dass ihnen keiner auf die Finger schaut (geschweige denn klopft), also kümmern sie sich mit dem üblichen betriebseigenen Schlendrian drum. Za wos brauch ma des, de Leit soin froh sein, doss ma überhaupt foahrn.
-
Alle paar Tage Komplettausfall des Echtzeitdatenservices. Heute wieder. Eigentlich inakzeptabel, so eine Unzuverlässigkeit. Aber tun kann man eh nix dagegen. Vielleicht auch absichtlich, denn Qando funktioniert. So kann man die Leute auch davon abbringen, Auskunfts-Apps von Drittanbietern zu installieren...
-
Ist das nur bei mir so oder bekommt man - im Gegensatz zu Früher - über die Echtzeitschnittstelle nur noch die nächsten zwei Abfahrten je Haltepunkt? Das war doch einmal (weniger restriktiv) beschränkt auf alle Abfahrten in der nächsten Stunde oder?
-
Ist das nur bei mir so oder bekommt man - im Gegensatz zu Früher - über die Echtzeitschnittstelle nur noch die nächsten zwei Abfahrten je Haltepunkt? Das war doch einmal (weniger restriktiv) beschränkt auf alle Abfahrten in der nächsten Stunde oder?
Ja, früher waren's mehr. Im iTip ist es gefühlsmäßig auch deutlich weniger geworden. Da steht sehr schnell ein "?" o.ä. bei der Fahrt.
Statt potente Server zu kaufen werden eben einfach die Abfragemengen reduziert :) Bin aber ehrlich gesagt schon froh, dass es überhaupt wieder halbwegs funktioniert. Von normaler Verfügbarkeit kann man zwar noch lange nicht sprechen, aber es bessert sich in den letzten Tagen.
-
Statt potente Server zu kaufen werden eben einfach die Abfragemengen reduziert :)
Naja, ob da jetzt 2 oder 10 Abfahrten je Abfrage rausgeschossen werden, sollte eigentlich nicht der große Beinbruch für den Server sein - egal wie stark oder schwach er ist. Da scheint mir grundsätzlich ungenügende serverseitige Bandbreite eher plausibler - wenn auch genauso unwahrscheinlich. Ich vermute eher absichtliche Verschlechterung der Echtzeitschnittstelle, was ich aber gut nachvollziehen kann - wie ich dazu stehe, lass' ich jetzt mal getrost beiseite. ;)
Aber danke für deine Info.. Ich hab mir schon gedacht, ich hab' mir nur eingebildet, dass früher mehr gekommen ist. :D :P
-
Ich bestätige: Früher wurden Daten über die Fahrten in den nächsten 70 Minuten oder so geliefert. Jetzt sieht man nur noch die nächsten zwei.
Toller Service, muss man schon sagen.
EDIT: Man sieht zwar nur mehr die nächsten zwei Fahrten, diese dafür weiter in die Zukunft. Am Südtiroler Platz sieht man derzeit beispielsweise, dass in 16 und 132 Minuten Einzieher vom D-Wagen zum Bahnhof Favoriten fahren werden und in 29 und 153 Minuten Einzieher vom 18er. Analog fahren in 166 und 196 Minuten Busse des N66 Richtung Stadt und in 201 und 231 Minuten in die andere Richtung.
-
Toller Service, muss man schon sagen.
Es hot uns jo kana angschafft, daß mas gscheit machen solln.
-
Toller Service, muss man schon sagen.
Es hot uns jo kana angschafft, daß mas gscheit machen solln.
Ich würd's den Zuständigen ja anschaffen, ich fürchte aber, die werden mir nicht zuhören. :(
-
Eigentlich müßte man ein Hacker-Team auf den WL-IT-Sauhaufen ansetzen – wenn die ihnen einmal das System nachhaltig niederreißen würden, müßte die Amateurtruppe schon gute Ausreden haben, daß man sie nicht durch fähige Leute ersetzt.
-
Eigentlich müßte man ein Hacker-Team auf den WL-IT-Sauhaufen ansetzen – wenn die ihnen einmal das System nachhaltig niederreißen würden, müßte die Amateurtruppe schon gute Ausreden haben, daß man sie nicht durch fähige Leute ersetzt.
Nun, nicht immer sitzen die Schuldigen bei den Wiener Linien: http://www.wienit.at/eportal/ep/programView.do/pageTypeId/9595/programId/9710/channelId/-15050 (http://www.wienit.at/eportal/ep/programView.do/pageTypeId/9595/programId/9710/channelId/-15050)
-
Das zeigt nur, daß die dort auch lauter Tüftler haben, anstatt Fachleute. ;)
Also: Wiener Stadtwerke :ugvm:
-
Eigentlich müßte man ein Hacker-Team auf den WL-IT-Sauhaufen ansetzen – wenn die ihnen einmal das System nachhaltig niederreißen würden, müßte die Amateurtruppe schon gute Ausreden haben, daß man sie nicht durch fähige Leute ersetzt.
1. Auch Hacker haben ihren Stolz und machen nicht alles mit. :P
2. Das System niederzureißen schaffen die doch regelmäßig selbst, da brauchts garkeine externe "Hilfe" - okay, die U-Bahn-Störung heute hat schon "geholfen".
-
Hacken dürfte jedenfalls null Problem sein. Die verwenden ohnehin einen uralten Apache mit vielen bekannten Securityproblemen. Nur meine Ethik hindert mich daran, sie aufzumachen 8)
-
Hacker könnten das System keinesfalls zerstören, allerhöchstens ungewollt reparieren 8)
-
Hacken dürfte jedenfalls null Problem sein. Die verwenden ohnehin einen uralten Apache mit vielen bekannten Securityproblemen. Nur meine Ethik hindert mich daran, sie aufzumachen 8)
Kannst ja was harmloses machen, die Homepage ersetzen durch:
"Straßenbahnlinie 13 bauen, JETZT! Gezeichnet: The Army of the 13 Monkeys". :D
-
Anscheinend hat sich wieder was an der OGD-Schnittstelle getan (vielleicht liest man ja mit ;) ): Es werden wieder pro Haltepunkt und Linie wieder alle Abfahrten in der nächsten Stunde (sogar etwas mehr - ich denke 70 Minuten) geliefert.
-
Folgende Konversation von der Dr.-Richard-Facebookseite wurde mir zugespielt:
[attach=1]
Wenn also Dr. Richard Echtzeitdaten hat, warum verlangen die WL selbige nicht? Oder muss man sie erst mit der Nase drauf stoßen, dass sie selber gefprdert haben, dass die neuen Richard-Gummistinker mit Echtzeitdatenmodul ausgerüstet sein müssen? :ugvm:
-
Liebe Frau Marliot!
Nachdem der 93A ein Intervall von 15 Minuten hat, handelt es sich nicht um eine Verspätung, der Bus ist selbstverständlich pünktlich abgefahren. Eine Anzeige der Echtzeitdaten ist somit nicht notwendig. Wir hoffen sie weiterhin zu unseren zufriedenen Fahrgästen zählen zu dürfen.
Wiener Linien – Kundendienst.
-
Wenn also Dr. Richard Echtzeitdaten hat, warum verlangen die WL selbige nicht? Oder muss man sie erst mit der Nase drauf stoßen, dass sie selber gefprdert haben, dass die neuen Richard-Gummistinker mit Echtzeitdatenmodul ausgerüstet sein müssen? :ugvm:
Die Wiener Linien wollen die Daten der Auftragslinien gar nicht, weil sie vermutlich Angst haben, dass ihre von Tüflern betriebenen Server dann noch häufiger zusammenbrechen, als sie es jetzt schon tun.
-
Was erwartet ihr von einem Unternehmen, das auf alle Busse absichtlich nur "Ersatzverkehr" draufschreiben lässt, obwohl die Busse die echten Ziele anzeigen könnten?
-
Man könnte ja den Dr. Richard fragen, ob man seine Daten in einer App verarbeiten darf.
-
Was erwartet ihr von einem Unternehmen, das auf alle Busse absichtlich nur "Ersatzverkehr" draufschreiben lässt, obwohl die Busse die echten Ziele anzeigen könnten?
Richtig – was erwartet man von einem Unternehmen, das von seinen Auftragnehmern Fahrzeuge mit Plastikpritschen mit ultradünner Stoffauflage verlangt, obwohl die Auftragnehmer freiwillig bequemere, gepolsterte Stoffsitze verwenden würden?
-
Die Busse dürfen halt nicht bequemer sein, als die Wiener-Linien-eigenen. Deswegen die gleichen steinharten Sitze, kein RBL und die Schneiderin darf die Haltestellen exklusiv nur für die Wiener Linien ansagen, nicht aber für einen Auftragnehmer - wobei letzteres aber eh kein großer Verlust ist. ::)
-
Steht eh alles in dem einen Satz: Dr. Richard richtet sich nach den Vorgaben der WL, also ist der "Zustand" ja erklärbar. 8-)
-
Folgende Konversation von der Dr.-Richard-Facebookseite wurde mir zugespielt:
...
Wenn also Dr. Richard Echtzeitdaten hat, warum verlangen die WL selbige nicht? Oder muss man sie erst mit der Nase drauf stoßen, dass sie selber gefprdert haben, dass die neuen Richard-Gummistinker mit Echtzeitdatenmodul ausgerüstet sein müssen? :ugvm:
Gschwindl hat z.B. alle nötigen Vorbereitungen im Bus, müsste nur von den WL eingebunden werden. :ugvm:
-
Was heißt "Vorbereitungen"? Produzieren die Fahrzeuge Echtzeitdaten oder besitzen sie bloß die dafür notwendige Schnittstelle, aber keine eigentlichen Gerätschaften?
-
So viel ich weiß nur die Schnittstelle. Wäre aber auch kein Problem - baut man bei Beginn der Übernahme die Geräte in die Fahrzeuge ein und wenn der Vertrag ausläuft werden sie wieder ausgebaut und in die neuen Fahrzeuge eingebaut. Kann ja wohl kaum so viel arbeiten sein, oder?
-
Und wer zahlt die Geräte? 8)
-
Man könnte ja die aus den alten Bussen (oder Bims falls kompatibel?) nehmen - das wäre ja schon ein Anfang! Laut Gschwindl dürften von den WL aus nur eigene Geräte verwendet werden. Wie könnte man denn auch andere nehmen? :bh:
-
Und wer zahlt die Geräte? 8)
Wäre bei Verwendung von GPS kein großer Aufwand!
Aber GPS-Ortung funktioniert in Wien ja leider nicht. Sonst würden das die WiLi schon längst verwenden :'(
-
Aber GPS-Ortung funktioniert in Wien ja leider nicht. Sonst würden das die WiLi schon längst verwenden :'(
Sie bauen doch das RBL eh ständig aus, bis sie daraus ein eigenes GPS entwickelt haben. Glaub mir, in ca. 500 Jahren ist es serienreif. Und was sind schon 500 Jahre für ein Verkehrsunternehmen mit Erfahrung aus zwei Jahrtausenden? :))
-
Sie bauen doch das RBL eh ständig aus, bis sie daraus ein eigenes GPS entwickelt haben. Glaub mir, in ca. 500 Jahren ist es serienreif. Und was sind schon 500 Jahre für ein Verkehrsunternehmen mit Erfahrung aus zwei Jahrtausenden? :))
500 Jahre halte ich für sehr optimistisch, schließlich müssen sie zur Entwicklung eines eigenen GPS vorab noch die Raketentechnik ertüfteln (nicht zu vergessen den Bau von Atomuhren und die Entdeckung der Relativitätstheorie). 8)
-
GPS möchten die WL nicht einsetzen, weil was ist, wenn die USA wegen eines Krieges das Signal verschlechtern? So gehört vor ein paar Jahren von einem hochrangigen Mitarbeiter als Erklärung ;)
-
500 Jahre halte ich für sehr optimistisch, schließlich müssen sie zur Entwicklung eines eigenen GPS vorab noch die Raketentechnik ertüfteln (nicht zu vergessen den Bau von Atomuhren und die Entdeckung der Relativitätstheorie). 8)
Erinnert an den Spieleklassiker CIV.
Die Wiener Linien haben soeben das Schießpulver erfunden, während die Franzosen bereits mit Panzern und Atombomben angreifen. Bis die veralteten Phalanxen jedoch durch die neu vergügbaren Musketiere ersetzt werden, dauert's noch ein paar Spielrunden.
Außerdem arbeitet die Hauptstadt Erdberg soeben am Bau eines Weltwunders, was die gesamte Wirtschafsleistung des Imperiums bindet.
:D
-
Auch in der Realität haben wir schon einmal wegen veralteter Waffen verloren, das ist in Österreich nix Neues ;)
-
Jetzt wissens alle:
Seit die Wiener Linien ihre Echtzeit-Daten freigeben, gibt es erstmals auch eine öffentlich Störungsstatistik. 304 schadhafte Fahrzeuge (im Schnitt eines pro Tag), 19 Gleisschäden, 33 Oberleitungsgebrechen, 166 Polizeieinsätze in Stationen oder Fahrzeugen und 304 Falschparker bzw. andere außerplanmäßige Vorfälle verursachten seit September 2013 insgesamt 6.338 Störungen bei Bim, Bus und U-Bahn. Für Frust bei den Fahrgästen sorgten auch 936 Verkehrsunfälle und 16 Demos (Infobox).
Ausgebremst
"Unsere 516 Straßenbahnen, 470 Busse und 155 U-Bahnen fahren zusammen täglich eine Strecke, die vier Weltumrundungen entspricht", sagt Wiener- Linien-Sprecher Dominik Gries. "Bei der Menge an Fahrzeugen und gefahrenen Kilometern kann es schon die eine oder andere Panne geben", erklärt er. In der Statistik erfasst werden nur Pannen, die Auswirkungen auf den Fahrbetrieb und auf die Fahrgäste haben.
Sicherheit geht vor
"Wir sind sehr auf Sicherheit bedacht. Wenn irgendwo ein Kontrolllämpchen aufgeht, gehen wir der Sache nach", sagt Gries. (ber)
Pleiten, Pech und Öffi-Pannen
Schadhafte Fahrzeuge 304 Gleisschäden 19 Weichenschäden 1 Feuerwehr &Rettungseinsätze 506 Polizeieinsätze 166 Falschparker 304 Verkehrsunfälle 936 Demonstrationen 16 Fahrleitungsgebrechen 33 Verspätungen 3.529 Sonstige Störungen 474 GESAMT 6.338
Quelle (http://www.österreich.at/nachrichten/Wiener-Linien-Jeden-Tag-geht-ein-Fahrzeug-ein/144857857)
Fantastillionen an Badewannen ...
-
Quelle (http://www.österreich.at/nachrichten/Wiener-Linien-Jeden-Tag-geht-ein-Fahrzeug-ein/144857857)
Und die haben als Quelle vermutlich f59.at ;)
-
304 schadhafte Fahrzeuge (im Schnitt eines pro Tag),
Finde ich ehrlich gesagt nicht so schlimm. Bei insgesamt 1104 Fahrzeugen im Fuhrpark ist das eine Zuverlässigkeit von etwa 99,9 %. Zieht man 20 % Reserve ab, die nicht unterwegs ist, kommt man immer noch auf etwa 99,8 % Zuverlässigkeit.
Interessant wären die Zahlen aufgeschlüsselt nach Verkehrsträger (Bim, Bus, U-Bahn). Auch verlässliche Zahlen zum ULF-Einsatz (durchschnittliche Wartezeit auf Niederflur) wären interessant.
-
Und die haben als Quelle vermutlich f59.at ;)
No na! ;)
Interessant wären die Zahlen aufgeschlüsselt nach Verkehrsträger (Bim, Bus, U-Bahn). Auch verlässliche Zahlen zum ULF-Einsatz (durchschnittliche Wartezeit auf Niederflur) wären interessant.
DAS werden sie sich nicht freizugeben trauen.
-
Interessant wären die Zahlen aufgeschlüsselt nach Verkehrsträger (Bim, Bus, U-Bahn). Auch verlässliche Zahlen zum ULF-Einsatz (durchschnittliche Wartezeit auf Niederflur) wären interessant.
DAS werden sie sich nicht freizugeben trauen.
Nachdem es ja freigegebene Daten sind, könnte ja jemand anders diese Statistiken erstellen ;)
-
Wollte nur sagen, dass die freigegeben Daten mit Sicherheit gefiltert sind.
-
Wollte nur sagen, dass die freigegeben Daten mit Sicherheit gefiltert sind.
Es sind in Wirklichkeit um einiges mehr. Die meisten schadhaften Züge werden ja gar nicht in die Schnittstelle eingetragen. Es sind so im Schnitt drei bis fünf Züge pro Tag schadhaft, würd ich jetzt mal über die letzten paar Monate grob schätzen.
Die Anzahl der Gleisschäden ist auch deutlich höher.
Und das sind sicher die Zahlen von f59, das passt genau zusammen :up: Gut, dass darauf jemand aufmerksam wird!
-
Wollte nur sagen, dass die freigegeben Daten mit Sicherheit gefiltert sind.
Es sind in Wirklichkeit um einiges mehr. Die meisten schadhaften Züge werden ja gar nicht in die Schnittstelle eingetragen. Es sind so im Schnitt drei bis fünf Züge pro Tag schadhaft, würd ich jetzt mal über die letzten paar Monate grob schätzen.
Da gebe ich euch vollkommen recht. Ich verrate nicht wie ivele schadhafte Züge wir wirklich habe. Ich sage nur soviel. Ein JEDES Verkehrsunternehmen in der Größenordnung der WL wäre froh, wenn er NUR EIN schadhaftes Fahrzeug pro Tag hat. Mich würden Vergleichszahlen aus anderen Städten, wie München, oder Zürich interessieren.
-
Da gebe ich euch vollkommen recht. Ich verrate nicht wie ivele schadhafte Züge wir wirklich habe. Ich sage nur soviel. Ein JEDES Verkehrsunternehmen in der Größenordnung der WL wäre froh, wenn er NUR EIN schadhaftes Fahrzeug pro Tag hat. Mich würden Vergleichszahlen aus anderen Städten, wie München, oder Zürich interessieren.
Ob diese anderen Unternehmen wohl ehrlicher sein werden als die WL?
-
Die W.L. halten keinen Vergleich mit der MVG in München aus, was die Fuhrparkunterhaltung angeht! In Polen oder Kroatien sind die Straßenbahnwagen ebenfalls in einem besseren Lack- und Erhaltungszustand. Die E2 und c5 sollen noch bis 2025 eingesetzt werden, aufgrund der Lack- und Korrosionsschäden etlicher E2 und c5 würde man eher glauben, dass eine Ausmusterung und Verschrottung unmittelbar bevorsteht.
nord22
-
Die E2 und c5 sollen noch bis 2025 eingesetzt werden, . . .
Eher bis 2030, unter Umständen auch noch ein wenig darüber hinaus.
-
Die E2 und c5 sollen noch bis 2025 eingesetzt werden, . . .
Eher bis 2030, unter Umständen auch noch ein wenig darüber hinaus.
Dann ist der E2 auch im Club der 50er angelangt, gemeinsam mit so Legenden wie G, K, M und c3. Traurig irgendwie! :(
-
Ob diese anderen Unternehmen wohl ehrlicher sein werden als die WL?
Ich habe schon in einigen Betrieben mit den Verantwortlichen gesprochen und Werkstätten besucht und ich habe schon das Gefühl, dass in diesen mehr Wert auf Wartung gelegt wird. Natürlich wächst auch dort das Geld nicht auf den Bäumen, aber zum Unterschied von uns gibt es dort einen Verkehrsdienstleistungsvertrag, der seinen Namen wert ist, und da kostet jede ausgefallene Fahrt. Außerdem ist dort der Druck von der Politik höher, wenn es auffallend viele Schäden gibt. Bei uns ist das ja alles wurscht, außer es ist kurz vorm Zusammenbrechen wie bei der U4, dann tut man eben notgedrungen doch was (aber nicht, weil man selbst will, sondern weil man von den Medien dazu gezwungen wird).
-
Ob diese anderen Unternehmen wohl ehrlicher sein werden als die WL?
Ich habe schon in einigen Betrieben mit den Verantwortlichen gesprochen ...
Und so fängts ja auch an. Als "Normalo" kannst du im Ausland einfach mit "Verantwortlichen im Betrieb" sprechen... probier das mal in Wien!
-
Und so fängts ja auch an. Als "Normalo" kannst du im Ausland einfach mit "Verantwortlichen im Betrieb" sprechen... probier das mal in Wien!
Ausse do! Des is Privatgrund! Und überhaupt! Dienstgeheimnis!!!
-
Und so fängts ja auch an. Als "Normalo" kannst du im Ausland einfach mit "Verantwortlichen im Betrieb" sprechen... probier das mal in Wien!
Ausse do! Des is Privatgrund! Und überhaupt! Dienstgeheimnis!!!
Soweit kommts noch, dass sich irgendwer dafür begeistern darf, was ich so mache. Was die Leute zu interessieren hat, sag ich (bzw. die PR-Abteilung).
Man stelle sich vor: Als Kind habe ich öfter in irgendwelchen Betrieben, wo ich zufällig mit den Eltern war (Autowerkstatt, Buchbinder, Tischlerei usw.), gefragt, ob ich ein Bisschen zuschauen darf. Alle waren begeistert, dass sich jemand für ihre Arbeit interessiert. Man hat mir alles gezeigt, erklärt, manchmal habe ich sogar selbst irgendwas (unproblematisches) machen dürfen. Die beste Art und Weise, Nachwuchs für den eigenen Beruf zu werben... Stattdessen arbeitet man lieber mit Sklaven, die man vom AMS gefördert bekommt. Wenn die aufhören, ist es egal, weil wo die herkommen, gibts noch mehr :down:
-
Ich verrate nicht wie ivele schadhafte Züge wir wirklich habe.
Bei der Straßenbahn sind es täglich durchschnittlich 10 und über alle Betriebszweige (Straßenbahn, U-Bahn, Bus) summiert täglich durchschnittlich über 40. Die führen nicht alle zum Ausfall von Fahrten, aber Schaden ist Schaden.
-
Achja: irgendwie gibt es auf f59.at (http://f59.at/stoerungen/index_now.php) wiedermal einen Überhang an nicht beendeten Störungen - wäre es möglich, die manuell zu beenden?
Außerdem würde ich gerne anregen, dass vielleicht auch eine eigene Seite für die Störungen der letzten Woche oder des letzten Monats angelegt wird, weil mittlerweile ist die Liste aller Störungen - auch ohne Verspätungsmeldungen - schon sehr lang.
-
Achja: irgendwie gibt es auf f59.at (http://f59.at/stoerungen/index_now.php) wiedermal einen Überhang an nicht beendeten Störungen - wäre es möglich, die manuell zu beenden?
Danke für den Hinweis, wir schauen uns das an ;) Nein, ist natürlich schon behoben. Ich weiß leider auch nicht, wo die Leichen herkommen. Da hängt wohl hie und da irgendwas, kann aber auch an meinem Programm liegen.
Außerdem würde ich gerne anregen, dass vielleicht auch eine eigene Seite für die Störungen der letzten Woche oder des letzten Monats angelegt wird, weil mittlerweile ist die Liste aller Störungen - auch ohne Verspätungsmeldungen - schon sehr lang.
Es gibt jetzt einen zusätzlichen Menüpunkt, wo man nur die Störungen der letzten 30 Tage bekommt!
-
Perfektes Service! :up: :)
-
Bei der Straßenbahn sind es täglich durchschnittlich 10 und über alle Betriebszweige (Straßenbahn, U-Bahn, Bus) summiert täglich durchschnittlich über 40. Die führen nicht alle zum Ausfall von Fahrten, aber Schaden ist Schaden.
Hier noch die Aufschlüsselung nach Betriebszweigen seit Anfang 2014:
Straßenbahn
West: 340
Nord: 337
Süd: 513
Mitte: 260
Autobus
Leopoldau: 1053
Rax: 652
Spetter: 804
U-Bahn
Gesamt: 2563
Die Zahlen enthalten keine Entgleisungen, defekte Bahnräumer oder Stromabnehmer, das würde also noch dazukommen.
-
Logisch, dass Süd als Hochburg der E2 die meisten Schadwagen hat! >:D Brrrr, Klumpert! :D
-
Logisch, dass Süd als Hochburg der E2 die meisten Schadwagen hat! >:D Brrrr, Klumpert! :D
Wie kommt's dann, daß der E2-freie Norden viel mehr Schadwägen hat hat als das Referat Mitte?
-
Wie kommt's dann, daß der E2-freie Norden viel mehr Schadwägen hat hat als das Referat Mitte?
Sicher die B-ULFe und ganz besonders die 33er-A. ;)
-
Hier noch die Aufschlüsselung nach Betriebszweigen seit Anfang 2014:
Straßenbahn
West: 340
Nord: 337
Süd: 513
Mitte: 260
Autobus
Leopoldau: 1053
Rax: 652
Spetter: 804
U-Bahn
Gesamt: 2563
Die Zahlen enthalten keine Entgleisungen, defekte Bahnräumer oder Stromabnehmer, das würde also noch dazukommen.
Um den Anstieg zu verdeutlichen, hier die Zahlen zwei Tage später:
Straßenbahn
West: 343
Nord: 344
Süd: 524
Mitte: 265
Autobus
Leopoldau: 1069
Rax: 661
Spetter: 824
U-Bahn
Gesamt: 2598
-
Da hat wohl jemand vergessen, die Zahlen der U-Bahn zu korrigieren. >:D
-
Da hat wohl jemand vergessen, die Zahlen der U-Bahn zu korrigieren. >:D
Es sind ja eh 35 neue Fälle dazu gekommen, oder sollten es noch mehr sein?
-
Jetzt verstehe ich, wie das mit "1 Fahrzeug" pro Tag gemeint ist – pro Linie! >:D
Los geht's:
05.31 4032/D
06.49 57/62
08.21 42/42
08.25 620/6
08.41 655/26
:D
-
Aktuelle Störungssummen:
Straßenbahn
West: 345
Nord: 347
Süd: 529
Mitte: 269
Autobus
Leopoldau: 1081
Rax: 670
Spetter: 829
U-Bahn
Gesamt: 2626
Signal- und Stellwerksstörungen U-Bahn: 231
-
Ich schreib das einmal da dazu, weil ich keinen passenderen Thread finden kann: Es wurde im Pfostenthread die OGD-Schnittstelle zu den Abfahrtszeiten der WL erwähnt, zum Beispiel http://www.wienerlinien.at/ogd_realtime/monitor?rbl=345
Wenn ich mir diese Daten nun anschaue, bemerke ich, dass bei etwa der Hälfte der Abfahrtsdatensätze der Teil "vehicle" fehlt, man also nicht sagen kann, ob es sich um einen Hochflurer oder Niederflurer handelt. Andererseits ist die Information auf Qando und Itip sehr wohl vorhanden. Wo liegt der Unterschied? Verwenden die WL intern eine bessere Datenquelle als das, was sie nach außen abgeben?
-
Ich schreib das einmal da dazu, weil ich keinen passenderen Thread finden kann: Es wurde im Pfostenthread die OGD-Schnittstelle zu den Abfahrtszeiten der WL erwähnt, zum Beispiel http://www.wienerlinien.at/ogd_realtime/monitor?rbl=345
Wenn ich mir diese Daten nun anschaue, bemerke ich, dass bei etwa der Hälfte der Abfahrtsdatensätze der Teil "vehicle" fehlt, man also nicht sagen kann, ob es sich um einen Hochflurer oder Niederflurer handelt. Andererseits ist die Information auf Qando und Itip sehr wohl vorhanden. Wo liegt der Unterschied? Verwenden die WL intern eine bessere Datenquelle als das, was sie nach außen abgeben?
Ich kenne die Datenquelle nicht, aber kann es sein, dass dies Datensätze von Autobus, bzw U-Bahn handelt? Denn bei diesen Linien werden diesbezüglich keinerlei Info notwendig. Die Busse sind schon zu 100% Niederflur und bei der U-Bahn unterscheidet das System nicht zwischen Silberpfeil und V-Zug
-
Ich kenne die Datenquelle nicht, aber kann es sein, dass dies Datensätze von Autobus, bzw U-Bahn handelt? Denn bei diesen Linien werden diesbezüglich keinerlei Info notwendig. Die Busse sind schon zu 100% Niederflur und bei der U-Bahn unterscheidet das System nicht zwischen Silberpfeil und V-Zug
Ich habe mir die Daten von Straßenbahnhaltestellen angeschaut.
-
Ich kenne die Datenquelle nicht, aber kann es sein, dass dies Datensätze von Autobus, bzw U-Bahn handelt? Denn bei diesen Linien werden diesbezüglich keinerlei Info notwendig. Die Busse sind schon zu 100% Niederflur und bei der U-Bahn unterscheidet das System nicht zwischen Silberpfeil und V-Zug
Ich habe mir die Daten von Straßenbahnhaltestellen angeschaut.
Aber auch dort bleiben Buslinien stehen. Und es gibt doch sehr wohl andere private Apps, die sehr wohl auch unterscheiden, ob bei der Straßenbahn ein Hochflurer oder ein ULF kommt. Oder täusche ich mich da.
-
95B sprach glaub ich hiervon, dass bei den Straßenbahnen bei einer Abfahrt das "vehicle" angegeben ist, während bei einer anderen nicht. Schnellgebastelter Screenshot siehe Anhang - es geht hier nur um die 5er Station am Praterstern Richtung Westbahnhof, steht sogar im Datenpaket drinnen.
Und ja, auch mir ist aufgefallen, dass qando und itip in einigen Fällen besser sind als OGD oder Apps, die darauf beruhen. Da scheints ein paar Unterschiede zu geben, bestätigen kann ichs aber nicht.
-
95B sprach glaub ich hiervon, dass bei den Straßenbahnen bei einer Abfahrt das "vehicle" angegeben ist, während bei einer anderen nicht. Schnellgebastelter Screenshot siehe Anhang - es geht hier nur um die 5er Station am Praterstern Richtung Westbahnhof, steht sogar im Datenpaket drinnen.
Ja, genau darum geht es.
-
Nachdem ich mir die Datenstruktur der
WL Rohdaten in den letzten Tagen genau angesehen habe, kann ich das Rätsel lüften. Die Information "vehicle" kann als Unterkapitel von "departure" angegeben werden und dient hauptsächlich dazu, ein nicht behindertengerechtes Fahrzeug anzugeben. Man findet dann unter vehicle den Vermerk barrierfree: false. Fehlt die Angabe zu vehicle, ist das Fahrzeug behindertengerecht.
Unter https://www.data.gv.at/katalog/dataset/stadt-wien_wienerlinienechtzeitdaten finden sich sämtliche Details und Links zu den Rohdaten, ebenso wie eine Aufschlüsselung aller Angaben.
-
Die API Beschreibung scheint aber nicht aktuell zu sein. Ich hab da die letzten Wochen dran gesessen, den ankomenden Datemüll ansatzweise für mich aufzubereiten.
-
Ohne die Wiener Linien jetzt in Schutz nehmen zu wollen, in der Doku der API (http://data.wien.gv.at/pdf/wienerlinien-echtzeitdaten-dokumentation.pdf (http://data.wien.gv.at/pdf/wienerlinien-echtzeitdaten-dokumentation.pdf)) steht folgendes:
monitors.lines.departures.departure.vehicle | element | required:n | Informationen über das Fahrzeug (nur wenn abweichend von der Linie)
Wenn ich mir die Abfahrtsinfo jetzt anschaue, dann wird bei der Haltestelle eine grundsätzliche Definition der Linie angegeben:
"lines":[{"name":"5","towards":"Westbahnhof SU","direction":"H","platform":"1","richtungsId":"1","barrierFree":false,"realtimeSupported":true,"trafficjam":false
Diese Attribute gelten dann grundsätzlich für alle Departures dieser Linie, wenn es über das Element monitors.lines.departures.departure.vehicle keine abweichende Parametrisierung gibt.
Demnach ist die ganze Linie grundsätzlich als Hochflur-Linie im System, abweichende Fahrzeuge, also ULFe, müssen daher über dieses Element extra angegeben werden, z.B. "vehicle":{"name":"5","towards":"Westbahnhof SU","direction":"H","richtungsId":"1","barrierFree":true,"realtimeSupported":true,"trafficjam":false,"type":"ptTram","attributes":{},"linienId":105}}
EDIT: Anbei noch die gesamte Liste der Einträge "lines" und "departures" von 15:06:19, die ich mir angesehen habe.
"lines":[{"name":"5","towards":"Westbahnhof SU","direction":"H","platform":"1","richtungsId":"1","barrierFree":false,"realtimeSupported":true,"trafficjam":false,
"departures":{"departure":[
{"departureTime":{"timePlanned":"2020-02-05T15:08:30.000+0100","timeReal":"2020-02-05T15:08:30.000+0100","countdown":2}},
{"departureTime":{"timePlanned":"2020-02-05T15:16:00.000+0100","timeReal":"2020-02-05T15:16:00.000+0100","countdown":9},
"vehicle":{"name":"5","towards":"Westbahnhof SU","direction":"H","richtungsId":"1","barrierFree":true,"realtimeSupported":true,"trafficjam":false,"type":"ptTram","attributes":{},"linienId":105}},
{"departureTime":{"timePlanned":"2020-02-05T15:23:30.000+0100","timeReal":"2020-02-05T15:23:30.000+0100","countdown":17}},
{"departureTime":{"timePlanned":"2020-02-05T15:31:00.000+0100","timeReal":"2020-02-05T15:31:00.000+0100","countdown":24},
"vehicle":{"name":"5","towards":"Westbahnhof SU","direction":"H","richtungsId":"1","barrierFree":true,"realtimeSupported":true,"trafficjam":false,"type":"ptTram","attributes":{},"linienId":105}},
{"departureTime":{"timePlanned":"2020-02-05T15:38:30.000+0100","timeReal":"2020-02-05T15:38:30.000+0100","countdown":32},
"vehicle":{"name":"5","towards":"Westbahnhof SU","direction":"H","richtungsId":"1","barrierFree":true,"realtimeSupported":true,"trafficjam":false,"type":"ptTram","attributes":{},"linienId":105}},
{"departureTime":{"timePlanned":"2020-02-05T15:46:00.000+0100","timeReal":"2020-02-05T15:46:00.000+0100","countdown":39}},
{"departureTime":{"timePlanned":"2020-02-05T15:53:30.000+0100","timeReal":"2020-02-05T15:53:30.000+0100","countdown":47},
"vehicle":{"name":"5","towards":"Westbahnhof SU","direction":"H","richtungsId":"1","barrierFree":true,"realtimeSupported":true,"trafficjam":false,"type":"ptTram","attributes":{},"linienId":105}},
{"departureTime":{"timePlanned":"2020-02-05T16:01:00.000+0100","timeReal":"2020-02-05T16:01:00.000+0100","countdown":54}},
{"departureTime":{"timePlanned":"2020-02-05T16:08:30.000+0100","timeReal":"2020-02-05T16:08:30.000+0100","countdown":62}},
{"departureTime":{"timePlanned":"2020-02-05T16:16:00.000+0100","timeReal":"2020-02-05T16:16:00.000+0100","countdown":69}}
-
Die API Beschreibung scheint aber nicht aktuell zu sein. Ich hab da die letzten Wochen dran gesessen, den ankomenden Datemüll ansatzweise für mich aufzubereiten.
Die Daten sind eigentlich schon in der Rohform fast selbsterklärend. Wo kommst du nicht klar?
Firefox kann die odg-Daten auch in einem recht übersichtlichen Format anzeigen (siehe Anhang). Um daraus eine brauchbare Seite zu machen, muss man dann doch einiges filtern.
Ich mache grundsätzlich eine cURL-Abfrage der Seite und arbeite das Resultat dann mit php ab.
Aufgefallen ist mir, dass bei manchen Linien einige Züge nur mit timePlanned angegeben sind, andere jedoch acuh mit timeReal. Ich nehme an, dass es davon abhängt, ob der Zug bereits von der Endstelle abgefahren ist.
Ich filtere als default die timeReal heraus und gebe nur, wenn diese fehlt die timePlanned an. Allerdings liste ich jeweils nur die nächsten 3 Abfahrten pro Linie.
Diese Attribute gelten dann grundsätzlich für alle Departures dieser Linie, wenn es über das Element monitors.lines.departures.departure.vehicle keine abweichende Parametrisierung gibt.
Demnach ist die ganze Linie grundsätzlich als Hochflur-Linie im System, abweichende Fahrzeuge, also ULFe, müssen daher über dieses Element extra angegeben werden, z.B.
...
Das erscheint schlüssig. Da ich mein Script nur für den QR-Code als Haltestellenbereicherung (siehe https://www.tramwayforum.at/index.php?topic=8975.msg359532#msg359532) zusammengestellt habe, habe ich die Barrierefreiheit des Fahrzeugs nicht berücksichtigt. Mit ein paar zusätzlichen Zeilen im Programm ließe sich das natürlich auch implementieren.
-
Was an dem System aber wieder bescheuert ist, kommt heraus, wenn man sich beispielsweise die Linie 43 ansieht.
Diese ist richtigerweise als Niederflurlinie definiert. Alle Fahrzeuge, die später als in 45 Minuten kommen werden aber über den Vehicle-Zusatz als Hochflurfahrzeuge markiert und werden demnach in den Systemen (also auch i.tip) als Hochflurer angezeigt.
http://www.wienerlinien.at/ogd_realtime/monitor?rbl=235
-
Das ist halt ein Problem, dass ein True/False-Feld kein "unknown" beinhalten kann.
-
Das ist halt ein Problem, dass ein True/False-Feld kein "unknown" beinhalten kann.
Dann sollen sie es halt ohne Zusatz-Spezifikation und damit auf der Definition der Linie belassen. Damit ist zumindest die Wahrscheinlichkeit schon einmal größer, dass es stimmt, wenn die Linien richtig gepflegt sind.
-
Sinnvoller, die Schnittstelle entsprechend zu erweitern. Über solche Alltagssituationen hätte man sich aber schon vor vielen Jahren Gedanken machen können.
-
Wer schaut eine Abfahrtszeit in mehr als 45 Minuten an, wenn vorher zig Abfahrten bereitstehen? Klar kann vor Abfahrt eines Zuges nicht zu 100 % gesagt werden, was wirklich kommt. Wenn etwa ein Zug ausfällt, stimmt die ganze Anzeige nicht mehr. Ich denke, dass die Angabe der Abfahrten in den nächsten 60-70 Minuten nur dazu dient, auch selten verkehrende Linien besser zu erfassen. Macht das System nicht schlechter als es ist. Das sind nun mal Rohdaten. Erst der Anwender/Entwickler kann das dann sinnvoll für den Enduser aufarbeiten.
-
Ich denke, dass die Angabe der Abfahrten in den nächsten 60-70 Minuten nur dazu dient, auch selten verkehrende Linien besser zu erfassen.
Genau, in erster Linie die Nachtbusse. Leider aber auch die Einzieher, die dann völlig unnötig auf den Haltestellenanzeigen den Platz wegnehmen.
-
Ich denke, dass die Angabe der Abfahrten in den nächsten 60-70 Minuten nur dazu dient, auch selten verkehrende Linien besser zu erfassen.
Genau, in erster Linie die Nachtbusse. Leider aber auch die Einzieher, die dann völlig unnötig auf den Haltestellenanzeigen den Platz wegnehmen.
Auf den VFGIs ist das Limit mit 45 Minuten gesetzt.
-
Ich denke, dass die Angabe der Abfahrten in den nächsten 60-70 Minuten nur dazu dient, auch selten verkehrende Linien besser zu erfassen.
Genau, in erster Linie die Nachtbusse. Leider aber auch die Einzieher, die dann völlig unnötig auf den Haltestellenanzeigen den Platz wegnehmen.
Und wieso sollen jetzt auf einmal Einzieher nicht mehr angezeigt werden? Bei den Fahrplänen gibt es hier immer einen Aufstand, wenn diese nicht angeführt werden. Und wenn es nicht genügend Platz gibt, dann werden die Linien abwechselnd angezeigt. Also wo ist da das Problem?
-
Und wieso sollen jetzt auf einmal Einzieher nicht mehr angezeigt werden? Bei den Fahrplänen gibt es hier immer einen Aufstand, wenn diese nicht angeführt werden. Und wenn es nicht genügend Platz gibt, dann werden die Linien abwechselnd angezeigt. Also wo ist da das Problem?
Naja, es ist halt relativ sinnlos, wenn zum Beispiel in der Haltestelle der Linien 6 und 18 die eigentlich wichtige Information (also Abfahrten Linie 6 Richtung Geiereckstraße und Linie 18 Richtung Schlachthausgasse) verdrängt werden von "49 Winckelmannstraße Betr.Bhf.Rudolfsheim 44". Solche Einzieher (also von Linien, die bei der jeweiligen Haltestelle normalerweise nicht vorbeikommen) sollten nur dann angezeigt werden, wenn sie der nächste oder übernächste Zug sind.
-
Welche Anzeige meinst du? An der Haltestelle selbst werden doch ohnehin nicht mehr als 3 Linien angezeigt, wobei bei jeder Linie maximal die nächsten 2 Abfahrten einander abwechseln.
Wenn die Einzieher Fahrgäste befördern, gehören die angezeigt. Setzt zwar eine gewisse Ortskenntnis voraus, aber unter Umständen kann man so spontan entscheiden, mit einem Einzieher zu fahren.
Die Rohdaten kann man ja entsprechend filtern, wenn man gewisse Angaben nicht wünscht.
-
Welche Anzeige meinst du? An der Haltestelle selbst werden doch ohnehin nicht mehr als 3 Linien angezeigt, wobei bei jeder Linie maximal die nächsten 2 Abfahrten einander abwechseln.
Wenn die Einzieher Fahrgäste befördern, gehören die angezeigt. Setzt zwar eine gewisse Ortskenntnis voraus, aber unter Umständen kann man so spontan entscheiden, mit einem Einzieher zu fahren.
Die Rohdaten kann man ja entsprechend filtern, wenn man gewisse Angaben nicht wünscht.
Auf wessen Posting beziehst du dich?
-
Naja, es ist halt relativ sinnlos, wenn zum Beispiel in der Haltestelle der Linien 6 und 18 die eigentlich wichtige Information (also Abfahrten Linie 6 Richtung Geiereckstraße und Linie 18 Richtung Schlachthausgasse) verdrängt werden von "49 Winckelmannstraße Betr.Bhf.Rudolfsheim 44". Solche Einzieher (also von Linien, die bei der jeweiligen Haltestelle normalerweise nicht vorbeikommen) sollten nur dann angezeigt werden, wenn sie der nächste oder übernächste Zug sind.
Deines.
-
Deines.
Ah, ok.
Welche Anzeige meinst du?
Die VFGI natürlich. Am Handy dürfen die Einzieher gern mit angezeigt werden, da ist genug Platz.
An der Haltestelle selbst werden doch ohnehin nicht mehr als 3 Linien angezeigt, wobei bei jeder Linie maximal die nächsten 2 Abfahrten einander abwechseln.
Wenn Einzieher dazukommen, wird normalerweise der vorhandene Platz gesprengt. Beispiel Westbahnhof, 6 und 18: zweizeilige Anzeige, erste Zeile Linie 6, zweite Zeile Linie 18. Wenn dann zusätzlich noch "49 Winckelmannstraße Betr.Bhf.Rudolfsheim 44" angezeigt wird, verdrängt das beide Linien, weil drei Linien auf der zweizeiligen Anzeige als "Linie A Linie B" abwechselnd mit "Linie C Leerfeld" angezeigt werden. Und das bis zu 20 Sekunden lang.
Wenn die Einzieher Fahrgäste befördern, gehören die angezeigt.
Ja, aber nicht eine Dreiviertelstunde im Voraus.
Setzt zwar eine gewisse Ortskenntnis voraus, aber unter Umständen kann man so spontan entscheiden, mit einem Einzieher zu fahren.
Spontan ja, aber dann sollen die Einzieher eben erst angezeigt werden, wenn sie der nächste oder übernächste Zug sind.
Die Rohdaten kann man ja entsprechend filtern, wenn man gewisse Angaben nicht wünscht.
Tut aber bei den WL niemand. :-\
-
Setzt zwar eine gewisse Ortskenntnis voraus, aber unter Umständen kann man so spontan entscheiden, mit einem Einzieher zu fahren.
Spontan ja, aber dann sollen die Einzieher eben erst angezeigt werden, wenn sie der nächste oder übernächste Zug sind.
Würde das eher nicht daran festmachen, wie viele Züge vor dem Einzieher noch kommen, sondern an einem Zeitraum. Zehn Minuten scheinen mir angemessen bei Einziehern.
-
Danke, alles klar.
Die Einzieher sind zum Teil recht verwirrend. Beispiel Linie 10 in der Lainzerstraße mit Fahrziel Wattmanngasse. Nun beginnt die Wattmanngasse in Alt-Hietzing und zieht sich über eine Länge von ca 2 km fast in Luftlinie über den Küniglberg bis nach Speising. Dabei weist die in Hietzing gut bekannte Straße eine erhebliche Steigung auf. Am südlichen Ende führt sie als teilweise steiler Fußweg zwischen Villen und schließlich unter der Verbindungsbahn durch und hat dann auf ihren letzten 40 noch ein Straßenbahngleis, welches in die Remise Speising führt und im Fahrgastbetrieb nicht befahren wird. Das wissen wohl die Wenigsten.
Zwar gibt es auf der Linie 62 eine Haltestelle Wattmanngasse in der Hetzendorfer Straße. Diese ist jedoch keine Endstelle. Eine Zielanzeige Wattmanngasse auf einem 10er, der durch Hietzing fährt, ist daher selbst für einen Ortskundigen eine Herausforderung, selbst wenn dies die letzte benutzbare Haltestelle des Einziehers ist. Ist zwar eine konsequente Bezeichnung, aber mit Remise Speising würden die meisten Fahrgäste eher etwas anfangen. Tatsächlich haben diese Einzieher selten Fahrgäste.
-
Es steht ja eh "Wattmanngasse Betr.Bhf.Speising" drauf. Ob die Einzieher Fahrgäste haben, hängt vor allem von ihrer Fahrplanlage ab. Wenn ein 10er von Unter St. Veit über Kennedybrücke nach Speising einzieht, wird er bis zur Kennedybrücke kaum Fahrgäste haben, weil er dem Planzug nachfährt. Ab der Kennedybrücke ändert sich das, weil er 60er-Fahrgäste mitnimmt. Auch die Einzieher über die Mariahilfer Straße haben meistens etliche Fahrgäste. Aber niemand wartet extra auf diese Züge, sondern die Leute nutzen die Chance spontan.