Talk:München/Transportation

From OpenStreetMap Wiki
Jump to navigation Jump to 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/Transportation Seite:

  1. Vollständig:
    1. wir wissen nicht, ob wir alle existierenden Buslinien des MVV auf der Seite aufgelistet haben
    2. wir wissen nicht, ob wir Artefakte, d.h. Buslinien gemapped haben die bereits (wieder) eingestellt oder umnummeriert worden sind
      1. S-Bahn, U-Bahn und Tram sind in ihrer Anzahl überschaubar, da besteht die Chance, dass wir vollständig sind
  2. PTv2:
    1. 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 Approved Feature Public Transport (approved Version 625726)
  3. Korrekt:
    1. 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:
    1. 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:
    1. wir haben keine Seite, auf der uns all das, vor allem aber die Probleme damit, übersichtlich angezeigt wird
  6. Automatisierbar:
    1. 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ätssicherung 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
    • diese Datei wurde ins sehr schnell von Franziska und Vivian (MVG/MVV) für die Busse zur Verfügung gestellt
    • diese Datei müsste periodisch beim Fahrplanwechsel im Dezember neu erstellt werden - noch abzustimmen.

Mögliche Overpass-API Abfragen

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).

==> Verworfen, da

  • nicht in einem Gebiet gesucht werden kann
  • "alte" Relationen keinen Route-Master haben. Eine Analyse auf Vollständigkeit scheitert somit.
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 Orte (?) 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).
  • http://overpass-api.de/api/interpreter?data=area[boundary=administrative][admin_level=6][name~"(Dachau|München|Ebersberg|Erding|Starnberg|Freising|Tölz|Wolfratshausen|Fürstenfeldbruck)"]->.L; rel(area.L)["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 weniger als vorher, enthält nun weniger fremde "network" .
    • Die Liste enthält nun aber auch Relationen, die kein "network" Tag haben, was wir ja auch wissen wollen.
    • Liefert derzeit etwa 135.000 Lines-of-XML (6.540 KB).

==> Verworfen, da

  • nur sehr wenige Checks (auf die Tags der Relation) gemacht werden können
Route-Master + Route

Mögliche Overpass-API Query um alle Route und die dazugehörigen Route-Master Relationen aus der DB zu extrahieren:

  • http://overpass-api.de/api/interpreter?data=area[boundary=administrative][admin_level=5][name='Oberbayern']->.O; area(area.O)[boundary=administrative][admin_level=6][name~'(Dachau|München|Ebersberg|Erding|Starnberg|Freising|Tölz|Wolfratshausen|Fürstenfeldbruck)']->.L; rel(area.L)[route~'(bus|tram|train|subway|light_rail|taxi|ferry)']; out; rel(br); out;
    • Beschränkt die Suche auf die bekannten (Land-)Kreise des MVV im Bezirk "Oberbayern" ohne nach dem "network" Tag zu filtern.
    • Hier wurde der Suchbereich noch auf den Admin-Level "5" (Bezirk) mit dem Namen "Oberbayern" eingeschränkt um z.B. Daten aus einem u.U. existierenden Kreis "Erding" sonstwo auf der Welt auszuschließen.
    • Zudem wurde die Overpass-API Query noch ein wenig erweitert - um "rel(br); out;" - um auch die zugehörigen "Route-Master" Relationen zu erhalten.
    • Relationen, die kein "network" Tag haben sind auch dabei, was wir ja auch wollen.
    • Die Liste enthält nun auch die zugehörigen "Route-Master" Relationen.
    • das "meta" wurde weg gelassen, die zugehörigen Informationen brauchen wir nicht.
    • Liefert derzeit etwa 150.000 Lines-of-XML (7.213 KB).

==> Verworfen, da

  • nur sehr wenige Checks (auf die Tags der Relationen) gemacht werden können
Route-Master + Route + Way

