@chris66: Von insgesamt 3973 associatedStreet-Relationen in Dortmund könnte JOSM durch Prüfen und Reparieren (Warnung: “Relation is obsolete”) mit einem Klick 3745 (94%) automatisch löschen.
Jain,
ich habe sowohl den Collector geändert als auch den Plot neu schreiben müssen.
Dabei könnte was passiert sein oder es war evtl die alte Auswertung nicht ok.
Leider kann ich den alten Plot nicht mehr laufen lassen, da QGIS sich weigert, das alte Projektfile zu öffnen.
Wenn ich mir allerding die Online-Karte (2.4) ansehe, ist der neue Plot “richtiger”. Diese Karte verwendet noch den alten Collector.
Auch hier ist Norddeutschland bis hin zu Hannover sauber:
Und hier sieht das auch identisch aus:
Daher dürfte wohl der alte Plot nicht ganz ok gewesen sein. 
Gruss
walter
Jo,
immer wenn ich etwas Entspannung brauche, putze ich ein wenig. Heute mach ich Freiburg platt:
Gruss
walter
ps: ist ne neue Version der Karte, allerdings noch nicht ganz fertig.
Moin,
so langsam frage ich mich, ob unser Ansatz ok ist:
- alle Adressen mit addr:city, addr:street, addr:postcode und addr:housenumber versehen (addr:country mag ich net)
- fehlende Objekte nachprüfen
- aS-Relationen löschen
Theoretisch reicht es, nur die Hausnummern und Straßen anzugeben und alles andere (Land, Ort, (Stadtteil?) und PLZ) den Auswertern zu überlassen. Für Nominatim stellt das mWN kein Problem dar, sich alle Geoinformationen aus den Daten zu besorgen.
Ich weiss, das wurde schon öfters diskutiert, aber irgendwie hab ich diese Redundanz und die damit verbundene Arbeit satt.
Gruss
Walter
ps: Ich rede natürlich von DACH, wo die Grenzdaten sehr gut erfasst sind. Ok, Suburb und - in der Schweiz - PLZ sind nicht so toll.
edit: Straßen vergessen.
Danach tauchen mit Sicherheit wieder etliche “Krypto-PLZ-Fools” auf, da die as-Relationen ja de facto nie daraufhin überprüft wurden.
* Prozentangaben geschätzt. Wambachers Ergänzung zu spät gesehen, mea culpa!
@gormo: Ich glaube @wambacher meinte, dass nur addr:street und addr:housenumber benötigt werden und alle anderen Angaben sich aus der Geometrie der anderen Objekte ableiten lässt. Ich würde aber diese Diskussion nicht hier führen wollen sondern separat vom Thema associatedStreet-Relation.
Ist zwar schon oft diskutiert worden, aber nochmal:
addr:street ist kaum verzichtbar, da an Ecken, zurückgesetzt u.ä. vom Auswerter nicht automatisch machbar.
Bei city, postcode ist es für die meisten Auswerter (und das Auge) viel leichter, wenn es am Gebäude/POI steht.
Außerdem sind die Grenzen auch in DE nicht in jedem Fall fehlerfrei (s.o.) und Fehler bleiben unentdeckt.
Vom Arbeitsaufwand her ist es für mich fast egal, ob ich ggf. nur Straßen oder auch noch PLZ und Stadt nachtrage. Die meisten Klicks habe ich davor, bis ich alle Objekte mit Rolle “house” in der rechten Spalte des Relationseditors habe.
Ein Blick auf die PLZ-Karte oder Fools hilft da weiter.
Ich kenne in Freiburg einen Fall, wo ich nicht weiss, welche PLZ richtig ist. Da muss ich nochmals ran. Oder es hilft mir wer:
https://wambachers-osm.website/plz/?zoom=18&lat=48.00639&lon=7.85415&layers=BTFFFTFFFFFFT
Münchhofstraße 17
Ansonsten hab ich ein relativ ruhiges Gewissen nachdem ich vor einigen Tagen “ertappt” wurde 
Gruss
walter
ich mach das so:
- Relation im RE öffnen
- alle STREET löschen (bei unübersichtlichen Rels vorher nach Rolle sortieren)
- save (nur lokal)
- im Relationen Fenster: alle Elemente auswählen
Dauer: 3-5 Sekunden
Gruss
walter
Kamener hier anwesend?
Dort gibt’s sehr viele Diffs addr:street am Gebäude vs Relation.
Habt ihr mal die aktuelle Entwicklerversion von JOSM probiert? Die erkennt redundante associatedStreet-Relationen automatisch, warnt und bietet auch eine Ein-Klick-Reparatur (Löschen der Relation) an.
Wenn mich die Karte nicht täuscht, dann habt Ihr Freiburg i.Br. (bis auf unbedeutende Vororte ;)) geschafft. Gratulation!
Persönlichen Dank auch an seichter für das Aufräumen in Markdorf; das war auch so ein as-Nest schlimmster Sorte … Dort wollte ich mal in meinen OSM-Anfängen ein paar Details nach Augenschein korrigieren – ich habe das dann damals schnell wieder gelassen, weil die Daten für mich als Anfänger viel zu unverständlich waren.
Update:
Uff, ich bin jetzt mit Leonberg fertig, das war auch so ein aS-Nest.
Uii, die hab ich glatt übersehen.
Gruss
walter
Neben associatedStreet gibt’s ja auch noch Relationen mit type=street.
Ist das für 'was gut oder kann das auch weg?
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. 