Das ÖPV-Mapping in OSM ist tot. Immer mehr Anwendungen würden jetzt unsere Daten benutzen … wenn sie irgendwie brauchbar wären. Also benutzen alle Anwendungen nicht-OSM-Routendaten und nehmen von OSM nur Fuß- und Radwege.
Wir hatten mal einen großen Fortschritt hin zu einem einigermaßen brauchbaren System – das war PTv2. Es hat sich aber nie durchgesetzt. Ich habe jahrelang intensiv nach PTv2 gemappt und dann das ÖPV-Mapping aufgegeben. Es gibt einfach keine ausreichende Akzeptanz in OSM für das einzige abgestimmte und beschlossene ÖPV-System.
Dir ist aber schon bekannt, das jeder die Unterteilung machen kann wie er will.
Für den HVV habe ich eine andere Einteilung, wie beim VRT. Also wenn du willst, kannst du es selbst anpassen. Sei du gewarnt, das es auch wieder rückgänig gemacht werden kann, da es die Übersichtlichkeit zerstören könnte. Oder aus anderen Gründen.
Also möchtest du gerne ein PTv3 vorschlagen, dann schreib das Proposal dazu und man kann dort weiter diskutieren.
Nein nicht ganz tot. Es kommt wirklich auf die Region an.
Ich selbst, seit ich in Hamburg wohne, daran, alle Linien im HVV auf PTv2 umzustellen. In der Stadt selbst geht das recht gut und schnell. Jedoch in den übrigen Landkreisen wird es schwierig. Oftmals fehlen die Grundlagen, sprich Haltestellen und Verkehrsführung. Zudem bin ich meiner Meinung nach, der einzige der sich in Hamburg intensiv am ÖPNV-Mapping beteiligt.
Daher, ist das PT-Mapping nicht tot, jedoch sehr verlangsamt.
Ein erster Schritt, um das PT-Mapping zu anzukurbeln, wäre mittels Wochenaufgabe das Mapping zu stärken und seitens der Editoren, Warnung auszusprechen, das PTv2 genutzt werden sollte, statt v1.
Das würde ich so nicht unterschreiben, nicht welt-weit.
Z.B. der ÖPNV in Managua, Nicaragua nutzt meinem Eindruck nach OSM. Die GTFS-Daten von dort haben route_id, trip_id und stop_id die aus OSM-Relation- und Node-IDs gebildet werden.
“Trufi” App (Google Playstore) aus Hamburg (?) arbeitet mit Mappern in Cochabamba, Bolivien; Duitima, Kolumbien; … zusammen um dort eine brauchbare App für ÖPNV zu erstellen.
Die Verbünde in DE haben eigene sehr gut entwickelte Anwendungen und sind von daher nicht auf OSM angewiesen - bis auf’s Fußgänger- und Radler-Routing und (siehe z.B. NW-AVV) zur Erstellung der Shapes (was aber nur mit den Straßen in OSM was zu tun hat).
Auch ich halte PTv2 für komplex und “einigermaßen brauchbar”. Aber die ÖPNV-Welt da draußen ist ja auch komplex und nicht durch ein simples Konzept abbildbar, oder?
Das würde PTV2 entsprechen und bzgl. des status-quo heißen, ‘light_rail’ durch etwas passenderes (existierendes) zu ersetzen
Das wäre eine größere Änderung am PTv2, nicht an den Ways, Platforms und Stops, aber am Tagging der Relationen.
Henne-Ei-Problem: bevor nicht alles umgestellt ist werden sich Anwendung (Datenkosumenten) um einen Mix kümmern müssen - das Problem verschärft sich wohl eher.
Das wäre das geringste Problem: die ‘tram’, ‘train’, ‘subway’, … Werte fließen derzeit nur bei der Overpass-API-Abfrage und den ‘@supported_route_types’ ein. Weitere “zusätzliche Tags” spielen derzeit keine Rolle, werden nicht geprüft.
Die Auswertung wird im Wesentlichen durch die CSV-Daten (im OSM-Wiki) gesteuert (2. Feld der CSV-Liste).
Änderungen am Code sind nur in geringem Maße für spezielle Checks notwendig (‘train’, … fährt auf ‘railway’, ‘bus’, … braucht ‘highway’).
S7;train;;Wolfratshausen;Kreuzstraße;DB Regio AG/S-Bahn München
U5;subway;;Laimer Platz;Neuperlach Süd;SWM/MVG
21;tram;;Westfriedhof;St.-Veit-Straße;SWM/MVG
210;bus;;Brunnthal, Zusestraße;Neuperlach Süd U S;Verkehrsbetrieb Ettenhuber GmbH;DE-BY-MVV;19-210-s20-1
Derzeit bei DE-Bahnverkehr: “train, light_rail, monorail” und da kommen in DE schon 329.7 MB XML-Daten zusammen. ‘tram’ und ‘subway’ habe ich bewust rausgelassen, da diese meistens einem einzelnen Verkehrsverbund zuzuordnen sind und somit in der entspr. Analyse auftauchen.
Ja es ist der hohe Aufwand bei wenig nutzen der das Ganze unattraktiv macht. Wenn man wieder mehr Leute für Ptv2 begeistern will dann muss man was ändern. Oft wird der große Aufwand aufgeführt… dann muss das mit weniger Aufwand auch gehen. Es ist so kompliziert… dann muss es auch einfacher gehen… Ptv2 ist halt wie Grashalm-mappen, viel Arbeit verbunden mit wenig nutzen
Das liegt aber nicht an PTv2. Das liegt an den Gerüchten, die darüber verbreitet werden.
Für eine Bushaltestelle auf der Landstraße, die in beiden Richtungen gleich ausgestattet ist, braucht man nur einen Node auf der Straße mit highway=bus_stop und name=xxx … mehr nicht. Dann hat man perfektes PTv2! Dann kommt aber ganz sicher jemand, der das “auf PTv2 umstellt” und daraus zwei stop_positions, zwei platforms und eine stop_area macht. Das ist zulässig aber sinnlos. Und dann macht noch jemand auf die Platformlinien einen highway=bus_stop-Node. Letzteres widerspricht PTv2 sogar. Und man hätte mit einem einzigen Node ohne public_transport=irgendwas schon perfektes PTv2 gehabt.
Im Bahnbereich gibt es das Gerücht, dass railway=platform ein public_transport=platform braucht, damit es als Personenbahnsteig gilt. PTv2 ist da ganz klar: railway=platform definiert eine Platform im Sinne von PTv2. Ein zusätzliches public_transport=platform ändert daran garnichts. Alle möglichen railway=station bekommen zusätzlich ein public_transport=station … obwohl die sieben Buchstaben “station” praktisch die einzige Gemeinsamkeit der beiden Tags sind.
Ist aber als “Schienenweg” gefährlich.
Meines Erachtens:
platform ist platform, die von Fahrgästen (Fußgänger) benötigt wird egal ob Straßenbahn, Bahn, Bus, Fernbus, … (Taxistand?)
wenn es zwei platform auf beiden Straßenseiten gibt, ist es schon richtiger, wenn ich zur richtigen geleitet werde (mir als Routingziel aussuchen kann) - dazu den Haltestellenfahrplan verlinken und ich weiß wie wohin ich weiterkomme.
Die Fahrwegrelation ist nicht notwendig, weil oft auch falsch, weil öfters geändert und teilweise 10 verschiedene in einer Linie vorhanden sind - schon allein durch Ferien- und Schulfahrten.
Wobei das einfügen der Haltestellen/Platform/stop_position auf der Straße ist oder nicht macht keinen großen unterschied von der Arbeit her. Aus der Praxis ziehe ich die detailliertere Version vor… für jede “Warteposition” ein bus_stop.
