You are not logged in.

#1 2015-01-24 12:23:05

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,647
Website

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;

Last edited by Nakaner (2015-01-24 14:52:02)


Werdet Mitglied in der OpenStreetMap Foundation für 15 Pfund pro Jahr und bestimmt über die Zukunft der Foundation und des OSM-Projekts mit.
Moderator im Bereich users: Austria.

Offline

#2 2015-01-24 12:33:03

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Qualitätssicherung associatedStreet-Relationen

Nakaner wrote:

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.

Das Rumgefrickele mit der Id finde ich nicht so doll, das geht doch auch besser! Beispiele dafür gibt's zuhauf.

Terracer query wrote:
["^addr:.*$"!~"."]

Das geht so nicht, Negation lässt sich nicht mit regulären Ausdrücken im Key kombinieren. Außerdem fehlt das einleitende "~" vor dem Key, wenn es unterstützt wäre.
So wird ^addr:.*$ nicht als regulärer Ausdruck, sondern einfach als normaler Key angesehen.

Nakaner wrote:

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.

Nakaner wrote:

PS Diese Abfrage habe ich noch nicht ausprobiert.

Das manuelle Suchen ist nicht wirklich notwendig, das macht genau die Query im Wiki: sie ignoriert die Relationen, die einen Way mit Rolle "street" oder auch mit leerer Rolle haben.

Nakaner wrote:

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

donecool (die beiden Freunde da hatte jemand nach dem Aufräumen im letzten Jahr wieder neu angelegt. Die lasse ich mal vorübergehend noch als Andenken an schlechte Zeiten stehen.)

Last edited by couchmapper (2015-01-24 14:01:16)

Offline

#3 2015-01-24 12:40:22

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 9,628

Re: Qualitätssicherung associatedStreet-Relationen

Und, wieviel Promille der Relationen waren korrekt? cool


Mapper aus dem Münsterland/NRW. Nicht auf fakebook.

Offline

#4 2015-01-24 13:02:57

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,647
Website

Re: Qualitätssicherung associatedStreet-Relationen

chris66 wrote:

Und, wieviel Promille der Relationen waren korrekt? cool

In Karlsruhe eigentlich nur alle Relationen im Stadtteil Weiherfeld (ca. 12 Stück). Ich habe sie aber gelöscht, da die Member alle schon addr:street=* hatten.


Werdet Mitglied in der OpenStreetMap Foundation für 15 Pfund pro Jahr und bestimmt über die Zukunft der Foundation und des OSM-Projekts mit.
Moderator im Bereich users: Austria.

Offline

#5 2015-01-24 13:51:35

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Qualitätssicherung associatedStreet-Relationen

Den hier würde ich ja auch einfach löschen: http://www.openstreetmap.org/relation/1946917
Irgendwelche Einwände?

Die Terracer Query in #1 ist übrigens nicht so ganz ok, siehe #2.

Last edited by couchmapper (2015-01-24 14:04:41)

Offline

#6 2015-01-24 14:13:45

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 426

Re: Qualitätssicherung associatedStreet-Relationen

Moin!

Nakaner wrote:

ich habe ja die Debatte entfacht und wambacher und weitere User haben lückenhafte Beispiele und Zahlen für Müll in OSM gezeigt.

Ich kenne die Pro- und Contra-Argumente für associatedStreet-Relationen. Ich nutze sie nicht.
Die Adresssuche funktioniert offensichtlich auch ohne diese Relationen.
Dennoch enthalten sie Informationen, die nur mit "addr:street" nicht vorhanden sind, etwas welche highway-Objekte zu einer Straße gehören.
Manche Fragen wie "Welche Straßennamen kommen doppelt in einer Gemeinde vor?" lassen sich nur oder sehr viel einfacher mit Relationen auswerten.
Ich bin überzeugt, dass wir mittelfristig eine Datenstruktur pro Straße brauchen (ohne dass ich mich auf einen der bisherigen Vorschläge festlegen will).

Vorhandenen Daten zu löschen ohne zumindest die Information über den Zusammenhang der highway-Objekte zu erhalten finde ich falsch.

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
[]
Ich bitte euch, meinem Beispiel zu folgen und in eurer Gegend Selbiges zu tun.

