Talk:Bayerische Eisenbahngesellschaft (BEG)

From OpenStreetMap Wiki
Jump to navigation Jump to search

Allgemeines zum Projekt

Generell werden momentan nur Bushaltestellen thematisiert, da die RMS-Mapper vorerst nur an diesen arbeiten. Parallel dazu wird das Tagging-Schema für komplexere Haltestellen geschärft, um auch dieses zeitnah vorstellen und diskutieren zu können.


Momentane Lösungen: Zur Zeit werden nur noch einfache Bushaltestellen, die nicht an Realtionen hängen hochgeladen. Die Haltestellen im Raum Rosenheim, an denen Relationen kaputt gegangen sind werden momentan von den Mappern der rms nochmal überarbeitet und repariert.

Mittlerweile werden im Raum Rosenheim, RBO und RVO auch Haltestellen, an denen Relationen hängen bearbeitet.

Grundsätzlich werden nun alle normalen Bushaltestellen als Nodes mit Attributen modelliert, was die Unstimmigkeiten zu Bänken, Wartehäuschen, sowie highway- und bus-tags einfach klären sollte.

Unter dem Link zu Verwendetes Tagging Schema könnt ihr den aktuellen Stand der Modellierungsvorgaben für einfache Bushaltestellen sehen. Dort wird auch ersichtlich, wie mit den Kritikpunkten umgegangen wurde.

Die weiteren Punkte werden gerade intern abgestimmt und hier zeitnah ergänzt.

Quellen

