Talk:Germany/Nahverkehr

From OpenStreetMap Wiki
Jump to navigation Jump to search

Hier sollen fragliche Aspekte geklärt werden. Bitte auch Links zu anderen Dokumentationen angeben, sofern vorhanden, damit man hier alle Infos zusammen hat. Und bitte die Signatur nicht vergessen - schon wegen des Datums - und das Einrücken mittels Doppelpunkt. --Krza 14:15, 4 December 2008 (UTC)


Hinweise

Es gibt neben der Wiki hier auch noch das Forum, die Mailinglisten und ggf. noch andere Wikis, die sich mit diesem Thema hier beschäftigen (siehe und ergänze ggf. unter Links unten). Sollte jemand dort etwas finden, was hier noch nicht eingeflossen ist, bitte hier hinzufügen, damit alle wichtigen Infos hier vorhanden sind. Danke. --Krza 11:42, 6 December 2008 (UTC)


Und noch ein Hinweis: Ich habe festgestellt, dass auf den Diskussionsseiten von lokalen Nahverkehrs-Wikis (z.B. VRS und VRR) teilweise auch allgemeine Dinge diskutiert werden. Das ist grundsätzlich gut, aber ich würde vorschlagen, dass wir diese Diskussionen hier in das übergeordnete Brett verlegen, denn die Inhalte betreffen ja alle Nahverkehrsdaten. Was natürlich auf den lokalen Seiten bleiben sollte, sind lokale Diskussionen, die also nicht allgemeingültig sind.

Wege

Gibt es Diskussionsbedarf zu den Wegen? Bei Bussen sollte es ja klar sein: Straßenabschnitte werden zur jeweiligen Relation hinzugefügt, bei Bahnen werden die ways sowohl mit highway=* als auch mit railway=tram getaggt, sofern die Straßenbahnschienen Teil der von den Autos befahrenen Straße sind. Es werden also keinesfalls separate railway- und highway-ways übereinander gelegt! --Krza 14:15, 4 December 2008 (UTC)

Es gibt etliche Regionen in denen Straßenbahnen immer als eigener Way getaged wird, auf Straßen dann gestapelt. Auch dieses Vorgehen hat seine Vorteile, so dass "keinesfalls" so nicht stimmt. Eigentlich sollte er Tagstyle der jeweiligen Region bei Änderungen beibehalten werden. Aikon 17:32, 8 January 2009 (UTC)

Haltestellen

Bus

Wie in Tag:highway=bus_stop beschrieben, sollten Bushaltestellen als separate Knoten ausgeführt werden. Es sollten also keine Weg-Knoten als Bushaltestelle getaggt werden. Darüber wurde viel diskutiert. Gerade auch in Bezug auf Relationen sollte man hier vielleicht abwarten, was die API0.6 diesbezüglich für Änderungen bringt. Bis dahin würde ich vorschlagen, separate nodes zu machen, weil es vermutlich am Ende auch darauf hinausläuft. --Krza 14:15, 4 December 2008 (UTC)

bus_stop name

Eine Frage zu den Namen von Bushaltestellen: Gehört der Ort der Haltestelle da mit hinein oder soll nur der Haltestellennamen selbst getaggt werden. Beispiel: Haltestelle Breitenfürst[das ist der Ort]-Schulhaus. Auf dem Schild an der Haltestelle steht nur "Schulhaus", ebenso wie auf den Liniennetzkarten; auf der Suchseite des VVS ist aber der Ortsname auch mit angegeben. (Was im Bus selbst angezeigt/angesagt wird, weiß ich nicht.) Verkompliziert wird das ganze noch durch Teilorte: Breitenfürst ist Ortsteil von Welzheim, was sich in der Haltestellensuche darin niederschlägt, dass eine Suche nach "Welzheim" auch alle Breitenfürster Haltestellen mit aufgelistet werden. Mir stellt sich das so dar, als ob die zugrunde liegende Frage ist, ob die Ortsinformation aus anderen Daten (z.B. Haltestellen-Node liegt innerhalb Gemeindegrenze) hervorgeht oder nicht. Wenn ja, dann kann man sich die Ortsbestandteile sparen; wenn nein, müssen sie irgendwie rein und es muss klar sein, wie sie rein müssen. Über Aufklärung freut sich --Harald.ithaca 10:54, 24 June 2009 (UTC)


Straßenbahn / U-Bahn

Bei Straßenbahnen werden die Knoten des Weges genutzt und getaggt, also keine separaten Knoten erzeugt. Das ist insofern auch plausibel als Bahnen nun einmal ans Gleisbett gebunden sind, die den Weg vorgeben, und die Haltestellen damit auch. Da scheint es auch keine Diskussion drüber zu geben, zumindest nicht hier. --Krza 14:15, 4 December 2008 (UTC)

Eine Bushaltestelle gehört ja eigentlich genausowenig zur Straße. Aber das wollte ich nicht schreiben.
Wie sind denn jetzt Straßenbahnhaltestellen zu Taggen, wenn sie
  • Tiefbahnsteig
    • am Straßenrand
    • eigene Verkehrsinsel
  • Hochbahnsteig
jeweils kombiniert mit:
  • außen (rechts der Fahrtrichtung)
  • mitte (links der Fahrtichtung, meist geteilt mit entgegengesetzten Gleisen)
und:
  • oberirdisch
  • unterirdisch