Defekte Daten wie (3)-(6) zu korrigieren oder zu löschen ist natürlich eine gute Tat.
Korrekte Datenstrukturen, die keine Widersprüche verursachen und von vielen Mappern genutzt werden, zu löschen finde ich sehr problematisch.
Dafür ist zumindest ein allgemeiner Konsens im gesamten Projekt, d.h. international nötig.
Ein Meinungsbild in einem Thread des deutschen Forums, in dem es ursprünglich um das Üben von Relationen durch Anfänger ging, genügt nicht.

[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. :-)

Mit diesem Argument könnte man sehr viele Daten in OSM löschen.
Insbesondere könnte man die vielen "addr:street"-Tags löschen, da eine einmalige Speicherung des Namens pro Straße viel Redundanz spart ;-)

Eine Anwendung, die die associatedStreet-Relationen nicht auswertet, dürfte nicht nennenswert betroffen sein.

Offline

#7 2015-01-24 14:16:25

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,647
Website

Re: Qualitätssicherung associatedStreet-Relationen

couchmapper wrote:

Den hier würde ich ja auch einfach löschen: http://www.openstreetmap.org/relation/1946917
Irgendwelche Einwände?

Ich bin für eine Löschung. Dieselben Infos sind ja auch schon an alle Mitglieder (außer ein paar hausnummernlose Gebäude) getaggt. Es geht keine Information verloren.


Werdet Mitglied in der OpenStreetMap Foundation für 15 Pfund pro Jahr und bestimmt über die Zukunft der Foundation und des OSM-Projekts mit.
Moderator im Bereich users: Austria.

Offline

#8 2015-01-24 14:23:42

berndw
Member
From: Erpel am Rhein
Registered: 2011-06-04
Posts: 484

Re: Qualitätssicherung associatedStreet-Relationen

Ich werde die Relationen im Norden von Rheinland-Pfalz übernehmen, aber vorher die Ersteller anschreiben.
Es sind teilweise ausser der Hausnummer keine addr:* gesetzt, ich muss dann alles übernehmen


Mein Fork des AIO-Styles auf GitHub

Offline

#9 2015-01-24 14:33:04

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,647
Website

Re: Qualitätssicherung associatedStreet-Relationen

seawolff wrote:

Moin!

Nakaner wrote:

ich habe ja die Debatte entfacht und wambacher und weitere User haben lückenhafte Beispiele und Zahlen für Müll in OSM gezeigt.

Ich kenne die Pro- und Contra-Argumente für associatedStreet-Relationen. Ich nutze sie nicht.
Die Adresssuche funktioniert offensichtlich auch ohne diese Relationen.
Dennoch enthalten sie Informationen, die nur mit "addr:street" nicht vorhanden sind, etwas welche highway-Objekte zu einer Straße gehören.
Manche Fragen wie "Welche Straßennamen kommen doppelt in einer Gemeinde vor?" lassen sich nur oder sehr viel einfacher mit Relationen auswerten.
Ich bin überzeugt, dass wir mittelfristig eine Datenstruktur pro Straße brauchen (ohne dass ich mich auf einen der bisherigen Vorschläge festlegen will).


Vorhandenen Daten zu löschen ohne zumindest die Information über den Zusammenhang der highway-Objekte zu erhalten finde ich falsch.

Die Anzahl der Banken mit Filiale in Mannheim lässt auch leichter ermitteln, wenn alle Banken eine Relation für alle ihre Filialen haben. smile Ich kann dir da nicht zustimmen. Ob es einen Straßennamen zweimal gibt, kann man nicht eindeutig bestimmen – weder als Mapper, der das street-Relationen festlegt, noch als Auswerter der mit räumlichen Abfragen arbeitet. Ich habe mehrere Straßen jetzt gesehen, die an einer Querstraße enden. Folgt man der Querstraße 10 bis 30 Meter geht die endende Straße weiter (d.h. um der Straße zu folgen biegt man links und gleich danach wieder rechts ab, Beispiel). Genauso unsicher, wie ein Mapper das tut, kann das auch ein Computerprogramm tun. Es handelt sich nämlich um Sammelrelationen, deren Vollständigkeit nie garantiert ist.

