Hallo johndoe,
warum gehst du immer davon aus, dass man dir etwas Böses will? In dem von dir erwähnten CS wurde immerhin eine Quelle genannt, nur das wird auch von dir erwartet. Auch wenn die Quelle leider nicht im aktuellen Zustand zulässig ist, da die vom VBB geforderte Nennung in der Liste der Beitragenden fehlt. Erst wenn diese beiden Bedingungen (oder eine plausible survey Quelle) erfüllt sind, können diese Daten auch durch OSM genutzt werden.

Hallo johndoe,
wie du auch selbst feststellst ist es schwierig in einigen Fragen zu einer Einigung zu kommen. Wenn du dann auch noch nicht einmal selbst bereit bist dich dieser Diskussion zu stellen unterlasse es doch bitte die Arbeit vieler anderer Mapper zu zerstören indem du dein, wie von mir erläutert fehlerhaftes, tagging flächendeckend verbreitest.
Danke und schöne Grüße

Hallo johndoe,
du hast hier wie auch in vielen weiteren changesets in Berlin und mittlerweile ja auch Brandenburg flächendeckend bei diversen Bushaltestellen den tag highway=bus_stop geändert. Dies halte ich so z.T. aus folgenden Gründen für falsch:
Wenn die Bushaltestelle nach PTv2 aus einem node public_transport=stop_position und einem way public_transport=platform besteht, ist ein zusätzlicher unabhängiger node highway=bus_stop, auch wenn er Bestandteil des ways der Plattform ist, nach osm.wiki/DE:Ein_Objekt,_ein_OSM-Element falsch, da er eine weitere Bushaltestelle darstellt. Software welche sowohl PTv2 als auch Ptv1 unterstützen, können den Zusammenhang dass es sich nur um eine Haltestelle handelt nur erkennen, wenn auf dem highway=bus_stop auch ein public_transport=* tag vorhanden ist. Dieser separate node ist somit lediglich mappen für den Renderer der Standardkarte.
Weiterhin würde mich noch interessieren wo du die ref:VBB herhast und ob man damit evtl. auch Fahrplanauskünfte abrufen kann wie über die ref:BVG, würde ich dann auch gern mit eintragen.

Und genau one-feature-one-osm-element ist ja das Problem!
Ich versuche es nochmal von der anderen Seite aufzuziehen. Ich rede hier nur von Bushaltestellen welche auf PTv2 umgestellt sind und aus einem node public_transport=stop_position und einem way public_transport=platform bestehen. Dieses anerkannte Schema ist auch korrekt, da es unterschiedliche feature sind, die "BusHalteStelle" wo der Bus hält und Platform/Wartebereich der Kunden.
Kommen wir nun zum highway=bus_stop. Dieser sollte auf einen node eingetragen werden und dies wird auch zu 99,6% so getan. Da bleibt somit von den beiden public_transport Elementen nur die stop_position, auch wenn die sich auf der Fahrban befindet, was auch nicht falsch ist wie ich dir auch schon versucht habe zu erklären. Nutze ich nun allerdings hierzu einen zusätzlichen node, selbst wenn dieser Bestandeil des ways platform ist, erzeuge ich ein weiteres Element Bushaltestelle obwohl diese ja schon eingetragen ist. Ein Datenauswerter der sowohl PTv2 als auch PTv1 nutzt erkennt hier also zwei Bushaltestellen wo es nur eine gibt, sobald aber der node mit highway=bus_stop auch einen public_transport tag enthält, kann die software erkennen dass es sich um EINE Haltestelle handelt. Daher zeigen auch die QS-tools die nodes highway=bus_stop ohne public_transport=* als Fehler an, was kein Fehler sein muß solange noch kein PTv2 ins Spiel gekommen ist.
Dass die wikis sich leider in vielen Fällen und auch bei diesem Thema teilweise widersprechen und wie von mir auch schon aufgezeigt teilweise plötzlich ins Gegenteil abdriften ist hinlänglich bekannt, daher muß man letztlich wie hier auch bis zu den Grundsätzen wie eben one-feature-one-osm-element oder auch KISS zurückgreifen.
Schöne Grüße Bernd

Jetzt weiß ich tatsächlich nicht mehr was du eigentlich willst. Abgesehen davon dass ich nicht erkennen kann dass du auf meine Argumente eingegangen bist, gehe ich wie oben ausführlich beschrieben nach den zuletzt von dir genannten wikis vor. Mir scheint, dir ist das Konzept von Ptv2 nicht ganz klar, auf meine Hinweise zum wiki One feature, one OSM element zu deiner Frage kommt von dir "...das bringt doch nichts"
Wir kommen hier wohl nicht weiter, du weißt wo du mich treffen kannst, nach meiner Erfahrung bringt ein Gespräch deutlich mehr in kürzerer Zeit als dieses ständige Missverstehen des Textes des Anderen.