Einige weitere Unterscheidungen findet man hier. (wikipedia:de:Haltestelle#Bauweise)
Ich bin bisher nur auf railway=tram_stop und railyway=halt gestoßen, aber teilweise auch beides für denselben Haltestellentyp. Ich finde diese Differenzierung wichtig (auch zum Routing), sowie für zum Beispiel Rollstuhlfahrer. In einem Hochbahnsteig, muss man zum Beispiel nie Treppen überwinden. Und wo wir gerade schon dabei sind, könnte man das für Bushaltestellen auch einführen. Oder wie soll man sonst Haltebuchten kennzeichnen? --E-Malte 19:50, 8 January 2009 (UTC)

Richtungsangabe

Dazu habe ich noch keine Infos rausgesucht. Ich weiß nicht, ob das oneway-Tag hier genutzt werden kann/sollte. Falls jemand was hat, her damit. --Krza 14:15, 4 December 2008 (UTC) Unten bei "Verteilte Einstiegspunkte habe ich eben backward_stop_x, forward_stop_x und Reihenfolge gelesen. Dazu habe ich nur dies bzw. übergeordnet das gefunden. Landwirt, Du hast es aufgebracht, hast Du darüber Informationen? Ich sehe ehrlich gesagt nicht so ganz den direkten Bezug zu Tags ;)

Es geht dabei auch nicht um Tags. Es geht dabei um die Rolle der Haltestellen (Mitglieder) in der Linienrelation. Unter Relation:route steht dazu mehr.
Die Richtung einer Linie wird durch die Reihenfolge bzw. Nummerierung der Stops vorgegeben.
--Landwirt 20:27, 6 December 2008 (UTC)
In der Role sollte "backward" oder "forward" angegeben werden. Im Verhältnis zur Wegrichtung. So wird es auch bei den Fahradrouten gemacht. --TEL0000 05:51, 7 December 2008 (UTC)
Achso. Hm. Das dachte ich auch schon, aber ich halte das für ... naja ... nicht ganz robust, weil die Relation und die angegebene Wegrichtung völlig unabhängig voneinander sind, und wenn nun jemand versehentlich die Wegrichtung ändert, ist alles futsch, und das merkt man bei Nicht-Einbahnstraßen noch nicht einmal. Neee, das ist mir zumindest auf den ersten Blick zu weich.
Auch das mit der Reihenfolge ist so eine Sache. Irgendwo hatte ich da vor einiger Zeit was drüber gelesen im Sinne von "Relationen-Mitglieder haben von sich aus keine Reihenfolge" oderso. Und wenn, dann wäre sie zufällig und nicht nachträglich bestimmbar mit den jetzigen Mitteln. Das einzige probate Mittel scheint mir dabei zu sein, sich Stops aufeinander beziehen zu lassen wie in einer (programmiertechnisch) doppelt verketteten Reihe von Pointern. Allerdings muss da die Richtung auch wieder separat hinzugefügt werden. Von einer statischen Nummerierung halte ich weniger, weil es dann vorkommen kann, dass Du alle Nummern neu vergeben musst, wenn Du einen Stop einfügst. Aber vielleicht bin ich auch gerade auf einem gedankliche Holzweg, und alles ist total einfach ;) Gibt es passende Links dazu?
--Krza 12:08, 7 December 2008 (UTC)
Ich bin natürlich für neue bessere Vorschläge offen. Aber die Richtung per Role "forward" und "backward" anzugeben hat sich halt schon sehr durchgesetzt. Die Opencyclemap rendert zum Beispiel Radwege mit einer solchen Role ... Genauso ist es auch bei der ÖPV-Karte von Melchior Moos ... --TEL0000 18:36, 13 December 2008 (UTC)
Aber was ist die Bezugsgröße? --Krza 02:00, 14 December 2008 (UTC)
Du meinst, wann man backward und wann forward angibt? Das richtet sich wie auch der oneway-tag nach der osm-wegrichtung. --TEL0000 02:06, 14 December 2008 (UTC)
Genau das hatte ich befürchtet. Wenn man nun aber z.B. Bushaltestellen nimmt, dann gibt es keine Wege, die eine Richtung haben könnten. Und was nun? Zumindest geht es dann nicht mehr mit der von Dir genannten Basis. Daher kam ich ja oben auf die doppelt verkettete Liste. --Krza 02:55, 14 December 2008 (UTC)
Da hast du natürlich Recht. Für Haltestellen macht das nicht viel Sinn. Auf DE:Relation:route steht zwar auch was von forward_stop_<number> im Verhältnis zur Linienrichtung. Aber da die ja als Punkt eingezeichnet werden funktioniert das nicht. Selbst wenn die Punkte auf dem Weg gezeichnet werden würden wärs nicht besonders elegant. Im Verhältnis zur Numerierung würde das zwar funktionieren, aber eine Numerierung halte ich nicht für besonders Sinnvoll, da man die komplette Route ändern müsste, wenn eine Haltestelle mittendrin dazukommt. --TEL0000 03:39, 14 December 2008 (UTC)
Mein Reden ;-) --Krza 15:01, 14 December 2008 (UTC)
Die Bezugsgröße ist die Richtung der Linie. Bei einer Buslinie sagt es, ob der Weg auf der Hin- oder Rückfahrt genutzt wird. Haltestellen, die mit forward_stop_X ausgezeichnet sind, werden über mit forward (oder nichts) gekennzeichneten Wegen angefahren. --Chrisix 00:20, 22 January 2009 (UTC)

Verteilte Einstiegspunkte

Sollten Stationen gleichen Namens in den verschiedenen Richtungen sehr weit auseinander liegen, würde ich auch zwei Knoten taggen.

Bei Bussen ... hm ... wenn die Haltestellen genau gegenüber liegen, habe ich auch schon mal einen (1) Knoten auf den Weg gelegt (also einen separaten node mit der Maus über den way geschoben). Da hätte man vielleicht sauberer einen Knoten des Weges direkt nutzen können, aber ich wollte das Prinzip "separater Knoten" nicht aufgeben. Meinungen dazu?

Bei Straßenbahnen ... hm ... oft ist ja eine Haltestelle auf der einen Seite der Kreuzung, die andere auf der anderen. Macht man nun einen (1) Punkt genau auf die Kreuzung oder jeweils einen davor und dahinter? Nicht vergessen: Hier handelt es sich um Wegknoten, nicht um separate, auch wenn das eigentlich keine große Rolle spielt bei dieser Frage.

--Krza 14:15, 4 December 2008 (UTC)

