Qualitätssicherung associatedStreet-Relationen

Hallo,

ich habe ja die Debatte entfacht und wambacher und weitere User haben lückenhafte [url=]Beispiele und Zahlen für Müll in OSM gezeigt. Das habe ich gestern Abend und heute Morgen zum Anlass genommen, mal zu schauen, wie schlimm es ist. Ich habe gestern im den Stadt- und Landkreisen Karlsruhe und Heilbronn nach den associatedStreet-Relationen gesucht und jede einzelne manuell gesichtet. Ich möchte euch in diesem Beitrag von meinen Beobachtungen (es gibt keine genauen Messwerte, alles Gefühl/Schätzung/subjektive Eindrücke) schildern.

Um alle associatedStreet-Relationen eines Gebiets zu finden, nimmt man folgende Overpass-API-Abfrage. Das Beispiel zeigt den Landkreis Böblingen. Für einen anderen Landkreis muss man die Grenzrelations-ID austauschen. Das ist die ID der Grenzrelation in OSM addiert mit der Konstante 3600000000. Die ID der Grenzrelation kann man mit der Suchfunktion auf osm.org ermitteln und wird dann ganz groß angezeigt.

[out:json][timeout:25];(␣relation["type"="associatedStreet"](area:3600062721););out␣body;>;out␣skel␣qt;

Es empfiehlt sich nur auf Landkreisebene abzufragen, wenn man in einem Bundesland mit vielen Treffern arbeitet (z.B. Baden-Württemberg). Sonst stürzt euch der Browser ab bzw. wird unbedienbar. Ich empfehle (entgegen meiner Pro-Firefox-Haltung) für den Overpass-Turbo Chromium/Chrome.

Für die Stadt- und Landkreise Karlsruhe und Heilbronn war das mein Vorgehen. Grafisch habe ich mir im Overpass-Turbo einen Überblick verschafft und die Relation mit einem Blick in eine der folgenden Kategorien eingeteilt:
(1) vollständige Relation, die alle Häuser der Straße enthält. Konvertierungstipps siehe unten.
(2) Relation, die viele, aber nicht alle Häuser der Straße enthält -> Die leidet am Sammelrelationssyndrom und habe ich sogleich durch addr:street an den Gebäude ersetzt und die Relation gelöscht. Kaputtes pflege ich nicht, wenn es einfacher (d.h. ohne Relationen) geht. Konvertierungs-/Reparaturtipps siehe unten.
(3) Terracer-Unfälle. Das Terracer-Plugin hat associatedStreet-Relationen erzeugt, die nur mit type=associatedStreet getaggt waren (keine weiteren Tags!). Man erkennt sie in der Relationsliste in JOSM (Alt+Shift+R) daran, dass sie als "Zugeordnete Straße (<ID>, 3 Elemente)" aufgeführt werden. Hätte die Relation ein name-Tag, würde statt ID der Straßenname in der Relationsliste stehen. Zur Reparatur siehe unten.
(4) Widerspruch zwischen Relation und addr:street=* an den Gebäuden. Tritt gern auf, wenn Eckhäuser, mit Terracer in zwei Doppelhaushälften geteilt wurden und eine Hälfte zur einen und die andere Hälfte zur anderen Straße gehört.
(5) Tennisplätze, z.B. http://overpass-turbo.eu/s/7e6 (kreativer Gebrauch des Terracer-Plugins)
(6) Abstruse Sonderfälle, z.B. http://overpass-turbo.eu/s/7e7

Nun zur Reparatur
(1) Vollständige Relationen umstellen
Das sollte man nur tun, wenn alle Mitglieder addr:street=* haben (dann ist die Relation nämlich überflüssig und belastet nur die Datennutzer und die Umwelt [1]) oder es sich um ein Gebiet mit freien Bauplätzen handelt, d.h. wo künftig noch neue Hausnummern hinzukommen und vermutlich wegen Unkenntnis nicht zur Relation hinzugefügt werden.

Um zu prüfen, ob alle Gebäude-Mitglieder der Relation ein addr:street=* haben öffnet man den Relationseditor für diese Relation und schaut die Mitgliederliste durch. Wenn das Mitglied ein addr:street=* hat, dann wird es als "Hausnummer 41 in Motorstraße" aufgeführt. Wenn das Mitglied amenity- oder shop-Tags hat, steht ggf. etwas anderes dran, dann muss man manuell prüfen (Rechtsklick auf den Eintrag -> Zoomen auf Objekt).

Man sollte auch prüfen, ob alle Mitglieder denselben Wert in addr:street=* stehen haben. Dazu alle entweder im Relationseditor alle Gebäude markieren und dann im Frame "Auswahl" auf das zweite Icon von unten "Wählen Sie Objekte für die ausgewählten Relationsmitglieder" klicken. Nun sind diese ausgewählten Relationsmitglieder die Auswahl im JOSM-Hauptfenster. Wenn in der Tag-Liste addr:street=<unterschiedlich> steht, dann ist ein Tippfehler drin, den man iterativ suchen kann (nach und nach einzelnen Gebäude aus der Auswahl ausnehmen). Wenn in der Tag-Liste addr:street=Motorstraße steht, ist alles in Ordnung.

Hat die Relation auch andere addr:street-Tags wie z.B. addr:postcode oder addr:city, sollte man sicherstellen, dass auch alle Mitglieder diese Tags haben, bevor man die Relation löscht. Gegebenenfalls ergänzt man fehlende Tags an den Mitgliedern.

