Im vorigen Blog-Beitrag haben wir uns den NVBW-Datensatz ÖPNV-Haltestellen Baden-Württemberg angesehen. In diesem Artikel vergleichen wir diesen Datensatz (Stand 28.08.2019) mit den aktuell in OpenStreetMap (Stand 06.09.2019) erfassten Daten.

Vorbemerkungen

Bevor wir auf die Ergebnisse des Abgleichs eingehen, vorneweg einige Hintergrund-Informationen zur Abbildung von Haltestellen in OpenStreetMap.

OpenStreetMap

Objekte der realen Welt werden in der offenen Karte OpenStreetMap als Punkt, Linie oder Relation (oder in Englisch: Node, Way, Relation) abgebildet. Flächen, wie z.B. Bahnsteige, werden als sogenannte "geschlossene" Linienzüge dargestellt, d.h. als ringförmige Linie, deren erste Koordinate am Ende nochmals wiederholt wird. Dazu kommen dann noch die Eigenschaften eines Objekts, die als Schlüssel-Wert-Paare (sogenannte Tags) der Form Eigenschaft=Wert erfasst werden. Dabei beschreibt meistens eine spezielle Eigenschaft, um welche Art Objekt es sich handelt und die weiteren beschreiben spezifische Ausprägungen dieses Objekts. Welche dies jeweils sind, hat sich über die mittlerweile 15 Jahre des Bestehens des offenen Kartenprojekts in einem fortwährenden Diskussionsprozess der Community herausgebildet und ist im OpenStreetMap-Wiki dokumentiert.

Haltestellen in OSM (PTv1 vs PTv2)

Für die Modellierung von Haltestellen (und generell ÖPNV-Informationen) hat sich so im Laufe der Jahre der erst im Nachhinein so sogenannte PublicTransport Version 1 Standard (PTv1) etabliert, der später durch den PTv2 Standard fortgeschrieben wurde.

So werden beispielsweise in PTv1 Bushaltestellen als Punktobjekt mit dem Tag highway=bus_stop ausgezeichnet. Das OSM-Wiki beschreibt dessen Verwendung.

In PTv2 kann der Wartebereich einer Haltestelle nun als Punkt, Linie oder Fläche (geschlossener Linienzug) mit dem Tag public_transport=platform erfasst werden, zusammen mit einem Tag, das die Transport-Modalität beschreibt (z.B. bus=yes für eine Bushaltestelle).

Zusätzlich kann die Stelle, an der der Bus/die Bahn auf der Straße oder dem Gleis zum Halten kommt, als Node mit dem Tag public_transport=stop_position erfasst werden.

Aus Gründen der Rückwärtskompatibilität sollen bestehende Auszeichnungen wie highway=bus_stop beibehalten werden. Aus unserer Sicht bedeutet dies auch, dass diese bei neu erfassten Objekten so ausgezeichnet werden.

Exkurs: Der iD-Editor weist mit der Meldung " hat unvollständige Eigenschaften" darauf hin, dass die klassischen Tags an diesem Objekt fehlen. Der OSM Inspector ÖPNV-Stops Layer hingegen weist nur "klassische" Stops, also solche ohne public_transport Tags nach PTv2 als problematisch aus, nicht jedoch solche, die nicht rückwärtskompatibel sind.

Im Folgenden stellen wir die Ergebnisse unseres Abgleichs dar. Details zu unserem Vorgehen und spezielle Abgleichsituationen beschreiben wir weiter unten. Den Code unseres Abgleichs haben wir auf github veröffentlicht.

Abgleichergebnisse

Von den 52.905 von uns als tatsächlich zu abzugleichend betrachteten NVBW-Haltestellen konnten wir ca. zwei Drittel einer OSM-Haltestelle zuordnen. Bei ca. 14% gibt es jedoch Mehrdeutigkeiten oder Abweichungen, die genauer untersucht werden sollten.

Exkurs: Falsch-Positiv und Falsch-Negativ. Wir ermitteln bei unserem Abgleich verschiedene numerische Bewertungen für eine Zuordnung von NVBW- und OSM-Halt. Ob wir eine Zuordnung als erfolgreich betrachten oder nicht, machen wir von heuristisch ermittelten Schwellwerten für diese Berwertungen abhängig. Dabei kann es immer passieren, das trotz Unterschreitung eines Schwellwertes ein Paar einander potentiell zugeordneter Halte tatsächlich doch dieselbe reale Haltestelle meint, wir sie jedoch nicht als Treffer werten (Falsch-Negativ). Oder umgekehrt, dass für uns einen Schwellwert erreicht ist und wir die Zuordnung als erfolgreich werten, obwohl tatsächlich verschiedene Halte gemeint sind (Falsch-Positiv).

