Java-Bibliothek Echtzeitdaten

[13er]

Eric S. Raymond hat einmal gesagt "release early, release often". Also bekommt ihr hier die Version 0.1 meiner Java-Bibliothek namens "libf59", die der Kommunikation mit der WL-Echtzeitdaten-API dient.

Warum Java? Damit man die Bibliothek (längerfristiges Ziel) auch sehr einfach aus Android-Apps heraus verwenden kann. So braucht nicht jeder Entwickler einer App immer wieder bei Null beginnen.

Die Lizenz der Library ist völlig offen. Ihr könnt damit machen, was auch immer ihr wollt: Verwenden, Ändern, Weitergeben, ... Sowohl in freien als auch kommerziellen Projekten, ist mir ganz egal. Ich würde mich auf jeden Fall aber über (positive wie auch kritische) Rückmeldungen freuen: f59@f59.at

Die Spezifikation (oder besser gesagt: das, was wirklich vom Server zurückgeliefert wird) wurde so gut wie möglich implementiert und das meiste sollte "out of the box" funktionieren. Es wird sicher noch mehrere "Komfort"-Methoden geben, damit alles einfacher verwendbar wird. Dazu muss ich aber selbst erst die Apps schreiben, die darauf aufbauen, damit ich merke, was noch besonders fehlt (und was noch nicht funktioniert).

Hier ist ein kleiner Ausschnitt, wie man die Library verwenden kann:

Code: [Auswählen]

        String sender = "<KEY>";
        Database db = Database.getInstance();
        Gate gate = db.getGate("10", "Hietzing");
        MonitorRequest request = new MonitorRequest(sender, gate.getRblNumber());
        MonitorResponse response = (MonitorResponse) request.send();
        System.out.println("Nächste Abfahrten:");
        for (Monitor mon : response.getMonitors()) {
            for (Line lin : mon.getLines()) {
                for (Departure dep : lin.getDepartures()) {
                    System.out.print(lin.getName()+"\t");
                    System.out.println(lin.getTowards() + "\t" + dep.getCountdown());
                }
            }
        }

Ich lese die Haltestellen- und Liniendaten bewusst nicht bei jedem Programmstart aus den CSV-Dateien ein, sondern habe sie mit (mitgelieferten) Perl-Scripts in eine Java-Klasse konvertiert. Die Datenbank wird nur dann aufgebaut, wenn man das erste Mal (mit getInstance(), ein Singleton) darauf zugreift, ansonsten (also wenn man die gewünschte RBL-Nummer schon kennt) verbraucht sie keine Laufzeit.

Vielleicht kann das ganze jemand von euch brauchen!

[13er]

Die Spezifikation hatte noch weitere Fehler; hab auch die Errata geupdated 

Außerdem wird jetzt der Key nicht mehr hartcodiert, sondern kann aus einer Datei eingelesen werden. Siehe Test.java.

Störungsinfos werden jetzt erfolgreich zurückgeliefert, z.B.:

Code: [Auswählen]

*** 62 Fahrtbehinderung
** Beginn: 2013-09-09T07:05:00.000+0200 VA: 2013-09-09T07:36:00.000+0200
* Nach einer Fahrtbehinderung kommt es derzeit zu längeren Wartezeiten.

*** 5 Fahrtbehinderung
** Beginn: 2013-09-09T07:35:00.000+0200 VA: 2013-09-09T07:54:00.000+0200
* Nach einer Fahrtbehinderung kommt es derzeit zu längeren Wartezeiten.

(Verspätungsinformationen habe ich da gefiltert)

[Tatra83]

Ts... Dass das unter Literatur, Kunst, Medien läuft... 

Ich hab hier mal alle Dinge, die mir so aufgefallen sind, zusammengeschrieben: http://f59.at/errata/

Zu deinen Errata folgende Anmerkungen:

Haltestellen - Bereiche - Steige/Haltepunkte: Dazu zum hoffentlich besseren Verständnis ein PDF, das ich kurz zusammengeschnitzt habe (Bei Interesse via PN).

Das Feld Steig folgt prinzipiell dem Muster nach dem folgenden Beispiel: Die landwärte Richtung einer Linie (meist HIN) hat den Suffix H, die städtwärtige Richtung einer Linie (RÜCK) hat den Suffix R. Bei der Straßenbahn gibt es so genannte Zugangssteige (Präfix "z"), die den Übergang vom GIS-Netz des Fußgängers auf das GIS-Netz der Straßenbahn (ist als eigenes Gleisnetz erfasst) ermöglichen. Manchmal hängt an den "z"-Steigen auch der Bus dran.

[13er]

So, hier wieder einmal ein Update nach ausgiebigem Testen, Version 0.3.

Änderungen zu 0.2:
- Vehicle.towards wird in der Spezifikation verschwiegen, gibt es aber (abweichendes Zeil einzelner Fahrten)
- Lines.direction wird in einigen Serverantworten nicht mitgeliefert, obwohl es in der Spezifikation als "required" markiert ist
- Update der Haltestellen- und Steiglisten in der Datenbank
- Die meisten Steige sollten jetzt besser passen, da die Dubletten möglichst entfernt wurden. Bei manchen Dubletten hat allerdings gar keine RBL-Nummer gepasst?!
- In den Response-Objekten ist jetzt per getRawResponse() auch die ungeparste JSON-Antwort vom Server verfügbar, falls man sie zum Debuggen der Spezifikation braucht
- Es gibt neue Methoden, um auf die Datenbank einfacher zuzugreifen

[95B]

- Vehicle.towards wird in der Spezifikation verschwiegen, gibt es aber (abweichendes Zeil einzelner Fahrten)

Planmäßig abweichend (Einziehfahrt) oder spontane Kurzführung (störungsbedingt)?

[13er]

- Vehicle.towards wird in der Spezifikation verschwiegen, gibt es aber (abweichendes Zeil einzelner Fahrten)

Planmäßig abweichend (Einziehfahrt) oder spontane Kurzführung (störungsbedingt)?

Gute Frage. Theoretisch sollte die Aufteilung so sein, wie du schreibst, aber ich bin mir ziemlich sicher, dass es auch Abweichungen geben wird.