seawolff wrote:
Nakaner wrote:

[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. :-)

Mit diesem Argument könnte man sehr viele Daten in OSM löschen.
Insbesondere könnte man die vielen "addr:street"-Tags löschen, da eine einmalige Speicherung des Namens pro Straße viel Redundanz spart ;-)


Es spart Redundanz und erhöht den Aufwand für Auswerter erheblich. Siehe auch die Aussage der Nominatim-Maintainerin Sarah Hoffmann dazu. Der OpenStreetMap Inspector der Geofabrik unterstützt (vermutlich um Rechenleistung zu sparen) z.B. keine associatedStreet-Relationen.

seawolff wrote:

Eine Anwendung, die die associatedStreet-Relationen nicht auswertet, dürfte nicht nennenswert betroffen sein.

Ja, das stimmt. Aber es gibt halt mehr als eine Anwendung die Geocoding macht, z.B. OsmAnd. Ich will nicht wissen, wie zeit- und RAM-intensiv das Erstellen des Adressindex gerade deshalb ist, weil wir in Deutschland noch weit über 15.000 solche Relationen haben.


Werdet Mitglied in der OpenStreetMap Foundation für 15 Pfund pro Jahr und bestimmt über die Zukunft der Foundation und des OSM-Projekts mit.
Moderator im Bereich users: Austria.

Offline

#10 2015-01-24 14:36:36

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,647
Website

Re: Qualitätssicherung associatedStreet-Relationen

berndw wrote:

Ich werde die Relationen im Norden von Rheinland-Pfalz übernehmen, aber vorher die Ersteller anschreiben.
Es sind teilweise ausser der Hausnummer keine addr:* gesetzt, ich muss dann alles übernehmen

In JOSM kannst du die Relation markieren (die Mitglieder sind dann rosa einfärbt) und in der Tag-Liste am rechten Rand (nicht im Relationseditor, sonden im Hauptfenster!) die Tags addr:street=*, addr:city=* usw. markieren, Rechtsklick und auf "Ausgewählte Tags kopieren" klicken. Dann markierst du in der Relationsliste (oder wenn die Relation gerade in der Tagliste aufgeführt wird) die Relation, klickst rechts darauf und klickst auf "Elemente markieren". Nun Bearbeiten -> Tags einfügen. Fertig.

Danach ist die Relation überflüssig.


Werdet Mitglied in der OpenStreetMap Foundation für 15 Pfund pro Jahr und bestimmt über die Zukunft der Foundation und des OSM-Projekts mit.
Moderator im Bereich users: Austria.

Offline

#11 2015-01-24 15:23:30

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,647
Website

Re: Qualitätssicherung associatedStreet-Relationen

Für Duplikatsrelationen habe ich mir auch eine Abfrage gebastelt. Sie sucht alle associatedStreet-Relationen, deren house-Member alle schon mit addr:street=* getaggt sind. Das heißt, die Relation ist unnötig er Ballast.

    /* Hier zunächst die Stadt/Region/etc. festlegen */
    {{nominatimArea:Karlsruhe}}
    (._; )->.area;
     
    /* Alle associatedStreet-Relationen in dieser Stadt ermitteln, die auch ein addr:street=* haben */
    rel[type=associatedStreet]["addr:street"](area.area)->.allASRelationsWAddrStreet;
     
    /* Ermittle alle associatedStreet-Relationen mit addr:street=*, in denen ways mit Rolle "house" vorkommen. 
        Diese Member haben kein addr:street=* */
way["addr:street"!~".*"](r.allASRelationsWAddrStreet:"house");rel(bw:"house")["type"="associatedStreet"]
["addr:street"]->.relationsWithRoleHouseAndWOAddrStreetW;

    /* dto. für Nodes */