Betrachtet man die Zuordbarkeit der 47.521 von uns als zuzuordnend betrachtenden OSM-Halte, können wir über 70% erfolgreich zuordnen:

Die Ursachen für Zuordnungsprobleme sind vielfältig. Zum einen ist die Datenqualität sowohl der Halte in OpenStreetMap als auch in der NVBW-Haltestellenliste nicht ideal (Beispiele folgen unten). Zum anderen ist unser Matching noch nicht fehlerfrei.

Ausgewählte Ergebnisse

Mehrere Steige einem Halt zugeordnet

Für viele Haltestellen sind in den NVBW-Daten nicht die Steige enthalten, sondern nur der übergeordnete Halt. Sind in OSM mehrere Haltestellen gleichen Namens vorhanden, ordnen wir diese dem Halt zu, werten diesen jedoch als mehrdeutig.

Zugeordnet trotz großer Distanz

Haben Haltestellen-Zuordnungen trotz großer Distanz (>200m) zwischen NVBW- und OSM-Halt eine hohe Übereinstimmnug in anderen Kriterien (wie z.B. übereinstimmender Name, Verkehrsmittel, Steigbezeichnung, vorhergehender/nachfolgender Halt), werten wir diese als Zuordnung trotz großer Distanz.

Handelt es sich bei der Zuordnung nicht um einen "Falsch-Positiv", so ist die Verortung des OSM-Haltes in weit überwiegender Zahl näher an der Realität.

Dies gilt insbesondere für solche (vielfach vorhandenen) Haltestellen, bei denen in den NVBW-Daten alle Steige eines Haltes auf derselben Koordinate verortet sind. Über Vorgänger/Nachfolger-Halt und eventuell in OSM erfasster Steigangabe (via local_ref oder seltener auch ref) versuchen wir dennoch, die korrekte Zuordnung zu ermitteln. Leider ist der nachfolgende Halt nur durch wenige Verbünde in den NVBW-Daten als Name_Steig erfasst. Ein explizites Attribut wäre zudem sinnvoll.

Zugeordnet trotz Namensabweichungen

Haben Haltestellen-Zuordnungen trotz großer Schreibweisenunterschiede des Namens eine hohe Übereinstimmung in anderen Kriterien (wie z.B. räumliche Nähe, übereinstimmende Verkehrsmittel, Steigbezeichnung, vorhergehender/nachfolgender Halt), werten wir diese als Zuordnung trotz Namensabweichung.

Solche Namensabweichungen sind vielfach bedingt durch abgekürzte Haltestellenbezeichnungen in den NVBW-Daten.

Aber auch ganz unterschiedliche Haltestellenbezeichnungen (womöglich aufgrund zwischenzeitlicher Umbenennungen) sind nicht selten.

Ein weiterer Grund kann sein, dass die hierarchische Gliederung der NVBW-Haltestellen keine unterschiedlichen Namen eines Haltes für unterschiedliche Bereiche zulässt. Dies ist jedoch gerade bei Halten, an denen unterschiedliche Verkehrsträger bedient werden, nicht unüblich.

Zugeordnet trotz fehlendem Namen für OSM Stop

Eine ganze Reihe von OSM-Halten in Baden-Württemberg haben kein Namen-Attribut und sind gleichzeitig weder einer stop_area-Relation zugeordnet, über die der Name abgeleitet werden könnte, noch sind sie bus_stop-Nodes einer platform-Linie mit name-Attribute.

Auch dort, wo wir bei der Vorverarbeitung der potentiell zu matchenden OSM-Objekte übereinstimmende Namen nutzen, um platform (bei Bus) und stop_position (bei Bahnen) gegenüber dem jeweils anderen vorzuziehen, führt das Fehlen von Namen (oder auch Schreibweisenunterschiede) zu Abgleich-Fehlern.

Nicht zugeordneter NVBW-Halt (kein einziger Steig des Haltes)

Ungefähr ein Fünftel der NVBW-Haltestellen konnten wir nicht zuordnen.

Ein Blick auf die räumliche Verteilung zeigt, dass es Regionen in Baden-Württemberg gibt, in denen dies gehäuft auftritt und in der mutmaßtlich tatsächlich die Quote der erfassten Haltestellen geringer ist als in anderen Teilen.

