Talk:München/Transportation

From OpenStreetMap Wiki
Jump to: navigation, search

Qualitätssicherung - München/Transportation

Ausgelöst wurde die ganze Diskussion durch unbeabsichtigtes Löschen von Bus-Relationen im Münchener Umfeld (es wurden aber neue Relationen erstellt). Dadurch waren viele Links auf der Seite München/Transportation nicht mehr aktuell. Allerdings muss man auch sagen, dass die Seite in der Vergangenheit eh nicht gut gepflegt war, z.T. gar nicht bekannt war. Die Qualität und Aktualität der Seite scheint also ein generelles Problem zu sein.
Auf dem Münchner OSM-Stammtisch am 8. Feb. 2017 wurde das Thema daher diskutiert. Es wurde beschlossen, das Thema intensiver zu bearbeiten, hier auf dieser Seite zu diskutieren und eine Lösung (Tool?) zu finden. Die folgenden Kapitel sollen die weiteren Arbeiten beschreiben und zur Diskussion hier einladen.

Motivation

Wie schon angesprochen, hapert es mit der Qualität der München/Transport Seite:

  1. Vollständig: wir wissen nicht, ob wir alle existierenden Buslinien des MVV auf der Seite aufgelistet haben
    1. S-Bahn, U-Bahn und Tram sind in ihrer Anzahl überschaubar, da besteht die Chance, dass wir vollständig sind
  2. PTv2: wir wissen nicht, welche der Linien schon auf "Public-Transport Version 2" umgestellt sind
    1. DE:Public_Transport. Den originalen Wortlaut des Proposals findet man unter Proposed_features/Public_Transport
  3. Korrekt: wir wissen nicht, ob die auf PTv2 umgestellten Linien durchgängig und sortiert sind
    1. d.h. ob die Ways komplett, in der richtigen Reihenfolge, ohne Lücken, ohne Fortsätze und bei Kreisverkehren korrekt erfasst sind
    2. ob die "stop" und "platform" Member komplett und in der richtigen Reihenfolge erfasst sind
  4. Einheitlich: wir wissen nicht, ob alle Relationen mit ihren Tags komplett und korrekt sind
    1. d.h. mit vorhanden, korrekten und gegebenenfalls einheitlichen "network", "operator", "public_transport:version", "name", "ref", "from", "to" (und "via"), ...
  5. Übersichtlich: wir haben keine Seite, auf der uns all das, vor allem aber die Probleme damit, übersichtlich angezeigt wird
  6. Automatisierbar: wir haben keine Möglichkeit eine solche Übersichtsseite automatisiert zu erstellen (wöchentlich, ...)

Ursachen gibt es viele:

  1. Vollständig: woher sollen wir die Informationen bekommen? Wir erhalten u.U. vom MVV eine Liste (CSV, ...)
  2. PTv2: einige Linien haben weder "Version" 1 noch 2 als Tag: vergessen, Unkenntnis der Existenz ...
  3. Korrekt: das ist eine mühsame Kleinarbeit, die immer wieder und wieder angestoßen werden muss, da Relationen schnell mal (unbeabsichtigt) mit Lücken "versehen werden", ...
  4. Einheitlich: was ist denn der Standard? network=MVV oder network="Münchner Verkehrs- und Tarif-Verbund" und so weiter? München/Transportation#Vorschlag_für_vereinheitliches_Tagging
  5. Übersichtlich: Teile der Seite sind schon übersichtlicher gestaltet, wie könnte eine übersichtlichere Seite aussehen (Layout?)
  6. Automatisierbar: da gibt es nichts

Wenn das alles, oder zumindest Teile davon erfüllt wäre, hätten wir zur Qualitätsicherung die Möglichkeit mit einem schnellen Blick auf die Seite München/Transportation zu ermitteln, wo mal wieder Hand angelegt, repariert werden muss.

Ein nicht repräsentativer Check von Berlin, Hamburg und Aachen zeigt, dass andere Städte u.U. das gleiche Problem haben.

Diskutierte Ideen für ein Tool zur Qualitätssicherung

  • Mehrstufiges Vorgehen, d.h. einfacher machbare Prüfung realisieren, Verfeinerung später.
  • Parallel kann z.B. die Vollständigkeitsprüfung und die Routenanalyse angegangen werden.
  • Anfangs ist ggf. halbmanuelle Analyse, Konvertierung in Wiki-Tabelle, Hochladen denkbar. Automatisierungsskripte später.

Die folgende Vorgehensweise könnte man verfolgen