Direkt gegenüber liegende Haltestellen tagge ich als zwei Knoten. Nur direkt nebeneinander liegende, zB auf Wendeschleifen, bekommen einen Knoten. Ich denke da grade an Ortsunkundige - die zwar den Bahnsteig kennen, aber dann mitten auf den getaggten Punkt (Kreuzungs- oder Straßenmitte) geführt werden und dort rumrätseln, weil sie nicht wissen auf welcher Seite der Kreuzung oder Straße sie einsteigen müssen, da sie nicht mal wissen in welche Richtung ihre Bahn oder ihr Bus überhaupt fährt.
--Landwirt 08:24, 6 December 2008 (UTC)
Hm, die Richtung ergibt sich aber aus der Lage des Punktes auch nicht. Man sieht daran lediglich, ob der Bus nach links oder rechts fährt, aber nicht, ob er einen ans gewünschte Ziel bringt. Das muss ich schon irgendwie anders herausfinden. Wie auch immer - bei Bussen kann man sicher beides machen. Ich habe z.B: eine Haltestelle mit 1 Punkt getaggt, die so eng gegenüber liegen, dass beide Busse gerade so hinpassen, wenn sie gleichzeitig da sind, und da sind nur ein paar Meter Asphalt dazwischen. Das meinte ich mit "direkt gegenüber". Anders ist es, wenn z.B. an einer mehrspurigen Straße noch eine Ampel oderso zwischen den (gegenüberliegenden) Haltestellen ist. Dann würde ich auch zwei Knoten machen.
Und bei Bahnen machst Du auch separate Knoten? Hm. Würde ich nicht machen. Wenn es sich um einen Bahnsteig handelt, an dem die Bahnen außen entlang fahren, ist es sowieso sinnlos, und wenn die Gleise innen sind, man diese also überqueren muss, um zur anderen Plattform zu kommen, ist es trotzdem noch 1 Gebilde. Sollten die Haltestellen weiter auseinander liegen, müssten auch die Schienen an der Stelle mit 2 ways gezeichnet worden sein, und dann ist wiederum klar, dass jeder Pfad seinen eigenen Haltestellenknoten bekommt, der dann aber wiederum Teil des ways ist.
Soweit zu meinen Überlegungen ;)
--Krza 11:03, 6 December 2008 (UTC)
Die Richtung ergibt sich ja aus den Angaben in der Relation (backward_stop_x, forward_stop_x und Reihenfolge). Es sollte ein leichtes für einen Router sein, die benötigte Richtung zu erkennen und den Nutzer zur richtigen Haltestelle zu führen.
Eigentlich verstehe ich auch die Frage nicht, ob einen Knoten oder mehrere. Mehrere Knoten pro Haltepunkt erhöhen die Genauigkeit zB von besagten Routern. Renderer sollten auch keine Probleme haben, sie haben die Möglichkeit zwei Knoten darzustellen oder sie zu einem Haltepunkt zusammenzufassen. Lediglich Mapper müssten einen Punkt mehr eintragen, aber die sind sich ja nicht zu Schade die Anzahl der Bäume in einem Proposal für Baumreihen und Alleen zu fordern. :)
Bei Bahnen enthalte ich mich meiner Meinung. Die einzige Bahn, die ich aufgenommen habe, ist eine einspurige Schmalspurbahn. Da störte das Schema mit einem Knoten pro Haltestelle auf den Schienen nicht. ;)
--Landwirt 15:34, 6 December 2008 (UTC)
Ja, also bei den Bussen bin ich inzwischen auch eher der Meinung, dass man immer zwei Knoten macht. Bei Bahnen bleibe ich bei einem ;) Das Zusammenfassen gleichnamiger und dicht beieinander liegender Haltestellen zu einem Punkt in der Karte (je nach Zomm-Level) ist in der Tat eine Aufgabe, der sich die Renderer noch stellen müssen.
--Krza 18:29, 6 December 2008 (UTC)
Früher oder Später werden die Gleise sowieso separat erfasst, dann wär auch eine Haltestelle pro Richtung auf dem Way möglich. --TEL0000 05:53, 7 December 2008 (UTC)
Meinst Du? Hm. Ich hoffe da eher auf intelligente Properties, die solche Angaben beinhalten. Denn bei Schienen sind die Freiheitsgrade ja nun eher eingeschränkt, so dass sich alle Möglichkeiten eigentlich relativ einfach erschlagen lassen müssten.

Öffentliche Linien und Schulbuslinien

sollte man beide eintragen / bzw. relationen machen, oder nur die öffentlichen, also die die jedentag über den ganzen tag fahren. Bei schulbuslinien ist das ja nicht unbedingt ein bus wo man als normaler passant / tourist mitfährt. wenn ihr mal hier guckt sind 146,140,168 schulbuslinien und 137,170,129 öffentliche linien --Kenji 10:52, 17 July 2010 (UTC)

Weil der 'normale Passant' nicht mitdarf oder nicht mitwill? Wenn der Kurs nicht ausschliesslich für Schüler ist und mehr als 1x pro Morgen/Nachmittag fährt, dann würde ich die Linie einzeichnen. Ob zur gewünschten Zeit ein Bus fährt muss man sowieso anderso nachschlagen. --t-i 10:01, 19 July 2010 (UTC)

Relationen

ref / name

  • Ein ref-Tag sollte eine eindeutige Bezeichnung einer Haltestelle sein. Die Deutsche Bahn hat alle Bahnhöfe und viele Bushaltestellen diverser Netze eindeutig durchnummeriert, als sogenannte IBNR Nummer. Diese eignet sich daher hervorragend für das ref-Tag und wurde auch schon auf der entsprechenden Seite

DE:Tag:highway=bus_stop vorgeschlagen. Die Nutzung der IBNR Nummer im ref Tag hätte echte Vorteile, da so die entsprechende Haltestelle eindeutig bestimmt ist und mit anderen Systemen (wie z.B. HAFAS) verknüpft werden kann.
Weitere Informationen über IBNR Onlinesuche für IBNR-Nummern
delasmurf 22.09.2009 21:08

Dürfen die IBNR-Nummern von der Seite genutzt und in OSM eingetragen werden? --E-Malte 18:25, 18 April 2010 (UTC)


Die Zuordnung zu den Buslinien erfolgt dann über Routen-Relationen [[1]].

old discussion(s)
Es scheint sich (Ende 2008) folgendes eingebürgert zu haben, und ich halte es für sinnvoll:

  • Busse, Straßenbahnen und U-Bahnen haben eine Liniennummer (in der Regel eine numerische), die auch in/an den Fahrzeugen angezeigt wird und so in den Fahrplänen steht. Genau diese soll in das ref-Tag. Zusätzlich sollte man im name-Tag diese Nummer wiederholen, aber mit einem vorangestellten "Bus " bzw. "Linie ", damit man am Namen der Relation direkt erkennen kann, worum es sich handelt. In Dresden habe ich auch ein "line"-Tag gesehen, aber das ist nirgends dokumentiert und sollte daher nicht verwendet werden. Die Renderer werden vermutlich den Inhalt des ref-Tags für die Beschriftung der Karten verwenden. Das ist zwar einerseits nicht ganz konsistent, weil ja für die Straßen auch das name-Tag genommen wird (klar), andererseits sind z.B. die Nahverkehrslinien auch in anderen Karten immer nur mit der Nummer dargestellt. Ob es sich um einen Bus oder eine Bahn handelt, ergibt sich aus der Farbe oder dem Linientyp.
  • S- und Regionalbahnen haben ja meist das "S", "RE" oder "RB" als Bestandteil der Nummer (und so steht es auch auf Fahrplänen und Fahrzeugen). Daher gehört das so ins ref-Tag. An dieser Stelle würde ich aber kein Leerzeichen machen wie z.B. bei den Bundesstraßen, weil in der Realität auch keine Leerzeichen gemacht werden, glaube ich. Das name-Tag würde ich in diesem Falle genauso füllen, es sei denn, es gibt einen konkreten Namen (z.B. "Rheinland-Express" oderso). Weglassen würde ich es aber nicht, weil es in manchen Tools (z.B. den Relations-Browsern) die Übersicht verbessert, da sonst manchmal die Relationsnummer verwendet wird, die nicht viel aussagt.

Siehe auch hier: Forum

--Krza 15:12, 3 December 2008 (UTC)

Das sehe ich genauso, habe es bis jetzt auch immer so gehandhabt. ich finde es auch nicht inkonsistent, dass das ref Tag gerendert wird, da bei den Straßen die Shield-Symbole auch aus den ref Tags kommen, dort also beide gerendert werden. Bei Autobahnen wird ja sogar nur das ref Tag gerendert.
--Nimix 18:31, 3 December 2008 (UTC)


Da ich über diese gewünschte Konvention auf der VRR-Seite gestoßen bin und es zuerst dort in die Diskussionsseite eingetragen habe, folgt hier eine Widerholung dessen:
Da hier gewünscht wird, die Routen-Relationen mit Name-Tags auszustatten, möchte ich mich für die meisten Fälle hier dagegen aussprechen:
  • Bus Liniennummer (bei Buslinien): Der Typ "Bus" ist aus dem Route-Tag bekannt, die Liniennummer aus dem Ref-Tag.
  • Linie Liniennummer (bei Straßenbahn/U-Bahnlinien): s. o.
  • gleich ref (in allen anderen Fällen): Warum?