node["addr:street"!~".*"](r.allASRelationsWAddrStreet:"house");rel(bn:"house")["type"="associatedStreet"]
["addr:street"]->.relationsWithRoleHouseAndWOAddrStreetN;
     

    /* Jetzt die Differenz aller Mengen bilden */
   ( (.allASRelationsWAddrStreet; - .relationsWithRoleHouseAndWOAddrStreetW;); - .relationsWithRoleHouseAndWOAddrStreetN;);
     
    /* Wege und Nodes dazu und raus damit*/
    (._; >>;);
    out meta;

Werdet Mitglied in der OpenStreetMap Foundation für 15 Pfund pro Jahr und bestimmt über die Zukunft der Foundation und des OSM-Projekts mit.
Moderator im Bereich users: Austria.

Offline

#12 2015-01-24 15:43:30

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Qualitätssicherung associatedStreet-Relationen

Nicht mal auf die Rollen kann man sich verlassen: ein Highway als "house"!?!? http://www.openstreetmap.org/relation/174186

Müssen wir jetzt erstmal validieren, ob die Nodes/Ways in den Membern auch ihrer Rolle entsprechen, bevor wir mit weiteren Queries auf den Daten arbeiten?
Und was ist mit den ganzen Relation Member, die erst gar keine Rolle haben?

Weitere Ungereimtheit: http://www.openstreetmap.org/relation/2092984 -> Wiki sagt: Rolle "street" darf nur Ways enthalten - hier hat aber jemand einen highway=turning_circle Node auch mit Rolle "street" getagt. Das finde ich gar nicht mal so unlogisch...

aS ist echt so ein Murks...

Last edited by couchmapper (2015-01-24 16:22:44)

Offline

#13 2015-01-24 17:34:20

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 426

Re: Qualitätssicherung associatedStreet-Relationen

Nakaner wrote:
seawolff wrote:

Dennoch enthalten sie Informationen, die nur mit "addr:street" nicht vorhanden sind, etwas welche highway-Objekte zu einer Straße gehören.
Manche Fragen wie "Welche Straßennamen kommen doppelt in einer Gemeinde vor?" lassen sich nur oder sehr viel einfacher mit Relationen auswerten.
Ich bin überzeugt, dass wir mittelfristig eine Datenstruktur pro Straße brauchen (ohne dass ich mich auf einen der bisherigen Vorschläge festlegen will).

Vorhandenen Daten zu löschen ohne zumindest die Information über den Zusammenhang der highway-Objekte zu erhalten finde ich falsch.

Die Anzahl der Banken mit Filiale in Mannheim lässt auch leichter ermitteln, wenn alle Banken eine Relation für alle ihre Filialen haben. smile Ich kann dir da nicht zustimmen. Ob es einen Straßennamen zweimal gibt, kann man nicht eindeutig bestimmen – weder als Mapper, der das street-Relationen festlegt, noch als Auswerter der mit räumlichen Abfragen arbeitet. Ich habe mehrere Straßen jetzt gesehen, die an einer Querstraße enden. Folgt man der Querstraße 10 bis 30 Meter geht die endende Straße weiter (d.h. um der Straße zu folgen biegt man links und gleich danach wieder rechts ab, Beispiel). Genauso unsicher, wie ein Mapper das tut, kann das auch ein Computerprogramm tun. Es handelt sich nämlich um Sammelrelationen, deren Vollständigkeit nie garantiert ist.

Dein Vergleich passt nicht. Banken mit gleichem Namen / Operator gehören eindeutig zusammen, highways mit "name=Dorfstraße" in einer Gemeinde manchmal nicht.
Ich behaupte, dass ich als Mensch besser als dein Programm bin. Beweise, dass das Gegenteil. Lass mich gegen dein Programm antreten.
Ein Mapper hat oft weitere Informationen, z.B. Kenntnis alter Gemeindegrenzen oder Zeitungsartikel zu doppelten Straßennamen bei Gemeindezusammenschlüssen.
Selbst wenn dein Programm existieren würde und perfekte Ergebnisse erzielte, müsste es jeder lokal installieren und laufen lassen, um zusammengehörige Straßen zu bestimmen.

seawolff wrote:
Nakaner wrote:

[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. :-)

