Freigabe der Verkehrsdaten

[13er]

Hat aber mit genau demselben Code vorher funktioniert! Also habens zumindest am Server was geändert.

[invisible]

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.

[Klingelfee]

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.

[haidi]

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.

[invisible]

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 

[ULF]

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...

[13er]

(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.

[uk]

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)?

[ULF]

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 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 )? 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... 

[13er]

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.

[Linie 41]

Das neue Qando lädt diese Daten doch dauernd vom Server oder?

[13er]

@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).

[ULF]

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 ). 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.

[13er]

Zur Zeit frage ich diese Elemente (newsList und trafficInfo) nicht ab (mir reicht vorerst der Rest und böse Sachen anzustellen ).

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.

[13er]

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).