Eine solche Redundanz von Daten sollte in meinen Augen vermieden werden, da sie keine Mehrinformation bringt und den Wartungsaufwand erhöht. Nur für den Fall, dass eine Linie wirklich einen Namen hat (NRW-Express, oder im VRS der Telekom-Express), gehört er in das Name-Tag.
Im verlinkten Foren-Artikel habe ich übrigens auch keinen Konsens darüber feststellen können, sondern nur zuerst die Position gelesen, wonach der Name nur dann gefüllt werden solle, wenn es auch einen gibt. (Dieser Position stimme ich auch zu.) Danach kam der Wunsch von Krza auf, zwischen den Daten im Bestand und den gerenderten Daten zu unterscheiden (so habe ich es jedenfalls interpretiert). Nur: Die gerenderten Daten sollten IMHO aus den im Bestand vorhandenen Daten automatisch generiert werden, d. h. wenn jemand möchte, dass nur die "1" gerendert wird, so konfiguriert er den Renderer so, möchte jemand "Buslinie 1" da stehen haben, so muss der Renderer halt so angepasst werden, dass er das Route-Tag plus "linie " plus das Ref-Tag rendert. Einwände? -- Fnolz 12:14, 10 January 2009 (UTC)
Dass ich für den Namen in der Relation bin, hängt wie gesagt damit zusammen, dass man die Relationen anhand des Namens einfach besser erkennen kann. Sonst bekommt man an einigen Stellen immer nur die Relations-ID angezeigt, nicht aber die ref oderso. Klar, das sollten die Tools besser machen, aber tun sie nun einmal nicht. Und so viel Information ist es ja nun nicht, die man damit erzeugt. Lass es ein paar hundert KB sein für Deutschland.
Das mit Bestand und gerendert habe ich jetzt nicht so ganz verstanden, also habe ich es vermutlich auch nicht so gemeint ;) Aber wenn ich Dein Statement lese, bin ich eigentlich nicht so weit davon weg: Es muss ein "Standard-Rendering" geben, und wer das nicht mag, muss sich eine neue Rule schreiben. Dabei ist meines Erachtens aber wichtig, dass der Standard einerseits den größten Bedarf abdeckt und andererseits unkomplizierte Abweichungen davon zulässt. Damit meine ich: Die Darstellung der Liniennummer ohne jeden Zusatz ist auf quasi allen Karten Standard, also sollte das auch in OSM so sein. Und aus einer einfachen Zahl eine Zahl mit Zusatz zu machen ist deutlich einfacher uns sicherer als umgekehrt. Das ist das zweite Argument dafür, nur die einfache Liniennummer einzutragen. Wo die jetzt eingetragen wird ... das hängt eben davon ab, was der Renderer standardmäßig verwendet, und momentan scheint es das ref-Tag zu sein. Einwände? ;) Kann schon sein, dass ich mich jetzt (ein paar Wochen später) selbst widersprochen habe, aber dafür gibt's ja Diskussionen ;) --Krza 14:31, 10 January 2009 (UTC)
Okay, ich bin kein Fan vom Name-Tagging als Krücke für fehlende Ref-Darstellung, aber sooo viel Energie will ich da jetzt nicht hineinstecken, da alle von zu überzeugen. Weniger schön finde ich es halt, wenn auf der VRR-Seite einzelne Routen als nicht vollständig gekennzeichnet werden, weil das Name-Tag fehlt, und dabei vielleicht ganz andere Dinge viel eher im Argen liegen (fehlende Haltestellen, etc). Könnte man sich darauf einigen, dass man die Wiederholung des ref=* im name=* als optional kennzeichnet?
Was die Renderer betrifft, habe ich aus der de-Mailing-Liste mehr oder weniger herausinterpretiert, dass häufig erst die Features in der Datenbank vorhanden sind, bevor sich irgendjemand bequemt, auch mal das Renering zum implementieren. Das ist dann aber auch nicht das "Standard-Rendering" - dazu ist OSM (leider) zu open - sondern nur ein Rendering. Und ich habe herausgelesen, dass nicht alles in der "slippy map" landen soll/wird. Für den ÖPNV haben wir ja jetzt die ÖPNV-Karte, die das Rendering in meinen Augen ja auch sinnvoll macht. Egal, für mich ist jetzt alles gut :-) -- Fnolz 17:37, 11 January 2009 (UTC)

network

Bei den Zügen und S-Bahnen habe ich gesehen, dass als network z.B. "NRW" oder "DB NRW" angegeben wird. Hm. Das ist nicht VRS, gehört aber trotzdem auch mit dort rein.

Was tun? Mehrere Werte reinschreiben in das tag? Auch blöd. Auf jeden Fall sollte man darauf achten, dass die Relationen mit in die VRS-Relation eingehängt werden. Das ist wichtiger als der Inhalt des Tags und nicht bei allen der Fall. --Krza 21:46, 30 November 2008 (UTC)

Ich kenne mich jetzt in NRW nicht aus. Ich würde folgendes vorschlagen:
network=Tarifverbund (in Berlin VBB)
operator=Betreiber (in Berlin z.B. BVG)
--TEL0000 05:59, 7 December 2008 (UTC)
Beitrag verschoben aus VRS-Diskussion: Seit kurzem gibt es auch die Seite VRR hier bei OSM. Gerade im Regionalverkehr haben wir relativ große Überschneidungen zwischen VRR und VRS, weswegen ich vorschlagen würde eine gemeinsame Seite zur DB Regio NRW anzulegen, und dort alle S-Bahnen, REs und RBs zu sammeln. Da kann man dann zum Beispiel eine Tebellenspalte einfügen im VRS bzw. im VRR (und wie die restlichen Verkehrsverbünde in NRW sonst noch alle heißen).
Eventuell könnte man das (auf Kosten der Übersichtlichkeit) auch so gestalten, dass man per <includeonly> u.ä. das mit dem Parameter VRS bzw. VRR einbinden kann, sodass alle Linien des jeweiligen Verbundes eingebunden werden. Das würde ich allerdings nicht empfehlen.
Liebe Grüße, E-Malte 09:45, 3 January 2009 (UTC)

Ich habe noch keine so richtig überzeugende Idee, was wo reingehört.

Für eine Strecke ist ein Eisenbahn-Infrastrukur-Unternehmen (EIU) zuständig (z.B. DB Netz AG). Das sollte irgendwo rein. Network klingt eigentlich passend. Dann gibt es die Züge, die darauf fahren. Im Güterverkehr werden das bei einer Hauptstrecke ohnehin dutzende verschiedene ständig wechselnde, fusionierende und sich umbenennede Eisenbahn-Verkehrsunternehmen (EVU) sein.

