@@ -5,18 +5,56 @@ eigenen Anwendungen nutzen will, um Dinge™ anzuzeigen - ein eigener
55Abfahrtsmonitor wird so z.B. möglich.
66
77## Technische Details
8- [ Hier] ( http://ivu.aseag.de/interfaces/ura/instant_V2 ) fällt JSON raus. Wenn
9- man einfach die API-Dokumentation von [ Transport for
10- London] ( http://www.tfl.gov.uk/cdn/static/cms/documents/tfl-live-bus-and-river-bus-arrivals-api-documentation.pdf )
11- nimmt, hat man eine ganz gute Anleitung, was man mit so einer
12- URA-Schnittstelle anfangen kann.
8+ ### Allgemein
9+ ` http://ivu.aseag.de/interfaces/ura/ ` ist die Basis, unter der dann alle
10+ Endpunkte erreichbar sind. Es scheint so, als wären dort dann zwei
11+ generelle Typen unterscheidbar.
1312
14- Da Schnittstellen für Haltestellenechtzeitdaten, Haltestellensuche und
15- Routing existieren, nutze ich die hier auch.
13+ ### {instant,stream}_ V{1,2}
14+ Diese vier Endpunkte geben die aktuellen Informationen aus (instant) bzw.
15+ streamen sie (stream). Wo genau der Unterschied zwischen _ V1 und _ V2 ist,
16+ ist nicht bekannt. Transport for London hat eine
17+ [ API-Dokumentation] ( http://content.tfl.gov.uk/tfl-live-bus-river-bus-arrivals-api-documentation.pdf ) ,
18+ die ganz gut die Verwendung beschreibt.
19+
20+ Die Endpunkte eignen sich wahrscheinlich für Echtzeitdaten für Haltestellen
21+ und einzelne Busläufe.
22+
23+ ### {location,journey,journeyUpdate}
24+ Diese drei Endpunkte geben jeweils nicht-kaputtes JSON aus (yay), aus denen
25+ man insbesondere recht einfach die Bedeutung von Werten rauslesen kann und
26+ dienen dazu, Haltestellen zu finden (location), Routing zu planen (journey)
27+ und Informationen zum Routing aktuell zu halten (journeyUpdate).
28+
29+ ` location?searchString=NAME ` findet Haltestellen mit passendem Name. Der
30+ Parameter ` maxResults ` kann dazu verwendet werden, das ganze weiter
31+ einzuschränken oder auch in Kombination mit * als Name, um alle
32+ Haltestellen auszugeben. Der Defaultwert scheint 10 zu sein.
33+ Der Parameter ` searchTypes ` kennt mindestens den Wert ` STOPPOINT ` , was auch
34+ der Defaultwert ist.
35+
36+ ` journey?startStopId=A&endStopId=B&departureTime=C ` gibt
37+ Routinginformationen aus. Die HaltestellenIDs A und B ergeben sich aus dem
38+ location-Endpunkt, ` departureTime ` ist ein Unix Timestamp in Millisekunden.
39+ Anstatt ` departureTime ` ist auch die Angabe von ` arrivalTime ` möglich(?).
40+
41+ ` journeyUpdate ` tut komische Dinge mit einem Parameter, der aus ` journey `
42+ rausfällt und weiteren Parametern. Keine Ahnung, hab ich bisher noch nicht
43+ verwendet.
1644
1745## Benutzung
1846` ./main [StopID] [BusIDs] ` macht Echtzeitinformationen zur Haltestelle. Als
1947StopID funktionieren sowohl Haltestellennamen als auch die numerischen IDs.
2048
2149` ./main [StartID] [StopID] ` macht Routing vom Start zum Stop. Für die IDs
2250gilt das gleiche wie bei den Echtzeitinformationen.
51+
52+ ## Todo
53+ Der Code ist scheiße. Über die Ausgabe von ` instant_V{1,2} ` kann man
54+ wahrscheinlich deutlich schöner iterieren und ich habe beim Einbauen des
55+ Routing viel Code aus der vorherigen Version übernommen. Man müsste also
56+ den ganzen Code mal wegwerfen und alles sauber neu schreiben - das wird
57+ in $(date +%Y) natürlich nicht passieren. Was ggf. in $(date +%Y) passiert:
58+ - [ ] Weniger magisches Argumentparsing
59+ - [ ] Sinnvolleres Iterieren über die Ausgabe von ` instant_V{1,2} `
60+ - [ ] Nutzung von ` stream_V{1,2} ` für eigene Echtzeitanzeigen
0 commit comments