Frage an die erfahrenen Mapper wegen Bushaltestellen

Was ich ja an dieser ganzen Diskussion vor allem darüber, wo jetzt highway=bus_stop hinkommt, ein bisschen erschwerend für Argumente finde ist, dass wenn man highway=bus_stop mit den Pendanten des PTV2-Schemas vergleicht, highway=bus_stop quasi zwei verschiedene Bedeutungen annehmen kann. Wenn es auf der Straße ist, soll highway=bus_stop public_transport=stop_position entsprechen, wenn es aber neben der Straße ist, soll es public_transport=platform entsprechen. Ich finde, dass diese Zweideutigkeit einen Teil des ÖPNV-Mappings deutlich erschwert. Eben weil man sich nie einig werden kann, wo highway=bus_stop denn jetzt hin gehört, wenn es sich mit den PTV2-Tags vertragen soll. Und zwar ist der schwerwiegende Fehler (meiner Ansicht nach): Das, was in PTV2 public_transport=platform ist, ist in PTV1 (eigentlich) highway=platform und nicht highway=bus_stop!!! Daher bin ich ja der Meinung, dass highway=bus_stop immer public_transport=stop_position entsprechen sollte, da es schlecht ist, wenn ein und dieselbe Key-Value-Kombination je nach seiner Lage der einen oder der anderen neuen Key-Value-Kombination entspricht. Natürlich kann es praktisch sein, highway=bus_stop neben die Straße zu packen, aber nur wegen dem Rendering. highway=platform sollte immer für public_transport=platform (evtl. plus bus=yes) stehen, auch dann, wenn highway=platform ein Punkt ist (bei wenig Haltestelleninfrastruktur zum Beispiel). public_transport=platform darf doch auch ein Node sein, warum darf es dann das PTV1-Pendant highway=platform nicht?
Das ist das, was ich schon immer nicht verstanden habe. Und aus solchen Fehlern resultieren dann frustrierte Leute, die es lassen, sich mit dem ganzen public Transport-Thema auseinanderzusetzen, weil sie es leid sind. Ganz ehrlich gesagt wundert mich das nicht.

Man hätte einfach highway=platform auch als Punkt zulassen sollen, und dann hätte es an jeder Haltestelle vorkommen sollen bzw. dürfen, so, wie jetzt public_transport=platform an (fast) jeder Haltestelle vorkommt. Darauf hätten sich die Renderer auch einstellen können, als Linie oder Fläche wird es halt grau gerendert mit Bus-Symbol in der Mitte, als Punkt dann eben nur als Bus-Symbol (so, wie highway=bus_stop) jetzt. Das sähe ich als eine mögliche Rendering-Lösung an aber was soll’s. (Wir wissen alle dass OSM-Carto und andere auch längst das Interesse an jeglicher Überarbeitung des Public Transport Renderings verloren zu haben scheinen, aus oben genannten Gründen vielleicht?)
Sorry es ist nichts böse gemeint, ich habe selber durch diese Thematik Ewigkeiten lang nicht durchgeblickt.

@Lukas458

Wo kommt highway=bus_stop hin?

So ist highway=bus_stop definiert:

Einsteigen, verlassen eventuell warten für den Bus ist meist neben der Fahrbahn… auf der Seite welche die Fahrrichtung hat in der man möchte bzw. kommt.

Auf der Straße einen einzigen Node zu erfassen ist eine vereinfachte Varante eine ganze Bushaltestelle zu Erfassung… deswegen aber nicht umbedingt eine stop_position. Viel mehr ist es eine Platform die hier auf die Straße gemappt wurde. Der nächste Schritt wäre eine genauere Aufnahme vor Ort :wink: → highway=bus_stop ist public_transport=platform + bus=yes :wink:

PTV2 sollte PTV1 erweitern und nicht überhaufen schmeissen bzw. kaputt machen… oder irgendwelche Bedeutungen hinzudichten… die es nicht gab. Linien und Flächen werden gemappt die es nicht gibt… Linien werden in 1000Teile aufgeteilt… also manchmal ist man da schon sehr nahe an der “Entf”-Taste :roll_eyes:

Ich kann die Renderer schon verstehen das man dieses PTV2 Müll/Durcheinander nicht Rendern kann… Dabei machen viele noch so vieles Kaputt. Diese “PTV2-Mapper” sollte auch mal vor Ort fahren…