Vollständigkeit

Hier brauchen wir etwas, gegen das wir die Vollständigkeit messen. D.h. Vorschlag: eine CSV-Datei mit allen Linien des MVV.

  • als ersten Ansatz eine selbst erstelle CSV-Datei, die noch nicht einmal alle Linien enthalten muss - Hauptsache wir fangen mal an und haben einen ersten Startpunkt
    • Hier als Textdatei: MVV-Linien.
    • Ich habe mal aus den MVV Verkehrslinienplänen Stadt und Region mit pdftotext selbigen herausgezogen, mit einigen egrep/sed/sort etc. Shellkommandos eine Liste erstellt und noch ein paar manuelle Korrekturen vorgenommen. Das Ergebnis ist für den Anfang nicht schlecht, denke ich. Eine Liste vom MVV kann es nicht ersetzen, denn wie wir am Stammtisch diskutiert hatten, wäre eine Liste mit den Fahrwegen der Linien sehr gut. --Rainero (talk) 21:40, 15 February 2017 (UTC)
  • als finale Lösung wäre eine solche, vom MVV erhaltene CSV-Datei ideal.


Route-Master

Mögliche Overpass-API Queries um alle Route-Master aus der DB zu extrahieren:

  • Hier ist zu beachten, dass Route-Master-Relationen keine Ways und keine Nodes enthalten, sondern "nur" Relationen. Damit enthalten sie keine physischen Objekte, eine Suche nach Route-Master in einem begrenzten Gebiet (z.B. Oberbayern) scheitert somit.
  • http://overpass-api.de/api/interpreter?data=rel[network~"(MVV|Münch)"]["route_master"~"(bus|tram|train|subway|light_rail)"]; out meta;
    • Holt alle Route-Master-Relationen für Busse, Trams, Trains, Subways und Light-Rails (weltweit) aus der DB, wenn sie den Text "MVV" oder "Münch" irgenwo im Tag "network" haben.
    • Das wäre aber zu kurz gegriffen, denn hier würden wir Route-Master-Relationen ohne "network" Tag nicht erhalten, obwohl sie u.U. dem MVV zuzuordnen sind.
    • Wir würden u.U. aber auch false-positives erhalten, denn "MVV" ist auch die Abkürzung vom "Mannheimer Verkehrs-Verbund"!
    • Liefert derzeit etwa 2.850 Lines-of-XML (137 KB).
  • http://overpass-api.de/api/interpreter?data=rel["route_master"~"(bus|tram|train|subway|light_rail)"]; out meta;
    • Holt alle Route-Master-Relationen für Busse, Trams, Trains Subways und Light-Rails (weltweit) aus der DB.
    • Aus dieser Liste könnte man alle Relationen filtern, die kein "network" Tag haben oder wo "network" "MVV" oder "Münch" enthält
    • Wir würden u.U. aber auch false-positives erhalten, denn "MVV" ist auch die Abkürzung vom "Mannheimer Verkehrs-Verbund"!
    • Liefert derzeit etwa 332.000 Lines-of-XML (15.415 KB).
Route

Mögliche Overpass-API Queries um alle Route aus der DB zu extrahieren:

  • http://overpass-api.de/api/interpreter?data=area[name="Oberbayern"]; rel(area)["route"~"(bus|tram|train|subway|light_rail)"][network~"(MVV|Münch)"]; out meta;
    • Holt alle Route-Relationen für Busse, Trams, Trains, Subway und Light-Rails aus der DB, die in "Oberbayern" liegen und zum "MVV" oder zu "Münch" im "network" Tag passen.
    • Evtl. ist "Oberbayern" aber auch zu weit gegriffen?
    • Liefert derzeit etwa 76.100 Lines-of-XML (3.782 KB).
    • Oops: das ist aber wenig.
  • http://overpass-api.de/api/interpreter?data=area[name~"(Dachau|München|Ebersberg|Erding|Starnberg|Freising|Tölz|Wolfratshausen|Fürstenfeldbruck)"]; rel(area)["route"~"(bus|tram|train|subway|light_rail)"][network~"(MVV|Münch)"]; out meta;
    • Beschränkt die Suche auf die bekannten (Land-)Kreise des MVV mit "MVV" oder "Münch" im "network" Tag.
    • Liefert derzeit ebenfalls etwa 76.100 Lines-of-XML (3.782 KB).
    • Das ist immer noch wenig, aber außerhalb der Kreise gibt's in Oberbayern zumindest keine "MVV" oder "Münch" Linien - ist ja auch schon mal gut zu wissen.
  • http://overpass-api.de/api/interpreter?data=area[name~"(Dachau|München|Ebersberg|Erding|Starnberg|Freising|Tölz|Wolfratshausen|Fürstenfeldbruck)"]; rel(area)["route"~"(bus|tram|train|subway|light_rail)"]; out meta;
    • Beschränkt die Suche auf die bekannten (Land-)Kreise des MVV ohne nach dem "network" Tag zu filtern.
    • Das ist mehr als vorher, enthält nun aber auch z.B. "network" = "TNW" (wo immer das ist) und "Ingolstädter Verkehrsgesellschaft mbH" und "RVO" und ... (läßt sich ja nachträglich rausfiltern).
    • Die Liste enthält nun aber auch Relationen, die kein "network" Tag haben, was wir ja auch wissen wollen.
    • Liefert derzeit etwa 170.000 Lines-of-XML (8.249 KB).