Doch nicht nicht jede nicht gematchte Haltestelle fehlt tatsächlich in OSM. Bei der OSM-Mapping-Party anlässlich des 15ten Geburtstages des OSM-Projekts in Sindelfingen wollten wir die vermeintlich in Maichingen fehlenden Haltestellen mappen. Dabei haben wir festgestellt, dass neun von zehn "fehlenden" Haltestellen nicht mehr bedient werden und teilweise bereits vollständig zurückgebaut wurden. Wie hoch der Anteil dieser, in den NVBW Daten schlummernden Karteileichen ist, lässt sich für uns momentan schwer abschätzen.

Nicht zugeordneter NVBW-Halt, wohl aber anderer Steig des Haltes

Für ca. 10% der NVBW-Steige konnten wir zwar den Steig selbst keinem OSM-Stop zuordnen, wohl aber andere Steige.

Eine mögliche Ursache hierfür sind historische Steig-Informationen in den NVBW-Daten, die leider nicht mit einem Gültigkeitszeitraum ausgewiesen sind. So werden z.B. in Stuttgart teilweise noch Steige der Straßenbahn (diese hatte eine Tiefeinstieg) ausgewiesen, obwohl diese schon vor Jahren zurückgebaut wurden.

Oder es der angegebene Steig ist mutmaßlich nur ein temporärer Datensatz gewesen wie hier in Obersulm:

Teilweise sind Haltestellen, die vor Ort baulich nur als eine Haltestelle ausgeführt sind (und so auch nur einmal gemappt werden sollten) in der NVBW-Haltestellenliste als mehrere logische Steige beschrieben, evtl. weil dort häufig mehrere Busse hintereinander halten.

Oder Ankunfts- und Abfahrtsposition unterscheiden sich, obwohl dies baulich nicht erkennbar ist.

Teilweise sind in den NVBW-Daten auch Warte-/Überholpositionen von Fahrzeugen als "normaler" Halt dokumentiert, die jedoch nicht für den Passagierverkehr als Zu- oder Ausstieg nutzbar sind.

Teilweise weichen NVBW-Halt und OSM-Halt so stark voneinenander ab, dass wir beide nicht mehr einander zuordnen. Der entsprechende OSM-Halt ist dann eventuell nicht (oder falsch) zugeordnet.

Nicht zugeordneter OSM-Halt

Ca. 8000 von uns als zu matchende OSM-Halte erachtete Halte konnten wir nicht zuordnen.

Für einen großen Teil liegt dies daran, dass die NVBW-Halte nicht verortet sind und wir bisher noch kein rein alphanumerisches Matching anhand von Orts- und Haltestellennamen vornehmen. Hiervon sind vor allem Halte im Hohenlohekreis, Rhein-Neckar-Kreis, Neckar-Odenwald-Kreis, Main-Tauber-Kreis, Enzkreis und in Schwäbisch Hall betroffen. Zum anderen umfasst der OSM-Baden-Württemberg-Extrakt noch einige Halte jenseits der Baden-Württembergischen Landesgrenzen.

Wenn wir nicht ableiten können, welchem Verkehrsmittel zugeordnet ist, z.B. weil ein bus=yes fehlt, werden eventuell platform und stop_position als zu matchen betrachtet, was zu falschen Zuordnungen und ungematchten osm_stops führt.

Eine besondere Herausforderung für unser Matching sind Busbahnhöfe. Hier kommen bis zu 22 Steige auf engem Raum zusammen, die NVBW-Koordinaten sind häufig nicht annhähernd so präzise wie die in OSM erfassten. Unser Matching wertet hier die local_ref eines bus_stops aus, sofern vorhanden. Den OSM-Namen des Steiges werten wir ebenfalls aus. Aus unserer Sicht sollte dieser die Steignummer jedoch nur enthalten, wenn der bus_stop Teil einer übergeordneten stop_area-Relation ist, die den Haltestellennamen trägt.

Spezielle Abgleichsituationen

bus_stop an stop_position statt an platform

Nach OSM Wiki sollte ein mit highway=bus_stop getaggter Node den Wartebereich einer Bushaltestelle markieren. Insbesondere im Deutschland hat sich jedoch auch teilweise durchgesetzt, dass bei gegenüberliegenden Haltestellen die Halteposition des Buses, der public_transport=stop_position Node mit highway=bus_stop ausgezeichnet wird (dies ist auf der deutschsprachigen Wiki-Seite auch so explizit im Wiki beschrieben, nicht jedoch auf der englischen).

