Bin schon wieder zu blöd: Wie voted man im Wiki? Muss ich da einen vorhandenen Eintrag klonen und anpassen oder gibt es irgendwo einen Knopf?
Thanks for doing this, associatedStreet relations are really irritating during editing and duplicating address tags gives no benefit.
Auf Bearbeiten gehen und dann
{{vote|yes}} OPTIONAL MESSAGE HERE --~~~~
{{vote|no}} YOUR REASONS HERE --~~~~
{{vote|abstain}} YOUR COMMENTS HERE --~~~~
Du schreibst auf die Diskussionseite unten
{{vote|<wasauchimmer>} --~~~~
. Klone also eineen bestehenden Eintrag, ersetze alles hinter “–” durch “~~~~”, dann kommt deine Signatur hintendran (du musst natürlich im Wiki angemeldet sein). Dann Vorschau drücken, gucken wies aussieht, dann absenden.
Wenn du was bei dir aufsetzt, dann nimm das leaflet-plugin “leaflet-layer-overpass”, das kann das.
Für mich würde eine solche Overpass-Query tatsächlich ausreichen. Alles, was diese (noch nicht existente) Abfrage zu tage führt, könnte direkt gelöscht werden.
Scheint sich erledigt zu haben. In der Tat ist unser Abstimmungsprozess nicht sehr Anwenderfreundlich. In andern Foren muss man nur einen Knopf drücken. 
@dkdue: schreibste noch den Termin rein?
@christ66: Datum ist jetzt drin.
Nö, ich kann keine Overpassisch - und will es auch garnicht lernen. Hab genug Programmier- und Querysprachen im Kopf 
Sowas mach ich mit dem GeoServer, der sich die Daten aus der PostgreSQL/PostGIS-DB lutscht und als Layer zur Verfügung stellt
Gruss
walter
Ich fände es super, wenn Du ein solches Werkzeug zur Verfügung stellen könntest. Toll wäre, wenn es neben der Existenz der Relation eben noch darstellen könnte, ob diese
- vollständig redundant
- teilweise redundant
- widersprüchlich zu addr:street
ist.
Wie war das nochmals mit dem “kleinen Finger”?
Bin schon froh, wenn ich das einigermaßen performant hinbekomme. An Objekte, die Member einer Relation sind, ist nämlich nicht so leicht ranzukommen.
Warum fängst Du nicht mit der Relation an?
Hier die umgekehrte Overpass Abfrage, nämlich alle Objekte in associatedStreet ohne addr:street
// building + nodes in associatedStreet w/o addr:street in PLZ Bereich
[out:json][timeout:125];
// get boundary and convert to area
relation["postal_code"=71034];
map_to_area->.PLZ ;
// get all associatedStreet relations in that area
(relation["type"="associatedStreet"](area.PLZ);>;)->.as;
// get all buildings and node w/o street in those relations
(way.as[building][!"addr:street"];
node.as["addr:housenumber"][!"addr:street"];);
out body;>;out skel qt;
Wenn die Abfrage leer wird, kann man alle associatedStreet in dem PLZ Bereich löschen.
Hi, ich hab mal die allererste Version fertig gestellt zusammengekloppt: https://wambachers-osm.website/associatedStreet/
Da fehlt noch einiges aber zumindest umsehen kann man sich damit schon mal. Morgen kommt noch einiges dazu.
Gruss
walter
Das ist doch zur Übersicht schon einmal sehr schön! Danke! Ich habe mir die associatedStreets bisher per Overpass-Abfrage „geangelt“, aber das ging nur landkreisweise, ganz Baden-Württemberg auf einmal war etwas viel. Daher ist Deine Visualisierung zur Übersicht viel praktischer …
Sehr schön sieht man jetzt die „Nester“ von associatedStreets, die oft nur auf einzelne, besonders engagierte Mapper zurückgehen …
Umgekehrt sieht man auch sehr schön, wo associatedStreets nur ganz fragmentarisch vorkommen und mMn schon deshalb entfernt werden sollten (natürlich immer erst nach Redundanz-Prüfung!).
Danke! Das ist schon mal super!
Der Landkreis Tübingen ist nun frei von associatedStreet-Relationen.
Hier noch ein paar Beobachtungen, für den Fall, dass es Schwierigkeiten mit der deprecation von associatedStreet-Relationen in Deutschland geben sollte. 
Als Argument für die Verwendung von associatedStreet-Relationen wurden ja v.a. immer wieder angeführt:
(1) Redundanzvermeidung: Nicht nur der Straßenname, sondern auch PLZ u.a. Daten könnten in der Relation erfasst werden statt an jedem einzelnen Gebäude. An sich klingt das gut, und wenn das irgendwo auch so gemacht wird, dann ist das schön! Ich habe aber in den Landkreisen HN, LB und MOS an keiner einzigen associatedStreet-Relation irgendwelche derartigen Daten gefunden – überall waren nur die Tags type=associatedStreet und name=* vorhanden. Pfff …
(2) Mehrsprachigkeit: Es soll einfacher sein, mehrsprachige Straßennamen zu erfassen, indem diese in der Relation erfasst werden statt in addr:street=. Auch hier gilt: An sich klingt das gut, und wenn das irgendwo auch so gemacht wird, dann ist das schön! Es gibt aber zumindest in Deutschlands zweisprachigen Gebieten durchaus associatedStreet-Relationen, wo ausgerechnet dieser Vorteil gar nicht genutzt wird. Z.B. in dieser Relation gibt es nur *name=, das interessante zweite Tag name:hsb= gibt es nur an den Straßensegmenten. Pfff …
Kurz: Beide Argumente klingen erst mal gut, aber zumindest in Deutschland werden diese Stärken von associatedStreet-Relationen oft gar nicht genutzt. Ihr angeblicher Vorteil gegenüber der Erfassung mit addr:-Tags ist aber auf jeden Fall null und nichtig, wenn diese Stärken nicht genutzt werden; dann bleiben nur noch die zahlreichen Nachteile von associatedStreet-Relationen übrig. 
Und was wird da nun angezeigt? Alle Relationen, die redundant sind?