und danke für das anpassen des Schreibwarenladens! ich hätte das auch machen können, wollte es aber nicht einfach ohne Konsens ändern

Im Endeffekt ist es eine Frage dessen wie puristisch man sein will. Ich würde dazu tendieren, name=* wirklich nur anzugeben, wenn es ein "echter" Name ist, der sich nicht einfach nur etwas ist was brand=* oder operator=* ist. Am Ende ist das auch immer eine Abwägung, und auch ich habe schon name=* verwendet wenn man das eigentlich als unpassend argumentieren kann.

Man kann da auch ganz schnell in ein "Mapping für den Renderer" (osm.wiki/Good_practice#Don't_map_for_the_renderer) kommen, auch wenn Renderer z.B. bei einem typischen Filialgeschäft einer Kette das brand=* wie einen Namen rendern können.

Dass der McD in Kleinostheim name und brand identisch hat, könnte gut einfach darauf zurückzuführen sein, dass früher der name sogar deskriptiv genutzt wurde. Am Ende ist es eine Grauzone, in der beides argumentierbar ist.

vgl. Diskussion im Community Forum: https://community.openstreetmap.org/t/ein-benutzer-loscht-andauernd-meine-anderungen-und-antwortet-nicht-auf-nachrichten/119490/5

Bei den Namen habe ich Zweifel ob das wirklich der Name sein sollte. Nicht jedes Objekt muss einen Namen haben.

Ich beziehe mich auf das "Names are not descriptions" Prinzip, s. osm.wiki/Names#Names_are_not_for_descriptions

Zunächst zu dem DVAG Büro: Da bin ich der Meinung, dass das eigentlich nur eine Marke ist. Ja, der brand=* Tag fehlt, ich hatte nur brand:wikidata=* und brand:short=* hinzugefügt. Wenn überhaupt wäre der Name sowas wie DVAG Generaldirektion XX YY, aber das ist eigentlich auch wieder nur eine Beschreibung.

Bei dem schreibwarengeschäft bin ich der Meinung dass Lotto Bayern definitiv falsch ist. Das ist ein Laden, der Vertriebspartner von Lotto Bayern ist. Vielleicht hat der wirklich keinen Namen, als ich den hinzugefügt habe, konnte ich zumindest keinen erkennen.
Was aber angemessen wäre, wäre lottery=yes + lottery:brand=Lotto Bayern + lottery:brand:wikidata=Q2324423

Ich habe jetzt mal die vorgeschlagenen Tags hinzugefügt, s. changeset/180942280

Den name=* werde ich nicht anfassen, solange wir uns da nicht einig sind, auch wenn ich der Meinung bin, dass der unangebracht ist, und eher tagging for the renderer ist. Durch die hinzugefügten Tags bin ich jetzt der Meinung, dass der name auch keine zusätzliche Information beinhaltet. Vielleicht könntest du dir ja stattdessen description=Raucherhütte Personal vorstellen?
Dass du schreibst, "Wer auf die Karte schaut, wei was er dort findet" klingt für mich tatsächlich danach, dass du den name=* v.a. für den Renderer haben willst.

Alternativ könnte ich mir auch noch ein anderes Tagging vorstellen, und zwar amenity=smoking_area + shelter=yes + shelter_type=* statt amenity=shelter + smoking=dedicated.
Das würde den Fokus mehr darauf legen, dass es ein Raucherbereich ist, als dass es eine Wetterschutzhütte ist.

Ob wir darüber weiter sprechen überlasse ich dir, ich denke ich habe alles gesagt was ich für relevant halte, du hast das lokale Wissen, und solltest dann auch bezüglich des Taggings das letzte Wort haben.

Ich könnte mir vorstellen, dass shelter_type=weather_shelter passender wäre, soweit habe ich gar nicht gedacht. Der ist ziemlich offen definiert, das dürfte wohl die Luxus-Variante sein ;)

Ich glaube meinen Hauptpunkt habe ich nicht gut rübergebracht. Mich stört die grundlegende Verwendung von name=*. Für mich sieht das nach einem Missbrauch (klingt ein bisschen härter als ich es meine), wie in osm.wiki/Names#Names_are_not_for_descriptions beschrieben.

Deswegen habe ich die anderen Tags vorgeschlagen. Die geben genau die Information, dass der Shelter zum Rauchen und durch Benutzung des Personals gedacht ist.
Und ich glaube das ist eine Sache die wahrscheinlich niemand bei OSM besser einschätzen kann als du: Ist "Raucherhütte Personal" wirklich ein Name, oder nur eine Beschreibung? Ein typischer Name wäre aber normalerweise so etwas wie Sehr-Wichtige-Person-Raucherhütte.

Falls es eine Beschreibung ist, sollte der name=* Tag weg (und durch die deskriptiven Tags ersetzt werden), falls es ein echter Name ist, dann würde ich sowas wie note=Raucherhütte Personal ist tatsächlich ein echter Name hinzufügen.

Hallo, ich habe deinen Beitrag durch die Diskussion im Community Forum gefunden.

Dass die Hütte name="Raucherhütte Personal" hat, irritiert mich ein wenig, das wirkt ein wenig wie eine Übernutzung des name=* ‑Tags für deskriptive Zwecke.

Aus dem name würde ich schließen: smoking=dedicated + access=private + private=employees
Analog auch bei der Raucherhütte Bewohner mit private=residents

Ist der Name wirklich ein echter Eigenname? wenn ja, würde das meiner Meinung nach ein note=* rechtfertigen.

Kennst du irgendwelche Datenauswerter die wirklich die tesla_supercharger_css anders interpretieren als ein normales type2_combo? das wäre ja der einzige Grund den ich sehen würde, einen „langsamen“ Übergang zu ermöglichen. Oder warum würdest du es behalten?