Ein Beispiel ist die Haltestelle Suttnerstraße in Stuttgart Freiberg (n2073485619).

Aus unserer Sicht handelt es sich hierbei um eine Form von Taggen für den Renderer, da es in den heutigen Kartendarstellungen dazu führt, dass statt zwei dicht nebeneinanderliegenden Bus-Symbolen nur eines in der Mitte der beiden dargestellt wird. An solchen Stellen wollen wir nicht auf den highway=bus_stop-Node matchen sondern die jeweiligen platform-Objekte.

bus_stop an stop_position und platform

Während das ausschließliche Taggen von highway=bus_stop an der stop_position statt der platform aus unserer Sicht unglücklich ist, aber wenigsten derzeit in Karten sinnvoll gerendert wird, ist eine Doppeltvergabe an stop_position und platform noch nicht einmal in der Karte ansprechend.

platform Node ohne bus_stop

Neben dem oben genannten Speziallfall bei gegenüberliegenden Bushaltestellen gibt es aber auch ganz generell viele Haltestellen-Nodes, die ausschließlich nach PTv2 (public_transport=platform, bus=yes) jedoch ohne Auszeichnung highway=bus_stop getaggt wurden. Ob aus Gründen der Rückwärtskompatibilität ein highway=bus_stop ergänzt werden sollte, wird in der Community diskutiert.

Jedenfalls werden diese derzeit in den meisten Karten nicht mit einem Haltestellen-Symbol dargestellt.

bus_stop ohne platform

Auch den umgekehrten Fall gibt es: Bushaltestellen mit Auszeichnung highway=bus_stop jedoch ohne Auszeichnung public_transport=platform, bus=yes.

bus_stop/platform ohne Namen

In BW haben derzeit noch 1702 bus_stop Nodes keinen Namen und dieser ist auch nicht indirekt ableitbar. Ableitbar wäre er z.B. aus einer übergeordneten stop_area, die den Namen definieren würde.

Zunehmend wird auch von der - bisher noch nicht im Wiki beschriebenen - Möglichkeit Gebrauch gemacht, einen Knoten einer platform mit highway=bus_stop zu kennzeichnen. Dieser hat dann häufig keinen weiteren Tag sondern nur die übergeordnete platform.

stop_position oder platform ohne Modalität

Teilweise sind stop_positionoder platform nicht mit dem bedienten Verkehrsträger (z.B. bus=yes) ausgezeichnet. Dies beeinträchtigt unsere Matching mehrfach. Zum einen identifizieren wir stop_position und platform eventuell nicht als einander zugehörig und versuchen beide zu matchen, zum anderen ordnen wir eventuell NVBW-Halte anderer Verkehrsträger zu.

Namensdifferenzen zwischen stop_position und platform

Teilweise weichen einander zugehörige stop_position und platform hinsichtlich ihres Namens voneinander ab. Können wir diese aufgrund fehlender stop_area Relation nicht dennoch als zum gleichen stop gehörig erkennen, so versuchen wir beide zu matchen, was zu fehlerhaften Zuordnungen führt.

Matching-Probleme

Aber auch ohne Datenfehler ist unser Matching noch nicht fehlerfrei. Wir haben derzeit insbesondere Probleme bei der auch bezüglich der Fahrtrichtung korrekten Zuordnung von Bushaltestellen. Diese treten insbesondere dann auf, wenn die Lageabweichungen zwischen NVBW und OSM hoch sind und wir weder Steig-Bezeichnungen noch Folgehalte für die Halte ermitteln können.

Nachfolgend beschreiben wir unseren Ansatz für das Matching.

Matching-Verfahren

Zur Zuordnung der mutmaßlich korrespondierenden Halte/Steige verwenden wir den nachfolgenden Algorithmus:

1. Berücksichtige als zu matchende NVBW-Halte/Bereiche/Steige nur solche die
   1. kein Ersatzhalt sind
   2. im Netzbereich liegen
   3. kein x+Ride sind
   4. kein Zugang sind
   5. eine IFOPT haben
   6. eine Bereichs-Nummer < 10 haben (größere sind i.d.R. Zug-/Eingänge, Parkplätze, Brücken etc., leider nicht anders auswertbar)
