DE talk:Public transport

Proposed move

Is it not conventional for the title for articles that are translations for English articles to have English headings? Without it the article appears in an odd place in the categories. Would DE:Public transport be better? PeterIto 10:18, 13 June 2012 (BST)

I have used the guidelines from DE:Wiki Übersetzung (which, by the way, has also a translated title). I think this convention may have been used/was useful in the past, but now we have the nice {{Language}} template - it is no problem to switch to any language of an article even with different (local) titles. From a user perspective translated titles are clearly preferrable, because mappers will get better results when using the search function without English keywords.--Martinq 19:09, 13 June 2012 (BST)

Ein paar Kritikpunkte

...Routen- und Masterrouten-Relationen, die diesem Schema vollständig entsprechen, werden mit public_transport:version=2 gekennzeichnet.

Das "Masterrouten" sollte entfallen. Sonst entsteht der Eindruck, dass Routen nach V1 Masterrouten haben könnten.

...Wenn von einer Station keine platform exisitert, wird sie ausgelassen. ...

Das gilt ganz genauso für die stop_position. (Es gibt einen problematischen Fall (wohl nur bei Bussen, aber da nicht selten): Bei zwei gleichnamigen Halten nacheinander bei der ersten die platform weglassen und bei der zweiten den stop. Da muss einer der beiden ergänzt werden, sonst zählt es als ein Halt)

...via... wichtige Zwischenhalte

Nein, via soll nicht für wichtige Zwischenhalte benutzt werden. Es sollen Zwischenhalte angegeben werden, die die Varianten unterscheiden. Dabei soll man möglichst wichtige Zwischenhalte auswählen.

...Falls die Linie keine Nummer hat, die auf ganzer Länge gilt, dann sollte sie weggelassen werden...

Das steht nicht im PTv2. Das sind zwei getrennte Master. Insbesondere im Busbereich gibt es ziemlich oft auch einige Varianten mit nur einer ref und die ref im Master ist immer identisch mit der in der Variante (denn man kann sie aufgrund der bloßen Existenz einer Masterrelation weglassen). Das ganze Master-System funktioniert nicht mehr, wenn die ref nicht die Linie definiert. Der Wechsel auf die andere Linie kann PTv2 leider nur über note angegeben werden. next_ref und prev_ref oder succ_ref und pred_ref wären evtl. geeignete Tags.

user:Weide

Danke für deine Korrekturhinweise. Die ersten Kritikpunkte habe ich beseitigt.

Beim vierten muss ich dir leider widersprechen. Es gibt Routen, die vom Fahrgast als eine Route wahrgenommen werden, aber mehrere Nummern haben. Ein Beispiel ist die Linie R4 im Verkehrs- und Tarifverbund Stuttgart (VVS). Es handelt sich dabei um die RB-Linie Stuttgart Hbf–Heilbronn Hbf–Bad Friedrichshall Hbf–Osterburken. Der VVS bezeichnet die Linie als R4, der VRN als R85. Beide Nummern gelten nur auf einem Teilbereich (VVS Stuttgart Hbf–Kirchheim (Neckar), VRN Bad Friedrichshall Hbf–Osterburken). Der Abschnitt dazwischen ist der Heilbronn-Hohenlohe-Haller Nahverkehr (H3NV), der keine Nummer vergibt. Keine der genannten Nummern steht an Fahrzeugen oder auf Aushängen, sondern nur in Fahrplänen der Verbünde und auf deren Website. Wenn man jedoch im DB-Kursbuch schaut, dann stellt man fest, dass die Linie eine Linie ist (es gibt Zugläufe Stuttgart–Heilbronn, Stuttgart–Osterburken, Stuttgart–Neckarsulm und Bad Friedrichshall Hbf–Osterburken). In Baden-Württemberg gibt es keinen landesweiten Nummern für Regionalzüge, die werden von den Verbünden vergeben und daher nicht an den Fahrzeugen und auf Anzeigetafeln angezeigt. --Nakaner (talk) 09:53, 14 December 2014 (UTC)

Die ersten Kritikpunkte sind leider noch nicht beseitigt. In der Tabelle zu master_route muß die unterste Zeile entfallen. --Axelr (talk) 15:49, 21 September 2017 (UTC)

Bushaltestelle mit PTv2 und bus_stop