Ergebnis-Analyse

Die beiden Ergebnisse zu Route-Master und Route kann man nun analysieren ... dazu später mehr ...

Was gibt es in dem Umfeld schon?

Im Umfeld gibt es schon einige Relation-Analyzer, auch welche, die sich auf Routen spezialisieren. Allen gemein ist, dass sie für eine gegebene Relation-ID (Input) eine Analyse durchführen - aber das wäre ja eigentlich schon mehr als die Hälfte dessen was wir brauchen.
Eine unstrukturierte Linksammlung:
Zwei Links haben wir im Wiki gefunden ...

Unsere französischen Kollegen haben schon seit längerem ein Tool zur Analyse von Route-Relationen

User Weide hat ein Tool "putr", das auf .pbf-Dateien (Geofabrik) angewendet wird und Plausibilitätsprüfungen macht und eine Fehlerliste erstellt:

Weiteres Vorgehen / Zeitplan

tbd.

Offene Punkte

tbd.


Diskussion 2017 zum Thema "Qualitätssicherung - München/Transportation

--ToniE (talk) 10:50, 14 February 2017 (UTC)
Was mir noch auffiel ...
Die Verwendung des Tags "network" ist in München/Transportation#Empfohlene_Tags überall nur "empfohlen". Es würde die Qualitätssicherung erleichtern, wenn wir "network" zumindest für Route-Master "verpflichtend" machen würden. Bei Route wäre es auch gut, wenn's dran wäre.
--ToniE (talk) 10:50, 14 February 2017 (UTC)

--Rainero (talk) 21:57, 13 February 2017 (UTC)
Hallo,
ein paar Gedanken habe ich in "diskutierte Ideen zur Qualitätssicherung" hinzugefügt. Die Einbindung von Fahrplandaten halte ich nicht für zielführend, weil das der Realität immer hinterherhinken wird und ob es jemals halbwegs vollständig wird, bezweifle ich. Andererseits liegen die Daten beim Verkehrsverbund aktuell vor, d.h. es braucht nur eine passende Verknüpfung. Hier für Karlsruhe ist das über die uic_ref der Haltestelle realisiert. Vielleicht für den MVV und andere auch machbar?
Wir hatten am Stammtisch auch kurz die Diskussion zu Betriebstagen und -zeiten, was aber verworfen wurde. Bzgl. Routingprogamm statt Wege in der Routenrelation war letztes Jahr mal kurz was im Users:Germany Forum; ich erinnere mich, daß es Ansätze dazu in der Schweiz gibt, das aber noch nicht perfekt funktioniert. Oft sind mehrere Wege zwischen zwei Haltestellen möglich.
Das französchische Tool zur Routenanalyse gefällt mir beim ersten Blick ganz gut, es liefert Werte für Unterbrechung (Ouverture), die in eine Übersichtstabelle geschrieben werden könnten. Die Darstellung auf der Karte finde ich übersichtlich, Verknüpfung der Problemzonen mit JOSM (éditer la zone dans JOSM) ist auch gut.
Deine Erfahrung, Miche101, kann ich gut nachvollziehen. Ich habe mich erst letzten Herbst an solche ÖPNV-Relationen gewagt und die ersten Schritte waren schon ... puuh. Aber ein Qualitätssicherungstool würde eben genau dabei helfen Fehler zu erkennen, von einem selbst oder anderen aus der OSM-Gemeinde. Ist ja gerade das schöne daran, daß jeder den Teil beitragen kann, den er kann bzw. gerne macht. Wenn ich heute wissen will, wie der Status der Buslinien im Lkr. Ebersberg ist, wo gibt's was zu tun, tja, was mache ich denn da?
--Rainero (talk) 21:57, 13 February 2017 (UTC)

