Frage an die erfahrenen Mapper wegen Bushaltestellen

Moin,

Solange man nur highway=bus_stop betrachtet, sind die Daten eindeutig. (Klassische/historische Auswerter)
Solange man nur pt=* betrachtet, sind die Daten eindeutig. (Moderne Auswerter)

Ein Gemisch funktioniert, solange man highway=bus_stop mit einem punktförmigen pt-Objekt gleichsetzt, z. B. dem Haltestellenmast. (Ein identisches OSM-Objekt mit beidem Tagging)

Die Probleme entstehen nur, weil man es partout mit einem linien- oder gar flächigem OSM-Objekt (pt=platform) vermischen will …

Man könnte durchaus - wenn man denn nur wollte …

Grüße, Georg

Ein heiß umkämpftes Thema :wink:

highway=bus_stop
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop

Ist als Punkt definiert:

Für diese Elemente

  • kann Punkten zugeordnet werden
  • sollte nicht über Linien verwendet werden
  • sollte nicht über Flächen verwendet werden
  • sollte nicht über Relationen verwendet werden

Aber! Wegen der Kompatibilität sollte highway=bus_stop weiterhin getaggt werden. Was auch notwendig ist… wie du schon festgestellt hast.

Meine Meinung:

public_transport=* ist hoch motiviert gestartet vor vielen Jahren und dann zum stillstand gekommen. Es gibt fast keinen nennenswerten Vorteil gegenüber PTV1. Vor allem weil es keine Fahrplandaten gibt… kann man mit dem ganzen recht wenig anfangen.

Ein viel größeres Problem ist meines erachtens… wenn es überhaupt keine Relation gibt… egal ob PTV1 oder PTV2 bzw. wenn die Haltestellen überhaupt nicht erfasst sind.

MfG Miche

Ich bin der Meinung, dass eine Bushaltestelle so bedeutend ist, dass sie auch auf der “Standardkarte” von OSM angezeigt werden sollte. Dies sollten unsere Experten zusammen mit dem Renderer sicherstellen und dann eindeutige Hinweise geben.
Ein Problem ergibt sich auch dann, wenn ein shelter als Fläche und nicht zusammen mit der platform als node eingezeichnet wird. Dies führt dann dazu, dass z.B. in Bietigheim-Bissingen die Haltestelle Auwiesenbrücke (nördlich der L 1125) als shelter dargestellt wird, in Löchgau die Haltestellen Wette gleich 2 Symbole zeigen, nämlich den shelter und das Buszeichen. Die Unterschiede beim Taggen sind m.E. nur die Anzahl der Angaben beim shelter. Wird die platform nicht innerhalb des als Fläche eingezeichneten shelter gesetzt, sondern außerhalb, erscheint der Name der Bushaltestelle überhaupt nicht.

Gruß ghostrider44

Zu mindestens wird bei OSMI PTv2 behandelt…

http://tools.geofabrik.de/osmi/?view=pubtrans_stops&lon=13.32812&lat=52.44362&zoom=11&overlays=stops_,stops_positions,stops_classic,stops_positions_not_on_ways,platforms_,platforms_nodes,platforms_ways
http://tools.geofabrik.de/osmi/?view=pubtrans_routes&lon=13.44691&lat=52.48921&zoom=11&overlays=ptv2_routes_,ptv2_routes_valid,ptv2_routes_invalid,ptv2_error_,ptv2_error_ways,ptv2_error_nodes

Sven

Hallo Frank,

Wo hast du denn aufgeschnappt, dass highway=bus_stop veraltet ist? (Das täte mich schon sehr interessieren, damit man das an der Quelle der Fehlinformation korrigieren kann) Das Proposal “Public Transport” (aka PTv2) hat das Tag nicht ersetzt, es hat nur Alternativen eingeführt, mit denen angegeben werden kann, ob es sich bei dem gemappten Node um eine Halteposition oder ein neben der Straße liegenden Punkt handelt.

highway=bus_stop gehört zwar laut manchen Wikiseiten (bis vor ein paar Tagen stand es nur auf highway=bus_stop, bis es dann der umstrittene Benutzer Geozeisig auch auf DE:Public_transport ergänzt hat) an einen Node der Plattform, falls diese als Way gemappt ist, aber das ist in meinen Augen ein noch schwerwiegenderer Verstoß gegen die One-Feature-one-Object-Regel als schon die Verwendung von Plattform und Stop Position für eine einzige Haltestelle.

Es sei darauf hingewiesen, dass die Darstellung in Karten einem Mapper egal zu sein hat. Ob die “Standardkarte” etwas darstellt oder nicht, hat einem Mapper völlig egal zu sein. Dass dort gewisse Dinge lange Zeit nicht gerendert werden konnten, ist technischen Beschränkungen geschuldet, die andere Kartenstile und Tileserverbetreiber schon längst behoben haben.

Viele Grüße

Michael

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.