P.S.: Um meine Micro-Logik zu verstehen: Im theoretischen Idealzustand würde ich OSM gern dazu benutzen, ein 3D- oder AR-Modell der Stadt zu generieren, welches mir an einem Gebäude den korrekten Eingang zu meinem Ziel anzeigt - oder den gesuchten POI/Laden an der korrekten Stelle. Das beißt sich vielleicht mit einer "2D-Renderlogik", wie du sie ausgebreitet hast, aber da das derzeit der übliche Anwendungsfall ist, kann ich das absolut akzeptieren :)

In dieser Ausführlichkeit habe ich mir dazu noch nie Gedanken gemacht, aber nicht nur, da ich auch gern heimlich für den Renderer mappe, kann ich das ganz gut nachvollziehen :) Habe es entsprechend angepasst:
osm.org/node/7143509625

Für mich schließt sich hier allerdings eine Grundsatzdiskussion an: Muss ich dann wirklich auf eine Relation zurückgreifen, wenn ich gern eine Verbindung zwischen dem POI und seinen Eingängen herstellen möchte? Bei nem kleinen Laden ist das sicher kein Thema, aber nehmen wir das Hostel von vorhin: Der Eingang ist an der Sonnenallee (osm.org/node/7143509625), das Hostel umfasst das gesamte Gebäude (zur Zeit eher nicht korrekt wiedergegeben). Hier kann man nach 30 Sekunden suchen den Eingang noch finden, aber wie oft habe ich mich schon an großen Behörden- oder Bürogebäuden über ungenaue Daten geärgert, wenn ich 10 Minuten nach dem richtigen Eingang gesucht habe...? Aber gut, diese Diskussion muss an anderer Stelle geführt werden :)

Gerade hier in dieser "unübersichtlichen" Situation (viele Eingänge, unklare Hausnummern) scheint es mir hilfreich, um die reale Situation korrekter abzubilden. (vgl. osm.org/note/2017490) Und letztendlich betritt man einen Laden ja immer über den entsprechenden Eingang... Also auch noch gut fürs Fußgänger-Routing :) Gibt es aus deiner Sicht etwas, was dagegen spricht? Im Wiki habe ich bisher weder Empfehlungen noch Diskussionen dazu gefunden und als eher micro-orientierter Mapper scheint mir das die korrekteste und informationsreichste Mappingvariante zu sein... lg, Alex
P.S. Hausnummern sollten mMn generell als Eingänge gemappt werden...

cycleway:buffer gab es sogar vorher schon (siehe osm.wiki/Key:cycleway:buffer), cycleway:protection könnten wir bei Gelegenheit mal anlegen. Allerdings bräuchte es dann wohl auch Seiten für "protection" und "buffer" (ohne cycleway-prefix), für separat gemappte Radwege? (siehe Hasenheide)

Achso, und die Bezeichnung einer parking_lane als "protection" bezieht sich eher auf die Raumaufteilung bzw. die Trennung verschiedener Verkehrsteilnehmer - das Value "parking_lane" als Gefahr zu interpretieren (erst recht bei buffer=no) steht dir natürlich frei :) Auch in anderen Fällen kann "protection" auf einen eher geringen Schutzstatus hinweisen: Also nicht nur bei "protection=no", sondern z.B. auch bei "protection=surface", womit wir eine lediglich durch Bodengestaltung abgehobene Radwegführung meinen (also de facto kein ausreichender Schutz).

Hallo Jan,
ursprünglich habe ich an dieser Stelle "cycleway:right:protection:right" geschrieben (also zweimal :right), es aber dannn noch "gekürzt", da oneway. Ich bin davon ausgegangen, dass die Suffixe ":right" oder ":left" auf das jeweils vorherige Tag bezogen interpretiert werden (im von dir angesprochenen Fall also auf "protection"). Aber es kann wohl nicht schaden im Wiki zu empfehlen, immer klar Eigenschaft und Seite gemeinsam zu benennen, um bei ein- und beidseitig befahrenen Spuren nicht durcheinanderzukommen. Hier also dann doch "cycleway:right:protection:right"?