Im Artikel steht, dass wenn ein richtiger Bussteig vorhanden ist, die Node auf der Straße mit "public_transport=stop_position" getaggt werden soll und zusätzlich auch mit "highway=bus_stop". Außer in diesem Artikel finde ich diesen Hinweis jedoch nirgends, auch nicht im englischen Originaltext des Artikels. Ganz im Gegenteil weist der Artikel DE:Tag:highway=bus_stop ausdrücklich darauf hin, dass "highway=bus_stop" neben der Straße verwendet werden soll. Im Zuge der Umstellung auf PTv2 nun ausgerechnet den Tag "highway=bus_stop", der nur aus Gründen der Rückwärtskompatibilität noch angegeben wird, im Widerspruch zu seiner Definition zu verwenden, erscheint mir wenig sinnvoll. Hat jemand etwas dagegen, wenn ich den Satz "Er erhält auch das Tag highway=bus_stop." aus der Tabelle lösche? Grüße, --Biff (talk) 15:01, 6 May 2016 (UTC)

Hallo Biff, von meinem Verständnis her wäre es sinnvoll diesen Tag eher an den Bussteig zu hängen. Da dort aber schon highway=platform Verwendung findet, hat man sich offenbar entschieden ihn an den Node auf der Straße zu hängen. Ich bin grundlegend auch dafür es wegzulassen um langsam mal diese alten Zöpfe abzuschneiden, aber werden die Haltestellen denn schon vernünftig gerendert wenn sie nur mit den PTv2-Tags versehen sind? --Esperanto (talk) 19:10, 6 May 2016 (UTC)

Auch highway=platform soll nicht mehr verwendet werden (und kollidierte wohl auch früher schon häufiger mit <highway=bus_stop>). Den Hinweis darauf würde ich also entfernen. Für die Rückwärtskompatibilität reicht es aus, eine Node neben der Straße mit <highway=bus_stop> zu taggen, die wird dann auch vernünftig gerendert. --Biff (talk) 20:58, 2 June 2016 (UTC)

highway=bus_stop direkt auf die Straße zu schreiben wo schon public_transport=stop_position steht schein mir nicht durchdacht zu sein. Es ist auch im Gegensatz zu dem was in der Wiki steht. Im aller einfachen Fall, wenn nicht bekannt ist wo genau das Bushaltestellen Schild steht, mag es eine Zwischenlösung sein. In allen anderen fällen sollte man es seitlich von den Straße platzieren. Gut es so auf ein neues System mit public_transport umgestellt werden. Diese sollte aber wenigsten die Anforderungen des alten Systems erfüllen. Das heißt unter anderem es sollte auf der Standardkarte gerendert werden. Aber das ist bis jetzt nicht der Fall (issues/311). --geozeisig (talk) 10:52, 1 November 2017 (UTC)

Name

Beim taggen der Bushaltestellen wird ein sehr inkonsequentes Namensschema verwendet. In den Fahrplänen steht meistens erst der Ortsname und dann der eigentliche Name der Haltestelle. Wie sollte ich das in OSM verwenden? Den Ortsnamen weglassen? --Crbrhz 09:36, 18 September 2016 (UTC)

Ich würde mich an die Schreibweise des örtlichen Verkehrsverbunds halten. Beim Hamburger Verkehrsverbund werden alle Haltestellen im Umland mit Ortsnamen versehen, aber in Hamburg selbst wird er weggelassen.--GerdHH (talk) 09:50, 14 June 2019 (UTC)

Insbesondere, wenn die online Fahrplanauskunft der Bahn (bahn.de) die Haltestelle unter dem Namen nicht findet würde ich zum Tag name= zusätzlich das Tag ref_name= angeben ([1]). Das hilft sehr die Abfahrzeiten zu ermitteln. --Bernward1 1. Juli 2024

Reihenfolge der Haltepositionen verstehe ich nicht

Im Text steht:

Die korrekte Reihenfolge ist wichtig, sie muss die Folgende sein:

Rolle stop – 1. Halteposition

Rolle platform – 1. Plattform

Rolle stop – 1. Halteposition

Rolle platform – 1. Plattform

…

Fahrweg (leere Rolle), geordnet''

Ist das ein Fehler? Warum sollte man die erste Halteposition mehrfach eingeben? --Jo (talk) 22:22, 2 January 2019 (UTC)

Ich denke das war ein Kopierfehler. Habe dies mal korrigiert. --Josef73 (talk) 12:40, 27 February 2019 (UTC)