Im Personenverkehr gibt es die Kursbuchstrecken, in manchen -leider nicht allen- Bundesländern gibt es Liniennummern (z. B.: RE1) und Linienbezeichnungen (z. B. NRW-Express). Diese Linien werden meist von einem, manchmal auch von mehreren EVU gefahren (Beispiel: Auf der RB 73 nach Lemgo fährt normalerweise die Eurobahn. Ein Zugpaar wird jedoch von der NordWestBahn gefahren).

Um die Sache vollends verwirrend zu machen. Die Linien bleiben nicht immer in einem Bundesland. Manchmal werden die Namen beibehalten. Der RE5 (Koblenz - Emmerich) heißt sowohl in NRW, als auch in Rheinland-Pfalz so. Einen anderen RE5 gibt es dort nicht. Allerdins hat RLP seinen eigenen RE1. Anders sieht es zwischen anderen Bundesländern aus. Die Sieg-Dill-Bahn (Au(Sieg) - Siegen - Dillenburg) heißt in NRW und RLP RB 95, während sie der RMV als RB40 bezeichnet.

Dann gibt es die Aufgabenträger. Diejenigen, die mit den Regionaliserungsmitteln die Nahverkehrszüge bestellen und bezahlen. Das kann die Eisenbahngesellschaft des Bundeslandes sein (z. B. in Bayern), kann aber auch eine Kreisverkehrsgesellschaft sein (Hessen - ist das immer noch so?).

Und als letztes gibt es noch die Zugehörigkeit zu einem oder mehreren Verbünden (Verkehrsverbünde, Verkehrsgemeinschaften, Tarifgemeinschaften etc.) . In den Grenzbereichen zwischen den Verbünden gibt es meist Übergangs- oder Kragentarife. In dem hessischen Teil der oben angesprochenen RB 40 gilt beispielsweise der RMV-Tarif, für Fahrten nach NRW bis Siegen aber auch der VGWS-Tarif.

--LongWajong 06:26, 25 January 2009 (UTC)

Wenn eine Strecke in verschiedenen Verbünden auftaucht, würde ich sie für jeden einzelnen Verbund in eine eigene Relation packen. Dies aus zwei Gründen. Einerseits könnte man dann recht einfach alle Strecken eines Verbundes rendern bzw. extrahieren, auf der anderen Seite könnte unterschiedlichen Linienbezeichnungen in den Verbünden Rechnung getragen werden.

So ähnlich habe ich es auch innerhalb des RMV gemacht. Die Bahnstrecke Frankfurt/Main-Limburg/Lahn wird als RB20 (hält überall) wird auch als SE20/RE20 (hier unterschiedliche Bezeichnungen im Fahrplan als im Netzplan) befahren, hält aber nicht überall. Bei der SE/RE20 sind einfach nur weniger Haltepunkte/Bahnhöfe in der Relation.

Mir stellt sich aber eine andere Frage: bis wohin ist eine Relation zu taggen. Am Beispiel des Liniennetzplanes des VRM (Rhein-Mosel): Die Strecke RRS (Rechte Rheinstrecke Süd, beim RMV RB/RE10) wird auf dem Netzplan innerhalb des Verbunds bis Kaub / Lorchhausen veröffentlicht, deren Fahrplan geht bis Rüdesheim, die eigentliche Strecke geht bis Wiesbaden / Frankfurt/Main (Ist die KBS 466). Wo zieht man da die Grenze und endet mit dem Tagging der Relation? Noch deutlicher wird dies beim Liniennetzplan des RMV, wo neben den Endhaltestellen auch noch Haltestellen in Übergangsgebieten gezeigt werden.

--Dartial 12:50, 24 March 2009 (UTC)

Haltestellen separat einschließen?

Bei Bushaltestellen ist es meines Erachtens notwendig, dass auch die Haltestellenknoten mit in die Relation aufgenommen werden, also nicht nur die Wege, die der Bus überfährt. Ganz einfach deshalb, weil sonst keine Beziehung zwischen dem Fahrweg und den separaten bus_stop-Knoten besteht. --Krza 14:15, 4 December 2008 (UTC)

Das sehe ich genauso! --TEL0000 05:54, 7 December 2008 (UTC)


Bei Bahnen ist das wohl nicht notwendig, da werden also nur die Wegstücke zu der Relation hinzugefügt, da ja die getaggten Haltestellenknoten Teil dieser Wege sind. --Krza 14:15, 4 December 2008 (UTC)

Auch bei Bahn, Tram, etc. sollten die Haltestellen mit in die Relation. Dann kann man auch nachvollziehen, wo ein Zug hält, denn nicht jeder Zug hält an allen Haltestellen auf seiner Strecke. --Moonwashed 07:00, 10 January 2009 (UTC)

Da muss ich Moonwashed recht geben. --TEL0000 19:32, 10 January 2009 (UTC)

Zusammenfassen oder nicht?

Jede Linie sollte am Ende in einer Relation zusammengefasst sein, klar. Dann ist aber die Frage, ob alle Linien-Relationen eines Verkehrsverbundes zu einer Relation des Verbundes zusammengefasst werden sollen. Ich sage: Ja. Diese Relation ist dann übrigens auch in der Tabelle unten angegeben. Darüber hinaus kann man natürlich auch die Linien eines Betreibers innerhalb des Verbundes zu einer Relation zusammenfassen. Das wäre dann optional. So könnte man z.B. alle KVB-Linien bündeln, die parallel dazu aber schon in der VRS-Relation stecken. Ob diese KVB-Relation dann in die VRS-Relation eingehängt werden sollte? Ich weiß es nicht, denke aber zur Zeit: Nein. Denn eine Verbund-Relation enthält meiner Meinung nach Linien, also routes, aber keine Unter-Netzwerke, also networks. --Krza 14:15, 4 December 2008 (UTC)

Analog läuft das übrigens bei Bundesstraßen und Autobahnen. Dort war ich übrigens auf die Meinung gestoßen, dass die Zusammenfassung zu Problemen führen kann. Ich wüsste nicht, zu welchen, lasse mich aber gerne aufklären. --Krza 14:15, 4 December 2008 (UTC)

Ich habe gerade festgestellt, dass es alles zu geben scheint: Busse / Bahnen einer Stadt zusammengefasst, alle Linien einer Stadt, alle Linien eines Betreiber, ... Wichtig ist nun zu entscheiden, ob man die Verkehrsverbünde so lässt: Dann enthalten sie alle Linien, die zum Verbund gehören, aber keine Unter-Netzwerke. Oder doch beides parallel? --Krza 14:15, 4 December 2008 (UTC)