2. Berücksichtige als potentielle OSM Halt/Steige:
   1. Alle Nodes mit highway=bus_stop (nicht, wenn diese public_transport=stop_position sind und es gleichnamige platform in der Nähe gibt), railway=stop/tram_stop (nicht, wenn diese nicht gleichzeitigpublic_transport=stop_position sind, es aber gleichnamige public_transport=stop_positions in der Nähe gibt) oder public_transport=stop_position (letztere bei Bussen nur, falls ref gesetzt, als Spezialfall an Busbahnhöfen, wo mitunter mehrere Stops von einem Steig bedient werden)
   2. Alle Nodes und Ways mit public_transport=platform (für Ways berechnen wir Steigmittelpunkt und verwenden diesen)
   3. Alle public_transport=station oderrailway=halt, falls nicht gleichnamige stops aus Schritt 1 existieren (teilweise sind die stops nicht erfasst)
3. Ist das name-Attribut nicht gesetzt, so übernehmen wir dies aus der stop_area-Relation der der eventuell Stop zugeordnet ist bzw. der den Node enthaltenden benannten Line-platform)
4. Nochmaliges Filtern der in Frage kommenden OSM-Halte (z.B. präferieren wir bus_stop Nodes wenn es gleichzeitig namensgleiche platform-Lines in der Nähe gibt)
5. Ermittle potentielle Match-Kandidaten für jeden NVBW-Stop im Umkreis von 400m
6. Vergib für jede NVBW-Steig/OSM-Stop Paarung ein rating, das sich aus folgenden Komponenten zusammensetzt
   1. eventuell vergebene ref:IFOPT, deren normalisierter Wert mit normalisiertem Wert der NVBW-Haltestelle übereinstimmen muss
   2. Namensübereinstimmung via Bigram-Matching (bessere Wertung des Vergleichs Haltestelle bzw. Haltestelle_lang mit name-Tag des OSM-Stop)
   3. Inverse Distanz (je näher, umso besser das rating, derzeit linear)
   4. Übereinstimmung der Steig-Referenz (local_ref bzw. ref des OSM-Stops stimmt überein mit Steig-ID)
   5. Namensübereinstimmung des oft in Name_Steig angegeben nächsten Haltes mit dem Namen des nächsten, aus der OSM-Route-Relationen abgeleiteten Haltes (bzw. ein Malus, falls der vorhergehende Halt eine hohe Übereinstimmung hat)
   6. Übereinstimmungsgrad der Modalität
7. Ignoriere alle Paarungen, für die die Modalitäten (bus, train, light_rail, tram,...) offensichtlich nicht zusammenpassen und die einen heuristisch ermittelten Schwellwert unterschreiten
8. Für alle Steige eines Haltes: bestimme die Kombination ein-eindeutiger Zuordnung mit der besten Gesamtbewertung (ermittelt anhand Summe der individuellen Ratings)
9. Bei Mehrfach-Zuordnungen eines OSM-Stops zu Steigen verschiedener Halte, behalte nur die des besser bewerteten bei

Dieser Algorithmus ist ein erster Ansatz und kann sicher noch verbessert werden.

Zusammenfassung

Dank der Veröffentlichung der baden-württembergischen Haltestellen unter einer offenen Lizenz konnten wir einen Abgleich mit den in OSM erfassten Haltestellen durchführen.
Hierbei konnten wir ca. 52% der NVBW-Halte erfolgreich OSM-Halten zuordnen, weitere 16% nur mit größeren Zweifeln und 32% gar nicht. Umgekehrt konnten wir ca. 71% der OSM-Halte erfolgreich zuordnen, 17% jedoch gar nicht.
Die Ursachen hierfür liegen zum in unzureichend beschriebenen Haltestellen in den NVBW-Daten (keine angegebenen Gültigkeitszeiträume für Haltestellen, fehlende oder ungenaue Koordinaten, unzureichende Angaben zum angebundenen Verkehrsmittel oder der Art der Haltestelle), oder mitunter fehlenden oder inkonsistent erfassten Haltestellen in OSM (fehlende Namen oder Angaben zum Verkehrsmittel).
Unser Gesamteindruck ist, dass dort, wo OSM-Daten vorhanden sind, diese von deutlich höherer Qualität sind, als die offiziell verfügbaren. Von großem Wert für eine zukünftige Verknüpfbarkeit der beiden Datenbestände sind die offiziell vergebenen IFOPT-Kennungen der Haltestellen.
Jedoch: Auch wenn der Gedanke eines automatischen Imports der IFOPT-Schlüssel vielleicht dem ein oder anderen verlockend erscheinen mag: weder die Qualität der Datenbestände noch die unseres Abgleichs geben dies her.

Ausblick

Im nächsten Blogpost zeigen wir, wie man diese Ergebnisse mit QGIS und QWC2 als Web-Anwendung veröffentlichen kann.