Es gibt auch noch ein Verfahren, ohne den Relationseditor zu benutzen. Dazu muss man die Relation in der Relationsliste finden, den Eintrag markieren und dann im Kontextmenü des Eintrags auf "Elemente auswählen" klicken. Die Relation muss vorher vollständig heruntergeladen sein (geht auch über dasselbe Kontextmenü mit "Unvollständige Mitglieder herunterladen"). Mit gedrückter Strg-Taste entfernt man nun alle Straßen aus der Auwahl (meistens sind das nur ein bis vier Straßensegmente) und stellt sicher, dass in der Tag-Liste kein addr:street=<unterschiedlich> aufgeführt wird.

Die Relation löscht man wie folgt: Wenn sie gerade in der Tag-Liste aufgeführt wird, weil eines ihrer Member markiert ist, klickt man rechts auf den Eintrag und wählt "In Relationsliste auswählen", dort klickt man auf das Papierkorb-Symbol.

(2) Relation, die viele, aber nicht alle Häuser der Straße enthält
Zuerst stellt man sicher, dass alle ihre Mitglieder mindestens mit addr:street=<Straßenname> getaggt sind. Wenn alle Gebäude-Mitglieder der Relation ausgewählt sind (Methode siehe Abschnitt Fall (1)), sollte in der Tag-Liste kein addr:street=<untrschiedlich> stehen. Dann ist entweder die Relation nicht vollständig heruntergeladen oder ein Mitglied hat einen anderen Straßennamen (siehe auch Fall (5)) oder ein Mitglied hat kein addr:street=*. Wenn jedes Mitglied addr:street=<Straßenname> hat, dann kann man die Relation löschen. (siehe Fall (1))

(3) Terracer-Unfälle
Dafür empfehle ich folgende Overpass-Abfrage (Beispiel für Landkreis Ludwigsburg, den ich heute morgen davon bereinigt habe):

[out:json][timeout:25];(␣relation["type"="associatedStreet"]["name"!~"."]["^addr:.*$"!~"."](area:3600062536););out␣body;>;out␣skel␣qt;

Bitte EDIT am Ende dieses Beitrags beachten!

Einfach das Gebiet zoomen, wo Treffer im Overpass-Turbo angezeigt werden, und dieses Gebiet in JOSM herunterladen. In der Relationsliste tauchen nun Einträge wie "Zugeordnete Straße (<ID>, 3 Elemente)" auf. Wenn man das Kontextmenü eines dieser Einträge aufruft und "Elemente auswählen" klickt, werden diese markiert. Mit der Taste 3 (auf Auswahl zoomen) zoomt man Auswahl. Ist keine Straße in der Relation enthalten, kann man sie löschen. Dazu in der Relatiosliste auf das Papierkorb-Symbol klicken.

Meist findet man in einem Wohngebiet mehrere solcher Exemplare. Dann wurde es von einem Mapper gemappt, der das Plugin mochte.

Ich habe auch von Terracer verursachte associatedStreet-Relationen gefunden, deren Mitglieder keine Adressen (Hausnummern hatten). Da die Relation keine Straße enthielt, habe ich die Relationen einfach gelöscht.

(4) Widerspruch zwischen Relation und addr:street=* an den Gebäuden
Hier ist Nachdenken angesagt. Wenn der Widerspruch an einem Doppelhaus auftritt, schenke ich den addr:street=*-Tags am Gebäude mein Vertrauen und lösche die Relation (siehe oben). Wenn der Widerspruch an anderen Stellen auftritt, frage ich per Changeset-Kommentarfunktion nach. Mittlerweile ist der Botlauf fertig, sodass man für seine Changesets aus Urzeiten noch Benachrichtigungsmails über Kommentare erhält. Ich richte mir in Thunderbird-Lightning für jeden kommentierten Changeset eine Aufgabe ein, um nach einer Woche selbst Hand anzulegen, wenn der Mapper nicht antwortet. Sollte ein Mapper in solch einem Fall nicht antworten, kann man entweder den Tags am Gebäude Vorrang geben oder beide Adressen eintragen oder eine OSM-Note anlegen oder nochmal nachhaken.

(5) Tennisplätze
Diese Relation habe ich gelöscht. Methodik siehe oben.

(6) Abstruse Sonderfälle
Diese Relation habe ich aufgelöst. Methodik siehe oben.

Ich bitte euch, meinem Beispiel zu folgen und in eurer Gegend Selbiges zu tun.

In der Stadt Karlsruhe habe ich gefühlt die Hälfte der Relationen in die Kategorien (2) und (3) einteilen können und durch einfacheres Mapping ersetzt. Der Rest der Relationen fiel in die Kategorie (1) und wurde von mir ebenfalls meistens gelöscht. Im Landkreis Karlsruhe habe ich einige Relationen stehen lassen, da sie vollständig waren und die Gebäude kein addr:street=* trugen. Im Landkreis Heilbronn habe ich ca. 95 % gelöscht, 1 Relation gibt es jetzt noch in Weisberg. Im Stadtkreis Heilbronn gab es nur zwei Relationen, den Tennisplatz und eine unvollständige. Im Landkreis Ludwigsburg (besonders Raum Gerlingen) gibt es noch viel zu tun. Den größten Müll (kaputte Relationen, d.h. Fall 2–4 und 6) habe ich aber schon weggeräumt.

Viele Grüße

Michael

PS Diese Abfrage habe ich noch nicht ausprobiert.

[1] Durch Erhöhung des Rechenaufwands für Auswerter wie Nominatim werden mehr Treibhausgase für die Erzeugung elektrischer Energie und die Kühlung der Rechenzentren ausgestoßen. :-)

EDIT: Bessere Query nach Terracer-Unfällen:

[out:json][timeout:25];(␣relation["type"="associatedStreet"]["name"!~"."]["addr:street"!~".*"](area:3600062536););out␣body;>;out␣skel␣qt;