layer = -1 ist nicht level = -1 - es heißt nur, dass sich der Weg unterhalb anderer Objekte befindet (in diesem Fall dem Gebäude/Gebäudeteil). Ich werde noch ein covered = yes ergänzen. Siehe layer=*

Wobei ich mit "garage" unzufrieden bin - oder welcher access-Tag würde passen, um klarzumachen, dass hier wahrscheinlich keine Anwohnenden ihre Autos unterstellen..?

Waaaas ok ich wusste sofort welche du meinst :) Ich habe lange darüber nachgedacht, weil vor allem auf dem 2019er-Bild irgendwas entlang der Gebäudekanten zu sehen ist, aber ich hab es für ausgeschlossen gehalten, dass da jemand Autos oben draufstellt :D

Also die hier (und die beiden daneben), ja? (wieder ergänzt) way/785441340

access ist frei möglich, also yes. Hab es ergänzt!

Done. Also was mir fehlt, ist ein Key für Grundsteinlegung :)

Da war ich mir auch nicht sicher und wollte erst "2020" schreiben. Dann dachte ich mir aber, dass beim Thema "Baujahr" ja auch die Grundsteinlegung interessant ist... Ich dachte außerdem, ".." würde als "von bis" und nicht als "irgendwann zwischen" interpretiert, aber da liege ich wohl falsch. Auch zum Wohle der Auswerter werde ich mal "2020" draus machen (ohne Monat - wüsste jetzt nicht genau, woran ich das festmachen sollte - die ersten Einzüge sollen wohl im April starten...)

...Nun frage ich mich nur: Was wäre das start_date bei der Kirche in Barcelona, die seit über 100 Jahren gebaut wird? :) relation/9194723

Bist du schon dabei, den Spielplatz an der Geygerstraße neu zu kartieren? :) Sonst gucke ich mir den heute Abend mal an...

Danke ;) Gibt es dort neue Spielgeräte? Mir war nur beim Spaziergang neulich aufgefallen, dass der Verbindungsweg zwischen Spielplatz und Lessinghöhe fehlte und hab beim Eintragen gleich noch die Spielgeräte auf Grundlage deiner (inzwischen schon etwas älteren) Mapillary-Bilder gemappt (oder es zumindest versucht - sind teils recht speziell...). Die Reckstange scheint laut deinem Tagging jetzt nicht mehr zu existieren und die Schaukel ausgetauscht - richtig? (alte Bilder: https://www.mapillary.com/app/?lat=52.475964399757316&lng=13.436997450621789&z=18.950178324573052&pKey=gu19RZfaMDFmf1ZrvJiS8A&focus=photo&x=0.4857181445134708&y=0.3957128454159845&zoom=0)

P³.S.: Der oben verlinkte Node sollte eigentlich auf das entsprechende CS verlinken: changeset/79766940

P.P.S: @SupapleX/diary/43613

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:
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 (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. 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 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 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" :)