Mögliche Overpass-API Query um alle Route und die dazugehörigen Route-Master Relationen sowie deren Ways aus der DB zu extrahieren:

  • http://overpass-api.de/api/interpreter?data=area[boundary=administrative][admin_level=5][name='Oberbayern']->.O; area(area.O)[boundary=administrative][admin_level=6][name~'(Dachau|München|Ebersberg|Erding|Starnberg|Freising|Tölz|Wolfratshausen|Fürstenfeldbruck)']->.L; rel(area.L)[route~'(bus|tram|train|subway|light_rail|taxi|ferry)']; out; way(r); out; rel(br); out;
    • Beschränkt die Suche auf die bekannten (Land-)Kreise des MVV im Bezirk "Oberbayern" ohne nach dem "network" Tag zu filtern.
    • Hier wurde der Suchbereich noch auf den Admin-Level "5" (Bezirk) mit dem Namen "Oberbayern" eingeschränkt um z.B. Daten aus einem u.U. existierenden Kreis "Erding" sonstwo auf der Welt auszuschließen.
    • Die Overpass-API Query wurde erweitert - um "rel(br); out;" - um auch die zugehörigen "Route-Master" Relationen zu erhalten.
    • Zudem wurde die Overpass-API Query noch weiter erweitert - um "way(r); out;" - um auch die zugehörigen "Way-Member" der Route-Relationen zu erhalten.
    • Relationen, die kein "network" Tag haben sind auch dabei, was wir ja auch wollen.
    • Die Liste enthält nun auch die zugehörigen "Route-Master" Relationen.
    • Die Liste enthält nun auch die zugehörigen "Way" Member der Route-Relationen.
    • das "meta" wurde weg gelassen, die zugehörigen Informationen brauchen wir nicht.
    • Liefert derzeit etwa 1.161.000 Lines-of-XML (37.744 KB).

==> Verworfen, da

  • zwar mehr, aber nocht nicht alle möglichen Checks gemacht werden können - Nodes fehlen.
Route-Master + Route + Member (Relationen + Ways + Nodes)

Mögliche Overpass-API Query um alle Route und deren Route-Master sowie alle Member: Relationen (z.B. Platformen als MP), Ways und Nodes aus der DB zu extrahieren:

  • http://overpass-api.de/api/interpreter?data=area[boundary=administrative][admin_level=6][name~'(Dachau|München|Ebersberg|Erding|Starnberg|Freising|Tölz|Wolfratshausen|Fürstenfeldbruck)']->.L; rel(area.L)[route~'(bus|tram|train|subway|light_rail|taxi|ferry)']->.R; rel(br.R); out; rel.R; out; rel(r.R); out; way(r.R); out; node(r.R); out;
    • Liefert derzeit etwa 1.244.200 Lines-of-XML (41.000 KB).

==> Ausgewählt, da

  • hiermit schon sehr viele wichtige Checks gemacht werden können

Ergebnis-Analyse

Vorgehen

Die Ergebnisse zu Route-Master, Route und deren Member Ways und Nodes kann man nun analysieren ...

Siehe hierzu: ToniE's Wiki-Page

Ergebnisse

Basierend auf der so genannten "großen Abfrage": Route-Master + Route + Member (Relationen + Ways + Nodes)

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:

Einen weiteren Hinweise findet man auf der zum Overpass API zählenden Seite

Dort findet man (von ebenfalls französische Kollegen?) ein Python Skript ...

Der OSM Inspector hat sei neuestem (2017-11) eine verbesserte Analyse von Public Transport

Weiteres Vorgehen / Zeitplan

Freigegeben: Siehe: PTNA - Public Transport Network Analysis

  • Implementierung läuft ...
  • Fortschritt kann ToniE's Diskussionsseite entnommen werden.
  • Die Ergebnisse für München, Oberbayern, Augsburg, Ingolstadt und Verkehrsverbund Rhein-Sieg werden in der Regel
    • abends aktualisiert
    • Zeitstempel der Daten zwischen 19:00 und 20:00
    • update erfolgt semi-automatisch
      • Skript: Download der Daten mit wget-Aufruf und Start der Analyse
      • Manuell: c&p des Ergebnisses ins Wiki
  • Die Funktion soll im HTML-Format auf Regio-OSM bereitgestellt werden. Die Analyse läuft dann automatisiert, derzeit täglich um 23:25 wird aber noch nicht verlinkt.

Offene Punkte

  • Route-Master, deren Route-Member als Relation nicht mehr existieren (kann das auftreten?)
  • Route-Master, die keine Route-Member haben
    • komplett leer sind
    • oder nur Nodes und Ways enthalten (was eigentlich schon ein Fehler an sich ist)

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