Mit diesem Argument könnte man sehr viele Daten in OSM löschen.
Insbesondere könnte man die vielen "addr:street"-Tags löschen, da eine einmalige Speicherung des Namens pro Straße viel Redundanz spart ;-)

Es spart Redundanz und erhöht den Aufwand für Auswerter erheblich. Siehe auch die Aussage der Nominatim-Maintainerin Sarah Hoffmann dazu. Der OpenStreetMap Inspector der Geofabrik unterstützt (vermutlich um Rechenleistung zu sparen) z.B. keine associatedStreet-Relationen.

seawolff wrote:

Eine Anwendung, die die associatedStreet-Relationen nicht auswertet, dürfte nicht nennenswert betroffen sein.

Ja, das stimmt. Aber es gibt halt mehr als eine Anwendung die Geocoding macht, z.B. OsmAnd. Ich will nicht wissen, wie zeit- und RAM-intensiv das Erstellen des Adressindex gerade deshalb ist, weil wir in Deutschland noch weit über 15.000 solche Relationen haben.

Jeder Anwender kann frei entscheiden, ob er associatedStreet-Relationen auswerten will, auch Nominatim.
Viele Anwendungen nutzen den Straßennamen in Adressen nicht und würden von kleineren Daten profitieren.
Manche Anwendungen brauchen ganze Straßen als Objekte.

Du kannst erst einmal alle defekten Daten aus (3)-(6) löschen.
Bevor du Daten unter Informationsverlust systematisch löscht, brauchst du m.E. die Zustimmung der Ersteller oder einen allgemeinen Konsens.
Bitte diskutiere dein Vorhaben auf der Tagging Mailingliste bevor du weitere korrekte Relationen entfernst.

Den Aufruf, alle associatedStreet-Relationen zu löschen, als "Qualitätssicherung associatedStreet-Relationen" zu bezeichnen ist ein Euphemismus.

Offline

#14 2015-01-24 17:52:31

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 3,554
Website

Re: Qualitätssicherung associatedStreet-Relationen

chris66 wrote:

Und, wieviel Promille der Relationen waren korrekt?

Ich habe mir Südbrandenburg vor 2 Tagen angeschaut. Es waren eh wenige und es waren alles Fragmente... Eine Straße, ein Haus oder wenige Straßensegmente wenige Häuser. Alle Häuser hatten zudem sie Adresse am Objekt entsprechend dem Karlsruher Schema...

Meiner Ansicht war es kein Verlust auf diese Fragmente zu verzichten...Korrekt und vollständig war keine. Also Ratzeputz.

Sven

Online

#15 2015-01-24 18:12:27

AndiG88
Member
Registered: 2014-01-30
Posts: 474

Re: Qualitätssicherung associatedStreet-Relationen

Knaller sind auch die relationen mit name=street;plz;ort

Kann man irgendwie nach ; in name= filtern?

Offline

#16 2015-01-24 18:29:33

seichter
Member
Registered: 2011-05-21
Posts: 2,725

Re: Qualitätssicherung associatedStreet-Relationen

Wenn ich auf aS-Fragmente und sonstige Datenleichen stoße, entsorge ich sie.
Größere Relationen bearbeite ich nicht, lösche sie aber auch nicht. Wer möchte, darf sie verbessern.

Ein spezielles Beispiel, wo aS ein Problem sogar etwas eleganter lösen:
In Mannheim haben recht oft Eckhäuser zwei Adressen, ob sie auch zwei Eingänge haben, weiß ich nicht.
Der Umriss bekommt deshalb keine Adresse, ich lege dafür zwei Knoten mit je einer Adresse in den Umriss.
Das Haus könnte aber dagegen problemlos Mitglied in zwei aS-Relationen sein, ohne "künstliche" Adressknoten.

Offline

#17 2015-01-24 18:49:20

AndiG88
Member
Registered: 2014-01-30
Posts: 474

Re: Qualitätssicherung associatedStreet-Relationen

Grade festgestellt, dass man mit JOSM sehr einfach Fragmente findet, indem man die overpass daten von einem größeren Gebiet läd und dann steht in Klammern ja immer die member anzahl der relationen... <5 ist da immer ein gutes Indiz und unter 10 ist die Müll quote auch recht hoch. Zudem sieht man auch schnell solchen Spass wie 3 relationen für 1 Straße.