Unklar: Wo beginnen und enden Verzweigungen im Fahrtweg?

Im Text steht "Verzweigungen im Fahrtweg sind nicht möglich, für jede Fahrtvariante ist eine eigene Routenrelation erforderlich." Aus dem Text geht nicht hervor, wo die Route mit der alternativen Linienführung beginnt und endet.

Ich sehe zwei Möglichkeiten:

1. Eine Extra-Relation nur für den Abschnitt wo sich die Linienführungen unterscheiden
2. Beide Reationen von Beginn bis Ende, in identischen Abschnitten sind es dann zwei Buslinien mit gleicher Nummer.

Nr. 1 hat den Nachteil, dass man außerhalb der Verzweigung nicht sieht, dass es noch andere Linienführungen gibt.

Nr. 2 hat den Bachteil, dass bei Bussen mit vielen kleineren alternativen Linienführungen die Anzahl der Linien sehr hoch werden kann.

Was ist richtig?

--Jo (talk) 19:59, 26 January 2019 (UTC)

Beim "Flügeln" von U-Bahn-Strecken (A-B-C1|C2) haben wir in Hamburg je eine Relation A-B, B-C1, B-C2 und alles zusmmengebunden in einer Master-Relation. Beispiel: Volksdorf-Großhansdorf --GerdHH (talk) 14:22, 29 April 2019 (UTC)

OK, also Nr. 2. Eine Buslinie mit zwei Routenvarianten A-B-XX-D-E und A-B-YY-D-E würde ich also entweder mit 4 Relationen abbilden (A-B, B-XX-D, B-YY-D und D-E) oder mit 2 Relationen (A-B-XX-D-E und B-YY-D).

2 Relationen fände ich einfacher und auch besser, wenn z. B. nur ein sehr geringen Anteil der Busse über YY fährt und der Großteil über XX.

Nachteil beider Varianten von Nr. 2 ist, dass bei größerer Anzahl von Teilrouten nicht immer erkennbar ist, welche Kombinationen von Teilrouten tatsächlich durch Busse gefahren werden.

Grüße, Jochen --Jo (talk) 21:00, 1 May 2019 (UTC)

Normal würde ich Doppelerfassungen derselben Strecke vermeiden und bei Deinem Beispiel 4 Relationen nehmen. Wie oft die jeweilige Variante genommen wird, kannst Du ja mit interval=* festhalten. Ein anderer Fall, der häufiger vorkommt, wären Expresszüge, die nicht an allen Stationen halten. Da würde ich dann für jede Variante (Normal/Express) eine eigene Relation nehmen, aber die ganze Strecke halt zweimal erfassen. Möglich ist beides, ich würde das pragmatisch entscheiden. --GerdHH (talk) 11:56, 2 May 2019 (UTC)

Ich gebe Dir recht, dass diese Fragen geklärt und im Wiki erläutert werden müssen. Abzweigungen erfolgen logischerweise an Kreuzungen, nutzen dieselbe Straße hin und zurück und haben Haltestellen, die auf Hin- und Rückweg der Abzweigung unterschiedlich angefahren werden. Meist ist das Muster für beide Richtungen der Hauptroute gleich (X > A1 > B > C > A2 > X). Im Moment erfasse ich die Abzweigung als zwei Relationen (Hin und Rück), um doppelte Elemente zu vermeiden (X > A1 > B und C > A2 > X), die ich in die Masterroute aufnehme. Aber die Reihenfolge der Haltestellen geht damit verloren. --GerdHH (talk) 10:03, 8 May 2019 (UTC)

OK, ich werde ergänzen, dass man selber entscheiden soll, ob man in der Relation der Routenvariante den gesamten Fahrtverlauf abbildet oder nur den Bereich, in denen sich die Varianten unterscheiden.

Ich habe bisher alternative Routen nicht an den Kreuzungen beginnen lassen sondern an der letzten gemeinsamen Haltestelle. Somit lässt sich in den meisten Fällen die Reihenfolge der Relationen ableiten. Zudem kann es Fälle geben, wo es noch vor der Routenverzweigung eine Haltestelle gibt, an der nur die Busse der einen Variante halten. Grüße, --Jo (talk) 18:48, 11 May 2019 (UTC)