--ToniE (talk) 12:31, 5 August 2017 (UTC)
Ich stimme Dir zu, und auch ich bin eher nachlässig was den Update angeht. Wir können auf das manuelle Pflegen der Listen verzichten.
Ich kann die Skripte zur Qualitätssicherung ein wenig erweitern, und für München auch zwei Listen generieren MVV-Stadt und MVV-Region.

  • 'fixme' und 'note' Tags werden derzeit wie 'Fehler' behandelt und in der entsprechenden Spalte ausgegeben
  • 'comment' Tag wird als 'Anmerkung' gewertet und ebenfalls ausgegeben
  • 'check_date' Tag wird ebenfalls als 'Anmerkung' gewertet und ausgegeben. 'check'date' könnte als 'zuletzt geprüft am ...' hergenommen werden (ist teilweise schon der Fall)

Was den roten Haltestelle-Punkt angeht: Artefakt? Schon gelöscht und nach dem nächsten Update der Karte wieder raus? Ich konnte in den Daten nichts finden.

--Flutus (talk) 12:02, 5 August 2017 (UTC) Einige route_master ergänzt und andere Aufräumarbeiten.

Die Übersicht https://wiki.openstreetmap.org/wiki/M%C3%BCnchen/Transportation#Verkehrsmittel ist an manchen Stellen recht veraltet. Offenbar legen Leute fehlende Linien an, ohne das im Wiki nachzutragen, Die U7 Verlängerung wurde im Wiki auch nicht nachgetragen, etc. Ich bin inzwischen dafür die Übersicht für München (ggf. ohne die Regionalbusse) automatisch zu generieren mit den Skripten, welche für die Qualitätssicherung entwickelt wurden. Die Daten dafür sind alle schon in OSM vorhanden, die Liste im Wiki ist eine Kopie und wird damit letztlich immer veraltet gegenüber dem OSM stand sein. Die Qualität der Münchner Linien in OSM ist bis auf vereinzelte Ausnahmen und die Regionalbusse sehr gut. Ein Status "Komplett" von 2014 ist heute auch nicht mehr viel wert. Fehler können im Fixme Feld direkt in OSM eingetragen und in die Listen mit reingeneriert werden. Andere Stati wie z.b. zuletzt geprüft am ... etc. abenfalls, braucht man nur sich auf ein neues Feld einigen. Sonstige Anmerkungen kann man gesondert als Text aufführen, wie das mit dem Abschnitt Fahrplanänderungen ja ohnehin schon der Fall ist.

PS: Weiß jemand woher dieser rote Haltestellen-Punkt in den Bavaria-Filmstudios kommt? https://www.openstreetmap.de/karte.html?zoom=16&lat=48.06339&lon=11.55622&layers=00B0TT

--ToniE (talk) 09:02, 13 July 2017 (UTC)
Danke für die Sammel-Relationen, ich werde mal schauen, wie ich sowas in die Analyse mit einbauen kann ...
--ToniE (talk) 09:02, 13 July 2017 (UTC)

Ich habe einige fehlenden Sammel-Relationen angelegt:
http://www.openstreetmap.org/relation/7099889
Bei den Regionalbussen noch nicht, da dort vielfach die Master-Relationen fehlen.
--Flutus (talk) 22:09, 23 March 2017 (UTC)

--ToniE (talk) 09:02, 13 July 2017 (UTC)
Danke für die Anregung, derzeit haben wir:

  • network="Münchner Verkehrs- und Tarifverbund"
  • netwirk:short="MVV"
  • network:guid="DE-BY-MVV"
  • network:area=city|region|...
  • route:category=metro|express|normal|...
  • by_night=yes|no

--ToniE (talk) 09:02, 13 July 2017 (UTC)

Ich bin auch dafür Eindeutig zu definieren, dass es verpflichtend ist, Vorschlag:
Verpflichtend für Route und Route-Master:
network: "MVV"
network:long: "Münchner Verkehrs- und Tarifverbund"
Da MVV auch bei anderen Verbünden als Abkürzung vorkommen kann würde ich dann network:short= "de-by-mvv" oder etwas änliches verwenden.
PS: Gibt es eine Möglichkeit um temporäre/Sonder-Linien zu kennzeichnen die nur zu bestimmten Anlässen fahren (z.B: Badebus, SEV)?
PPS: Gibt es eine Möglichkeit zur weiteren Unterteilung von route=bus in einem extra Feld: Xpress-Bus, Metro-Bus, (Normal,) Ruftaxi, Sonstiges (SEV, Christkindel Tram, Linie 07, ...)?
--Flutus (talk) 22:00, 20 March 2017 (UTC)