Wir drehen uns im Kreis, du verstehst mich einfach nicht. Ich entferne highway=bus_stop an keiner Bushaltestelle, ich verstehe auch deinen Ansatz den Haltemast einzutragen, das findet durchaus auch in einem meiner Gedankenspiele zum Thema seinen Platz. Erstelle dazu gern ein neues tag, denn den gibt es dafür nicht, Vorschläge gab es hierzu auch schon in den Foren. Die Bushaltestelle ist mit platform und stop_position wie von mir schon aufgeführt vollständig eingetragen, ein zusätzlicher unabhängiger! bus_stop ist daher nach osm.wiki/DE:Ein_Objekt,_ein_OSM-Element falsch

Entschuldigung angenommen :)
der OSM-Stammtisch ist der einfachste Weg um sich mit erfahrenen Mappern und Datennutzern auszutauschen und ist durchaus eine wichtige Kommunikationsmöglichkeit neben mailing-listen und Foren, speziell auch für Neueinsteiger und regionale Belange. Nicht ohne Grund gab es seinerzeit diesen BVG-Stammtisch, wo durchaus Interesse an der Nutzung der OSM-Daten bekundet wurde, allerdings auch das Gezeter um das tagging als Hinderungsgrund mit angeführt wurde.
Eine Beteiligung in den Foren erachte ich derzeit leider als sinnlos, da alles zu diesem Thema von beiden Seiten gesagt wurde, ich konnte dort allerdings noch keine Annäherung erkennen, im Gegenteil, es läuft neben grundsätzlicher Ablehnung von PTv2 hauptsächlich immer kompromisslos auf die geliebte Darstellung des blauen Busses auf der Standardkarte an der Stelle des Haltestellenmastes hinaus. Es wird auch regional durchaus unterschiedlich gehandhabt, z.B. ist München seit Jahren überwiegend nach dem von mir unterstütztem Schema getaggt. Auch hieß es lange Zeit im wiki "An der Halteposition des Busses einen Node auf der Straße mit folgenden Tags: public_transport=stop_position... Er erhält auch das Tag highway=bus_stop." was im Zuge einer dieser vielen Diskussionen Ende 2017 geändert wurde. Nach diesem Schema hatte auch ich etliche Linien schon angepasst, nachdem es dann nun wieder durch andere flächendeckend zurückgebombt wurde um sich danach hinzustellen dass ja die Mehrheit so getaggt wird... (nicht böse gemeint, wenn du dir die Jacke anziehen solltest ;)
Abschließend noch: der wichtigste editor JOSM hat seine Vorlagen so programmiert und mindestens zwei der wichtigsten QS-tools osmi und osmose werten die aktuellen Berliner Bushaltestellen als fehlerhaft.
So falsch kann ich also nicht liegen, daher sei mir bitte nicht böse wenn ich in meiner Region diese Fehler wieder korrigiere ;)

Hallo Kevin, ich habs mal mit changeset/62986013 angepaßt, ich hoffe damit können alle Seiten gut leben :)

Hallo RoterEmil,
gern möchte ich versuchen einige Missverständnisse auszuräumen.
Ich habe noch an keiner einzigen Bushaltestelle highway=bus_stop gelöscht!
Den entsprechenden node neben den highway zu setzen war der erste Ansatz und ist damit immer noch die einfachste und daher auch gebräuchlichste Variante eine Bushaltestelle darzustellen. Allerdings wurde spätestens mit Einführung von highway=platform dazu übergegangen die Detailtiefe zu erhöhen und den Wartebereich separat darzustellen welcher als way sogar auf der Standartkarte gerendert wird. Hier wird dann eben nicht ein node neben sondern auf der Fahrbahn gesetzt "Es ist zum Teil auch üblich highway=bus_stop auf die Straße zu setzen,...falls zwei Haltestellen genau gegenüber liegen, oder aus Analogie zum railway=tram_stop...wird highway=platform als Punkt/Linie/Fläche anstelle des sonst üblichen Knotens highway=bus_stop gesetzt." Auf dieses Schema setzt auch PTv2 auf, womit eine Parallelexistenz beider Systeme problemlos möglich wäre. Dieses Schema (1 node highway=bus_stop + public_transport=stop_position und 1 way highway=platform + public_transport=platform) ist auch vor Monaten an einem OSM-Stammtisch mit Beteiligung der BVG (welche auch diese Daten nutzen) seinerzeit so abgestimmt worden. Ein weiterer *zusätzlicher!* node highway=bus_stop ist somit nicht nur nicht notwendig sondern falsch und lediglich mappen für den Renderer der Standartkarte, was zudem wie schon erwähnt noch weitere Fehler bei der Datennutzung mit sich bringt.
Dieses Thema ist leider doch sehr komplex um es an dieser Stelle zum Konsens zu führen, was auch diverse Diskussionen in Foren etc. zeigen, daher kann ich immer wieder nur auf den Stammtisch verweisen, wo sich doch durchaus einfacher über die jeweiligen Vor-und Nachteile reden lässt ;)
Schöne Grüße
Bernd

ein zusätzlicher separater node highway=bus_stop ist keine Korrektur sondern unnötiges tagging für den Renderer das zudem eine sinnvolle Nutzung für Anwender (z.B. OsmAnd) nahezu unmöglich macht