Nein. PTv1 hat gar keine Beziehung zu highway=platform. “highway=platform” war zu “PTv1-Zeiten” nicht im Gebrauch und wurde später entsprechend zu railway=platform erfunden und sollte vermutlich das Bauwerk beschreiben.

Die einzigen Bushaltestellen in PTv1 waren Nodes mit “highway=bus_stop” und zwar nur einer pro Halt des Fahrzeugs. Man konnte den Node auf die Kreuzung setzen um alle Haltestellen an der Kreuzung zu repräsentieren. Man konnte ihn auf die Fahrbahn setzen, um Haltestellen für beide Richtungen zu repräsentieren und man konnte ihn neben die Fahrbahn (oder auf die Fahrbahn mit “direction=xx”) setzen um eine Richtung zu repräsentieren.

Das liegt nicht an PTv2! Eine “PTv1-Haltestelle” mit “highway=bus_stop, name=Rathaus” wird - wenn man PTv2 richtig macht - überhaupt nicht bearbeitet weil sie für PTv2 schon völlig in Ordnung ist. Wo es einen Sinn ergibt darf man mit den neuen PTv2-Tags noch etwas hinzufügen … nur das ist der Sinn von public_transport=xxx. Deshalb ist der von mir oben benutzte Begriff “PTv1-Haltestelle” auch völliger Mumpitz, denn jede “PTv1-Haltestelle” ist eine “PTv2-Haltestelle”. (Bei den Routen ist es dagegen völlig anders: Es gibt PTv1-Routen und PTv2-Routen und die sind sehr verschieden)

Hallo Leute!

Vielen Dank erst einmal für eure zahlreichen und ausführlichen Antworten.

Die Regel das man nicht für den Renderer mappen sollte halte ich persönlich (in diesem Fall) für blöd.
Denn meine Motivation ist (in diesem Fall) natürlich das die Haltestellen auf Karten auch angezeigt werden, damit sie auch von Personen gefunden werden die einfach in unbekannter Gegend zur nächsten Bushaltestelle gelangen wollen.
Für mich persönlich steht da der Nutzen für die Allgemeinheit mehr im Vordergrund.
Denn was würde es nützen, wenn die Daten refasst worden sind, aber niemandem auf einer Kartendarstellung zur Verfügung stehen? Also quasi für den Endverbraucher nicht nutzbar sind? Für mich wäre das nur eine andere Form von Datenmüll.

Wie ich ja schrieb, richtete sich meine Frage an die “erfahrenen Mapper”. Soll heißen, dass ich mir das nötigste Wissen angeeignet habe, um die Bushaltestellen und Strecken halbwegs korrekt eintragen zu können.
Wenn ich in diesem Zusammenhang highway=bus_stop als veraltete Schreibweise bezeichnet habe, ist das sicherlich eher meinem mangelndem Wissen als einer falschen Informationsquelle geschuldet. - Von daher, “alles Gut” - wie man hier zu sagen pflegt.

Um Konflikte zu vermeinden wird mir wohl nichts anderes übrig bleiben, als highway=bus_stop als separaten Punkt abzuändern.

Gruß Frank

Das ist der richtige Ansatz ;), man kann auch über das Ziel hinausschießen. Was manchmal mehr Probleme macht als es nutzt.

Für den ÖPNV-Nutzer wäre nur wichtig wo er für die jeweilige Fahrrichtung hin oder raus kommt. Infrastruktur kann für verschiedene interessant sein z.B. der Unterstand ist auch für Fahrradfahrer interessant wenn es regnet :slight_smile: usw. Sollte aber auch nicht doppelt gemappt werden… z.B. Unterstand extra node/way und auf platform/bus_stop auch noch… hier hat man dann wieder Problem mit suchen wie OSMand :confused:

Entweder:
Du kannst ohne Probleme einen separaten Node mit highway=bus_stop neben die Fahrbahn setzen. Das ist dann die Platform im Sinne von PTv2. Es darf dann aber kein zusätzliches Objekt mit public_transport=platform geben. Denn dann hätte man zwei Platforms, beide müssten mit der Rolle “platform” in die Route und das bedeutet zwei Haltevorgänge des Busses und das wäre falsch.

Oder:
Du kannst ohne Probleme einen separaten Node mit highway=bus_stop in die Fahrbahn setzen. Das ist dann die Stop-Position im Sinne von PTv2. Es darf dann aber kein zusätzliches Objekt mit public_transport=stop_position geben. Denn dann hätte man zwei Stop-Positions, beide müssten mit der Rolle “stop” in die Route und das bedeutet zwei Haltevorgänge des Busses und das wäre falsch.