--Miche101 (talk) 08:33, 13 February 2017 (UTC)
Hallo, ToniE hat mich angeschrieben ich soll hier auch mal meinen Senf dazu abgeben bzw. Kommentare, Ergänzungen, Ideen, ... Hintergrund... ich hab etliche Relationen in Ebersberg, Erding... und Richtung Freising schon gemacht.. Erfahrung es ist sehr aufwändig ;-)... das Ganze in eine geordnete Form zu bringen. Je mehr Relationen desto Aufwändiger.. eine Linie die Nummer 512 von Erding zum Flughafen oder 501 Erding - Moosburg ist für mich nicht mehr drin... da bräuchte man einen halben Tag bis mal das alles durchgesehen und verstanden hat. Bin dazu übergegangen erst einmal eine Relation zu machen in der alles ist alle Varianten... und wenn ich alle Haltestellen habe diese auf Hin- und Rückfahrt aufzuteilen mit einer Master-Relation aber mehr auch nicht. Mehr Aufwand für den wenigen Nutzen den man mit der Relation erzielt ist nicht drin. Ideen

  • Die Sketch-Line ist ganz nett zum kontrollieren müsste aber gefixt werden... da Platform und Halteposition doppelt aufgeführt werden.. wenn diese in der Relation drin sind. (Gibt schon seit längeren eine Bug-Report.. so weit ich weiss)
  • In Anwendung.. oder Kartendarstellung fehlt wichtige Infos... zu wann und wie oft so eine z.B. Bus fährt.. ob nur unter der Woche nur einmal am Tag usw.
  • Bei Buslinien könnte der Weg zwischen den Haltestellen auch durch einen Routingprogramm gerechnet werden.. und müsste man in einer Relation nur noch die Haltestellen vorhalten.. und auch nicht mehr die Wege zerstückeln... hab ich schon zum erstellen einer Relation angewendet, weil ich den Weg nicht genau kannte.
  • Das man auch Links zur Fahrplanauskunft hinterlegt... dass man z.b. in OSMand unterwegs... auf eine Haltestelle drückt und dann auf die Homepage des zuständigen Verkehrsbetriebes kommt..

--Miche101 (talk) 08:33, 13 February 2017 (UTC)


Relationen

Alte Diskussion zu Relationen von 2009-2011

Gehören die Haltestellen in die Relation? Ich denke, ja, hab sie aber nicht reingetan.Basstoelpel 12:32, 29 March 2009 (UTC)

