public_transport=station Konflikt

Beim Tag “public_transport=station” ist es zur unangenehmen Situation gekommen, dass sich in verschiedenen Mappingbereichen zwei völlig verschiedene Bedeutungen ergeben haben.

In PTv2 wurde es eingeführt und bezeichnet eine dem Zugang zum ÖPNV gewidmete Fläche. Typisch ist hier z.B. die Haltestelle Jakobistraße in Düsseldorf für Straßenbahn und “U-Bahn”. Der U-Bahn-Teil ist ein eigenes unterirdisches Gebäude und dessen Fläche ist eine “public_transport=station” im Sinne von PTv2. http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726#Station

Bei einigen Wikis im Eisenbahnbereich hat man dagegen eine völlig andere Bedeutung, die am deutlichsten im deutschen Openrailmap-Tagging Wiki wird: public_transport=station ist ein Ergänzungstag für Nodes mit railway=station mit dem man angibt, dass an diesem Bahnhof Personenverkehr stattfindet. http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Tagging

Dies führt bei den Mappern zu Edit-Wars oder Frustration. Bei der Auswertung kann man das Tag eigentlich nur noch ignorieren, da keine Bedeutung mehr erkennbar ist.

Wat nu?

Schwierige Sache. Mir persönlich ist aus der Praxis auch nur nur die sehr gängige Variante bekannt, dass der railway=station bzw railway=halt bei Personenbahnhöfen zusätzlich mit transport=station getaggt wird. dies entspricht in der Regel einer Node, kann aber auch ein Bahnhofsgebäude umfassen. Ich sehe da auch keinen direkten Widerspruch zu https://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dstation.
Letzendlich sehe ich aber auch dass Problem, dass beim Taggigschema der Openrailwaymap railway und public_transport Tags gleichgesetzt werden, die aber nicht genau das selbe bezeichnen. Ich hatte in diesem zusammenhang schon mal auf die Doppelnutzung einer Realation als railway=facility und public_transport=stop_area mit teilweise inkompatiblen Definitionen hingewiesen, was allerdings keine erkennbare Reaktion hervorgerufen hat.

Zum Taggen von Eisenbahninfrastruktur gibt es eine zentrale, ausführliche und halbwegs verständliche und widerspruchsfreie Wikiseite, die von allen relevanten Nutzergruppen als maßgeblich anerkannt wird. Das ist bei public_transport leider völlig anders. Da gibt es viele widersprüchliche Angaben und viele verstreute Seiten. Vielleicht ist es mittlerweile anders, aber mein Wissenstand ist, das es keine einzige deutschsprachige Seite im OSM Wiki gibt, die das PTv2 Schema, wie es von Benutzer Weide Definiert wird, vollständig und verständlich wiedergibt. Wie will man da erwarten, dass es jemand korrekt umsetzt? Ich nehme an, dass man bei der Openrailwaymap wie so viele andere auch, einfach PTv2 falsch verstanden hat und dieses falsche Verständnis sowohl in die Wikiseite als auch in die Mappingpraxis eingeflossen ist. Das diese Fehler auf public_transport Seite trotz zig-tausendfacher Anwendung viele Jahre lang niemandem aufgefallen sind, spricht meiner Meinung nach auch eine klare Sprache. Offenbar ist es nicht gelungen, PTv2 einer relevanten Nutzerschicht verständlich zu machen oder nützlich erscheinen zu lassen was angesichts der von mir angesprochenen Defizite in der Vermittlung auch wenig verwunderlich erscheint.

Ich denke man hätte sich ganz am Anfang gemeinsam Gedanken über die sinnvolle Koexistenz der railway* und public_transport tags machen müssen. Ob man jetzt Jahrelang gelebte Praxis nachträglich korrigieren kann weiß ich nicht, aber es dürfte nicht leicht sein.

Vielleicht aufschlussreich zum Thema ÖPNV, PTv2 usw. von der diesjährigen FOSSGIS 2017

2017 - ÖPNV-Mapping in OpenStreetMap
https://www.youtube.com/watch?v=v5IE_l40MkI

Interessantes Viedeo, das ich noch gar nicht kannte. Ich frag mich allerdings, warum immer gerade das mappen der Linienverläufe in Frage gestellt wird, da gerade die Linienverläufe eines der wenigen PT-Features mit hohem Nutzen in der Praxis ist.

Äh … definiert hab ich da nichts. Nichts in PTv2 stammt von mir außer vielleicht der Bezeichnung “PTv2”, die im Original nicht vorkommt. Ich habe es nur gründlich durchgelesen.