Edit:
Sagte ich 3? http://www.openstreetmap.org/user/AndiG88/diary/34269

Last edited by AndiG88 (2015-01-24 19:26:57)

Offline

#18 2015-01-24 18:53:18

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Qualitätssicherung associatedStreet-Relationen

Ich putze gerade größere Mengen unnütziger aS-Relationen in DE, so wie die hier: http://www.openstreetmap.org/relation/3374004/history
Die Changesets sollten hoffentlich aussagekräftig genug sein, Link zur Query ist jeweils im source-Tag zu finden.

Last edited by couchmapper (2015-01-24 18:54:54)

Offline

#19 2015-01-24 19:04:45

Thomas8122
Member
From: Sachsen
Registered: 2012-04-15
Posts: 1,027

Re: Qualitätssicherung associatedStreet-Relationen

seichter wrote:

Das Haus könnte aber dagegen problemlos Mitglied in zwei aS-Relationen sein, ohne "künstliche" Adressknoten.

Das mag ja sein. Aber die Hausnummer wird ja wohl nicht die gleiche sein.

seichter wrote:

zwei Knoten mit je einer Adresse

Mit der Lösung funktionierts.

Offline

#20 2015-01-24 19:31:20

kartler175
Member
Registered: 2012-09-10
Posts: 253

Re: Qualitätssicherung associatedStreet-Relationen

seawolff wrote:

Dennoch enthalten sie Informationen, die nur mit "addr:street" nicht vorhanden sind, etwas welche highway-Objekte zu einer Straße gehören.
Manche Fragen wie "Welche Straßennamen kommen doppelt in einer Gemeinde vor?" lassen sich nur oder sehr viel einfacher mit Relationen auswerten.

Das ist aber nicht Aufgabe von associatedStreet-Relationen. Und zu diesem Zweck sind sie auch nicht angelegt, deswegen würde ich auch nie diese Relationen für solche Fragestellungen  zweckentfremden. Wenn man glaubt, Fragen socher Art beantworten zu müssen, muss man eben für genau diesen Zweck ein geignetes Tagging-Schem einführen

seawolff wrote:

Insbesondere könnte man die vielen "addr:street"-Tags löschen, da eine einmalige Speicherung des Namens pro Straße viel Redundanz spart

Man sollt sich halt entscheiden, ob man streng nach der Theorie eines relationalen Datenmodells vorgehen will und die damit verbundenen Nachteile  oder pragmatisch die mehrfache Speicherung des gleichen Wertes in Kauf nimmt und damit die Komplexität und den Auswerteaufwand verringert.

Auf Fälle vermeiden sollte man aber, den gleichen Sachverhalt, hier also ein und dieselbe Adresse, auf verschiedene Weise darzustellen und das auch noch gleichzeitig. Es würde viles vereinfachen, wenn man sich auf eine Methode einigen könnte, dann müssten sich weder Mapper noch Datennutzer sich verschieden Herangehensweisen herumschlagen.

seawolff wrote:

Korrekte Datenstrukturen, die keine Widersprüche verursachen und von vielen Mappern genutzt werden, zu löschen finde ich sehr problematisch.

Was wird zerstört, wenn die Informationen aus der Relation in die Einzeladressen übernommen werden und die Relation dann überflüssig ist?

Dafür ist zumindest ein allgemeiner Konsens im gesamten Projekt, d.h. international nötig.

Wenn man sich in D z.B. einigt, auf associatedStreet-Relationen möglichst zu vezichten, warum ist dazu ein allgemeiner Konsens im gesamten Projekt notwendig? Und was ist ein allgemeiner Konsens? Gibt des dazu eine Abstimmung, ist Einstimmigkeit notwendig, ist ein erfülltes Quorum Voraussetzung?

Offline

#21 2015-01-24 21:31:03

seawolff
Member
From: Kiel
Registered: 2008-08-29
Posts: 426

Re: Qualitätssicherung associatedStreet-Relationen

