• Zuhause
  • Artikel
  • Entwicklung einer API zur Hervorhebung von Ungenauigkeiten in UK Open Data
Veröffentlicht am 19-02-2019

Entwicklung einer API zur Hervorhebung von Ungenauigkeiten in UK Open Data

Foto von Samuel Foster

Bus Stop Checker war das erste Projekt, bei dem ich bei Passenger die Zügel übernahm.

Der Bus Stop Checker, der ursprünglich von Manuel Martin Salvador, einem früheren Mitarbeiter, ins Leben gerufen wurde, war eine Initiative zur Visualisierung möglicher Fehler in der Datenbank der National Public Transport Access Nodes (NaPTAN). Wir hatten den Verdacht, dass diese offenen Daten, die Informationen zu allen Haltestellen und anderen Zugangspunkten zu öffentlichen Verkehrsmitteln in Großbritannien enthalten, zahlreiche Inkonsistenzen aufwiesen. Wir wollten diese Unstimmigkeiten unleugbar und offensichtlich machen.

Der ursprüngliche Grund für die anfängliche Entwicklungsarbeit war die bessere Berechnung der ETAs der Reise für unsere Passagierprodukte. Die Dinge begannen sich zu ändern, als wir Abweichungen entdeckten, und das Projekt entwickelte sich zu dem, was der Bus Stop Checker heute ist.

Bushaltestelle Checker Beta

Manuel hatte ein Python-Skript geschrieben, das die Straßenlage eines Stopps in NaPTAN gegen OpenStreetMap (OSM) für Dorset berechnete. Als es anfing, mögliche Fehler aufzuwerfen, planten wir sie mit Google Maps. Dies war ein nützliches Experiment, da es eindeutig zeigte, dass mit den NaPTAN-Daten etwas nicht stimmte - und das Feedback bestätigte, das wir zuvor von Endbenutzern von mobilen Apps für Passagiere erhalten hatten.

Zu diesem Zeitpunkt war das alles - ein Experiment. Das Passenger-Team wollte diese Erkenntnisse jedoch so skalieren, dass NaPTAN-Probleme in ganz Großbritannien leicht durchsuchbar und durchdringbar sind. Die Hoffnung war, dass die Ergebnisse des Projekts die Diskussion um den Datensatz anregen und die Leute dazu bringen würden, darüber nachzudenken, wie sie verbessert werden könnten. Der Passagier könnte dann in die Diskussion um die Aufrechterhaltung der NaPTAN-Daten einbezogen werden, die größtenteils hinter dem scheinbar unzugänglichen, ummauerten Garten der örtlichen Transportbehörden stattfanden.

Lesen Sie eine gründlichere Einführung in das Bus Stop Checker-Projekt

Das Python-Skript

Ausschnitt aus Manuels Python-Skript

Manuels Python-Skript würde diesem Prozess folgen:

  • Durchlaufen Sie Knoten in der OSM-Datendatei und importieren Sie diese Knoten in MongoDB
  • Durchlaufen Sie jeden NaPTAN-Stopp in MongoDB
  • Finden Sie die nächsten 4 OSM-Knoten, die OSRM über HTTP verwenden
  • Versuchen Sie, einen Straßennamen in OSM mit dem in NaPTAN anhand der Levenshtein-Entfernung abzugleichen
  • Berechnen Sie die Richtung der Straße und der Bushaltestelle und geben Sie diese Daten in einem CSV aus

Bewaffnet mit diesem Python-Skript machte ich mich daran, Bus Stop Checker zu bauen.

Zuerst habe ich die Abhängigkeiten des Skripts (hauptsächlich PyOsmium und PyMongo) aktualisiert und das Skript korrigiert, damit es wieder für Dorset funktionieren konnte. Der nächste Schritt bestand darin, den größeren Datensatz Großbritanniens herunterzuladen und zu sehen, wie das Skript damit umgehen würde.

Etwa sieben Stunden später waren die Bindungen von Osmium Python abgestürzt, aber wir hatten wesentlich mehr Daten als zuvor: mit etwa 35% von ganz Großbritannien. Beim Durchsuchen dieser Daten wurde deutlich, dass im Datensatz erhebliche Fehler aufgetreten sind. Das Google Maps-Frontend hat es gerade geschafft, diesen Datenblock (jeden einzelnen Halt auf einmal) zu rendern, und gab einige nützliche Rückmeldungen zu Randfällen, die ein wenig genauerer Prüfung bedürften.

Probleme lösen

Ich hatte jetzt umfangreichere Daten, was großartig war, aber dies machte es auch schwierig, Probleme mit dem alten Google Maps-Viewer aufzudecken. Ich entschied mich dazu, eine API zu schreiben, die PHP (die primäre serverseitige Sprache, die von Passagieren und Basen verwendet wird) verwendet, um diese Daten in PostgreSQL zu importieren. Dies stellte einige Endpunkte vor, mit denen unser Front-End-Team eine frühe Prototyp-Benutzeroberfläche für Bus Stop Checker erstellen konnte.

Early Bus Stop Checker Prototyp-Benutzeroberfläche

Sobald wir eine frühe Front-End-Version des Bus Stop Checker hatten, konnten wir nach Problemen suchen und diese beheben.