Sorry, das war vielleicht missverständlich ausgedrückt. Ich wollte damit sagen, dass die einzige geschlossene, verständliche und halbwegs vollständige Darstellung von PTv2 in deutscher Sprache die ich kenne, deine Ausführungen dazu sind :slight_smile:

Ja, Linienverläufe haben einen gewissen Nutzen. Der einzige für mich nachvollziehbare Nutzen besteht aber nur darin, dass man eine Liniennetzkarte rendern kann (z.B. openptmap.org) und ganz allgemein weiß, welche Gegenden durch welche Linien erschlossen werden. Dazu reichen PTv1-Relationen aber völlig aus.

Der Mehraufwand, jede Linienvariante zu erfassen, steht in keinem Verhältnis zum zusätzlichen Nutzen. Es wird nämlich niemand alleine mit OSM seine Bus- und Bahnfahrten planen, alleine schon deshalb, weil es in OSM keine Fahrplaninformationen gibt. Das Hauptproblem ist jedoch der hohe Erfassungs- und Pflegeaufwand, was in meinem Vortrag hoffentlich rübergekommen ist.

Ich hatte eigentlich gehofft, mit meinem Vortrag noch einmal eine Diskussion über das ÖPNV-Mapping in Gang zu setzen, bei der es zu irgendwelchen Ergebnissen kommt. Feedback habe ich bisher jedoch nicht wirklich bekommen und auch der Workshop am OSM-Samstag war nicht wirklich zufriedenstellend und hat keinerlei Ergebnisse hervorgebracht. Manche Teilnehmer haben mein Anliegen scheinbar nicht wirklich verstanden, sondern stattdessen eine noch detailliertere Erfassung vorgeschlagen (z.B. die Erfassung von Taktungen). Ich sehe deshalb nicht, dass es in absehbarer Zeit noch zu irgendeinem Konsens im ÖPNV-Mapping kommen wird. Deshalb beschränke ich mich nur noch auf die Haltestelleninfrastruktur.

Gruß
Alex

Das ist sicher am sinnvollsten.

Ich verwende dann den QR-Code zur Haltestelle oder die Website des Verkehrsunternehmen:
http://www.openstreetmap.org/way/476960480#map=18/51.01826/13.63924&layers=H

Und diese aktuell halten (share_taxi=yes ist auch seit April weggefallen - habe ich gerade bemerkt.)

OK, noch zur eigentlichen Frage in diesem Thread:

Hmm, auf den ersten Blick macht das Tagging wenig Sinn, denn nicht-Personenbahnhöfe werden ohnehin nicht als railway=station oder railway=halt getaggt.

Jedenfalls wäre es konsequent, dass wir aus dem OpenRailwayMap-Schema das public_transport=station entfernen, da sich die OpenRailwayMap ja eigentlich auf die Infrastruktur beschränkt. Die Abgrenzung wäre also railway=* für die Infrastruktur und public_transport=* für den Verkehr. Aus diesem Blickwinkel macht das Doppeltagging dann doch wieder Sinn, indem das railway=station den Bahnhof als Infrastruktur kennzeichnet und das public_transport=station den Bahnhof als Verkehrsstation.

Ob das public_transport=station nun am gleichen Node oder einer separaten Fläche hängt, ist mir persönlich eigentlich egal, solange das railway=station ein Node bleibt. Andererseits erzeugt man durch eine Erfassung in zwei Objekten gewisse Redundanzen.

Auf jeden Fall aber sollten public_transport=station und railway=station nicht gemeinsam an einer Fläche getaggt sein, da die Ausdehnung eines Bahnhofs aus ÖPNV-Sicht eine völlig andere ist als aus Sicht der Bahninfrastruktur.

Dass public_transport=station nur für Flächen verwendet werden soll, habe ich das erste Mal auch erst von Weide gehört… Bei PTv2 gibt es eben immer wieder Überraschungen :wink:

Das Problem habe ich ja schon oben beschrieben: Die verkehrliche und die infrastrukturelle Sicht unterscheiden sich teilweise, deshalb sollte das irgendwo getrennt voneinander erfasst werden, was dann aber wieder zu Redundanzen führt. Deshalb haben sich damals solche Hilfskonstrukte entwickelt, die aber wie man nun sieht nicht immer zu einer sauberen Trennung führen.

Um das ganze noch einmal strukturiert anzugehen: Wo genau gibt es derzeit Überschneidungen zwischen railway und public_transport? Beim Durchsehen des Taggingschemas habe ich folgende Punkte identifiziert:

  • railway=station vs. public_transport=station
  • railway=facility vs. public_transport=stop_area
  • railway=platform vs. public_transport=platform
  • railway=stop vs. public_transport=stop_position