Ich finde ehrlicherweise sowieso den socket:tesla_supercharger_css ziemlich unnötig. jetzt will ich herausfinden, warum es den Tag überhaupt gibt...

ich nehme mal die socket:tesla_supercharger_ccs* raus. Der Tag ist deprecated, der richtige CCS Eintrag von dir ist besser und die Kombination ist verwirrend (als gäbe es je dispenser 2 Stecker)

sources: local knowledge, i survey them

ach ja, danke für das Lob :)

das habe ich auch mit den anderen HPC in Kleinostheim gemacht ;)

Wobei ich der Meinung bin, dass da noch die Spannungs/Strominformationen fehlen. Bei den HYC*** habe ich das

Oder meinst du dieses kleine Fenster oberhalb der Frage? Ja, da wird auch der operator=* berücksichtigt, wenn kein name=* vorhanden ist.

Ja, das kann auch verwirrend sein.

Ich glaube verstanden zu haben, woran es lag:

Ursprünglich wurden diese beiden flächen mal als landuse=* + operator=* getaggt, jeweils zusätzlich zu dem eigentlichen amenity=kindergarten daneben (z.B. node/10958958858)
Irgendwann wurden die mal zu amenity=kindergarten geändert (was meiner Meinung nach dem Prinzip "Ein Objekt, ein OSM Objekt" osm.wiki/DE:Ein_Objekt,_ein_OSM-Element widerspricht).
Scheinbar berücksichtigen die Renderer (zumindest der, den SC als Hintergrund verwendet) auch den operator=* wenn sie einen Namen angeben. operator=* und name=* sind natürlich nicht zwangsläufig identisch (z.B. ein Studierendenwerk was mehrere Kindergärten betreibt), aber wenn man nichts Besseres hat, ist das besser als nichts zu rendern.
Gerade in einem Tool wie StreetComplete, was gezielt darauf entwickelt ist, dass man mit der Datenstruktur nichts zu tun hat, kann das definitiv verwirrend sein.

StreetComplete hat dann einfach gesehen, da ist ein Kindergarten, bei dem name=* fehlt (aber Kindergärten haben normalerweise einen Namen, also muss der fehlen) und noname=yes ist auch nicht gesetzt. Also hast du die Frage bekommen.

Was du in StreetComplete machen kannst, ist, einen Hinweis zu hinterlassen. Vielleicht wäre dann auch jemandem aufgefallen, dass die Kindergärten praktisch dupliziert sind.

Hallo sqrt-1764,

vielen Dank für deine Beiträge zu OpenStreetMap.
Dein Beitrag ist einem Mitglied der OSM DE Matrix Gruppe aufgefallen. Durch deine Änderung haben die beiden Kindergärten die Eigenschaft name="So wie ihr ihn (mir) hier anzeigt" bekommen. Im Gegensatz zu anderen (kommerziellen) Diensten schreibst gehen deine Änderungen die du per
StreetComplete machst, direkt in die Datenbank.
Wenn du also in SC nach einem Namen gefragt wirst, wirst du das was du da eingibst nach wenigen Minuten in der Datenbank, und auch ggf. in Renderings finden.

Die grundlegende Art, wie das gemappt ist, ist auch noch verbesserungswürdig (Das hat aber nichts mit deinen Änderungen zu tun). Dafür öffne ich noch eine Note, dass das von jemandem mit lokalem Wissen verbessert werden kann.

Hallo Alex, danke für deine Beiträge in Kleinostheim.

Zu diesem Changeset habe ich zwei kleine Fragen:

* auf node/12618340522 hast du ein entrance=yes gesetzt, was meiner Meinung nach node/1809846990 dupliziert, was an der tatsächlichen Position des Eingangs und nicht des Vordachs ist. Ich würde vorschlagen, diese node wieder ohne tags zu machen, und dafür einen highway=footway noch bis zur Tür zu erstellen. In dem Kontext könnte ich auch noch die anderen beiden Türen auf Turmseite ans Wegenetz anschließen.

* way/1473796815 hast du einerseits mit name=* und access=private gemappt. Der Name erscheint mir eher eine Beschreibung zu sein. Ist das wirklich ein vor Ort ausgeschriebener oder anderweitig etablierter echter Name? Sonst würde ich zu operator=Hotel zum Schwanen für sinnvoller halten. Außerdem irritiert mich das access=private. Ich würde auf einem Hotelparkplatz eher ein access=customers (s access=*) erwarten, ggf. in Verbindung mit fee=yes. Ist das privat wirklich richtig?

Puh, dass ich da keine ÖPNV-Relation kaputtgemacht habe, war reines Glück …

it was an admin_level=10, but does not matter for the conclusion

Warum hast du den Weg auf access=yes gesetzt? Die A45-Brücke wird gerade neu gebaut, Baustelle bis vsl. 2031 [1], wie auch bei note=* erwähnt. Ja, ein Weg mit Radwanderweg-Relationen und access=no ist etwas seltsam, ggf. könnte man sogar die Relationen für die nächsten 5 (+x) Jahre auf die Umleitung verschieben. Aber komplett kommentarlos halte ich für falsch. Das ist das absolute Gegenteil einer kurzfristigen Baustelle, schneller vorbei ist, als die Daten bei den Datenkonsumenten angekommen sind.

[1] https://www.mainhausen.de/pressemeldungen/ersatzneubau-mainbruecke-bab-a45-mainflingen-umleitung-fahrradwege-1710411060/2024/03/14

super, danke dass du es gleich gefixt hast :)

Nehme ich richtig an, dass das Objekt way/1461259488 ein barrier=fence sein sollte?

Ich glaube, da ist ein Typo drin.