Wie sieht das mit den verwendeten Quellen aus? Sind sie OSM konform, sprich unter welcher Lizenz stehen sie?
Wie sieht das mit den GTFS-Daten aus insbesondere ref:IFOPT=*? Sind die Daten für OSM freigegeben? Können sie dann auch in PTNA aufgenommen werden?
Könnt Ihr das bitte auf der Seite klar stellen und entsprechende Quellenangaben, eventuell mehrere, in Euren Änderungssätzen angeben? Vielen Dank --Skyper (talk) 14:18, 11 March 2021 (UTC)

  • Danke für den Hinweis, die verwendeten Quellen werden in der Hauptseite klarer hervorgehoben. Für dieses Projekt wird die Haltestellendatenbank der BEG genutzt, welche derzeit durch Vor-Ort-Begehungen bezüglich barrierefreier Infrastruktur und Fotos der Haltestellen ergänzt wird. Das Ziel dieses Projektes ist, eben diese aufgenommenen Informationen über OSM frei verfügbar zu machen,dazu zählt auch die "ref:IFOPT". Zusätzlich werden bei der Modellierung auch Stationspläne der BEG (https://wiki.openstreetmap.org/wiki/File:Scan_Nutzungsbest%C3%A4tigung_Stationspl%C3%A4ne_OSM_f%C3%BCr_Mentz.pdf) und Luftbilder als Informationsquellen verwendet. --BEG (talk) 08:14, 19 March 2021 (UTC)
Unter "deutlich" dargestellt, verstehe ich einen eigenen (unter-)Abschnitt mit Überschrift. Stehen die ref:IFOPT=* auf den Schildern bzw. auf den Stationsplänen. Gibt es Pläne von jeder Haltestelle? Habe leider immer noch nicht genau verstanden woher die ref:IFOPT=* kommt und ob diese Daten frei zugänglich gemacht werden können. --Skyper (talk) 12:09, 24 March 2021 (UTC)
  • Ja, die ref:IFOPT Angaben sind frei nutzbar. Im Projekt BEG Barrierefreiheit4ÖPNV werden die ref:IFOPT Angaben aus der DEFAS Datenbank nach OSM übertragen. Die dort enthaltenen ref:IFOPT Angaben stammen von den jeweils für die Haltestelle Verantwortlichen Datenlieferanten. Diese DEFAS Daten werden auch regelmäßig an das zentrale Haltestellenverzeichnnis ( https://zhv.wvigmbh.de ) übergeben. Die dort enthaltenen Daten können nach Registrierung öffentlich abgerufen werden.--BEG (talk) 12:57, 26 March 2021 (UTC)
  • Der DELFI e.V. hat auf unsere Rückfrage nochmals bestätigt, dass die Übernahme der globalen Haltestellen ID (DHID) in OSM als Teil des Projektes ausdrücklich erwünscht ist und die DHID auch OSM lizenzkonform frei zur weiteren Verfügung genutzt werden kann. --BEG (talk) 09:55, 21 May 2021 (UTC)

Relationen

Schwerwiegende Fehler

Hierbei handelt es sich um Fehler, die bestehende Daten unbrauchbar machen. Bevor hier keine Lösung gefunden wurde sollte so nicht weiter editiert werden. (--ToniE (talk) 09:34, 24 February 2021 (UTC))

  • Zerstörung von Bus-Relationen (--ToniE (talk) 09:34, 24 February 2021 (UTC))
    • Die Informationen von Haltestellen-Nodes werden an neue Haltestellen-Ways übertragen und ergänzt. Dabei wird die Member-Eigenschaft des Nodes in diversen PT-Relationen nicht auf den Way übertragen. In den Relationen bleiben Haltestellen (platform), die keinerlei Informationen enthalten. Die PT-Relation wird unbrauchbar, der Reparaturaufwand ist hoch (z.B. ~ 15 Minuten für 5 Haltestellen in Rosenheim, abhängig von der Anzahl der betroffenen Relationen).
  • Zerstörung von stop_area-Relationen (--ToniE (talk) 09:34, 24 February 2021 (UTC))
    • Das oben gesagte gilt auch für diese Relationen, wenngleich sie (derzeit noch) seltener vorkommen und der Reparaturaufwand "nur" mit der Anzahl der Haltestellen korreliert.
Beide Fälle lassen sich mit der Funktion "Replace Geometry" des Plugins utilsplugin2 vermeiden. Wieweit diese Umwandlung gewollt gut ist, ist eine andere Frage, s.u.. --Skyper (talk) 16:15, 28 February 2021 (UTC)
  • Lösung Bus-Relationen: Die betreffenden Haltestellen wurden nochmal überarbeitet und Relationen repariert. Grundsätzlich werden die allermeisten Bushaltestellen-Plattformen nun als Nodes modelliert, wodurch sich das Problem mit den Relationen direkt löst. Wenn z.B. bei großen Bushaltestellen für mehrere Busse, ZOB, oder ähnliches eine Plattform als Linie dennoch sinnvoll ist, werden alle bestehenden Relationen auf das Linienobjekt übertragen.--BEG (talk) 10:23, 17 March 2021 (UTC)
  • Lösung stop_area-Relationen: Stop-Positionen werden grundsätzlich nur noch in Ausnahmefällen ergänzt, aber nicht mehr aktiv modelliert. Ein Fall dafür wäre, wenn sich herausstellt, dass ein Haltestellensteig eine andere Position hat, als bereits in OSM gepflegt. Dann setzen wir die Plattform an die entsprechende Stelle und verschieben auch die Stop-Position, wenn diese bereits vorhanden ist. Dabei wird aber darauf geachtet alle Attribute und Relationen zu erhalten, somit sollte auch hier kein Fehler mehr entstehen.--BEG (talk) 10:23, 17 March 2021 (UTC)

Mapping/Tagging

  • highway=bus_stop wird von Nodes auf Ways übertragen (--ToniE (talk) 09:34, 24 February 2021 (UTC))
    • highway=bus_stop ist für Ways nicht definiert/erlaubt
    • highway=bus_stop sollte aber an Nodes bzw. dort wo vorhanden nicht gelöscht werden
      • Lösung: Bushaltestellen werden als Nodes modelliert/nicht mehr in Ways geändert --BEG (talk) 09:38, 17 March 2021 (UTC)
  • bus=yes + public_transport=platform an amenity=shelter + shelter_type=public_transport (--ToniE (talk) 09:34, 24 February 2021 (UTC))
    • Gleich neben diesem "shelter" existiert allerdings eine vollständige PT-Platform, der "shelter" wiederholt das tagging. Ein "shelter" ist ein eigenständiges Objekt". Dieses ist an mehreren Haltestellen zu beobachten.
      • Lösung: wurde geklärt und sollte nicht mehr vorkommen. Grundsätzlich werden shelter und bench an Punkt-Plattformen als Attribute vergeben. Als eigenständige Punktobjekte modelliert, wenn die Plattform als Linie/Fläche modelliert wird. Oder wenn das Wartehäuschen/die Bank nicht barrierefrei nutzbar sind, während die Plattform selbst es ist. Dann wird dem "shelter" das Attribut "wheelchair=no" mitgegeben.--BEG (talk) 09:38, 17 March 2021 (UTC)
  • public_transport=stop_position/platform (--ToniE (talk) 09:34, 24 February 2021 (UTC))
    • Werden diese neu angelegt, so sollten sie in vorhandene PT-Relationen entsprechend eingetragen werden.
  • public_transport=stop_position (--ToniE (talk) 09:34, 24 February 2021 (UTC))
    • Sind zwei Platforms an einer Straße nahezu an der selben Position (rechts/links) von der Straße, so soll es nur eine Stop-Positon auf der Straße geben. Siehe auch Anmerkung zu ref:IFOPT unten.
    • Lösung stop_position: wie schon beschrieben werden diese nicht weiter erfasst und nur in Ausnahmefällen lagekorrigiert.--BEG (talk) 10:31, 17 March 2021 (UTC)
  • barrier="kerb =0.100" geht so nicht --ToniE (talk) 09:29, 25 February 2021 (UTC)
    • stattdessen bitte eine der beiden folgenden Möglichkeiten nutzen (ich bevorzuge die 2. Variante):
      • barrier=kerb + height=0.100
Dann aber bitte separat als Linie erfassen und nicht barrier=* und highway=* an einem Objekt. --Skyper (talk) 16:15, 28 February 2021 (UTC)
    • oder
      • kerb=yes|no|raised|lowered|flush|rolled + kerb:height=0.100
+1, gleiches gilt m.M für width=* bei Punkten. Besser ist platform:width=* --Skyper (talk) 16:15, 28 February 2021 (UTC)
Zumindest beim Zugverkehr bietet sich wohl eher platform:height=* anstatt kerb:height=* an. --Skyper (talk) 14:38, 1 March 2021 (UTC)
      • Lösung kerb: Bordsteine werden grundsätzlich nur an einer Punkt-Plattform erfasst, wenn man diese "Stufe" auch tatsächlich überwinden muss, um zum Wartebereich zu kommen. Ist dies der Fall wird mit kerb=raised + kerb:height=* getagged. --BEG (talk) 10:31, 17 March 2021 (UTC)
  • Merkwürdige "virtuelle" Verbindungswege von einer Plattform als Punkt zur vorbeiführenden Straße ohne separate Fußwegerfassung. (--Skyper (talk) 16:15, 28 February 2021 (UTC))
    • Router sollten diesen Weg nicht benötigen. Wenn nötig kann diese Beziehung mit public_transport=platform und public_transport=stop_position und Hilfe von local_ref=* bzw. ref:IFOPT=* dargestellt werden.
      • Lösung Verbindungswege: die Verbindungswege zwischen einer Plattform und dem Fußwegenetz werden in Zukunft nur noch zu Gehwegen hin modelliert, wenn diese realweltlich auch vorhanden sind und die Gehwege als eigenständiges Linienobjekt erfasst sind.--BEG (talk) 10:31, 17 March 2021 (UTC)
  • Verwendetes Tagging-Schema (--Skyper (talk) 16:15, 28 February 2021 (UTC))
    • Ich fände eine detaillierte Beschreibung der verwendeten Tags mit Beispielen hilfreich bevor hier, im Aktionismus, ein wildes Durcheinander entsteht.

Warnungen von QS Tools

  • amenity=* (Node) ist Teil eines Weges (Way) (--ToniE (talk) 09:34, 24 February 2021 (UTC))
    • amenity=bench ist Teil eines Weges (einer Platform-Linie): steht die Bank wirklich mitten auf dem Weg oder nicht doch daneben?
      • an der Platform (Node,Way,Area) kann ein bench=yes getagged und auf das explizite Mapping der Bank verzichtet werden - gängige Praxis
    • amenity=shelter ist Teil eines Weges (einer Platform-Linie): steht das ÖPNV-Wartehäuschen wirklich mitten auf dem Weg oder nicht doch daneben?
      • an der Platform (Node,Way,Area) kann ein shelter=yes getagged und auf das explizite Mapping des Wartehäuschens verzichtet werden - gängige Praxis
      • Lösung bench/shelter: Beide Objekte werden als Attribut mitgegeben, wenn die Plattform als Node erfasst wird. Ist die Plattform als Linie/Fläche erfasst werden sie als eigenständige Objekte erfasst, aber nicht als Teil des Weges der Plattform-Linie erfasst.--BEG (talk) 10:20, 17 March 2021 (UTC)

Unterschiedliche Interpretation

  • ref:IFOPT=de:aaaa:bbbb:cccc:dddd (--ToniE (talk) 09:34, 24 February 2021 (UTC))
  • nach meinem Verständnis handelt es sich hier (bei voller Verwendung des Schemas) um eine Steignummer, d.h. die Nummer der Platform, des Wartebereichs. Das leite ich auch aus der Analyse von vielen GTFS-Daten her, bei denen die Position der Haltestelle (aus stops.txt) neben der Straße liegt.
Mmh, im Schienenverkehr liegen die Stops auf der Schiene. Die Plattformen haben je nach Mapping die gleiche id oder bei Plattformen für mehrere Stops ein Level kürzer. Beide, Stop und Plattform haben eine Id und mittlerweile auch Zugänge zu den Plattformen mit individuellen Ids. --Skyper (talk) 16:15, 28 February 2021 (UTC)
Grundsätzlich halte ich eine Dopplung von ref:IFOPT=* für unproblematisch wenn korrekt gesetzt, wobei beim Straßenverkehr wohl public_transport=platform das wichtiger Objekt ist. --Skyper (talk) 16:15, 28 February 2021 (UTC)
  • würde man es als Halteposition des Busses interpretieren, so wäre das u.U. bei OSM nicht immer OK, da man dann in jedem Fall zwei Stop-Positionen auf der Straße für eine normale Haltestelle benötigt. Siehe hierzu: "Mapping/Tagging - public_transport=stop_position"
  • public_transport=stop_position (--ToniE (talk) 09:34, 24 February 2021 (UTC))
  • public_transport=stop_position wird in der Kritik häufig als überflüssig betrachtet, auch weil dem kein physisches Objekt in der Realität entspricht. Die Begeisterung hierfür hält sich in Grenzen, manche Bus-Relationen haben keine Stop-Positionen. Sind allerdings Stop-Positionen vorhanden/gemapped, dann sollen sie in Relationen drin sein. Wer sie mapped sollte sie in Relationen an der richtigen Stelle eintragen.
Bei vollständiger id `de:aaaa:bbbb:cccc:dddd` sollte im Straßenverkehr ein Objekt abseits der Straße diese Id bekommen und die Mitgliedschaft entsprechenden Route-Relationen sowie der Stop-Area-Relation erhalten. Stop_position ohne highway=bus_stop sehe ich da nicht ganz so wichtig, auch wenn es begrüßenswert ist, wenn auch diese gleich richtig eingepflegt werden. --Skyper (talk) 16:15, 28 February 2021 (UTC)
  • Lösung ref:IFOPT: dieses Attribut wird zukünftig nur noch an die Plattformen vergeben. --BEG (talk) 10:15, 17 March 2021 (UTC)
  • Lösung public_transport=stop_position: Stop-Positionen auf der Straße werden zukünftig nicht mehr modelliert. Innerhalb des Projektes werden für Bushaltestellen künftig nur noch die Plattformen erfasst. Einzige Ausnahme ist, wenn die Position eines Steiges korrigiert wird, dann wird die Stop-Position passend dazu versetzt, aber in ihrem Tagging nicht verändert --BEG (talk) 10:15, 17 March 2021 (UTC)
Das bedeutet im Umkehrschluss dann aber auch, dass ein highway=bus_stop an die Plattform gehängt werden kann, bei fehlender Stop-Position. Dann würden die Haltestellen und Eure Arbeit auch visuell sichtbar. --Skyper (talk) 11:50, 17 March 2021 (UTC)
  • Die Verwendung des Tags highway=bus_stop ist ja etwas kritisch. Es ist richtig, dass ohne dieses Attribut das Rendering noch nicht greift und das Bushaltestellensymbol nicht auf der Standardkarte auftaucht. Allerdings ist eigentlich das Tagging mit public_transport ausreichend. Wir haben dieses Thema auch am letzten Münchener Stammtiscch besprochen und sind zu dem Schluss gekommen highway=bus_stop nicht zu taggen. Dabei hoffen wir mit einer großen Menge an Haltestellen nach neuem Schema ein Argument dafür zu liefern, das Rendering endlich anzupassen. --BEG (talk) 07:18, 24 March 2021 (UTC)
Diese Argument habe ich schon vor 10 Jahren angegeben, als ich alle Straßenbahnlinien einer Stadt auf PTv2 umgestellt hatte. Das einzige was entstanden ist, waren fürchterliche Tricks die Renderer zu Darstellung zu bewegen. Beim Zug besteht dieses Problem bis heute. Denke es wird darauf hinauslaufen, dass eine andere Person den Tag hinzufügt. --Skyper (talk) 12:09, 24 March 2021 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Bayerische_Eisenbahngesellschaft_(BEG)&oldid=2155965"