Bei den Bahnsteigen sehe ich keine Probleme, da es dort keine unterschiedlichen Auffassungen von der Ausdehnung gibt. Das doppelte Tagging ist hier lediglich zur Abwärtskompatibilität gedacht, bzw. um die Daten einfacher auswerten zu können (Filtern nach railway=* ist einfacher als public_transport=platform + train=yes/subway=yes/… abzufragen).

Bei stop/stop_position ist die Situation identisch. Dort ist es so, dass railway=stop weiter gefasst ist als public_transport=stop_position. railway=stop ist praktisch das public_transport=stop_position für Stellen ohne ÖPNV, was vor allem für das Routing oder die Erzeugung von Streckengraphen wie in der Wikipedia von Bedeutung ist.

Bei station und facility/stop_area sehe auch ich die hier schon angesprochenen Probleme. Zu den Bahnhöfen hatte ich oben ja schon etwas geschrieben. Was die facilities betrifft, stellen wohl vor allem die Rollen ein Problem dar. Wobei sich die Frage stellt, ob man railway=facility nicht wieder ganz aus dem Schema wirft. Ich weiß gerade nicht genau, wie oft das erfasst wurde, aber ich selbst habe das nur am Anfang mal ein paar Mal eingetragen. Mittlerweile trage ich das aber gar nicht mehr ein, da es bislang auch von keiner Anwendung ausgewertet wird.

Gruß
Alex

Warum einen highway/railway als *=platform - doppelt als public_transport=platform - eintragen?

Ich sehe das Problem:

Ein Fußweg kann eine public_transport=platform sein.
Auch ein Bahnsteig ist normalerweise ein “Fußweg” und kann somit auch zum Routing verwendet werden.

Dieser Fußweg mit name Gleis 1 oder Gleis 2 kann dann Bestandteil eines Bahnsteiges sein und auch in einer Relation (Route/Fläche) genutzt werden.

Ist auf alle Fälle “richtiger” als die “separaten highway/railway” mit den Fußwegen “zu verbinden”.

Man kann auch Probleme suchen, wo keine sind.

Für railway gilt das railway-Schema, für public_transport gilt das public_transport-Schema.

Der Schnittpunkt station wird bei railway an den Bahnhofszentralpunkt gesetz,
das public_transport=station gehört an die Fläche oder falls diese nicht angelegt ist, kann es an den Bahnhofszentralpunkt gesetzt werden.

Gruß Axel

Ja, aber nicht nur eine Karte mit allen Linien. Auch wenn ich sehen möchte wo eine einzelne Linie lang fährt ist das sehr nützlich. Das bietet sonst auch fast keiner. Wir auch auf Wikipedia bei Artikeln zu einzelnen Linien genutzt. Es stimmt, dass dafür auch PTv1-Relationen reichen. Bei der Infrastruktur würde ich aber schon gerne die Neuerungen von PTv2 behalten. Nur PTv2 einzustampfen halte ich daher für keine Lösung. Ich glaube auch wenn wir jetzt sagen, nachdem vieles mit PTv2 gemappt ist, wir schmeißen das wieder weg und gehen wieder zurück, würden uns niemand mehr ernst nehmen und das noch die letzten engagierten PT Mapper vergraulen. Ich denke wenn man mittelfristig von PTv2 weg will, braucht man ein PTv3, wie auch immer das sein soll. Bis dahin verspreche ich mir durchaus Verbesserung durch besseren Tools. Ich finde z.B. der vergleichsweise neue “PT Assistant” ist schon eine riesige Erleichterung beim reparieren der ständig kaputt gehenden Relationen.

Vielleicht bringt die laufende Open-Data Welle bei den Verkehrsunternehmen in den nächsten Jahren neue Erkenntnisse, welche Daten in welcher Form für welche Anwendungen nützlich sind und damit frischen Wind in die Diskussion. Solange hingegen noch völlige Uneinigkeit herrscht, wohin die Reise gehen soll und warum, wird man wahrscheinlich keine Einigkeit, sondern nur noch mehr Frustration erzeugen, wenn man wieder eine neue Sau durchs Dorf treibt.

Wenn ich einige Wikis lese, dann verstehe ich das. Wenn ich das PTv2-Original lese, dann nicht: Man klickt da auf “Station” und es beginnt mit “A Station is an area…”