Ich vermerke das Problem mal im Wiki. Das protection-Tagging ist noch recht frisch und befindet sich in der "Testphase", siehe:
osm.wiki/Talk:Berlin/Verkehrswende/PBL-Notes

P.S. Den "loc_name"-Tag ("Plumpe") finde ich allerdings legitim, da diese Bezeichnung für diese spezifischen Objekte tatsächlich existiert. Diesen würde ich auch gern wieder in den Tagging-Vorschlag aufnehmen. Wenn es dazu Bauchschmerzen gibt, lässt sich das aber sicher auch gut im Wiki klären (osm.wiki/Talk:Names).

Hallo! Bin gerade erst auf die Diskussion gestoßen. Es gibt ein mit dem name-Tagging verbundenes Problem, was ich in der Diskussion im Wiki geschildert habe. Auch auf der Berliner Mailingliste habe ich gerade etwas dazu rumgeschickt. Finde das name-Tagging aber grundsätzlich auch unglücklich und bin gespannt, was sich ergibt. --beste Grüße!

Hi, ja, das "position"-Tagging finde ich super und habe ich ergänzt. Es ist zwar bislang nur ein Vorschlag, aber ich finde ihn passend. Über Tags wie diesen diskutieren wir übrigens zur Zeit regelmäßig bei einem Berliner OSM-Fahrrad-und-Verkehrswende-Treffen: osm.wiki/Talk:Berlin/Verkehrswende

Access=yes wäre an dieser Stelle etwas überflüssig, da das ja der Standardfall ist und nicht extra ausgewiesen werden muss. (Wenn die Fahrradständer auf einem Privatgelände mit Zugangsbeschränkungen stehen würden, wäre das vielleicht etwas anderes.)

Mit "start_date" wollte ich dokumentieren, dass die Fahrradständer im August 2019 gebaut/eingeweiht wurden (also ganz frisch) - schadet ja nicht es festzuhalten :) (siehe auch osm.wiki/Key:start_date)

Ok! Im physischen Sinne ist dieser Weg ja auch tatsächlich da, nur hat später jemand einen Zaun draufgestellt - daher ist es auch nicht nur "Mapping für KeepRight" :)

Soweit ich weiß sind die Innenhöfe leider nur in Ausnahmen (wie Kopfstraße 15) mit den Haupteingängen verbunden. Die Innenhöfe sind auch hier meist nicht mehr erreichbar, nur für die Leute im Erdgeschoss und aus ein paar sozialen Einrichtungen heraus. Soweit ich weiß auch nicht aus den Gebäudeaufgängen heraus.
Allerdings gibt es ja noch die (verschlossenen) Feuerwehrzufahrten, die den öffentlichen Raum mit den Innenhofwegen verbinden - müssten Fehlermeldungen dadurch nicht verhindert werden? Bei einem der Ringbauten hab ich die Feuerwehrzufahrt noch vergessen zu mappen bzw. bin beim systematischen "durchkartieren" auf 360-Grad-Fotobasis aus dem letzten Frühjahr noch nicht bis dorthin gekommen...

Hey, ja, das ist eine blöde Stelle hier - genau so blöd wie die Realität :)
Der früher mal öffentlich zugängliche Weg wurde nämlich vor einigen Jahren mit einem Zaun vom Straßenraum abgeschnitten und ist nun eigentlich nicht mehr erreichbar - höchstens für Anwohnende aus dem Erdgeschoss oder - so wie als ich dort mappen war - mit etwas Glück, wenn die Feuerwehrzufahrt nicht abgeschlossen ist...
Deshalb diese merkwürdige Kartierweise. Ich würde es nicht verbinden, aber hätte auch kein Veto, falls du es verbinden willst. Wenn, dann müsste es ein kurzer footway sein vom Fußweg entlang der Kienitzer Straße bis zum Zaun, anschließend an die Treppenstufen, die zur Zeit das Ende des nicht angeschlossenen Weges bilden - und irgendwo müsste noch ein access=no ran...

