Sperrobjekt Weblog

HERE Traffic API

Um das HERE Traffic API nutzen zu können, wird ein Developer Account bei HERE benötigt. Dieser ist in der einfachsten Version kostenlos, diese reicht für den Zweck dieses Bots völlig aus. Die Dokumentation des API finde ich eher oberflächlich und unübersichtlich, hilfreich ist aber die Suchfunktion, über die ich Informationen gefunden habe, die auf den ersten Blick nirgends verlinkt sind. Auch Stack Overflow mit dem Tag here-api ist eine nützliche Quelle bei Problemen.

Das Traffic API bietet jedenfalls die Möglichkeit, Daten über den so genannten "Traffic Flow" abzufragen. Dahinter steckt - weil HERE ja ursprünglich ein Kartendienstleister wie Google Maps ist - die Idee, Fahrzeuge entsprechend der Verkehrslage routen und Strecken mit starkem Verkehr entsprechend rot/gelb/grün einfärben zu können. Die Abfrage lässt sich regional begrenzen, z. B. für Wiesbaden. Das kann unter anderem über einen bbox-Parameter geschehen, also eine "Bounding Box" mit begrenzenden Koordinaten ("links oben"/"rechts unten"):

curl -L -X GET 'https://traffic.ls.hereapi.com/traffic/6.2/flow.json?bbox=50.069068,8.208654;50.086831,8.263328&apiKey=***'

Das Format der JSON-Antwort ist leider nirgends ausführlich dokumentiert. Eine verkürzte beispielhafte Response habe ich hier ins Repository committet. Zu sehen sind jede Menge zwei- und dreistellige Buchstabencodes, deren Bedeutung sich zunächst nur teilweise erschließt. Hier helfen Common Acronyms und die XSD weiter, die sich abfragen lässt:

curl -L -X GET 'https://traffic.ls.hereapi.com/traffic/6.0/xsd/flow.xsd?apiKey=***'

Warum es diese nur für Version 6.0, nicht aber die oben verwendete 6.2 gibt, weiß ich nicht. Wichtig sind für uns vor allem die "FlowItems" (FIS/FI), die sowohl TMC Daten als auch "Current Flow"-Daten (CF) enthalten. Außerdem sind die Straßenbezeichnung (FIS -> DE für "Description") und ein Zeitstempel (PBT) vorhanden. Entscheidend für die Bestimmung einer überhöhten Geschwindigkeit ist aber das Feld SU, was für "Speed Uncut" steht (daneben gibt es noch SP "Speed" für die Geschwindigkeit, die vom Tempolimit begrenzt ist). Diesen SU-Wert vergleichen wir mit dem Tempolimit plus 10 % Toleranz, also 55 km/h. Liegt SU höher, ist davon auszugehen, dass da ein Fahrzeug zu schnell gefahren ist. Doch halt! Zu berücksichtigen ist hier noch der CN "Confidence"-Wert; nur wenn 0.7 < CN <= 1.0, sind nach Angaben von HERE überhaupt erst Echtzeitdaten in die Berechnung miteingeflossen. Andernfalls greift HERE nämlich auf historische Daten zurück, was in unserem Kontext nichts bringt.

Zu bedenken ist, dass HERE bestehende Daten für Routing-Dienste aggregiert. Selbst die Echtzeitdaten stellen einen Wert zur Verfügung, der vorher durch einen wie auch immer gearteten Algorithmus aus mehreren Datenquellen über einen längeren Zeitraum berechnet wurde. Das bedeutet, dass zumindest ein Fahrzeug mit der angegebenen Geschwindigkeit gefahren ist; aber wann genau und ob es sogar noch schnellere Fahrzeuge gab, kann nicht mit Sicherheit gesagt werden. Mehr Informationen dazu finden sich in diesem Issue, insbesondere in diesem Kommentar.

Nach einigen Tagen Testbetrieb habe ich den Eindruck, dass die Geschwindigkeiten in Zeiten mit wenig Verkehr (vulgo: nachts) relativ lang hoch bleiben. Entweder fahren die wenigen Fahrzeuge allesamt sehr schnell, oder der HERE-Algorithmus lässt die Geschwindigkeiten nur langsam "abklingen", einfach weil zu wenig Datenpunkte vorliegen. Manche Orte habe ich aus der Auswertung herausgenommen, weil dort das Tempolimit nicht eindeutig ist bzw. ich die Position nicht so genau zuordnen kann.

Zusammengefasst sieht es für mich so aus, als ob die Daten also durchaus dazu geeignet sind, ungefähre Orte und Zeitpunkte zu identifizieren, an und zu denen Fahrzeuge zu schnell fahren. Das ist keine exakte Wissenschaft und mag auch manchmal daneben liegen, aber um Aufmerksamkeit für Problemzonen zu schaffen, reicht es allemal.

n8n

n8n ist eine Open Source-Software zur Automatisierung von Workflows. Die grafische Oberfläche erinnert stark an Node-RED: einzelne Funktions-Nodes lassen sich mittels Pfeilen zu einem komplexen Workflow verbinden. Während Node-RED ein sehr universelles und vielseitiges Werkzeug ist (mit allen Vor- und Nachteilen), stellt n8n eher eine Alternative zu IFTTT, Zapier oder Huginn (ebenfalls OSS) dar.

n8n kann selbst gehostet werden, es gibt aber auch eine gehostete bzw. Cloud-Version, die kostenlos ist, wenn ich das richtig sehe. Bei mir läuft n8n in einem Docker-Container auf meinem NAS:

docker run -it --rm --name n8n -p 5678:5678 -e WEBHOOK_TUNNEL_URL=<LOCAL_URL_AND_PORT> -v ~/.n8n:/home/node/.n8n n8nio/n8n

Die Umgebungsvariable WEBHOOK_TUNNEL_URL ist in meinem Fall für die OAuth-Autorisierung bei Twitter wichtig; ebenso müssen für das n8n-Browserfenster Popups zugelassen sein, sonst klappt das nicht (für euch getestet).

Unter LOCAL_URL_AND_PORT ist dann auch die grafische Oberfläche von n8n aufrufbar, wo Workflows erstellt/importiert und bearbeitet werden können. Dort habe ich einen Workflow angelegt, der mehr oder weniger so aussieht:

1. Der Workflow wird in einem definierten Intervall gestartet (aktuell: 10 min.)
2. Daten werden vom HERE API abgefragt (s. o.)
3. Über eine JavaScript-Funktion werden die Daten gefiltert und umgeformt:
   • Liegen Echtzeitdaten vor (Konfidenzintervall 0.7 < CN <= 1.0)?
   • Wo ist die Geschwindigkeit überhaupt höher als 55 km/h?
   • Welche Streckenbereiche sollen ausgenommen werden)?
   • Welche Straßennamen sollen ersetzt werden, z.B. "Rheinstraße" statt "L3037"?
4. Bleiben valide Datensätze übrig, werden sie an die Twitter-Funktion weitergeleitet, die jeweils einen entsprechenden Tweet absetzt.

Das ist im Prinzip schon alles. n8n macht es einem leicht, eine Vielzahl an Diensten anzuschließen, ich habe unter anderem Automatisierungen laufen, die Inhalte an Rocket.Chat oder andere Messaging-Lösungen schicken. In unserem Fall ließe sich der Workflow sehr leicht um andere Integrationen als Twitter erweitern.

Twitter

Für den Twitter-Bot habe ich einen neuen Twitter-Account erstellt und diesen als Developer-Account freischalten lassen. Im Entwickler-Portal von Twitter lässt sich dann eine neue App erstellen, die neben Lese- auch Schreibrechte bekommen muss. Unter "Authentication settings" ist außerdem "3-legged OAuth" zu aktivieren und die Callback-URL aus n8n einzutragen - hier ist eine ausführliche Anleitung. Damit lässt sich dann die n8n Twitter-Node verwenden.

Ansonsten gibt es im Netz ausführliche Anleitungen zum Einrichten von Twitter-Bots, so dass ich hier auf die Einzelheiten nicht eingehen möchte. Wer dem Bot auf Twitter folgen möchte, kann das unter https://twitter.com/WiesbadenRaser tun.

71.8 km/h statt 50 km/h auf Aarstraße (Richtung ↘). 23.8.2021, 00:19 Uhr #SpeederBot #RaserWiesbaden #WiesbadenSpeedWatch

— WiesbadenRaserBot (@WiesbadenRaser) August 22, 2021

Fazit

Den Twitter-Bot zu erstellen war einerseits gar nicht so schwierig, andererseits aber mit mehr Fummelei verbunden als erwartet. Letzteres waren meist Kleinigkeiten, die nicht oder anders als erwartet funktioniert haben. Außerdem war es teilweise mühsam, alle nötigen Informationen zu finden, kryptische Fehlermeldungen zu verstehen und die richtigen Credentials an den richtigen Stellen einzutragen. Willkommen im Alltag eines Software-Entwicklers

Hinzu kommt, dass die Daten über die Geschwindigkeiten und Ortsangaben ganz klar mit Vorsicht zu genießen sind. Der Bot ist einerseits nur eine anspruchsvolle Spielerei, andererseits hilft er vielleicht ein kleines Bisschen dabei, Bewusstsein für zu schnelles Fahren zu schaffen. Und mehr soll es ja auch nicht sein.

Das Experiment steht noch am Anfang, und ich werde es bei genügend Zeit und Interesse weiterentwickeln.

Mitmachen

Mir sind noch ein paar Features eingefallen, die ich meinem Bot gern spendieren würde, wenn ich Zeit dafür finde:

• "High Scores": Eine tägliche/wöchentliche/ewige "Besten"liste der höchsten Geschwindigkeit
• "Conversations": Der Bot könnte auf Fragen via Twitter antworten, z. B. "Wie viele Raser gab es heute?"

Über weitere Anregungen oder auch Fehlermeldungen, im Idealfall als GitHub-Issue, würde ich mich freuen.

Ich würde mich ebenfalls freuen und auch unterstützen, wenn jemand einen ähnlichen Bot für seine Stadt oder Region aufsetzen möchte. Ob anhand meiner Anleitung mit n8n, mit Integromat wie bei englischen Original oder vielleicht auch ganz anders, ist egal. Vielleicht lassen sich auch noch weitere Datenquellen anzapfen, wer weiß, schließlich werden immer mehr Sensoren auf den Straßen verbaut.

Vielleicht gibt es auch schon ähnliche Projekte in Deutschland oder anderswo? Im Vereinigten Königreich habe ich bereits die Organisation Community Speedwatch UK gefunden, die sich für "die Schaffung gemeinsamer Daten, Verfahren, Standards, Regeln und Ergebnisse im gesamten Vereinigten Königreich" (meine Übersetzung) stark macht.

PS: Damit die Bots nicht auf Twitter gesperrt werden, scheint es wichtig zu sein, dass nicht alle Bots den gleichen Text oder die gleichen Hashtags verwenden ¯\_(ツ)_/¯