Zum Beispiel würde das Python-Skript für Bus Stop Checker zu diesem Zeitpunkt beispielsweise die 4 nächstgelegenen OSM-Knoten für einen bestimmten Halteort erhalten - dies war jedoch manchmal nicht ausreichend.

"Knoten" sind die Datenpunkte, aus denen ein "Weg" und "Weg" die Straße besteht, auf der sich diese Punkte befinden. Einige Wege werden von sehr wenigen Knoten definiert, andere von vielen. Wenn Sie nur die 4 nächstgelegenen Knoten erhalten, würden wir oft nicht genügend Daten zurückgeben, um mit der korrekten Straße übereinzustimmen, da eine nahegelegene Straße (aber nicht die tatsächliche Straße, auf der NaPTAN sagt, dass sie eingeschaltet ist) viele unglaublich detaillierte Punkte enthalten kann und somit falsche Daten zurückgibt.

Ich habe dies behoben, indem ich alle Knoten in einem festen Radius um den Stopp herum sammelte und nicht nur den nächstgelegenen. Ich verbesserte auch die Fehlerbehandlung des Skripts, indem es seinen letzten verarbeiteten Stopp speichert und im Falle eines Fehlers von diesem Stopp aus fortfährt.

An dieser Stelle habe ich das Skript zu den OSM-Daten für Großbritannien erneut ausgeführt.

Verbesserung des Prozesses

16 Stunden später war das Skript fertig und lieferte genauere Ergebnisse. Weitere Untersuchungen der neuen Daten zeigten, dass die Python-Osmium-Bindungen für ein Produktionssystem immer noch unzuverlässig sind. Daher habe ich an diesem Punkt nach anderen Optionen gesucht.

Ich entschied mich für NodeJS, da es offizielle OSRM- und Osmium-Bindungen hat, dass wir uns nicht mehr auf die Python-Bindungen verlassen und auch den Overhead des HTTP-Aufrufs von OSRM beseitigen und die Verarbeitung beschleunigen würden.

Ich habe das NodeJS-Projekt mit einigen Änderungen genau auf das Python-Skript abgestimmt:

  • Lesen Sie direkt den NaPTAN-CSV, anstatt ihn zuerst in MongoDB zu importieren
  • Verwenden Sie LevelDB anstelle von MongoDB, um die Geschwindigkeit zu erhöhen
  • Die Ergebnisse werden direkt in PostgreSQL und nicht in eine CSV geschrieben
  • Multi-Threading des Überprüfungsprozesses: Jeder Stopp würde vom Haupt-Thread gelesen und an einen freien untergeordneten Thread übergeben, wo die eigentliche Verarbeitung stattfinden würde (dies hat die Leistung erheblich verbessert)
  • Ausgabe in eine Datei mit Protokollpuffern für eine effiziente Protokollierung

Das abschließende Projekt, das die NodeJS-Bindungen verwendet, lieferte weitaus verlässlichere Ergebnisse. Durchschnittlich 53 Minuten für ganz Großbritannien!

Prototyp-Benutzeroberfläche mit endgültigen Daten

Jetzt musste ich dieses Projekt in regelmäßigen Abständen mit Produktionssicherheit laufen lassen - keine leichte Aufgabe.

Ich habe einen auf Alpine Linux basierenden Container erstellt, der die OSM-Daten abruft und für OSRM bereit verarbeitet. Ich habe auch einen Container eingerichtet, der das NodeJS-Projekt ausführen und die Überprüfung durchführen würde. Ich habe diese Container in ECS von Amazon Web Services geladen, Jobdefinitionen, Jobwarteschlangen und Rechenumgebungen für AWS Batch hinzugefügt und einige AWS CloudWatch-Regeln erstellt, um die Container am letzten Tag jedes Monats auszulösen.

Einige weitere Verbesserungen am Algorithmus, einschließlich der Erweiterung der API, um dem Front-End-Team alle erforderlichen Daten zur Verfügung zu stellen, und der Bus Stop Checker war abgeschlossen.

Final Bus Stop Checker-BenutzeroberflächeFinal Bus Stop Checker UI - Ansicht einer Behörde

Das Projekt umfasste am Ende 3 Programmiersprachen: Python, PHP und NodeJS und war letztendlich ein voller Erfolg. Seit seiner Einführung war der Passagier an Gesprächen mit der Verkehrsabteilung über die Verbesserung des NaPTAN-Datensatzes beteiligt, und einige örtliche Verkehrsbehörden haben das Tool tatsächlich zur Verbesserung der Daten ihres Gebiets verwendet.

Ein Blick auf die endgültige Datenbank

Es ist äußerst erfreulich zu sehen, dass die Entwicklungsarbeit von Bus Stop Checker echte Ergebnisse liefert, die den öffentlichen Personennahverkehr in ganz Großbritannien verbessern.

Siehe auch

Die Woche, die war (TWTW)Wie sind Shredderservices für Organisationen vorteilhaft?Was wäre, wenn Tech nein sagte?Technologiegetriebene Ära - Ja, die Gesundheitsbranche ist auch die, die aktiv wächst!TSA Flexible agile skalierbare Teams (FAST)Autorisierter Laptop-Bildschirmersatz in Ost-Delhi