--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, 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)

Tagging von Haltestellen

Bisher habe ich mich mit ÖPNV-Haltestellen nur als Nutzer von OsmAnd oder osm.org beschäftigt. Dabei habe ich mich immer wieder geärgert/gewundert, dass die Haltestellen in München bei kleiner Zoom-Stufe immer (?) auf der Straße gezeigt werden, so dass nicht von vornherein klar ist, in welche Richtung der Bus dort abfährt. Bei höherer Zoom-Stufe wird dann jede Haltestelle doppelt angezeigt (auf/neben der Straße, oder es tauchen Wartehäuschen an Stelle der Haltstellen auf). In anderen Städten klappt das besser, z.B. in Berlin.

In München sieht eine typische Bushaltestelle so aus (ganz im Einklang zu dem für München empfohlenen Tagging; sorry für die Ausführlichkeit -- ich bin ÖPNV-Anfänger):


Zu München: hier sind der MVV und auch die Firma Mentz (im Auftrag des MVV) an der Arbeit. Bevor hier geändert/zerstört wird, sollte man das auch mit denen diskutieren. --ToniE (talk) 13:30, 27 July 2017 (UTC)
Danke für den Hinweis. Ich habe beide auf diese Seite hier aufmerksam gemacht. Die DE:MENTZ GmbH/Modellierungsvorschläge ÖPNV finde ich gut, wobei mir auffällt, dass das 'old style' highway=bus_stop dort gar nicht erwähnt wird. --Paosow (talk) 15:47, 28 July 2017 (UTC)
Bzgl. highway=bus_stop: hier gibt es Mischformen, ich stimme Dir aber zu, dass man das wie in Berlin handhaben sollten. Haben einige Leute (auch ich) z.T. schon geändert. --ToniE (talk) 13:30, 27 July 2017 (UTC)
Es freut mich, dass du das genauso siehst. Das war ja der Auslöser, dass ich mir überhaupt das ÖPNV-Tagging etwas detaillierter angeschaut habe. Und es ist weiter mein wichtigstes Anliegen. Der Rest den ich hier geschrieben habe, betrifft nur Dinge, die mir sonst noch aufgefallen sind. --Paosow (talk) 15:47, 28 July 2017 (UTC)


In Berlin dagegen wird es einheitlich so gemacht

In vielen anderen Städten scheint es keine Einheitlichkeit zu geben.

Der wesentliche Unterschied ist, dass in München das highway=bus_stop auf, in Berlin dagegen neben der Straße ist. Laut der Beschreibung zu bus_stop ist neben der Straße das Empfohlene und Übliche. In München wird es derzeit einheitlich anders gemacht. Ich finde, das sollte an den 'Standard' angepasst werden. Gibt es Gründe gegen eine Änderung? Wie ist eure Meinung? Ich mag nicht ohne Rückfrage die Einheitlichkeit stören.

"das sollte an den 'Standard' angepasst werden": einen solchen 'Standard' gibt es meines Erachtens nicht. Sollte highway=bus_stop mit flächendeckender Einführung von Public Transport V2 (Public Transport, Approved Feature Public Transport) nicht sogar verschwinden? --ToniE (talk) 13:30, 27 July 2017 (UTC)
Das ist mir bewusst; deshalb steht 'Standard' in Anführungszeichen. Ich habe es so genannt, weil es aus meiner Sicht das Übliche ist. Auch was den Wegfall von highway=bus_stop angeht, sind wir uns anscheinend einig. --Paosow (talk) 15:47, 28 July 2017 (UTC)

