Hallo Lukas,

entschuldige bitte. Ich habe einige deiner Tags wieder eingesetzt. 'operator' habe ich nicht wiederhergestellt, weil das aus der 'stop_area'-Relation ableitbar ist und dadurch redundant wäre. Auch 'bus=yes' ist für highway=bus_stop überflüssig, genauso wie pt=platform bei Vorhandensein eines Ways mit pt=platform (welcher vor meiner Änderung, meine ich, noch nicht vorhanden war). ref=7 ist einfach falsch, allein local_ref=7 wäre korrekt.
'description' hatte ich abgeändert, da der SEV schon seit geraumer Zeit grundsätzlich an der Stadthallte abfährt. Hier verkehrt also nur noch, wenn überhaupt, der Schwebebahn-Express.
Den Rest meiner Änderungen muss ich glaube ich nicht einzeln begründen.
Und ehrlich gesagt, der Sinn von 'pole' erschließt sich hierzulande für mich nicht. Er ist im Wiki auch explizit nicht dokumentiert, jedoch tatsächlich in Gebrauch. Aber in D ist doch jede Haltestelle ausgeschildert (impliziert nach meinem Verständnis immer pole=yes). Bringt also aus meiner Sicht keinen wirklichen Mehrwert, dieses Tag hier zu führen. Höchstens um zu erfahren, ob das Schild an einem Mast oder an einer Wartehalle angebracht ist (dann pole=no?)? Aber vielleicht magst du mir das ja mal genauer erklären, evtl. übersehe ich was... :)

Für die Namensanpassung hatte ich mich entschieden, da die beiden Haltepositionen auf der B7 betrieblich zum Busbahnhof, ergo zum Hbf gehören - zum einen spricht dafür die fortlaufende Nummerierung der Steige (1-5 für Busbf, 6+7 für Bundesallee), zum anderen dieselbe IFOPT-Nummer (..11376) und dadurch auch derselbe epon- bzw. EFA-Name. Mir ist klar, dass auf dem Schild der Zusatz "Döppersberg" steht, daher hatte ich den mal in alt_name gepackt. Die leichte Unterscheidung auf dem Schild hat allerdings auch mit der Minimierung von Missverständnissen für Ortsunkundige zu tun; es sollte dann zugleich doch eine kleine Distanz zu den Busbf-Haltestellen erzeugt werden, damit diese nicht für die Haupthaltestelle gehalten werden. Ja, nun mit demselben OSM-Namen wird z.B. auch auf der Transport Map die Zusammengehörigkeit visuell dargestellt. Und die räumliche Entfernung erkennt man in jedem Fall. Findest du den aktuellen Stand denn so nicht sinnvoll? Ich bin dahingehend offen für Änderungsvorschläge, mir ist das nicht so wichtig.
Eine ganz ähnliche Problematik gibt's im Übrigen auch nebenan in Remscheid (am H2O mit dem Steig D), aber das auszuführen, würde hier den Rahmen sprengen.

LG

Hallo Ruben,
erst einmal sorry für die späte Rückmeldung, ich war länger nicht mehr hier aktiv :)

Es geht hier nicht darum, dass mir "construction=* nicht gefällt". Dieses Tag war einfach objektiv unzutreffend. Warum? Da es an der Stelle einfach keinerlei Bauarbeiten gibt (und nie gab) - und so habe ich die Löschung ja auch begründet. Die Existenz des Kreisverkehrs in OSM verstößt so gegen das On-the-ground-Prinzip. Auch die "proposed"-Keys gelten ja nicht als unumstritten. Drittens sah es einfach total suboptimal aus, dass der Kreisverkehr auf der bestehenden Kreuzung platziert und auf den Karten rund 9 Monate lang so prominent sichtbar war. Diese Vermischung sorgte visuell einfach für Verwirrung. Es suggerierte einen Zustand, der so einfach nicht existieren kann (Kreuzung + Kreisverkehr gleichzeitig/übereinander).