Da läuft derzeit ein Vorschlag Unified Stop Area bzw. Vereinheitlichung von Haltestellen.
Ich denke, den sollten wir abwarten, da er z.B. die Verwendung von highway=bus_stop neu definieren will. ToniE 08:24, 07 April 2009 (UTC)
Soweit ich das sehen kann, lassen sich alte Bus stops, die neben dem Weg liegen per Bot auf Platform umstellen. Es gibt also keinen Grund etwas abzuwarten. --Lulu-Ann 16:00, 7 April 2009 (UTC)
Ist aber derzeit "nur" ein Proposal! Ja, bus_stop neben der Fahrbahn lässt sich per bot in platform ändern, im Ernstfall (Proposal: rejected) u.U. aber nicht 100%ig wieder rückgängig machen. ToniE 19:16, 07 April 2009 (UTC)
Wer sagt denn, daß man den Bot starten soll, bevor das proposal angenommen wurde? Basstoelpel 20:03, 9 April 2009 (UTC)
In Karlsruhe gab's einen Workshop zu ÖPNV. Das Ergebnis ist hier dokumentiert: --ToniE 20:57, 28 May 2009 (UTC)
Ich habe mal angefangen mit der Regional-Busline 224. Die ÖPNV-Karte zeigt zwar die Bushaltestellen (highway=bus_stop noch vorhanden, neben public_transport=platform|stop_position), nicht aber die Linie (Relation: line=bus statt route=bus). Bin mal auf GeoFabrik gespannt. --ToniE 15:32, 28 June 2009 (UTC)
Ich hab mir angewöhnt, die Haltestellen in die Relation aufzunehmen und die Liniennummern mit bus_routes zu taggen, normalerweise die bus_stop oder, wenn schon jemand eine Stop Area angelegt hat, dann die Haltestellenrelation. Stop areas mag ich selbst nicht anlegen, weil ich die vorgeschlagene Struktur ehrlich gesagt noch nicht verstanden habe. Solange da weder Konsens zur Unified Stop Area besteht noch JOSM einem mit einer brauchbaren Vorlage unterstützt, finde ich das am praktischsten und sinnvollsten. Wenn die Haltestellen in der Relation sind, kann ich sowohl mit der Online-Relationsprüfung, als auch mit dem Relationseditor in JOSM einfach die Vollständigkeit der Haltestellen erkennen. Sendelhorst 09:35, 1 May 2010 (UTC)
So, nun muss ich mir doch mal selbst antworten. Inzwischen hab ich verschiedenes ausprobiert und die Erklärungen in http://wiki.openstreetmap.org/wiki/Proposed_features/Stop_Area#Stop_Area erscheinen mir einigermaßen einleuchtend. Das passt für Bahnstationen und Busse und lässt sich IMHO ohne Konflikte mit anderen Tagging-Varianten kombinieren. Unklar bleibt allerdings, welche Element die Route-Relation gehören. Eindeutig und ausreichend wäre IMHO die Stop-Position, aber die zugehörige Plattform ist u.U. nicht eindeutig aus der Relation ermittelbar. Im Zweifelsfall kann man sie ja hineinnehmen mit Rolle plattform. Auf die Eingangsfrage zurückkommend, denke ich, mindestens ein Element sollte zur Haltestelle in die Routenrelation aufgenommen werden, ob das die Site-Relation der Haltestelle oder die Stop-Position und optional die platform hängt von den Gegebenheiteten ab und davon, welche Details in OSM erfasst sind. Sendelhorst 20:41, 13 June 2010 (UTC)
Unter Proposed_features/Public_Transport wurde vor kurzem ein Schema zum erweiterten Tagging von ÖPNV-Linien vorgeschlagen und mit großer Mehrheit angenommen. Damit sind wohl das Schema von Oxomoa und die anderen Vorschläge obsolet. In Bezug auf die ursprüngliche Frage: Sowohl die "stop positions" als auch die "platforms" sollen in die Relation, und zwar gruppiert (erst der stop, dann die zugehörigen platforms) und sortiert in der Richtung der Route. Die Ways der Route sollen zusammenhängend sein und nach den stops und platforms kommen, ebenfalls in der Reihenfolge der Route. --MForster 16:01, 24 April 2011 (BST)

Templates

Für den Status wären Templates nett. Gibt es die schon irgendwo oder fühlt sich jemand berufen, welche zu designen?

Hab es jetzt selbst gemacht. Kommentare? Basstoelpel 18:19, 25 June 2009 (UTC)
Für die Haltestellen hast Du 'bus_lines' und 'bus_routes' als in München gebräuchlich beschrieben. Ich schlage vor, auf das allgemeine Tag 'ref' zu wechseln, da dieses Tag universeller ist. Siehe: Autobahnen, Bundes-, Staats- und Kreisstraßen, Strommasten, ... und nicht zuletzt: Name der Busline in einer Relation 'route=bus'. --ToniE 15:25, 28 June 2009 (UTC)

Behindertengerecht

Hi, es wäre wertvoll, wenn die Behindertengerechtigkeit gleich mit getaggt werden könnte.

Siehe tactile_paving=yes/(no)/irritating und wheelchair=yes/no/limited User:Lulu-Ann

Tagging vereinheitlichen

Ich schlage vor, dass wir uns ein bisschen detaillierter einigen, wie wir ÖPNV in München taggen. Nachdem vor kurzem ein erweiterter Vorschlag zum Tagging von ÖPNV mit großer Mehrheit angenommen wurde, denke ich, dass wir uns danach richten sollten. Ich habe kürzlich die Tram 19 nach diesem Schema gemapped: Relation 61456 (XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx), und stelle diese Linie gerne als Diskussionsobjekt zur Verfügung.