Ein weiterer Unterschied ist, dass in München die platform eigentlich immer eine Fläche ist. Eine typische Größe scheint 15m·2m zu sein. Für einzelne große Haltestellen mag das okay sein, aber nicht für die Feld-Wald-Wiesen-Station. Zusätzlich zu dieser Fläche gibt es dann, soweit vorhanden, noch eine shelter (shelter_type=public_transport), die von der Logik her aber nichts mit der Haltestelle zu tun hat, häufig aber statt der Haltestelle dargestellt wird. Dabei steht im platform-Objekt schon shelter=yes. Insgesamt ist das Münchner tagging um einiges komplizierter.

Hier sind/waren MVV und Mentz tätig
Der Eindruck täuscht, tatsächlich sind Punkt, Linie und Fläche als platform zu finden.
Es spricht nichts dagegen, durch shelter=yes an der Platform und amenity=shelter, shelter_type=public_transport als eigenständiges Objekt etwas Redundanz zu haben.
"aber statt der Haltestelle dargestellt wird": das ist ein Renderingproblem, nicht ein Problem der Datenerfassung, denn die Daten sind ja korrekt.
"Insgesamt ist das Münchner tagging um einiges komplizierter": nicht komplizierter, eher redundanter? --ToniE (talk) 13:30, 27 July 2017 (UTC)
Da liegt der Hase im Pfeffer. Mit der Redundanz habe ich nämlich so meine Probleme. Normalerweise wird doch versucht, Redundanzen in Datenbanken zu vermeiden, denn wo es Redundanzen gibt, sind Inkonsistenzen nicht fern, die sich nur mit großem Aufwand und viel Disziplin vermeiden lassen. Hier haben wir ein Nebeneinander von 'old style' tagging (highway=bus_stop und amenity=shelter) und 'new style' tagging (public_transport=platform mit shelter=yes). Es hat eine ganze Weile gedauert, bis ich da halbwegs durchgeblickt habe. Alle Probleme damit auf den Renderer zu schieben, finde ich 'unfair'. Man muss es ihm doch durch die Angabe von doppelten, sich ergänzenden oder womöglich einander widersprechendenden Infos nicht unnötig schwer machen. Auch bei openptmap.org, wo sich die Entwickler mutmaßlich viele Gedanken zu ÖPNV gemacht haben, werden sowohl die bus_stops als auch die platforms dargestellt, obwohl sie dasselbe repräsentieren. Diese Doppelung fehlerfrei zu verhindern, dürfte kaum möglich sein. --Paosow (talk) 15:47, 28 July 2017 (UTC)
Bzgl. Redundanzen: da habe ich eine leicht andere Auffassung, aber: ja mei ... Inkonsistenzen (d.h. fehlerhafte Daten) lassen sich bei Redundanzen u.U. besser erkennen --ToniE (talk) 09:28, 1 August 2017 (UTC)

Ich habe drei Haltestellen einmal entsprechend geändert:

  • Planegger Straße: highway=bus_stop als Punkt neben der Straße (sonst keine Änderung);
  • Engelbertstraße: zusätzlich die platform-Fläche durch eine Linie ersetzt;
  • Pasinger Marienplatz: zusätzlich die amenity=shelter abgeräumt (bei der platform ist sie drin; an der Engelbertstraße gibt's keine shelter).
das ist nicht so gut, denn hier hast Du Informationen ohne Nachfrage zerstört, die andere in u.U. Kleinarbeit mühsam eingetragen haben. --ToniE (talk) 13:30, 27 July 2017 (UTC)
In diesem begrenzten Umfang (shelter-amenities an einer Haltestelle gelöscht) schien und scheint mir das vertretbar zumal die shelters ja durch shelter=yes nicht weg sind. --Paosow (talk) 15:47, 28 July 2017 (UTC)

Ich finde das System 'Pasinger Marienplatz' am besten. Es ist deutlich einfacher; nur weiß ich nun nicht mehr, ob die shelter rechts, links oder hinter dem Haltestellenzeichen steht. Bisher habe ich sie aber immer auch ohne Karte gefunden.

wie sieht das System "Pasinger Marienplatz" konkret aus? Vorher, nachher. --ToniE (talk) 13:30, 27 July 2017 (UTC)
Vorher: 'Münchner Tagging' (siehe ganz oben); nachher: Änderungen s. voriger Absatz (außerdem habe ich die Positionierung geändert). --Paosow (talk) 15:47, 28 July 2017 (UTC)

--Paosow (talk) 12:29, 26 July 2017 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:München/Transportation&oldid=1689414"