PTv2 braucht kein Doppeltagging, denn in PTv2 gelten die alten Tags alle weiter und man muss die neuen nicht verwenden. Nur bei den Bussen gab es da ein Problem das zu den neuen Tags geführt hat: Es darf pro Anhalten des Busses nur ein highway=bus_stop geben und das darf nur an einen Node. Wollte also jemand beides mappen oder eine Linie oder Fläche benutzen, dann musste es dafür ein neues Tag geben. Das ist public_transport=platform oder stop_position. (highway=platform gab es damals noch nicht. Es wäre damals auch sinnlos gewesen, denn PTv1 konnte es nicht verwenden. Da galt ganz einfach und brutal Node=Haltestelle und Linie=Fahrweg und Rollen benutzen wir als freie Zusatztags.)

Nach PTv2 ist “railway=platform” also ein “muss” und “public_transport=platform” kann man dranschreiben, wenn es einem Freude macht.

Im PTv2-Original findet man übrigens “xxx=yes” ausschließlich bei stops. Für platforms ist es nicht vorgesehen.

Nein. Es heißt nicht “falls sie nicht gemappt ist” sondern “falls diese unbekannt ist”. Das habe ich in Mitteleuropa noch nicht gesehen.

Es ist ohnehin meist nicht sehr sinnvoll, “public_transport=station” bei normalen Bahnhöfen zu verwenden. Bahnhöfe sind fast immer gewidmete Gelände … da kann auch ein Bot eine konvexe Hülle um Bahnsteige und das Gebäude ziehen. Inhaltlich sinnvoll ist sowas da, wo ein gemeinsames Gelände für mehrere stop_areas existiert oder wo eine stop_area aus einem gewidmeten Gelände (z.B. U-Bahn-Bahnhof) und einigen in den Straßenverkehr integrierten Teilen (für Tram und Bus) besteht.

Die Probleme sind leider da … aber sie verschwinden bei vernünftigem Mapping fast überall.

Die meisten dieser Probleme kommen aus PTv2-Irrtümern:

  • Man muss immer einen stop haben
  • Man muss immer eine platform haben
  • Platforms müssen linien- oder flächenförmig sein
  • An eine Busplatform gehört highway=platform
    Alles das ist nicht PTv2.

Die simple Bushaltestelle mit zwei einander gegenüberliegenden Haltestellen ist einfach und komplett als ein Node auf der Straße mit highway=bus_stop und name=Karlshof erledigt. Das kommt dann in die PTv2-Routen mit der Rolle “stop”. (Wenn man gern hätte, das JOSM die Rolle automatisch einträgt, dann braucht man auch noch public_transport=stop_position)

Liegen die beiden Haltestellen deutlich versetzt, dann legt man zwei genauso getaggte Nodes neben die Straße und sie kommen mit der Rolle “platform” in die PTv2-Routen. (Wenn man gern hätte, das JOSM die Rolle automatisch einträgt, dann braucht man auch noch public_transport=platform. (Ganz pingelig betrachtet ist das nach PTv2 falsch … aber der Fehler hat keine schädlichen Auswirkungen))

In solche Nodes kann man problemlos auch wichtige Zusatzinformationen wie “tactile_paving”, “bench” und “shelter” eintragen, sofern diese Sachen nicht bereits anderswo gemappt sind. Natürlich steckt in einem Node nicht die Länge der Haltestelle … aber bei Bussen ist das anders als bei Bahnen auch für Gehbehinderte ziemlich egal.

Schade das es zu diesem Thema keine Diskussion in Gang gesetzt hat :confused: . Vor allem der Punkt alle Linienvarianten einzeln zu erfassen sehe ich nicht ein… ich mache zur Zeit PTv2 lite :wink: … eine Relation für die eine Richtung eine andere für die Gegenrichtung und mehr nicht…

mfg Miche

Meine Kritik an PTv2 bezieht sich auch überwiegend auf die Linienvarianten. Das Haltestellentagging sehe ich nicht so als Problem an. Zwar finde ich, dass es auch dort Vereinfachungen geben könnte (stop_areas bei 90% aller Bushaltestellen überflüssig, stop_positions bei 90% der Bushaltestellen automatisiert ermittelbar), aber das verursacht meiner Meinung alles nicht einen so großen Aufwand wie die ganzen Linienvarianten.

Mit besseren Tools wie z.B. Routing und Qualitätssicherung könnte man schon den Aufwand zur Erfassung und Pflege reduzieren, was etwa das Zusammenklicken des Routenwegs oder die Reparatur von kaputten Relationen betrifft. Allerdings hilft das nicht wirklich bei den Linienvarianten weiter, denn da besteht der Aufwand darin, dass man diese Daten nur sinnvoll erfassen kann, indem man schlicht Fahrpläne abschreibt.