Hallo Kevin,
danke für deine Antwort.
Wie gesagt bevorzuge ich die vorherige Version (natürlich inkl. deiner Ampeldetails), eilt aber nicht, wenn du es schaffst ok, mache ich aber auch gern selbst - wer halt zuerst die Zeit findet.
Ansonsten freue ich mich auf ein Treffen bei einem der nächsten Stammtische :)
Gruß Bernd

Hallo Kevin,
das "Problem" mit der Ampel wird durchaus als letztes Beispiel unter osm.wiki/DE:Key:crossing#Beispiele aufgegriffen. Es kann ja letztlich auch nicht dazu führen Verkehrsinseln mit und ohne Ampel evtl. unterschiedlich einzutragen.
Ich will aber auch nicht abstreiten dass es schwierig ist festzulegen ab wann eine bauliche Trennung vorliegt oder bis wann es noch als Verkehrsinsel/-beruhigung durchgeht. Solange Straßen und Wege als Linien und nicht als Flächen getaggt werden wird es immer Kompromisse geben müssen. Z.B. kann im vorliegenden Fall wohl jeder mit einer Trennung des Spandauer Damm leben, obwohl nur ca. 5m dazwischen liegen und somit streng nach wiki man jedes Teilstück auch als ein way mit traffic_calming=island kennzeichnen könnte (wäre ich auch dagegen...). Andererseits wird aber durch deine Darstellung aus einer 12m Insel eine ca. 50m aufgetrennte Fahrbahn die abgesehen davon ja schon wieder vor der südlichen Fahrspur wieder zusammengeführt werden müsste und ein tag *=island für die ja vorhandene Insel fehlt auch.
Will sagen ich finde meinen Ansatz einfacher (KISS-Prinzip) ohne dass Informationen verloren gehen.
Vielleicht kannst du es ja auch mal zum OSM-Stammtisch einrichten, war nun gerade gestern erst, aber ich bin da eigentlich regelmäßig ;)
Gruß und schönes WE
Bernd

Hallo kartonage,
ich halte die Auftrennung der Reichsstr. am Spandauer Damm für falsch. Hier ist lediglich eine Fußgängerinsel crossing=island auf der Fahrbahn, welche als ein node vollkommen ausreichend dargestellt ist. Vergleichbar auch mit traffic_calming=island wo ich dem wiki deutlicher entnehme dass hier nicht aufgetrennt werden soll.
Gruß Bernd

Hallo glibbertorsten, relation/1240551 ist die Gemeinde Wustermark inkl. aller Ortsteile und relation/1823314 ist nur der gleichnamige Ortsteil,
siehe auch https://de.wikipedia.org/wiki/de:Wustermark?uselang=de/#Gemeindegliederung

Hallo johndoe,
wieso löschst du Merkmale wie shelter, bench, bin, tactile_paving von nodes highway=bus_stop? Viele Anwendungen nutzen diese Daten so noch und es ist deshalb nach wie vor nicht vorgesehen die alten PTv1-tags zu löschen (nur weil ID das evtl. so will...). Selbst OsmAnd, welcher auch Ptv2 unterstützt nutzt in der Standardansicht die Ptv1-Daten. Ich bitte dich daher dies bitte zukünftig zu unterlassen.
danke

hab's reverted, danke für dein Verständnis, letztlich möchte ich auch nur auf das Thema Versatz sensibilisieren, damit man sich nicht auch noch zukünftig unnötig Arbeit macht.
Wenn du mal am OSM-Stammtisch vorbeischaust geb ich dir n Bier aus ;)

Hallo kartonage,
um zwei CS zu reverten (siehe Kommentare changeset/57159055) würde ich diesen gern vorher ebenfalls reverten, da er damit zusammenhängt.
Ich werde mich dann morgen dran setzen.
danke
Gruß Bernd

Hallo Frank, danke für die schnelle Antwort. Selbst die beiden DigitalGlobe Luftbilder Premium und Standard weisen genau die gleichen Differenzen untereinander auf. Esri sieht identisch mit bing aus. Die GPS-Rohdaten Daten kannst du ganz einfach in josm mit den Kartendaten runterladen und an den Kreisverkehren kann man ganz gut erkennen dass Mapbox und DG Premium besser passen und somit die älteren Daten.
Gruß Bernd

Hallo Elwood,
hast du schon mal davon gehört, dass die neuen bing Bilder leider z.T. einen starken Versatz um mehrere Meter haben? Das ging schon sofort nach Erscheinen durch diverse Foren.
Auch wenn du sehr viel Arbeit hier reingesteckt hast würde ich diesen und changeset/57124957 gern wieder zurücksetzen, da ich mir relativ sicher bin, dass die alten Daten durchaus korrekter waren. Ich habe dies in und um Nauen mit eigenen gpx Daten vor geraumer Zeit schon mal abgeprüft und auch die frei verfügbaren gpx Spuren deuten eher darauf hin.
Gruß Bernd

Hallo nochmal,
ich hab das mal wie beschrieben mit changeset/56271986 angepaßt, ich hoffe alle Relationen und Einbahnstr. erwischt zu haben, um nichts zu zerschießen. Wem es nicht gefällt, kann es gern ändern ;)