Außerdem habe ich festgestellt, dass wir einigermaßen uneinheitlich taggen. Vielleicht schaffen wir es, das etwas zu vereinheitlichen. Ich führe hier mal beispielsweise einen ein paar Punkte an, die wir klären sollten. Bitte fügt weitere Punkte hinzu!

  • Sollen wir ältere, obsolete (?) Tags entfernen (bus_routes=66,77, bus_lines=66,77, etc)?
    • Eigentlich sind bus_routes=66,77, bus_lines=66,77, ref=66,77, route_ref=66,77, ... redundant, wenn (und da) jede Haltestelle (platform, stop_position) in entsprechenden Relationen eingebunden sind. Aber das setzt die Verarbeitung von Relationen voraus: die alte Diskussion bzgl. am Node/Way taggen vs. Relationen. Wenn wir etwas belassen, dann aber einheitlich - gibt es da schon etwas? --ToniE 10:57, 25 April 2011 (BST)
    • Ich würde langfristig diese Tags gerne loswerden, aber das geht erst wenn es Relationen für alle Routen an einer Haltestelle gibt. Aber mehrere verschiedene Tags am Knoten sind wirklich nicht notwendig. Mein Vorschlag wäre nur ref=66,77 zu verwenden. Das hat laut Wiki die beste Legitimation. Allerdings tendiere ich dazu, lieber gleich die Knoten in die Relationen aufzunehmen (auch wenn diese noch unvollständig sind), und alle diese Tags gleich zu entfernen. --MForster 15:36, 25 April 2011 (BST)
  • Wie verlinken wir zu MVG/MVV etc? Weit verbreitet scheint operator=MVG, network=MVV, website=http://www.mvv-muenchen.de, note=http://wiki.openstreetmap.org/wiki/M%C3%BCnchen/Transportation#StadtBus oder ähnlich.
    • Ja so würde ich es machen. Eventuell eine Relation: MVV mit allen Transportmitteln drin: als Relationen U-Bahn, S-Bahn, Tram, Nacht-Tram, Metro-Bus, Stadt-Bus, Nacht-Bus, Regional-Bus. In diesen Relationen dann wieder die Route Master der Linien, ... --ToniE 10:57, 25 April 2011 (BST)
      • Das ist auch ein altes Diskussionsthema. Viele argumentieren, dass solche Relationen nicht notwendig sind, weil sie sich aus den Elementen ableiten lassen. Ich hab da keine Meinung. Wenn jemand diese Relationen anlegt würde ich sie auch gerne bei meinen Edits aktuell hatlten. --MForster 15:36, 25 April 2011 (BST)
    • Und 'note' hatte ich mal eingefügt um auf note=http://wiki.openstreetmap.org/wiki/M%C3%BCnchen/Transportation hinzuweisen, damit die Seite allgemeiner bekannt und gepflegt wird. Z.T. existierten mehrere Relationen für den selben Bus. --ToniE 10:57, 25 April 2011 (BST)
      • Das macht durchaus Sinn. Ich denke es reicht aber, den Verweis in die Routen, Route Masters und Stop Areas aufzunehmen. Auch die anderen Tags sind an den Platformen und Stop Positions normalerweise redundant. Abweichendes Beispiel: Am Ostbahnhof würde ich die Stop Area mit operator=DB;MVG markieren, die Haltestelle der Tram mit operator=MVG und die Bahnsteige der S-Bahn als operator=DB. Vor mir aus auch gerne die ausgeschriebenen Namen, aber dann konsequent. --MForster 15:36, 25 April 2011 (BST)
  • Umsteigemöglichkeiten im Haltestellennamen: Einige Namen von Haltestellen und Liniennamen enthalten Zusätze wie "(S/U)" um anzuzeigen wie man an einer Haltestelle umsteigen kann. Ich denke dass diese Zusätze nicht Bestandteil des Namens sind und deshalb nicht angeführt werden sollten. Außerdem sind diese Zusammenhänge automatisch leicht aus den Routen und Stop Areas zu erkennen.
    • Ja, "(S/U)" kann man weglassen, wenn stop_areas vorhanden sind. --ToniE 10:57, 25 April 2011 (BST)

Lasst uns das doch hier diskutieren. Wenn wir uns einigen können, dann erkläre ich mich gerne bereit, eine ausführliche Zusammenfassung zu schreiben.

--MForster 16:01, 24 April 2011 (BST)

So, ich hab jetzt mal eine erweiterte Beschreibung auf der Hauptseite hinzugefügt. Ich hoffe, es sind nicht zu viele Fehler drin. Bitte korrigieren und diskutieren! --MForster 20:50, 25 April 2011 (BST)

Wäre es angebracht das man bei der "Empfohlenen Tags" für die Relationen Route, Route Master und Stop Area auch die Mitglieder der jeweiligen Relationen mit aufführt, wie es in dem Vorschlag zum Tagging von ÖPNV erklärt wird ? --JJ Rammerl 17:18, 10 June 2011 (BST)

Von mir aus gerne --MForster 20:01, 10 June 2011 (BST)
Hab das mal hinzugefügt --JJ Rammerl 20:40, 13 June 2011 (BST)