Ich habe für den Verkehrsverbund Warnow lediglich die Betreiber in die Relation aufgenommen, die Linien sind alle den jeweiligen Relationen der Betreiber zugeordnet. Ich denke so ist es viel logischer. Sollte sich jemand für alle Linien der Verbünde interessieren, kann auf Skripte zurückgegriffen werden. Notfalls kann man ja noch sowas ähnliches wie einen admin_level einführen.
--Landwirt 07:59, 6 December 2008 (UTC)
Stimmt eigentlich, und darüber bin ich gedanklich jetzt auch schon ein paar mal gestolpert. Die Idee, Linien in Verbünde zu hängen, rührt daher, dass ich es irgendwo so gesehen und zunächst für sinnvoll gehalten hatte, aber um genau mit solche Dingen aufzuräumen, gibt es ja diese Wiki hier ;) Ich werde mal die vermutlich logischste Struktur visualisieren und hier reinhängen. So kompliziert ist sie ja nicht ;)
Ich fasse Eure Überlegungen jetzt mal an Hand eines Beispiels zusammen:
network "Verkehrsverbund VRS"
         |
         -------- network "Betreiber KVB"
         |                 |
         |                 -------- network "KVB Buslinien"
         |                 |                |
         |                 |                -------- route "Bus 157"
         |                 |                -------- route "Bus 250" etc.
         |                 -------- network "KVB Bahnlinien"
         |                 |                |
         |                 |                -------- route "Linie 3"
         |                 |                -------- route "Linie 18" etc.
         -------- network "Betreiber DB NRW"
         |                 |
         |                 -------- network "DB NRW S-Bahnen"
         |                 |                |
         |                 |                -------- route "S6 Essen Hbf - Köln Nippes"
         |                 |                -------- route "S11 Wuppertal Vohwinkel - Bergisch Gladbach"
         |                 |                -------- route "RE9 Rhein-Sieg-Express" etc.

network "Verkehrsverbund VRR"
         |                 |
         -------- network "Betreiber DB NRW"
         |                 |
         |                 -------- network "DB NRW S-Bahnen"
         |                 |                |
         |                 |                -------- route "S6 Essen Hbf - Köln Nippes"
         |                 |                -------- route "S11 Wuppertal Vohwinkel - Bergisch Gladbach"
         |                 |                -------- route "RE9 Rhein-Sieg-Express" etc.
Wenn ich das falsch interpretiert haben sollte, dann korrigiert mich bitte direkt.
Problematisch wird es meiner Meinung nach, wenn jetzt bei oben genannten Beispiel Kooperationen zwischen einzelnen Verbünden gibt. Im oben gezeigten Beispiel gehört die RE5, betrieben von DB NRW, defintiv nicht zum VRR.
In manchen Gegenden gibt es halt "globale" Betreiber, von daher fände ich es besser wenn wir da eine andere Lösung finden würden. Das separate Pflegen von Operator-Relation -> Bus/Bahn-Relationen -> Einzelne Routen-Relationen und Verbund-Relation -> Bus/Bahn-Relationen -> Einzelne Routen-Relationen ist sicherlich für manche "doppelte gemoppelt", aber aus meiner Sicht die einzige Möglichkeit um keine falschen Daten zu erzeugen.
Was meint Ihr? --Mighty eighty 00:12, 10 January 2009 (UTC)
Du meinst Verbunrelationen und Betreiberrelationen sollten direkt die Linien als Mitlieder haben? Wenn ja, dann sehe ich das genauso. Es gibt strecken die nicht zum Verkehrsverbund gehören, aber dennoch den gleichen Betreiber haben, und natürlich auch andersrum. --TEL0000 19:36, 10 January 2009 (UTC)

In ländlichen Gebieten dürfte die feste Operatorzuweisung nicht funktionieren. Da teilen sich mitunter mehrere Unternehmer eine Linie. Insbesondere auch bei den fahrplanmäßigen Schulverstärkern wird es richtig kunterbunt. Man kann da lediglich den Verkehrsverbund angeben. Zudem werden nach Schulschluss und in den Ferien manche Schulhaltestellen nicht angefahren. Ich habe noch keinen blassen Schimmer, wie ich das managen soll. Gruß -- Tirkon 19:35, 22 March 2009 (UTC)

Ich würde sagen, gar nicht. Ich bin der Meinung, daß OSM eine geographische Datenbank ist und keine Fahrplan-Datenbank. Ich würde also die Strecken erfassen, auf denen grundsätzlich (irgendwann) gefahren wird. Den Rest muß sich ein (potentieller) Fahrgast sowieso woanders raussuchen: Fahrplan, Tarifzone(n), etc. --Sellerhäuser 14:04, 17 August 2010 (BST)

Route-Tag Chaos bei Bahnen

Was die ÖVP-Karte von Melchior Moos angeht, möchte ich hier doch nochmal eine Problematik ansprechen, die er in seiner Ankündigung und in einer Folgemail angesprochen hat. Da wir ja in Deutschland schon verschiedene Klassen für den Personenschienentransport haben (ICE,IC/EC,RE/RB,S-Bahnen) sollten wir uns Gedanken machen, wie wir das mit Hilfe der Relationen darstellen können. Das zur Zeit Schema mit route=train, route=rail, route=railway, route=light_rail etc. kann man ja gerne beibehalten, nur sollten wir uns da auf einen Nenner einigen. Vielleicht kann auch wer berichten, wie außerhalb Deutschlands damit umgegangen wird. Natürlich könnte man ja auch ein weiteres Tag in die Relationen für Bahnen einführen (z.B. class=ICE, class=RB) um die Klasse der Strecke abzubilden. Vielleicht muß das noch ein wenig international angepasst werden. Somit könnte Melchior jedenfalls auch sauberer und übersichtlicher rendern. --Mighty eighty 03:00, 3 January 2009 (UTC)