Moin,

In meinen Augen völlig falsch verstanden:
Es besteht absolut kein Grund, ein ‘Kann’-Objekt zu einem ‘Muss’-Objekt zu machen.
Die PTv2-Relation kann sich auf ihre notwendigen Objekte beschränken.

Das das gewünschte Prinzip der Objekt-Auswertung in solchen Konstellationen (pt=platform != node) nicht funktioniert, ist nicht die Schuld des highway=bus_stop nodes - sondern des in diesem Punkt nicht weit genug gedachten PTv2-Proposals!

Ich halte es also für grundverkehrt, deshalb ein vorhandenes funktionierendes System (highway=bus_stop) zu zerstören, indem man dieses Objekt dann zwangsweise löscht.
Wenn das PTv2-Proposal damit nicht klar kommt, dann muss das Proposal den node eben ignorieren (können).
Edit:
Prinzipiell ist dies bereits gegeben, wenn der bus_stop-node Teil der pt-platform ist.
Aber
wenn dies praktischer z. B. nur durch ein zusätzliches PTv2-Hilfstag am bus_stop-node gelingt, dann muss man sich eben mal dazu durchringen.

Grüße, Georg

Nein. Die Wiki-Seite zu highway=platform ist von 2009 und PTv2 erst von 2010/2011. Seit 2011 steht auf der englischen Wiki-Seite auch, dass highway=platform durch public_transport=platform ersetzt wurde.

Das sehe ich anders. Im Proposal sind die Tags public_transport=stop_position bzw. public_transport=platform als verbindlich bezeichnet. Das Proposal widerspricht sich allerdings selbst etwas durch eine allgemeine Aussage, dass die Tags des Proposals nicht verbindlich sondern nur empfohlen sind. Ich würde dies aber eher so deuten, dass die Anwendung von PTv2 nicht vorgeschrieben ist. Wenn man die Tags beliebig weglassen kann, sind sie ohnehin nutzlos.

Es ist ein Kann-Objekt beim Mappen der Haltestelle. Aber gemappte Objekte müssen in die Route.

Beides steht ausdrücklich in PTv2 drin:

PTv2 ist in dem Punkt durchdacht. Das Problem entsteht erst durch das doppelte Mappen von Platforms oder Stop-Positions.

Ich bin nie auch nur auf die Idee gekommen, das highway=bus_stop zu löschen und das steht auch nirgendwo in PTv2.

OK. Vielleicht wurde es schon vor der Einführung von PTv2 benutzt. In PTv1 hat es aber niemals eine Rolle gespielt, da sämtliche Linien einer PTv1-Route Fahrwege sind und sämtliche Nodes Haltstellen. Es gab und gibt keine Möglichkeit, linien- oder flächenförmige Platforms in eine PTv1-Route einzubauen. Die Unterscheidung von stop_position und platform existierte in PTv1 ganz einfach nicht.

Ja … und zwar im Abschnitt über public_transport stop_positions bzw. platforms. Natürlich ist das definierende Tag verbindlich für ein Objekt dieser Art. Das ist bei stop_area genauso. Die stop_area ist optional, aber das Tag public_transport=stop_area ist verbindlich für stop_areas, denn sonst wären es keine.

Das ist kein Widerspruch. Es ist das, was ich im zitierten Teil beschrieben habe: Alte Haltestellen (und PTv1-Routen) sind völlig in Ordnung.

Das kann man nicht. Mit highway=bus_stop kann man pro Halt des Fahrzeugs nur einen einzigen Node angeben. Ein zweiter wäre fehlerhaft. Wenn man also ein zweites Objekt hinzufügen will, dann braucht man dafür die in PTv2 definierten neuen Tags. Das darf dann auch linienförmig oder flächig sein.

Sehe ich genauso, wieso etwas erzwingen wollen wo nicht nötig. Man solte die Dinge so simple wie möglich halten.
Als Auswerter hat man sonst irgendwann nix mehr zum anzeigen.

Was mich stört ist das man highway=bus_stop weg von der Straßenseite auf die Straße getagt wird, wo es eigentlich nicht hingehört (siehe Wiki). Und warum? Ja, weil highway=bus_stop nur als Node definiert ist und dann bei einer public_transport=platform nix angezeigt bekommt wenn es als Weg/Fläche erfasst ist. Darum wird highway=bus_stop auf die stop_position getaggt und dann noch außenrum shelters gemalt… Wenn das nicht tagging für Renderer ist dann weiss ich auch nicht.