Sehr gute Ergänzung, das macht vieles klarer. PTNA besteht darauf, dass Routen und Varianten immer an Haltestellen beginnen und enden müssen. Wenn das Konsens ist, sollte man den Hinweis auch in den Text aufnehmen. --GerdHH (talk) 08:25, 6 June 2019 (UTC)

Danke!

Wenn das so gefordert ist, dann sollten wird das hier auch nur so empfehlen. --Jo (talk) 21:10, 6 June 2019 (UTC)

PTNA (ich) geht davon aus, dass jede Variante - somit auch Teilrouten - komplett als eigenständige Relationen gemapped wird.

also "U-Bahn-Strecken (A-B-C1|C2) haben wir in Hamburg je eine Relation A-B, B-C1, B-C2" sollte mMn als A-B-C1 und A-B-C2 gemapped werden.

--ToniE (talk) 11:07, 1 July 2024 (UTC)

Strecken ohne Liniennummern

In Griechenland haben Regionalbusse meist keine Liniennummern, Stadtbusse aber schon. Das führt dazu, dass der Fahrweg der Regionalbusse in der Stadt nicht mehr erkennbar ist, weil nur die Liniennummern der Stadtbusse auftauchen. Nun soll man ja nichts taggen, was nicht auf den Schildern steht, aber für die praktische Nutzbarkeit ist das unbefriedigend. Beispiel: Chania/Kreta - wo fährt der Bus nach Heraklion? Die sauberste Lösung ware eigentlich, wenn die Renderer bei fehlendem ref=* eine Linienkennung aus from=*/to=* generieren würden. Außerdem ware es hilfreich, wenn Stadt-, Regional- und Fernbusse spezifische Tags bekommen und optisch unterschieden werden könnten, wie es bei Bundes-, Landes- und Kreisstraßen selbstverständlich ist. --GerdHH (talk) 14:49, 29 April 2019 (UTC)

service=* ist in der Definition ja auf Schienenverkehr zugeschnitten, aber mit commuter | regional | long_distance könnte man ja wundervoll auch Stadt-, Regional- und Fernbusse abbilden. --GerdHH (talk) 12:00, 2 May 2019 (UTC)

Auch PTNA hat ohne ref=* ein Problem.--GerdHH (talk) 05:10, 9 June 2019 (UTC)

Und ÖPNV-Karte zeigt im Regionalverkehr nur lauter Kommata als "Connections" --GerdHH (talk) 10:44, 25 June 2019 (UTC)

Nicht erfasste Haltestellen - verwirrender Satz

Ich habe folgenden Satz erstmal entfernt, da nicht erkennbar ist, was damit gemeint ist.

"Haltepositionen/Plattformen müssen eingefügt werden, wenn sie erfasst sind. Wenn bei einer Haltestelle die Halteposition oder Plattform nicht erfasst ist, ist das kein Grund, sie deshalb zu erfassen."

Dass eine nicht gemappte Haltestelle auch nicht in eine Relation aufgenommen werden kann, ist logisch.

Ich vermuzte es war folgendes gemeint "Noch nicht gemappte Haltepositionen/Wartebereiche werden weggelassen. Sollten noch nicht alle Haltestellen erfasst sein, so sollte eine entsprechende Bemerkung in [[note]] note oder [[fixme]] darauf hinweisen." So habe ich es jetzt aufgenommen.

Zudem waren manche Dinge dreimal beschrieben, z.B. die Rollen in einer Routenrelation. Einmal als Text über der Tabelle, dann in der Tabelle der Rollen, dann nochmal darunter als Text. Ich habe das alles zusammengefasst und dabei die langen Sätze zur besseren Lesbarkeit aufgelöst.

Grüße, --Jo (talk) 21:44, 11 May 2019 (UTC)

Unicode für Namen

In der Beschreibung des Tags name wird ein maschinenlesbares Format mit => als Trennzeichen vorgegeben. Wozu wurde ausgerechnet diese Zeichenkombination ausgewählt? Sollte es für den Menschen wie ein Pfeil aussehen, so wäre doch das entsprechende Unicode-Zeichen → (U+2192) sinnvoller. Dieser ist für den Fall wesentlich eindeutiger und Unicode-Symbole sind in OpenStreetMap längst vertreten.

--ChrissW-R1 (talk) 06:47, 19 July 2023 (UTC)

Garmin Navigatoren haben Probleme mit Unicode. Ich weiß aber nicht, ob das der Grund war. --GerdHH (talk) 07:43, 19 July 2023 (UTC)