Just FYI: OSM puts a major focus on de facto rather than de jure so `place=*` isn't necessarily about places which legally exist (although the legality is one strong point of existence and partially affects the `place` value, see `place=suburb`) but simply any known named location, populated or otherwise.

Even when a place has been officially dissolved, its physical characteristics are still there (e.g. you still have amenities named "Kagwe") unless it has been wiped from existence.

@geodegazelle: The same can be said for any other deprecated tag, though, as well as tags which iD considers as a mistake but it makes sense to use more standardised tagging to avoid headaches for data consumers.

Hallo Mentz,

nur so zu Info: Gleise und Fahrbahnen sind separate Elemente und sind auf OSM auch deswegen separat zu erfassen: embedded_rails=*#Motivation_and_Rationale
Das Taggen von bus=yes an Gleisen ist deswegen sinnfrei, weil Busse ja nicht auf den Gleisen an sich fahren, sondern nur auf der Oberfläche, die deswegen als ein eigenes Element dargestellt wird, was hier auch der Fall ist: way/42037645

Und auch beim Wunsch von zwei Wegen: Anders als im Neustadtring gibt es hier keine physische Trennung zwischen beiden Fahrspuren und laut OSM-Philosophie sind diese auch nur als ein Weg einzuzeichnen. Dazu eine relevante Entscheidung vor ein Paar Jahren: https://community.openstreetmap.org/t/strassen-mit-gleisen-in-mainz/97291

Grüße,
Manuel

Der Grund, warum ich das nenne, ist weil auf einigen Straßenabschnitte immer noch die ganzen access-Werte übrig bleiben und z.B. PTNA die ganze Zeit sich beschwert: way/983346859

Sind die Sperrungen alle fertig?

Gibt es einen Grund, warum du das Geschäft nicht gelöscht oder zumindest als "disused=amenity=restaurant" mit den anderen Daten entfernt gekennzeichnet hast?

Almost the same issues as with CS #174269137, although this one does edit ways, at the very least. Many of these ways are areas, though, used to mark the areas of the corresponding road (granted, they might be better replaced by area:highway but this isn't what you had intended).

For comparison, only these ways were changed in the spirit of the CS (replacing highway=yes to highway=road for linear ways):
* way/26243960
* way/1135087195
* way/134548812

Few items enough that you could have fixed these manually by looking into their history and see how some users have mangled these objects in some way or another.
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/174269164

Same issues as with #174269137: changeset/174269137
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/174269141

Clearly an automated edit: You're replaced highway=yes indiscriminatingly into highway=road without ever checking if the data is even correct. In fact, both this and CS #174269141 didn't even edit any ways but rather guideposts (which follow *=yes pattern to denote the target group), a clear case why automated edits should be taken with care.
See also: osm.wiki/Automated_Edits_code_of_conduct

This is on top of the fact that these changesets leaves a huge footprint which makes them harder to review: osm.wiki/Changeset#Geographical_size_of_changesets
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/174269137

Sicher, dass die Weiche vor dem Eingang liegt? Ich kann mich erinnern, dass am Eingang nur ein Gleis und die Weiche erst weiter hinten im Inneren des Depots.

Davon mal abgesehen habe ich auch bemerkt, dass du Oberusel-Mitte durch Oberursel (Taunus) ersetzt hast. Zugegebenermaßen war das alte Tagging m.M.n. auch nicht angebracht, da man der Logik nach z.B. Bad Homburg oder Frankfurt auch als place=municipality taggen würde (wütender Blick zu surveyor) aber es gibt durchaus einen Stadtteil namens (Oberursel-)Mitte und der ist separat von Oberusel als ganze Stadt (welches u.a. Oberursel-Nord und Bommersheim) einschließt).

Hallo hmkaiser,

du solltest dir bewusst sein, dass wir sachlich solange nicht zueinander finden können, wenn du Edits von misterte einfach so zurücksetzt, nur weil sie DIR nicht gefallen.

Jetzt mal ernst und ohne Echo: Ich gute Gründe angegeben, welche Probleme bridge:name mit sich bereitet und welche Alternativen es gibt.

Außerdem bin ich und misterte gegen bridge:name, also auch 1+1, zudem Gkremp in der Diskussion sich hier auch nicht mit beteiligte.
Wenn du also meinst, dass die Diskussion schnurstracks zu ignorieren und dann noch in der Änderung anzugeben, dass andere dir Recht gegeben haben, dann kann ich das auch machen.