Mit offenen Fahrplandaten wäre es natürlich einfacher, die Daten bei uns aktuell zu halten, indem man automatisierte Vergleiche der Datensätze machen könnte, um veraltete Daten zu erkennen. Das wäre in einer Art uns Weise wie die Straßenlistenauswertungen vorstellbar. Dann wäre die Erfassung einzelner Linienvarianten auch eher umsetzbar als nun. So lange aber keine Fahrplandaten zur Verfügung stehen, sehe ich den Aufwand für OSM als zu hoch an.

Hä? Wozu hat man denn dann public_transport=platform eingeführt, wenn das dann doch nicht nötig ist? Ich hatte PTv2 immer so verstanden, dass die neuen Tags diese älteren Tags ersetzen sollen.

OK, das ist mir jetzt auch neu. Ich habe die Verkehrsmittel bisher immer bei stops und platforms getaggt. Warum die Verkehrsmittel nur bei den stops aber nicht bei den platforms genutzt werden sollen, erschließt sich mir nicht wirklich. Ich finde das eher auch unlogisch und fände es anders herum sinnvoller. Ohne die alten Tags wie highway=bus_stop oder railway=platform wäre dann überhaupt nicht auswertbar, ob ein Node mit public_transport=platform nun eine Bushaltestelle oder ein Bahnsteig ist.

Laut https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstation kann public_transport=station auch bei Nodes verwendet werden, was ich grundsätzlich nicht falsch finde. Allerdings ist es einfach eine redundante Informationen, einen Node mit railway=station auch nochmal als public_transport=station zu taggen, da gibt es keinen Mehrwert an Information.

Allerdings sehe ich auch eine Fläche mit public_transport=station als überflüssig an, weil es zum einen auch als konvexe Hülle aus den Mitgliedern der stop_area erzeugt werden kann.

Wie genau gehst du denn da vor? Gerade in ländlichen Gegenden gibt es ja bei vielen Linien gar keine “Hauptroute”, sondern fast jede Fahrt nimmt einen etwas anderen Weg. Erfasst du in diesen Fällen nur den Verlauf einer einzigen Fahrt, die du für wichtig hältst? Oder packst du auch noch die Fahrwege der Alternativrouten mit in die Relation (was ja dann PTv1 wäre, da bei PTv2 die Wege in der Relationen einen lückenlosen Verlauf bilden müssen).

Gruß
Alex

Ganz einfach… ich nehme den Fahrplan der Aushängt und füge eine nach der anderen wie sie aufgelistet sind auf dem Fahrplan zur Relation hinzu… gleichzeitig füge ich noch die Wege hinzu die von der einen zu anderen gehen… (Haltestellen für eventueller Gegenrichtung füge ich gleich in umgekehrter Reihenfolge hinzu… für spätere Gegenrichtungs-Relation)

Danach wird hochgeladen… dann schau ich ob ich im Graph ein Loch habe z.B. :
http://ra.osmsurround.org/analyzeRelation?relationId=3084863

Dann schau ich die Relation nochmal an ob ich noch was hinzufügen muss an Varianten (Meist Abkürzungen)
https://www.openstreetmap.org/relation/3084863

Dann nochmal schauen ob Löcher drin sind :slight_smile: Dann wenn es passt, kopiere ich die Relation und ändere diese für die Gegenrichtung ab… (Aus der ersten Relation entferne ich die Haltestelle für den Rückweg). Master-Relation mach ich auch :wink:

Ist für mich einfacher weil: An der Haltestelle zwei nicht unbedingt gleiche Fahrpläne aushängen. In meinem Beispiel gibt es in Freising Einbahnstraßen Regelungen die einen schon ein bisschen verwirren. Wenn man aus beiden Richtungen eine Relation machen möchte. So nehme ich erst den einen Fahrplan in die Hand und dann den anderen.

Durch das ich die Haltestellen am Anfang eine nach der anderen aufliste kann ich auch besser vergleichen und sehen was fehlt, zu viel ist usw…

Sollte ich was vergessen… naja bin ja auch nur ein Mensch :roll_eyes:

Die einzelnen Linien einzutragen ist m.E. zu aufwendig - vor allem die Aktualisierung dazu.

Bei uns verkehren 3-4 Linien parallel; fast jede Fahrt einer Linie hat einen anderen Verlauf (bis zu 6 verschiedene). Die Rückfahrten verlaufen dann auch wieder auf verschiedenen Wegen - mal über das Dorf oder den Ortsteil - dann wieder übers nächste. Auch die Ziele sind je nach Fahrt unterschiedlich.

Da finde ich das Haltestellen mappen mit den Verlinkungen zu den Fahrten wesentlich effektiver.