Errata

zu "Wiener Linien Realtime"-Schnittstellendokumentation

Die auf den ersten Blick informativ geschriebene Schnittstellendokumentation zu den Wiener Linien-Echtzeitdaten enthält leider mehrere Ungenauigkeiten, Stolpersteine und Fehler, auf die man im Zuge der Implementierung der Spezifikation trifft. Das folgende Dokument möge all jenen hilfreich sein, die ebenfalls mit der Spezifikation arbeiten müssen.

Ich nehme sehr gerne Feedback oder weitere Probleme, die Sie entdeckt haben, entgegen. Schicken Sie dieses bitte an errata@f59.at. Dankeschön!

Das nachfolgende Dokument ist sicher nicht vollständig; es ist eine Sammlung problematischer Punkte, über die ich selbst bei der Implementierung oder beim Testen gestolpert bin.

1. Abschnitt: PDF-Dokumentation

bezieht sich auf: V1.0 vom 13.08.2013

zu 2.1.2

monitors.locationStop.geometry.coordinates ist genauer gesagt ein JSON-Array von double.
monitor.locationStop.properties.municipalityId wird nicht als string, sondern als integer zurückgegeben.
monitors.lines.direction - Ist im Gegensatz zu den Angaben in der Spezifikation NICHT immer in der Antwort vom Server enthalten!
monitors.lines.richtungsId - wozu? Und warum deutsche Namen in einer englischsprachigen API?
monitors.lines.type - es fehlt eine Aufzählung der Möglichkeiten. Am besten holt man sich die Daten aus der CSV-Linien-Datei (sind das alle Werte? Die Qando-API kannte z.B. auch den CAT...).
mon...vehicle.towards wird nicht erwähnt, ist aber in den Daten vorhanden (nötig, wenn das Ziel dieses Wagens vom Ziel der Linie abweicht)
trafficInfos.relatedLines ist kein String, sondern ein Array von Strings! (betrifft auch 3.2.2!). Dasselbe auch bei den trafficInfoAttributes.
trafficInfos.relatedStops ist kein String, sondern ein Array von Integers! (betrifft auch 3.2.2!). Dasselbe auch bei den trafficInfoAttributes.

zu 2.1.3

Der Abschnitt sollte komplett neu geschrieben werden, hier stimmt nichts mit der Realität überein.
In Wirklichkeit handelt es sich um ein message-Objekt, das im Fehlerfall (bzw. nur bei Monitor-Anfragen auch im Erfolgsfall, dann mit Statuscode 1 (OK)) zurückgeliefert wird.

zu 3

Es sollte besser erklärt werden, worin der Unterschied zwischen kurzen und langen Störungstexten besteht. "AZBLinienspezialtext" ist wohl interner Slang, der für Außenstehende keinen Sinn ergibt.

zu 3.1

Wozu dieser Abschnitt? Entweder er steht ganz vorne und wird als Kurzeinführung in JSON geschrieben oder man lässt ihn ganz weg.

Faktisch ist der Abschnitt irreführend, da nicht die gesamte Antwort nur in data zurückgegeben wird, sondern u.U. auch in message (auf derselben Ebene).

zu 4

Warum gibt es überhaupt diese Zweiteilung zwischen TrafficInfos und News?! Verkompliziert nur die Implementierung, ohne echte Vorteile zu bieten. Es ist noch zu klären, ob die Aufzugsinfos einer TrafficInfo mit denen der News übereinstimmen.

zu 4.1

Dasselbe wie bei 3.1 - unnötig.

zu 4.2.1

Unter relatedStop gibt es eine unaufgelöste Referenz innerhalb des Dokuments.
Bei der Beschreibung von name sollte es poiCategories.name lauten (siehe auch nächster Abschnitt).

zu 4.2.2

Im gesamten Abschnitt wird schlampig "news" und "poi" vermischt. Sämtliche Felder haben mit "poi" bzw. "pois" zu beginnen.
poi.sname sollte pois.name lauten
pois.time-Daten werden als required angegeben, sind es aber nicht (und werden vom Server nicht immer mitgeliefert)
poiCategoryGroups.id: Die Verwendung von -1 für eine tatsächliche Gruppe ist nicht besonders glücklich, da -1 meistens als "nicht vorhanden" oder "unbekannt" verstanden wird.

2. Abschnitt: CSV-Daten

Auch in den zur Verfügung gestellten CSV-Dateien finden wir mehrere Unregelmäßigkeiten. Diese Dateien sind nicht weiter dokumentiert als durch ihre Headerzeile. Hier wäre mehr wünschenswert.

Generell ist anzumerken, dass der Stand der Daten problematisch ist, weil zu dieser Zeit noch die Umleitung der Währingerstraßenlinien aktiv war, wodurch die betroffenen Linie nicht sinnvoll abfragbar sind. Ein rasches Update auf den "Normalbetrieb" wäre hier wünschenswert. Spätestens (frühestens?) mit Inbetriebnahme der U2- sowie 26er-Verlängerung ist jedenfalls mit einer Aktualisierung zu rechnen.

Das letzte Datenfeld STAND ist Platzverschwendung. Diese Information hätte man auch ein einziges Mal im Header der Datei (oder auch außerhalb auf der Seite, wo man die Datei herunterladen kann) festhalten können als z.B. über 6000 Mal im Falle der Haltepunkte.

Haltestellen

Wozu wird das Feld TYP exportiert, wenn ohnehin immer der String "stop" enthalten ist. In der Form ist das Platzverschwendung. Es ist auch nicht ersichtlich, ob dieses Feld überhaupt andere Werte haben könnte (gibt es Dokumentation dazu?).

Haltepunkte

Vorsicht beim Parsen der CSV-Daten in eine andere Darstellung: Bei mehreren Datensätzen fehlt die RBL-Nummer (und weitere Daten), z.B. bei den Datensätzen ab 214703190 (mehrere Haltestellen in Schwechat) oder ab 214713181.

Die Bedeutung des Feldes BEREICH ist mir noch unklar und ich habe keine Dokumentation dazu gefunden.

Folgt das Feld STEIG irgendeinem Muster? Die Bedeutung ist mir noch nicht ganz klar.

Einige der RBL-Nummern in den Steigen sind von der Form "###:###", also eigentlich zwei Nummern in einer (z.B. im Datensatz 214690599). Manche Steige werden so zusammengefasst. Es stimmt immer genau eine Nummer, die andere ist falsch - ausprobieren!