Dieser Kreisverkehr wurde in der Form bereits in einem Bebauungsplan aus dem Jahr 2004 (!) festgelegt (Nr. 567), und er ist ja auch über 20 Jahre später noch immer nicht Realität. Klar, das Alter tut der Gültigkeit zwar keinen Abbruch, aber es ist und bleibt alles nun mal nur ein *Plan*. Nur weil der Kreisverkehr also in B-Plänen enthalten ist, bedeutet das nicht, dass er tatsächlich in absehbarer Zeit (oder überhaupt) realisiert wird. Daher war ich auf jeden Fall der Meinung, der hat nur dann seine Berechtigung in OSM, sobald er endgültig gebaut wird. Mit "gefallen" hatte das also gar nichts zu tun.

Aber hiermit ein Sorry, dass ich das ohne Rücksprache mit dir gelöscht habe, ich hätte dich vorher auch anschreiben können. Ich habe ihn für dich in #171155764 mal wieder eingezeichnet und mit proposed:highway=tertiary versehen, damit er zumindest in der Datenbank vorhanden ist. Solange er auf den gängigen Karten nicht gerendert wird, halte ich diesen Kompromiss für vertretbar. Sollten zu unseren Lebzeiten noch die Bauarbeiten beginnen, kann das Tagging natürlich gern angepasst werden :)

PS: Soweit ich das überblicken kann, hattest du damals selbst keine Quelle (also den B-Plan) angegeben, als du den Kreisverkehr eingezeichnet hast (#156868788). Das habe ich nun aber nachgeholt und mal den aktuellen (Nr. 668) angegeben.

Hallo RubenKelevra,
unter anderem bei dieser Änderung von dir ist wohl etwas schiefgelaufen. An zahlreichen Haltestellen in Remscheid und Umgebung sind die gültigen "highway=bus_stop"-Tags an den Nodes der platforms entfernt worden, sodass all diese Haltestellen u.a. in Carto und der Verkehrskarte nun überhaupt nicht mehr angezeigt werden. Bitte umgehend rückgängig machen.

Hey Lukas, danke für deinen Kommentar -- ich habe dir eine PN geschickt... :)

Hallo Lukas,
danke für deinen Hinweis!

Alles gut - ich weiß nicht mehr genau, warum ich die gesamte 'description' gelöscht hatte; eigentlich wollte ich damals nur den letzten Teil entfernen, weil für diesen Kurzläufer ab Grünental bis Lennep schon eine eigenständige Relation (9280721) existiert. Diese ist nötig wegen des anderen Steigs am Grünental, der mit dieser Relation hier nicht abgedeckt werden kann (Bstg 5 statt 2).

Du kannst also sehr gerne das mit der einen Fahrt am Tag zwischen Beyenburg und Lennep wieder ergänzen!

Die Linie 240 fährt die Haltestellen sowohl in Richtung Wermelskirchen als auch Richtung Lennep stets in der Abfolge […] – Bornefeld – Am Weidenbroich – Schwarzer Weg – […] ab. Dies ist auch auf den (Online-)Fahrplänen einzusehen.
Die westliche Position wird also von der 336 Ri. Hückeswagen und von sämtlichen Fahrten der 240 bedient; die östliche ausschließlich von der 336 Ri. Lennep (und dem AST Ri. Lennep/Wermelskirchen). Diese befindet sich direkt an der Einmündung Danziger Straße.

Da hast du natürlich vollkommen recht, ich habe *_on_demand von der "VRR-Tagging"-Seite im OSM-Wiki her (oder besser gesagt aus dem darauf verlinkten Modellierungsvorschlag von Mentz). Da das aber ohnehin nicht standardisiert ist bzw. ich sonst in der Praxis nirgends diese Rollen so gesehen habe, wollte ich sie auch schon durch die klassischen wieder ersetzen. Danke trotzdem für deinen Hinweis.