"Unschön wäre vor allem, wenn ich aus deinen Löschungen im OSM-dokumentierten Ablauf betrachtend, den Eindruck gewinnen müsste, dass du es auf den OSM-Mit-Mapper GKremp persönlich abgesehen hättest. Das sollten wir in jedem Fall vermeiden. "
Bist du eine Sockpuppe von GKremp oder warum sollte er durch etwas, was mit deinen Änderungen passierte, beleidigt sein?

Weil du das bridge:name wiederhergestellt hast...

Ich selber habe hierzu einen Overpass-Code erstellt, mit der man alle Wege auf der Südbrücke lädt:
https://overpass-turbo.eu/s/2eGD
Es ist also sehr wohl möglich, alle Wege, die auf der Brückenfläche liegt, auch ohne bridge:name zuzuordnen (außerdem kann es auch noch passieren, dass man einzelne Wegstücke vergisst – hier zum Glück nicht der Fall, könnte aber bei den komplexeren durchaus vorkommen).

Tatsächlich fallen mir jetzt sogar drei Gründe ein, warum bridge:name unnötig ist, wenn der Umriss schon vorhanden ist: Nicht alle Brücken haben einen Namen (im Grunde die meisten), bridge:name ist nicht uneindeutig (z.B. gibt es eine weitere Südbrücke in Köln) und ist selber nicht stabil, wenn der Namen der Brücke sich ändert (da ist bridge:wikidata eher geeignet, da es eben unabhängig zu Namen liegt).

Spätestens bei einer bridge-Relation gibt es keinen Grund mehr, die bridge:*-Tags an den Wegen anzuheften, da die Relation an der Stelle vollkommen ausreicht und man auch z.B. keine komplexe Overpass-Abfragen o.ä. machen muss.

Auch im Wiki: "Durch die Verbreitung von explizit mit man_made=bridge kartierten Brücken hat dieses Tag an Bedeutung verloren, da der Brückenname nun im Standard-Tag name=* für das Brückenobjekt verwendet wird. "

Für mich liest es eben so, dass bridge:name nicht nötig ist, wenn ein "man_made=bridge" bzw. "bridge"-Relation schon existiert, gleiches auch für alle anderen Brücken-Tags wie bridge:structure und bridge:ref.

@hmkaiser: Ich bin gegen dieser Änderung und sehe bridge:name nur als nötig, wenn die Brücke schon nicht als Umriss bzw. Relation eingetragen worden ist.

Adressnamen werden in OSM übrigens i.d.R. nicht abgekürzt, insbesondere, weil man mit SC ja auch Straßen antippen kann, um die Straße einer Adresse zu setzen.

Bei deinen Änderung hast du bridge:name auf ein man_made=bridge hinzugefügt, was komplett unnötig ist, da bridge:name nur eine Zwischenlösung für Wege auf Brücken ist, die noch nicht als Umriss bzw. als Relation eingetragen worden sind.

Da musst du nichts machen, weil misterte dies korrigiert hat – und zudem noch "bridge:name" von den Wegen entfernte: changeset/173575562

Das Problem ist, dass das Tagging davon unter "Tagging für den Router" fällt (gerade für einen internen Router), da dieser "Weg" ja physisch nicht vorhanden ist (z.B. kann man die Fußwege mit der Bahnsteigfläche bzw. dem Eingang davon verbinden).

Tatsächlich habe ich sogar bemerkt, dass Mentz schon vorher mit OSM Probleme machte: https://community.openstreetmap.org/t/was-hat-mentz-mit-den-bahnsteigen-des-hammer-hauptbahnhofs-gemacht/92987

Jedenfalls habe ich in den Foren einen Thread erstellt, wo man das im Detail erklären kann: https://community.openstreetmap.org/t/bahnsteigkanten-mit-fusswegen-verbinden/137311

bridge:name ist nur nötig, wenn die Brücke nicht als Umriss bzw. als Relation hinzugefügt ist und die Daten dadurch ersichtlich sind, alles andere ist ein Doppeleintrag, welches das Bearbeiten (z.B. Namenswechsel) unnötig erschwert.

By the way, landuse=grass is valid: way/1035611919