Die Problematik wirkt sehr einleuchtend. Ich habe mich gerade nocheinmal bei dict.leo.org über die möglichen Übersetzungen der vorgeschlagenen route-Tags erkundigt. In anbetracht der Tatsache, dass wir nur einen route-Tag für Straßenfahrzeuge haben (route=bus), und nicht etwa einen eigenen für Schnellbusse, Shuttlebusse oder ähnlichem, würde ich route=rail benutzen. (rail auf leo). Besonders der letzte Begriff rail-bound, schienengebunden hat mich überzeugt. Es sind schließlich alles Schienenfahrzeuge, was sie grundlegend von Straßenfahrzeugen unterscheidet. Weiterhin finde ich deinen Vorschlag mit den Klassen recht gut. Den kann man falls notwendig auch auf (Schnell-)Busse ausweiten. --E-Malte 21:34, 3 January 2009 (UTC)
route=train finde ich schon am sinnvollsten. Immerhin wird hier ja die Zugroute beschrieben, und nicht das Gleis. International am besten anwendbar wird es wohl, wenn man für alle Züge (auch S-Bahn) route=train verwendet. Oder man teilt route=* in drei international anwendbare Kategorien ein: Nahverkehr, Regionalverkehr und Fernverkehr. Um die Kategorien genauer (national) einzuteilen finde ich class=S/RB/RE/IC/ICE sinnvoll. Für Expressbusse dann class=expressbus oder so. --TEL0000 21:10, 4 January 2009 (UTC)
Unter einem Zug verstehe ich aber nur Regionalverkehr, das würde Stadt- und Straßenbahnen nicht mit einschließen (siehe wikipedia:de:Zug_(Eisenbahn))
Die Klassen könnte man von hier übernehmen: wikipedia:de:Zuggattung. Allerdings fehlt auch da die Straßenbahn. --E-Malte 00:14, 5 January 2009 (UTC)
Bei der Straßenbahn sollte es meiner Meinung nach auch bei route=tram bleiben.
Wie wärs mit folgenden Kategorien für den route-tag: bus, tram, subway, local_train, regional_train, national_train, international_train
Die Bezeichnung "class" ist auch nicht besonders Glücklich, da das eher mit Komfortbereichen verbunden wird. Da wär vielleicht eine andere Bezeichnung besser. (PS: Sorry wegen den vielen Bearbeitungen, aber mir fällt immer noch was neues ein.) --TEL0000 01:18, 5 January 2009 (UTC)
Also hier tut wohl auch mal eine Recherche not, was anderswo gemacht wird und wie bei ähnlichen Dingen verfahren wird. Grundsätzlich muss es international verwendbar sein von der Struktur her, sprich, auch eventuell andere Kategorien von Zügen abdecken. Wikipedia-Kategorien sind da sicher ein guter Anhaltspunkt, zumal es für Konformität sorgt.
Tram und rail oder meinetwegen auch train würde ich auch auseinanderhalten wollen. Die genannten route-Kategorien bergen aber auch Problem-Potential, denn es ist nicht immer eindeutig, zu welcher eine Route gehört. Hier in Köln geht es schon los, wo tram und subway praktisch eins ist. Was es gerade ist, hängt davon ab, wo sich die Bahn befindet. Ähnliche Beispiele wird es anderswo auch geben.
Was die "class" betrifft: Das ist schon der richtige Name. Dass man nun zufällig bei Zügen auch von Komfort-Klassen spricht, spielt da keine Rolle. Wenn wir uns über Autos unterhalten hätten, wäre die Frage gar nicht aufgekommen. Kann sein, dass es trotzdem noch ein besseres Kürzel gibt, aber das Komfort-Argument sticht in meinen Augen nicht. Auch hier gilt: Wenn man ähnliche Dinge anderswo mit "class" kategorisiert, sollte man es auch hier tun. Konsistenz.
--Krza 08:39, 5 January 2009 (UTC)
In der wiki steht zu Route-Relations route=railway, daher tagge ich RE- und RB-Strecken usw. so. Dies ist wird auch mehrheitlich in Europa gemacht (280 zu 100, z.Z., siehe Tagwatch). Light_rail für S-Bahnen ist meistens verkehrt, da es sich bei diesen um Normalspur-Eisenbahnen handelt. Daher tagge ich auch hier railway. Die Zug-Klassen oder Kategorien kann man auch aus den Anfangsbuchstaben des ref-Tag nehmen: RB, RE, S, ICE, IC, SB, etc...--Moonwashed 20:01, 6 January 2009 (UTC)
Ich bin mit dem class-tag einverstanden, sollte nur ein Hinweis sein. Die Klassen nach wikipedia:de:Zuggattung zu kategorieren finde ich gut. Die Abkürzungen, oder die vollen Namen? Da fällt mir schon beim Regional-Express auf, dass das in Deutschland und Östereich unterschiedlich gehandhabt wird.
Was das route-tag angeht, da das class-tag zwangsläufig sehr national ausfällt bin ich schon der Meinung, dass wir dort mehrere Kategorien brauchen, die international verwendbar sind.
Und was die gemischten Systeme angeht, in Hannover ist das genauso, dass die Bahn als Straßenbahn und U-Bahn verkehrt. Eigentlich ist es eine Stadtbahn, und genau so könnte es auch mit class kategoriert werden.
--TEL0000 22:13, 6 January 2009 (UTC)

Übergeordnete Relationen

Hallo Ihr fleißgen ÖPNVler! Kennt Ihr das Statement von Frederik Ramm zu diesem Thema? Was meint Ihr dazu? Wäre es nicht wert noch einmal darüber nachzudenken, bevor wir so richtig viel Arbeit in Relationen wie "Alle Schnellbusse Europas" stecken. Viele Grüße --Rotbarsch 12:53, 21 January 2009 (UTC)

