Ohne die uic_ref Daten der Deutschen Bahn oder von anderswo in OSM rein zu holen wird es aus meiner Sicht auch nicht gehen in Betrieb befindliche Personenbahnhöfe zu ermitteln. Man sehe sich mal diese “Haltestellen” an:
Um solche Stationen von “richtigen” Bahnhöfen unterscheiden zu können, wurden in der Vergangenheit diverse Tags wie station=miniature
oder usage=tourism
genutzt. Ein einheitliches Tagging gibt es bisher nicht. Da müsste sich mal jemand finden, der ein Taggingschema dafür entwickeln möchte.
Wenn du die von mir vorgeschlagenen Varianten (public_transport=station
oder Routenrelationen) nutzt, kannst du diese Stationen aber sauber herausfiltern.
Das heißt, die Idee wäre, man könnte den uic_ref tatsächlich nutzen, um mit dem entstehenden Datenbild ein Netz von Regional- und Fernbahnhöfen zur Personenbeförderung ableiten zu können. Mit dem sowieso in OSM vorgesehenen uic_ref sind vermutlich auch noch andere Use Cases abbildbar, die Kollegen von openrailwaymap wissen dazu bestimmt mehr.
Ich denke, dass die Abfrage nach uic_ref
im Ergebnis vielleicht dem entspricht, was du suchst, aber sozusagen als Korrelation und nicht als Kausaliät. uic_ref
ist letztlich nur eine ID, die nicht aussagt, ob eine Station regulär bedient wird, höchstens indirekt.
Ein konstruiertes Beispiel dazu: Wenn eine RB-Linie eingestellt wird, aber die Strecke und die Stationen für den Museumsbetrieb in Betrieb bleiben, sollten dann automatisch die uic_ref
von den Stationen entfernt werden, damit diese nicht mehr als regulär bediente Personenbahnhöfe gelten?
Probleme sehe ich auch in Ländern, in denen es diese Nummern gar nicht gibt oder sie mangels Quellen nicht in OSM erfasst werden können. Als internationales Projekt sollten wir bemüht sein, auch dort allein mit vor Ort erfassbaren Daten zwischen regulären und unregelmäßig bedienten Stationen unterscheiden zu können.
Abgesehen davon sehe ich das Tag inzwischen auch kritisch hinsichtlich der Überprüfbarkeit. Zur Erfassung dieser Angaben sind wir auf externe Datensätze angewiesen, da die Information nicht On the Ground erfassbar ist. In einigen Ländern können wir die Nummern daher schon gar nicht erfassen, weil es keine geeigneten Open-Data-Datensätze gibt. Die Mapper selbst können im Grunde auch nicht nachvollziehen, ob die Nummer überhaupt richtig ist. Im Grunde handelt es sich bis auf das Länderkürzel der ersten zwei Ziffern um eine willkürliche Zahl.
Darüber hinaus sind die Nummern auch gar nicht so einheitlich, wie das auf den ersten Blick scheint. Aus eigener Erfahrung mit der intensiven Beschäftigung diverser Open-Data-Datensätze aus dem ÖPNV-Bereich weiß ich, dass Stationen auch mehrere verschiedene Nummern haben können. Sonderfälle, mit denen ich zu tun hatte, waren zum Beispiel:
- Eine Station in Deutschland hatte im DB-Datensatz eine Nummer beginnend mit 80. Im Fahrplan der SBB hatte die Station eine Nummer, die auch mit 80 beginnt, aber sich in den übrigen Ziffern unterschieden hat.
- Bei Infrastruktur, die in Land X liegt, aber durch eine Bahngesellschaft aus Land Y betrieben wird (z.B. Basel Bad, Region Schaffhausen), gab es je nach Datensatz verschiedene Nummern mit verschiedenen Länderkürzeln (die DB hatte für die Station eine 80er-Nummer, die SBB eine 85er-Nummer).
Ich könnte also einen Batch Import bzw. “Merge” programmieren, vorausgesetzt dass
…
Klingt das sinnig oder wurde das schon versucht, oder was würde dagegen sprechen? Für mich sieht es jedenfalls nicht so aus, als wenn die Datensätze der Deutschen Bahn jemals importiert wurden.
Generell würde ich davon abraten, automatisch per Script Daten zu bearbeiten. Zu groß ist die Gefahr, dass durch Programmierfehler, nicht berücksichtige Sonderfälle oder Fehler in den externen Datensätzen Datenmüll entsteht. Dazu siehe auch DE:Automated Edits code of conduct - OpenStreetMap Wiki.
Wenn, dann sollten solche Importe oder Abgleiche manuell erfolgen, zum Beispiel mit einer Mapillary-Challenge oder einer Karte, die beide Datensätze vergleicht und Unterschiede anzeigt. Es gibt in OSM einfach schon zu viele Daten, als dass man automatisiert übernehmen könnte. Ohne Mapper, die sich die Datenunterschiede ansehen und entscheiden, was übernommen wird und was nicht, wird es nicht funktionieren.
Hälst du es für sinnvoll, die uic_ref
Idee trotzdem umzusetzen, sofern ein aktueller Datensatz erhältlich sein sollte? Immerhin ist ein Ansprechpartner auf der Seite der DB zu finden. Die sind vielleicht bereit, den Datensatz zu erneuern.
Wenn nein, dann würde ich mir das Vorhaben mal notieren. Ist ja kein riesen Aufwand sowas.
Wie oben erklärt, halte ich persönlich vom Import der uic_ref
nicht besonders viel. Den Abgleich von Namen, Betreibern, Lage, etc. fände ich dagegen eine sinnvolle Sache. Falls du dich damit beschäftigen möchtest, fände ich das super!
Das einzige was ich noch bemerkenswert finde ist, dass bspw. Hemmoor durchaus mal die uic_ref lt. DB CSV hatte und auch damit angelegt worden ist, aber in Revision 9 entfernt wurde (wie auch bei anderen Haltestellen auf dieser Linie)
Der Mapper hat die Daten anscheinend von dem Stationspunkt an die stop_area
übertragen. Kann man sich drüber streiten, ob das richtig ist und ob die Daten nur an einer Stelle oder doppelt gepflegt werden sollten. Würde hier zu weit ausholen und sollte in einem separaten Thema diskutiert werden.