@Geofreund1: Schau mal auf Seite 6, Beitrag #139 und meine Antwort darauf in #140.
Ja danke. Wenn ein Faden zu lang wird, wird’s halt unübersichtlich. 
Die street-Relationen sind nicht ganz dasselbe wie associated_street:
Mit Rolle *associated *können auch andere Objekte wie Zufahrtswege oder Parkplätze in die Relation aufgenommen werden.
In meinen Augen wäre das die einzig halbwegs schlüssige Rechtfertigung für diese Art von Relation, wenn nicht nur Adressen sondern auch noch andere Objekte erfasst würden.
Dann wären hypothetische Abfragen der Art “wieviele Parkplätze gibt es in dieser Straße” möglich.
Das Problem der Wartbarkeit hätte man allerdings genauso.
Momentan sind die as-Relationen für mich nur lästig, z.B. wenn man an den Gebäuden was ändern will.
+1 zu den Ausführungen von seichter. Allerdings habe ich solche „interessanten“ street-Relationen (die auch andere Objekte mit aufnehmen) im mittleren Baden-Württemberg in den Daten noch nicht gesehen (vielleicht gibt es sie anderswo?). Alle street-Relationen, die ich bisher gesehen habe, waren entweder
(a) so aufgebaut wie associatedStreet-Relationen (und sind daher entbehrlich, da wir die associatedStreet-Relationen für entbehrlich halten) oder waren
(b) sogar noch redundanter, weil sie nicht einmal Gebäude oder Adressknoten enthalten, sondern allein dazu verwendet wurden, mehrere Teilabschnitte einer Straße zusammenzufassen. (Das ist das, was ich in #139 salopp als „superredundant“ bezeichnet habe ;). In und um Leonberg gibt‘s x Stück davon.)
Wir sollten wohl, wie dktue in #140 vorgeschlagen hat, nochmal getrennt darüber befinden, aber mMn sind zumindest street-Relationen vom Typ (b), die also nur gleich benannte Straßenabschnitte zusammenfassen, mehr als entbehrlich. (Wenn diese Zusammenfassung für irgendetwas nötig sein sollte, kann sie doch sicherlich auch durch halbwegs intelligente Software aus den Daten selbst abgeleitet werden … und zwar jederzeit aktuell, ohne dafür auf fehleranfällige, da pflegeaufwändige Relationen zu setzen.)
Nur zur Info: Das Feature ist inzwischen auch in der aktuellen “Tested”-Version angekommen. Updaten lohnt sich diesmal also besonders. 
Stand vom 15.03.2019
Inspected file: germany-latest.osm
associatedStreet-relations: 42053
hereof redundant: 24438 (58%)
Stand vom 01.04.2019
Inspected file: germany-latest.osm
associatedStreet-relations: 14706
hereof redundant: 5215 (35%)
Änderungen vom 01.04.2019 gegenüber dem 15.03.2019
Anzahl associated-Street-Relationen: −27347
Relative Änderung: −65%
Wow, das ist doch echt beeindruckend!
Hier mal ein aktueller Plot:
Gruss
walter
Und wie nutzt man das Feature? associatedStreet-Relation auswählen und prüfen?
Entweder so oder einfach nichts auswählen und die Prüfung starten.
Man darf sich allerdings nicht wundern, wenn nichts bezüglich as-Relationen angezeigt wird: Schon geringe Unterschiede wie unterschiedliche Schreibweisen von Namen oder is_in-Tags führen dazu, dass dies als nicht völlig redundant betrachtet wird.
Das ist mMn auch in Ordnung so, denn: Was soll eine maschinelle Auswertung als “gering” oder irrelevant einstufen?
Auf einen Nebeneffekt möchte ich hinweisen: Wenn man die Prüfung ohne Auswahl über ein heruntergeladenes Gebiet startet, werden auch viele andere Fehlerchen wie fehlende layer-Tags bei Brücken usf. angezeigt. Die kann man bei der Gelegenheit gleich mit korrigieren (Kollateral-Mapping).
Ja. AS-Relationen auswählen, in die Auswahl übernehmen, Prüfen, in den Prüfresultaten “obsolete relations” auswählen und auf “Reparieren”.
https://www.openstreetmap.org/relation/3497427 ist aus meiner Sicht redundant, wird aber von JOSM nicht als überflüssig angezeigt. Wer hat recht?
Die dritte Straße hat keinen Namen. Du mußt selbst entscheiden, ob Du ihr einen Namen geben willst oder die Relation löschst ohne das zu tun.
Nactrag: keinen Namen geben, da sie Teil eines MPs ist.
Baßtölpel
Wenn ich so ein MP (1) mit highway=* und area=yes sehe, dann frage ich mich jedesmal, ob das nicht eigentlich eine area:highway=* hätte sein sollen.
(1) https://www.openstreetmap.org/relation/3497426
hw=pedestrian+area=yes gab es lange vor der Erfindung von area:hw und wurde schon immer auch für Platz-Strukturen verwendet.
Umtaggen würde ich sowas deshalb nicht. Da area:hw nicht gerendert wird, besteht auch die Gefahr es es wieder zurückgeändert wird. 
Ob es angezeigt wird oder nicht ist die eine Sache. Ob es irgendein Router verstehen kann ist die andere.
In diesem Fall scheint es ja zumindest wirklich ein Platz zu sein, daher finde ich das Flächen-Mapping sachlich gerechtfertigt. Wenn dagegen Flächen mit highway=* und area=yes dazu verwendet werden, einfach die Breite einer Straße zu mappen (auch das gibt es immer wieder), ist die Änderung in area:highway=* auf jeden Fall angebracht.
Statistik please? Hab den Eindruck dass in den letzten Tagen radikal geputzt wurde.