kartler175 wrote:
seawolff wrote:

Dennoch enthalten sie Informationen, die nur mit "addr:street" nicht vorhanden sind, etwas welche highway-Objekte zu einer Straße gehören.
Manche Fragen wie "Welche Straßennamen kommen doppelt in einer Gemeinde vor?" lassen sich nur oder sehr viel einfacher mit Relationen auswerten.

Das ist aber nicht Aufgabe von associatedStreet-Relationen. Und zu diesem Zweck sind sie auch nicht angelegt, deswegen würde ich auch nie diese Relationen für solche Fragestellungen  zweckentfremden. Wenn man glaubt, Fragen socher Art beantworten zu müssen, muss man eben für genau diesen Zweck ein geignetes Tagging-Schem einführen.

Daten für verschiedene Fragestellungen auszuwerten ist keine Zweckentfremdung sondern sinnvolle Nutzung.

seawolff wrote:

Insbesondere könnte man die vielen "addr:street"-Tags löschen, da eine einmalige Speicherung des Namens pro Straße viel Redundanz spart

Man sollt sich halt entscheiden, ob man streng nach der Theorie eines relationalen Datenmodells vorgehen will und die damit verbundenen Nachteile  oder pragmatisch die mehrfache Speicherung des gleichen Wertes in Kauf nimmt und damit die Komplexität und den Auswerteaufwand verringert.

Ich kritisiere nicht diese Entscheidung das "addr:street"-Modell zu nutzen und zu empfehlen. Ich kritisiere die Daten der Mapper, die ein anderes Schema bevorzugen, zu löschen.

Auf Fälle vermeiden sollte man aber, den gleichen Sachverhalt, hier also ein und dieselbe Adresse, auf verschiedene Weise darzustellen und das auch noch gleichzeitig. Es würde viles vereinfachen, wenn man sich auf eine Methode einigen könnte, dann müssten sich weder Mapper noch Datennutzer sich verschieden Herangehensweisen herumschlagen.

Den Vorteil hat man aber nur, wenn man sich international einigt.

seawolff wrote:

Korrekte Datenstrukturen, die keine Widersprüche verursachen und von vielen Mappern genutzt werden, zu löschen finde ich sehr problematisch.

Was wird zerstört, wenn die Informationen aus der Relation in die Einzeladressen übernommen werden und die Relation dann überflüssig ist?

Man übernimmt nur den Straßennamen, nicht die Information, dass die Mitglieder der Relation zum selben Objekt gehören.

Dafür ist zumindest ein allgemeiner Konsens im gesamten Projekt, d.h. international nötig.

Wenn man sich in D z.B. einigt, auf associatedStreet-Relationen möglichst zu vezichten, warum ist dazu ein allgemeiner Konsens im gesamten Projekt notwendig? Und was ist ein allgemeiner Konsens? Gibt des dazu eine Abstimmung, ist Einstimmigkeit notwendig, ist ein erfülltes Quorum Voraussetzung?

Bislang war OSM ein liberales Projekt. Verschiedene Taggingvarianten konnten nebeneinander existieren (solange es keine Widersprüche dazwischen gab). Es war üblich, die Daten der anderen nicht zu löschen.
Wenn jedes Land einzeln entscheidet, nur eine Variante zu dulden und andere zu löschen, zerbricht OSM in nationale Teilprojekte mit unterschiedlichen Regeln. Den Auswertern wäre damit nicht geholfen.

Ich würde für solche Fragen ein Vorgehen analog zur "Mechanical Edit Policy" empfehlen:
You must discuss your proposed changes with the community.
You must not go ahead with your plans if there is noticeable opposition.
As a rule of thumb, you should have 90% of the community behind you when you make the edit.

Das (inoffizielle) Voting "Do you approve the deprecation?" wird kontrovers beantwortet. Eine allgemeine Zustimmung sehe ich nicht. Die letzten Antworten waren eher negativ.

Offline

#22 2015-01-24 22:12:47

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,404
Website

Re: Qualitätssicherung associatedStreet-Relationen

seawolff wrote:

Bislang war OSM ein liberales Projekt. Verschiedene Taggingvarianten konnten nebeneinander existieren (solange es keine Widersprüche dazwischen gab). Es war üblich, die Daten der anderen nicht zu löschen.
Wenn jedes Land einzeln entscheidet, nur eine Variante zu dulden und andere zu löschen, zerbricht OSM in nationale Teilprojekte mit unterschiedlichen Regeln. Den Auswertern wäre damit nicht geholfen.

Wenn ich mir meine "Nische" der Administrativen Grenzen so ansehe, kann ich leider hier auch schon unterschiedliche Philosophien erkennen. genau genommen herrscht da weltweit gesehen ein Drunter und Drüber. Die Bedeutung der Level ist verschieden, wo die Kreis-/Ortsgrenze  in Bezug auf die Coastline ist, welche Tags an den Relationen hängen - alles unterschiedlich.

Wenn es für eine Aufgabe verschieden Modelle gibt, so sind wir in der Lage aufgrund unsere starken Community zumindest bei uns Ordnung zu schaffen, indem wir uns für eines der Modelle entscheiden.

Global Auswerter müssen eh alle Modelle beherrschen (Pech für das Nonminatim-Team), aber unsere lokalen Auswerter haben es ein wenig einfacher.

Das (inoffizielle) Voting "Do you approve the deprecation?" wird kontrovers beantwortet. Eine allgemeine Zustimmung sehe ich nicht. Die letzten Antworten waren eher negativ.

Ja, da hab ich mich heute früh auch ein wenig drüber gewundert. Das Projekt "Wir killen die associatedStreet-Rels" kam zumindest hier im 1. Beitrag so rüber, als weltweit alles in Butter sein. Dass dem nicht so ist, dürfte jetzt wohl dem letzten klar sein.

TL;DR: Wir räumen bei uns auf und lassen die anderen zufrieden.

Gruss
walter

edit: Hier nochmals der Link zur Diskussion im Wiki: https://wiki.openstreetmap.org/wiki/Tal … atedStreet

Last edited by wambacher (2015-01-24 22:19:04)

Offline

#23 2015-01-24 22:57:56

couchmapper
Member
Registered: 2013-02-17
Posts: 462

Re: Qualitätssicherung associatedStreet-Relationen

Nakaner wrote:
 /* Alle associatedStreet-Relationen in dieser Stadt ermitteln, die auch ein addr:street=* haben */
rel[type=associatedStreet]["addr:street"](area.area)->.allASRelationsWAddrStreet;[/quote]

Sorry, dass ich hier schon wieder nitpicking machen muss. Ich dachte, an der aS-Relation selbst müsste der Check auf name statt addr:street laufen, bzw. kann sogar ganz entfallen, da 'name' optional ist. Streng genommen müsste man wohl sogar die street member analysieren und alles was dort an name(:.*) auftaucht gegen die house member matchen (oh je, Denglisch ist böse, i know).

Offline

#24 2015-01-25 15:23:28

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,404
Website

Re: Qualitätssicherung associatedStreet-Relationen

Hi, hier mal einige Grafiken:

tn_associatedStreet_world.png

tn_associatedStreet_europe.png

tn_associatedStreet_europe2.png

Wie zu erwarten und auch zu erkennen ist, liegt der Schwerpunkt in Europa und dort in Frankreich, Belgien und bei uns. Die Ukraine kommt auch noch dazu, aber nicht so stark, wie ich es eigentlich aufgrund deren "NOGO" im Wiki erwartet habe.

Es waren gestern Abend übrigens 213052 Rels - "meint" zumindest meine DB.

Gruss
walter

Last edited by wambacher (2015-01-25 16:33:23)

Offline

#25 2015-01-25 15:27:11

Prince Kassad
Member
Registered: 2013-10-18
Posts: 2,391

Re: Qualitätssicherung associatedStreet-Relationen

Da erkennt man auch schön den Hinterwäldler aus dem Vogelsberg, der die gesamte Gegend mit associatedStreet-Relationen zugekleistert hat. Das regt mich immer wieder auf, wenn ich dort etwas machen will.

Offline

Board footer

Powered by FluxBB