So wie hier:
http://www.openstreetmap.org/#map=19/48.17335/11.75531

Nur blöd wenn es keine Shelters gibt :frowning:

In dem Beispiel könnte man aber das highway=bus_stop in die platforms legen. Den Node auf der Straße könnte man dann entweder ohne highway=bus_stop behalten oder ihn besser ganz weglassen.

Diese Haltestelle hat aber beidseitig Wartehäuschen so wie eingezeichnet. Bin da erst vorbeigekommen.

Das macht alles nur noch komplizierter, denn wo erfassen wir dann die Eigenschaften der Bushaltestelle? Etwa dreifach an stop_position, platform und bus_stop?

Entweder hätte man dann die neuen Tags auf die zusätzlichen Objekte beschränken sollen, oder auch bei den anderen Objekten konsequent anwenden sollen. Wenn die Tags bei den anderen Objekten inkonsequent angewendet werden, erzielen sie keine Vereinheitlichung und stellen dort nur Datenmüll dar, der keiner Anwendung hilft.

Ja. PTv2 erlaubt es, die neuen Tags nur bei den zusätzlichen Objekten anzuwenden. Das musste so sein, denn es durfte ja keine Situation entstehen, bei der man die Haltestellen wegen der Routen hätte umstellen müssen und die Routen wegen der Haltestellen. Dann hätte man die ganze Welt in einem Changeset auf PTv2 umstellen müssen.

Andererseits wollte man auf die Dauer eine Gesamtumstellung haben und erlaubte auch Doppeltagging. Diese Gesamtumstellung wird aber nicht vollständig passieren, da highway=bus_stop für die Kartendarstellung praktisch nicht zu ersetzen ist. Da sowohl stop als auch platform einzeln optional sind und an keinem der beiden dransteht, ob es den anderen gibt, stehen die Kartenhersteller vor einem nur sehr schwer lösbaren Darstellungsproblem. Da außerdem noch zu einer Platform mehrere Stops gehören können und zu einem Stop mehrere Platforms, kann man ein einzelnes Symbol für eine Haltestelle aus public_transport-Tags allenfalls nach Analyse aller beteiligten Relationen ermitteln. Deshalb muss highway=bus_stop bleiben.

Diese Situation ist etwas unangenehm. Sie wird aber massiv dadurch verschlechtert, dass viele Mapper denken, sie müssten jetzt überall aus einem einfachen und völlig ausreichenden “highway=bus_stop, name=Kalles Rübenfeld” auf der Straße zwei stop_positions, zwei Platformlinien und eine stop_area_Relation machen ohne auch nur ein bischen reale Information hinzuzufügen.

Wir sollten jetzt nicht PTv1 und PTv2 verdrehen, um die Probleme zu lösen. Das ist leider das, was im Moment in vielen Wikis und in der Praxis passiert (und das ist der Grund, warum ich mit ÖPV-Mapping aufgehört habe). Wir sollten es statt dessen sinnvoll und genau so wie es da steht anwenden und gleichzeitig gemeinsam an einem sorgfältig durchdachten PTv3 mit praktisch brauchbaren Umstellungsregeln arbeiten.

https://xkcd.com/927/

:slight_smile:

Konkurrierende Standards sind kein Problem! Man wird dann sehen, was sich durchsetzt und benutzt wird. Wir können z.B. bei der Computerei Dateien mit ftp oder mit rsync oder mit sonstwas kopieren. Kein Problem!

Wenn aber die Erfinder von rsync einfach RFCs für ftp umgeschrieben hätten um sich den rsync-Ideen anzunähern … dann hätten wir ein Problem! Deshalb bin ich gegen die verbreiteten Bastelarbeiten an den Regeln für highway=bus_stop, an PTv1-Routen und an dem ganzen PTv2-Kram.

Muss mich korrigieren: highway=bus_stop wir auch bei Flächen angezeigt… nur nicht bei Wegen

Fläche:
http://www.openstreetmap.org/way/241589910#map=19/48.07168/11.88826

Weg:
http://www.openstreetmap.org/way/482999237#map=19/48.17200/11.80904

Was der Kartenstil OSM Carto rendert, hat dir egal zu sein.