Nach meiner Erfahrung ja, denn solche Relationen wird man Euch ungefragt unter dem Po weg löschen (So geschehen mit "Alle Packstationen in Deutschland". Die Alternative Xapi-Abfragen zu lernen ist wohl die bessere Zeitinvestition. --Lulu-Ann 16:24, 21 January 2009 (UTC)
Ok, soweit, so gut. Xapi-Abfragen sind ja an sich kein Problem. Vielleicht ist es von Nachteil, das - wenn ich die Doku richtig verstanden habe, zur Zeit nur eine Eigenschaft abgefragt werden kann. Also kann man z.B. den "operator" NRW DB Regio im "network" VRR nicht abfragen. Das könnte man vielleicht zur Zeit mit einem BBox-Parameter umgehen, so das man quasi nur den operator "DB NRW Regio" im Boundary von NRW abfragt. --Mighty eighty 22:54, 31 January 2009 (UTC)
Relationen ala "Alle schnellbusse Europas" halte ich auch für Sinnfrei. Dass wir die API nicht richtig abfragen können bedeutet nicht, dass man für jede erdenkliche Abfrage eine Relation erstellen sollten. Da muss eher die API überarbeitet werden. In bestimmten Fällen halte ich übergeordnete Relationen durchaus für Sinnvoll, aber die Diskussion gehört dann doch eher auf die bereits angesprochene Wikiseite. --TEL0000 00:32, 4 February 2009 (UTC)

Einige Fahrten am Tag mit verlängerter Route

In Düsseldorf gibt es eine Linie 781, die normalerweise zwischen Punkt A und B verkehrt. Nur sehr selten am Tage fährt die Linie über Punkt B hinaus zu Punkt C und fährt dann eine geringfügig andere Route. Wie soll man solche Fälle regeln? Vielleicht könnte man zwei Relationen herstellen. Eine für die Strecke A-B und eine zweite für die darüber hinausgehende Strecke B-C. Beide Relation packt man dann zusammen in die 781 Relation Aber wie das Ganze dann taggen? 781 Regelstrecke und 781 erweiterte Strecke? -- Tirkon 19:43, 22 March 2009 (UTC)

Tarifgebiete und Waben

...oder wie sie in eurem Verkehrsverbund auch heißen mögen.

Vorteile

Ich halte es für sinnvoll diese auch in OSM einzutragen. Folgende Vorteile resultieren meines Erachtens daraus:

  • bessere Prüfbarkeit der Vollständigkeit
durch eine zusätzliche Seite mit Status/Vollständigkeit, Ort und Ausdehnung der einzelnen Waben
  • eine genauere Begrenzung der Verkehrsverbünde
denn die Linien Enden ja nicht zwingend an der Grenze zu einem anderen Verkehrsverbund, aber die Haltestellen können zu einem anderen Verbund gehören
  • Verkehrsverbundspezifische Karten erstellen können


Situation am Beispiel des VRR

Im VRR ist die Situation folgendermaßen:

  • Tarifgebiete sind größere Gebiete (Kreise, kreisfreie Städte, bei Großstädten auch 2 Tarifgebiete pro Stadt).
  • Waben sind kleinere Gebiete innerhalb eines Tarifgebiets, z.B. Gemeinden oder Stadtbezirke.

Die Wabennummer

  • steht auf jedem Haltestellenschild unten links in einem gelben Sechseck.
  • ist dreistellig, die ersten beiden Ziffern stehen für das Tarifgebiet, die letzte ist die Nummer der Wabe im Tarifgebiet.
Beispiel: Haltestelle Königsberger Straße in Düsseldorf. Waben-Nummer: 430. Daraus folgt: Tarifgebiet 43, Düsseldorf Mitte/Nord.

Es gibt auch Haltestellen mit zwei Waben. Ich vermute sie stellen eine Grenze zu einer anderen Wabe dar.

Näheres zur Situation im VRR hier.


Tagging

Wenn das Tarifgebiet nicht eindeutig aus der Wabennummer hervorgeht, sollte dafür ein weiterer Tag benutzt werden. Ich denke es gibt zwei sinnvolle Methoden die Wabe an der Haltestelle zu taggen:

Erste Möglichkeit: 

highway=bus_stop oder railway=tram_stop/halt
name=Name der Haltestelle
[...]
network=Kürzel des Verkehrsverbundes
wabe=Nummer der Wabe (bei mehreren durch Semikolon getrennt)

Zweite Möglichkeit: 

highway=bus_stop oder railway=tram_stop/halt
name=Name der Haltestelle
[...]
Kürzel des Verkehrsverbundes:wabe=Nummer der Wabe (bei mehreren durch Semikolon getrennt) → z.B. vrr:wabe=123

Meiner Meinung nach ist die zweite Möglichkeit besser, da sie ermöglicht, dass eine Haltestelle zu mehreren Verkehrsverbünden gehört (Grenzhaltestellen), deswegen werde ich momentan erstmal nach dem zweiten Schema vorgehen.

Wenn jemand einen passenderen Tag als wabe findet, wäre das vielleicht ganz gut, falls das Tagging sich durchsetzen sollte. Aber zumindest im VRR und im VBB wird dieser Begriff benutzt.


Verbesserungsvorschläge, Fragen, Anmerkungen, Kommentare? Ein besserer, allgemeinerer Begriff als wabe?

Viele Grüße, --E-Malte 06:45, 22 April 2009 (UTC)


Warum benutzen wir nicht, wie z. B. in Stuttgart üblich fee_zone und dahinter die Wabenziffer Also fee_zone:123 --findus05 14:58, 13 December 2009 (UTC)

Taktfrequenz?

Mich stört an ÖPNV-Karten immer, dass man nicht einmal grob herausfinden kann, wie oft die Linie verkehrt. Es gibt Busse die fahren im 10-Minuten-Takt und solche, die nur an Schultagen freitags morgens 1x fahren.

Deshalb möchte ich vorschlagen, dafür eine neue Rubrik einzuführen, z.B. in drei Abstufungen: "häufig", "selten", "unregelmäßig". Wobei "häufig" dann bedeuten kann: Durchschnittlich Mo-Fr. 7-20h je Richtung und Stunde 3 Fahrten oder mehr (=20-Min-Takt), "selten" = 1-2 Fahrten (30-60-Min.-Takt), "unregelmäßig" = weniger als 1 Fahrt, bzw. min. 4 Stunden lang (im Zeitraum 7-20h) gar keine Fahrt. (Man muss es natürlich nicht unbedingt ganz so wissenschaftlich mit Taschenrechner in der Hand machen.)

Das könnte dann in Karten dargestellt werden durch eine dicke Linie, eine dünne Linie und eine gestrichelte Linie. Ein Problem gibt es, wenn sich die Linie teilt und mal nach links, mal nach rechts fährt. Aber das ist ja weiter oben schon angesporchen, dieses Problem existiert ja unabhängig davon ohnehin. --User 7343 13:07, 25 November 2009 (UTC)

Zusammenfassende Relation NRW Züge

In VRS ist die Relation relation 37316 eingegeben als zusammenfassende Relation für NRW Bahnverbindungen. Es gibt aber auch relation 63226 mit (mehr) Bahnverbindungen. Ist ein von beiden Überflüssig? --Mdeen 12:42, 9 May 2010 (UTC)

Die zweitere enthält *alle* Zuglinien in NRW. Wenn es eine kürzer gehaltene Übersicht für den VRS parallel geben soll, darf sie gerne bestehen bleiben. Zusätzlich gibt es noch Relationen für das S-Bahn-Netz Rhein-Ruhr relation 448340 und -Köln relation 448365. --User:ajoessen 06:42, 11 May 2010 (UTC)

Links

Die angegebenen Links führen zu Diskussionen, die schon einmal anderswo geführt wurden bzw. gerade werden. Bitte immer auf die Datumsangaben achten, um das Gelesene richtig einsortieren zu können.

Wiki:

Forum:

Mailingliste:

ÖPNV-Karte als Poster ausdrucken

Ich hab im Wiki nichts drüber gefunden, deswegen frage ich einfach mal hier: Wie kann ich eine ÖPNV-Karte von www.öpnvkarte.de als Poster oder zumindest als A3 ausdrucken? Mit meinem Browser krieg ich maximal ein Screencopy hin. --Gypakk 10:12, 19 June 2009 (UTC)


Ansprechpartner bei Verkehrsverbünden und Verkehrsunternehmen zum Thema ÖPNV bei OSM

AVV: Thomas Reincke

VRS: Marcel Hövelmann

Private Anbieter

Hi, es gibt ja durchaus einige private Anbieter von Fernverkehrs-Verbindungen per Bus, etwa http://meinfernbus.de. Denkt ihr die sollten wir hier auch aufführen, so erfasst? --!i! This user is member of the wiki team of OSM 12:34, 21 June 2013 (UTC)

Sortierung der Tabelle

Im Moment ist die Tabelle ein Wirrwarr. Können wir eine alphabetische Sortierung der Tabelle einführen, Eventuell nach Bundesländer unterteilt? Das geht zwar auch mit Sortieranweisungen in der Tabelle, allerdings werden dafür Scripte im Browser benötigt und beim Bearbeiten der Seite beginnt die Suche erneut. --Skyper (talk) 11:01, 28 April 2021 (UTC)

PTNA und Grenzrelationen

Können wir noch Links zu PTNA und zu den Grenzrelationen, eventuell auch Waben, in der Tabelle unterkriegen? Ist vorallem für Verbunde ohne eigene Wikiseite empfehlendwert. --Skyper (talk) 11:01, 28 April 2021 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Germany/Nahverkehr&oldid=2146744"