Dann brauch ich mich nicht wundern, dass mich das verwirrt.
Ah, danke.
Das erklärt, warum die Karlsruher S2 lila ist, weil die hat korrekt route=tram, weil von der VBK als reine Straßenbahn nur nach BOStrab gefahren (Schienen außerhalb von KA gehören glaub der AVG, aber nach BOStrab) und warum die Karlsruher S1, die ist nämlich route=train (was’n da line=light_rail?!?), weil die fährt als Linie der AVG
- als Eisenbahn nach voller EBO (Hardtbahn-Teile)
- als Eisenbahn nach selbstgestrickter EBO (Albtal)
- als Straßenbahn nach BOStrab
- und in gut einem Jahr auch als Pseudo-U-Bähnle …
… auf Gleisen von AVG und VBK …
Und die Stuttgarter “U-Bahn” ist grün wegen falschem route=light_rail, während die Stuttgarter S-bahn ihr verwirrend gleiches Grün aus dem “S” zieht in der openpt …
Danke Phill,
und wie Michael (Nakaner) schon schrieb ist “Farbe” zunächst einmal ein “Problem”, eine Entscheidung des Renderers.
Und wie in den andere Beiträgen zu sehen ist, kommen da noch andere Informationen hinzu, um die Farbei auf der einen Karte “öpnvkarte.de” (?) zu definieren.
Sie wird durch die OSM-Datenbank nicht vorgegeben.
Die Frage, die daraus für mich resultiert ist: bieten die Daten in der OSM-DB genügend Kriterien um die U- / S- / Stadt- / Tram- / Eisenbahn-Verkehrsmittel zu unterscheiden und werden diese konsequent und konsistent angewendet?
- S- und Eisenbahn fallen ja schon wegen “train” zusammen
- Stadt- und Tram-Bahn wohl auch wegen “tram”, oder “Stadtbahn” fällt mit was anderem zusammen?
“light_rail” als “route_master” und “route” zu eliminieren wäre auch mein Wunsch, da bin ich ganz bei den anderen, denn das ist in PTv2 als Verkehrsmittel nicht definiert.
“Verkehrsmittel” als ungleich “Verkehrsinfrastruktur” (auf dem Boden liegend, in der Luft bei Hängebahnen, …) zu verstehen.
Gruß,
Toni
Also ich habe kein Problem mit der Farbe an sich. Aber wenn ein und das selbe Verkehrsmittel in einer Stadt als Straßenbahn, woanders als Stadtbahn und wieder woanders als U-Bahn in der Legende auftaucht, ist das ziemlich unglücklich und in sich nicht schlüssig. Und dieses Problem haben Stadt- und S-Bahnen.
Das mag an der Art der Eintragung in der Datenbank sowie den Kriterien liegen, ist dadurch aber kein kleineres Problem. Eine konsequente Anwendung ist ja was ich mir wünsche. Ob die Stadtbahnsysteme jetzt alle blau oder grün oder sonst was sind und als Straßenbahnen oder U-Bahnen eingetragen werden ist mir gleichgültig, verschiedene Farben sollten sie aber nicht besitzen (Vergleiche Köln, Stuttgart und Frankfurt).
Grüße, Phill
Das fängt doch aber damit an, als welches Verkehrsmittel man ein bestimmtes in einer konkreten Stadt ansieht. Jetzt beantworte mir dich mal meine Frage, welche Verkehrsmittel Stuttgart hat.
Hi Phill,
einen Überblick über den Bahnverkehr in OSM findest du hier bei PTNA.
Das ist eine IST-Analyse. Hier sind “train”, “light_rail” und “monorail” in DE gesucht worden. “tram” und “subway” werden nicht explizit gesucht, tauchen u.U. aber durch Seiteneffekte auf, sind aber nicht vollständig.
In dieser CSV-Liste kannst du ermitteln, was davon als “light_rail” getagged ist.
Das könnte dir einen Überblick über die Menge der zu erwartenden Relationen in DE geben …
Bevor du anfängst umzutaggen, sollten mMn noch mehr Stimmen eingefangen werden.
Ich kenne einige Mapper, die sich an ÖPNV/SPNV abrackern und deren Meinung hier noch nicht zu hören war, die ich aber gerne hören würde.
Die arbeiten in den Bereichen NW-AVV, BY-AVV, VRS, VRR, WT, VBB, VVS, MVV, MDV, VMS, HVV, NVV, RVF, RHB, VGN, VRN, RMV, …
Wäre evtl. ein anderer (neuer) Threadtitel besser, der direkt konkreten Bezug nimmt auf die zu diskutierenden Änderungen?
Gruß,
Toni
Hey
Ich sehe “route=light_rail” durchaus als wichtige Unterteilung. Zumindest für die Straßenbahnen im Raum Mannheim/Heidelberg/Karlsruhe macht sie durchaus Sinn. An den “railway=*” Werten der Mitglieder lässt sich das nicht ablesen und weder “tram” noch “train” ist geeignet.
Bei https://öpnv-karte.de finde ich die Darstellung der Städte, die ich kenne, eigentlich konsistent. Hier geht es wohl eher darum ob die Namen und Erwartungen die gleichen sind. Was erwarte ich, wenn “S-Bahn” im Namen ist ? Sind alle Straßenbahnen bzw. U-Bahnen gleich ?
Grüße skyper
Mammi71
Stuttgart hat eine Stadtbahn, wenn man diese mit light rail taggen möchte und das hier als richtig empfunden wird, ist das vollkommen okay. Ich betrachte es nicht als falsch. Im Umkehrschluss betrachte ich es dann aber als falsch, wenn in Köln und Hannover, Düsseldorf oder Frankfurt etc. andere Stadtbahnen nicht als light rail getaggt werden, sondern als Tram oder U-Bahn. Das darf ja nicht auf Empfindungen beruhen sondern sollte belegbar sein, wieso entsprechend getaggt wurde.
Dem entsprechend geht es meiner Meinung nach auch nicht um Erwartungen bezüglich der Systembezeichnungen, sondern einer technischen Klassifizierung. Aber ja, wenn ich U-Bahn lese, erwarte ich auch eine U-Bahn und keine Stadtbahn. Bei einer Straßenbahn erwarte ich ebene eine solche und kein System mit 76 U-Bahnhöfen (Stadtbahn Köln/Bonn) und eigener Trassenführung sowie Überlandstrecken (Vergleich Karlsruhe?).
Was ich damit sagen möchte ist, dass verschiedene Bahnsysteme mehr oder weniger klar kategorisiert werden können, wenn auch nicht immer. Ich wünsche mir einfach, dass man versucht diese Kategorien zu berücksichtigen, sodass ein technisch vergleichbare Systeme wie die Stadtbahnen von Köln, Stuttgart und Düsseldorf eben einheitlich getaggt werden. ToniEs Liste bestätigt mich da irgendwie auch.
Tatsächlich habe ich nicht den absoluten Durchblick, was die Bearbeitung der Datenbanken sowie der relevanten Einflussgrößen angeht. Aber die Ergebnisse sind so einfach nicht nachvollziehbar. Deshalb sehe ich Optimierungspotenzial, dass ich hier gerne diskutieren wollte.
Grüße, Phill
Hallo zusammen,
da ich früher viel in diesem Thema unterwegs war, möchte ich doch gerne hierzu meinen Senf abgeben, auch, wenn die die letzten Jahre kaum noch aktiv war.
Gehen wir dazu mal ins grundsätzliche und lassen Punkte wie verschiedene Farben beiseite, da dies zu ändern ohnehin nicht in unserer Macht liegt.
Ich greife mir mal Tonis Beitrag heraus, da er meiner Meinung nach am besten das Problem beschreibt:
Mal aus der deutschen technischen Sicht betrachtet: Wir haben zwei verschiedene Systeme, die man unterscheiden muss: EBO und BOStrab. EBO wird einheitlich mit “train” gemappt, bei BOStrab ist das schwieriger, hier liegen tram und subway vor. Dabei ist das bis auf einige Ausnahmen technisch wie rechtlich dasselbe, nur die Bahnsteighöhe und die Art der Stromversorgung können variieren, das reicht als Kriterium aber auch nicht aus, um eines der Systeme zweifelsfrei zu benennen.
light_rail kann beides sein, ohne Beisein von BOStrab kommt es jedoch nicht vor.
Bei route=train können wir schon genügend unterscheiden, um ICEs, REs und S-Bahnen voneinander zu unterscheiden. Wäre das vieleicht ein Ansatz, um das Problem auch für den BOStrab-Bereich zu lösen?
Wenn man jetzt in die große weite Welt blickt, sieht man, dass dort idR eine ähnliche Aufteilung der verschiedenen Bereiche existiert.
Ausnahme bilden die Hybrid-Systeme, die es auch in verschiedensten Ländern gibt. Dies ist auch die eigentliche Definition von “light_rail” und das ist auch ein wesentlicher Grund, warum dieser Schlüssel noch nicht ausgestorben ist. Im deutschen hat man das “hybrid” ein wenig weiter gefasst und auch den Übergang zwischen “subway” und “tram” dazu gezählt, was mMn nicht die schlechteste Idee war.
Nimms mir nicht übel, aber das ist ein sehr schwaches Argument. Denn wie oben dargelegt gibt es durchaus Fälle, bei denen light_rail definitiv Sinnvoll ist. In Köln ist das ja noch harmlos, weil auf den EBO-Strecken nur maximal sporadischer Güterverkehr existiert. Aber bei “route=tram” auf einer Hauptbahn zusammen mit einem ICE kräuselt sich bei mir doch schon einiges. Und diese Systeme werden auch immer häufiger, so etwa in Karlsruhe, Kassel, Saarbrücken oder Chemnitz.
Ist diese Trennung in dieser Endgültigkeit sinnvoll? Im Ursprungsgedanken war das ganz anders: railway=rail - route=railway; rail=tram - route=tram; rail=subway - route=subway. Das kann mMn gerne als Grundgerüst bestehen bleiben. Natürlich muss man bei Übergängen differenzieren, das erschließt sich aber schon aus der Sache.
Abschlussfrage: Warum muss ein Schlüssel, der vor Jahren bei der Erstellung eines Taggingschemas aus bisher nicht nachvollziehbaren (weil bisher nicht erläuterten) Gründen nicht in das Schema aufgenommen wurde, obwohl er in dem Bereich existiere, per se falsch sein?
Meiner Meinung nach sollte hingegen schleunigst eine Definition des Schlüssels dort angefügt werden, da wir ohne viel weiter weg von dem zu beschreibenden Objekt sind als mit.
Grüße
Stimmt, das war “formal” und nicht “inhaltlich” argumentiert und nicht zielführend.
Einfachste Lösung wäre also zunächst: ‘light_rail’ in PTv2 “aufzunehmen” und richtig anzuwenden? “Normative Kraft des Faktischen”.
Gruß
Toni
Da wäre ich dabei. Mit route=tram war ich in Köln noch nie wirklich glücklich. Dass ich das damals nicht direkt mit geändert hatte lag weniger daran, dass das nicht im PTv2-Schema erwähnt war, sondern schlicht an der Tatsache, dass die S-Bahn Köln noch mit route=light_rail versehen war. Das wiederum hab ich dann irgenwann geändert, bin danach aber die Stadtbahn nciht mehr angegangen.
Grüße
Ich bin hier ganz bei dir, aber bitte mach nicht den Fehler, jetzt im Alleingang ganz Deutschloand umtaggen zu wollen. Alleine Köln aufzuräumen war damals schon ein ganz ordentlicher Brocken.
Grundsätzlich gilt:
-
Mache nie etwas ohne die örtliche Community. Vor allem, wenn es was großes ist. Die wird sich zurecht dagegen wehren, wenn plötzlich jemand von außen kommt und in ihren Änderungen rum pfuscht. Nebenbei soll das ganze ja auch dauerhaft wirken und das bekommst du nur hin, wenn du die örtlichen Mapper mitnimmst, weil die das ja danach auch pflegen sollen.
-
Mache Änderungen nur, wenn du dir wirklich zu 100% sicher bist. Großflächiges Umtaggen ohne genaues Hinsehen wird als mechanischer Edit interpretiert, der zurecht mit hohen Hürden versehen ist. Es besteht die Gefahr, dass du Fehler einbaust oder zementierst, weil du die örtlichen Gegebenheiten nicht kennst. Das ist es auch nicht wert.
Nebenbei gibt es da noch sehr viel mehr Chaos. Die S-Bahnen in Berlin und Hamburg sind infrastrukturseitig als light_rail gemappt, was in meinen Augen schon immer Unsinn war und auf einem Übersetzungsfehler des Begriffs “light_rail” fußt. Die Routen in Berlin sind inzwischen wenigstens auf route=train geändert, dafür aber jetzt mit line=light_rail, was soll das denn bitte? Warum nicht den korrekten Wert passenger=suburban? In Hamburg ist es immer noch bei route=light_rail.
Wenn man wirklich großflächig aufräumen möchte, dann sollte man mMn dort anfangen.
Grüße
In Karlsruhe muss sich bei Dir nix kräuseln, denn alle S-Linien, die mit der EBO in Kontakt kommen, haben route=train, nur die eine reine BOStrab-S-Linie (S2) hat route=tram, die hat auch ihr eigenes Gleis direkt neben dem ICE-Gleis …
Dann kräuselt es sich bei mir aber andersherum, nämlich bei route=train auf railway=tram…
Grüße
Fiel mir weiter oben schon bei der Karlsruher S1 auf, ist laut overpass aber wohl bei allen Karlsruhe-Heilbronner S-Linien ohne S2 und bei allten Berliner S-Bahnen in Verwendung, sonst weltweit nirgends, ach halt, und dort seufz 
Einen Tod musste sterben in Karlsuhe, Kassel & Co. 
Nicht mit route=light_rail
Grüße
Hallo zusammen,
meiner Meinung nach sollte gerade auch bei OSM es relativ klar geregelt sein, was welche Tags bekommt, da es ja sonst das Maschinelle auswerten sehr schwierig bis unmöglich macht. Wobei ich auch sage, dass wir nicht an der Deutschen Grenze aufhören sollten!
OSM ist International, daher wäre es natürlich das sinnvollste, wenn es auch International einheitlich ist (z.B. U-Bahn = Metro) und nur was wirklich Länderspezifisch ist dann Einzel regelt.
Um gleich auf die Maschinelle Auswertung zu kommen wäre ja hier z.B. PTNA eine, in der dann aber auch ALLE auftauchen sollten (auch U-Bahn & Straßenbahn, …).
Zur Unterteilung, was, wie einsortiert wird bin ich für die Bauart, bzw. auf welchen Schienen sie fährt!
Hier denke ich, dass bei PTNA der Punkt “2.3 S-/Stadt-Bahnen” auch unterteilt werden müsste und dies eben aus den tags eindeutig hervorgehen sollte!
Wenn ich hier mal das Beispiel München nehme:
1a) klassische “train” also ICE, IC, RE, RB, … (das steht ja nicht zur Diskussion)
1b) S-Bahn: Sie nutzt die normalen Bahn-Schienen (teilweise zumindest), fährt auch aus der Stadt raus und gehört soweit ich weiß auch zur Deutschen-Bahn → train
2) U-Bahn: eigene Schienen - meist im Untergrund
3) Tram: Die Bahn die in der Innenstadt oberirdisch fährt - In anderen Städten auch “Straßenbahn” (und wahrscheinlich auch “Stadt-Bahn”) - soweit ich weiß sind hier die Schienen auch wieder nicht kompatibel zur Bahn oder U-Bahn
Bei Stuttgart wäre es zwar ein bisschen schwieriger, da es eine Bahn gibt, sowohl unten als auch viele Strecken oben fährt:
Laut Betreiber wird sie als “Stadtbahn” bezeichnet, trägt aber in der Nummerierung ein “U” am Anfang.
Nachdem es in Stuttgart auch noch zwei Straßenbahn-Linien gibt hätte ich überlegt die anderen trotzdem als U-Bahn zu taggen.
Um aber jetzt zu “light_rail” zu kommen, denke ich, dass dies nicht ideal ist, da es ja nicht genau spezifiziert (wie auch in Wikipedia beschrieben. Nachdem ich nicht alle Variationen kenne will ich jetzt nicht fordern es zu streichen, aber in den Definitionen (OSM-Wiki / PTv2) sollte es klar festgehalten werden wie es richtig wäre.
Für mich wären zwei Möglichkeiten Denkbar (für die Relation - Linie eines Verkehrsmittels):
Favorit:
train → Bahnen & auch die S-Bahn
subway → U-Bahn
tram → Straßenbahn / Tram (Stadtbahn)
light_rail → Sollte möglichst nicht mehr verwendet werden, da zu ungenau (tram / subway nutzen)
Alternative:
train → Bahnen & auch die S-Bahn
light_rail → für U-Bahn, Straßenbahn & Tram (Stadtbahn)
→ aber mit zusätzlichem Tag, um es genauer zu unterscheiden!
Die Auswertung (PTNA) muss dementsprechend auch angepasst werden!
Für die Schienen selbst (railway) müsste es auch angepasst werden.
Das ÖPV-Mapping in OSM ist tot. Immer mehr Anwendungen würden jetzt unsere Daten benutzen … wenn sie irgendwie brauchbar wären. Also benutzen alle Anwendungen nicht-OSM-Routendaten und nehmen von OSM nur Fuß- und Radwege.
Wir hatten mal einen großen Fortschritt hin zu einem einigermaßen brauchbaren System – das war PTv2. Es hat sich aber nie durchgesetzt. Ich habe jahrelang intensiv nach PTv2 gemappt und dann das ÖPV-Mapping aufgegeben. Es gibt einfach keine ausreichende Akzeptanz in OSM für das einzige abgestimmte und beschlossene ÖPV-System.