Hallo, danke für den Hinweis! Den OSM Inspector sollte ich bei solchen Edits zukünftig mal im Auge behalten - hatte ich nicht auf dem Schirm. Die JOSM-Warnings sind in dieser Hinsicht leider nicht hilfreich, da nicht "Indoor-kompatibel"...
Ich habe eine erste kleine Fehlerkorrektur versucht - mal sehen, ob der Inspector nach dem nächsten Datenupdate schon zufrieden ist.
Bei diesem Indoor-Changeset hatte ich versucht, über viele Stockwerke hinweg wirklich nur Objekte zusammenzukleben, die auch in der Realität physisch zusammenhängen. Das könnte unnötig und eher kontraproduktiv gewesen sein...

Und ein Teilstück des Schmollerplatz - auch wegen der Baustelle dort.

Alles klar, dann habe ich nicht gut geschaut vor Ort. Habe sie zwischen Schmoller- und Harzer Straße wieder eingetragen (von Süd nach Nord befahrbar). Neu eingetragen habe ich am Montag auch die temporäre Einbahnstraße in der Mengerzeile - da bin ich mir aber sicher ;)

Hey, du meinst, du hast gestern noch eine Einbahnstraße zwischen Heidelberger und Harzer Straße gesehen? Wenn du dir sicher bist, nehme ich sie wieder herein, aber ich war am Montag dort und meinte, keine mehr gesehen zu haben (obwohl die große Baustelle im Bereich der Nummer 39 weiterhin die Straße etwas verengt...) Ansonsten kann ich dort auch nochmal nachsehen demnächst.

Na, dafür warst du hier schneller als ich :) #Fahrradstraße Weigandufer

Hallo Gerd, ja, bei diesen Lampen wusste ich auch nicht wie ich sie am besten taggen soll - am Ende habe ich mich für diese Variante entschieden. Es handelt sich dabei um Bögen, die jeweils rechts und links der Straße im Boden verankert sind; das Licht hängt oben in der Mitte im Bogen. Alternative wäre aus meiner Sicht entweder ein Node in der Straßenmitte oder evtl. zwei Nodes jeweils am Punkt der Bodenverankerung, aber die finde ich beide noch irreführender als diese Lösung als Linie...

Hey robson,
großartig dass du Fahrradbügel kartierst - in anderen Teilen Nordneuköllns hab ich das nämlich auch schon systematisch gemacht und mit deinen Edits sind die Lücken im Bezirk inzwischen ganz schön klein geworden. Hatte dir dazu vor ein paar Wochen mal eine OSM-Nachricht geschickt, vielleicht kannst du mal in dein Postfach schauen - freue mich über Antwort :)

Hallo RoterEmil, huch, habe deinen Changeset-Kommentar irgendwie nie bemerkt!
Ja, die "area=yes"-Flächen sind überwiegend Gebäudeteile, inzwischen habe ich sie auch schon als solche getaggt. Vor Ort erscheinen sie nicht unbedingt so, es sind eher erhöhte "Podeste" mit Treppenaufgängen vor den Eingängen der großen, gut sichtbaren "Ringbauten", aber offenbar befinden sich auch Keller- oder "Service"räume darunter. Bei einigen in der Mitte habe ich inzwischen ja schon die exakten Zugangswege gemappt, die dann eben über die Gebäudeteile drüberführen.
Es dürften noch etwa zwei "area=yes"-Flächen übrig sein (vor Hausnr. 59 & 57), die ähnlich aussehen wie die anderen Aufgänge, aber technisch keine Gebäudeteile sind. Weiß noch nicht ganz, wie ich sie taggen soll - highway=footway trifft es aus meiner Sicht nicht so ideal...