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;

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…

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.

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.

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

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

Kann man irgendwie nach ; in name= filtern?

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.

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

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.

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

Mit der Lösung funktionierts.

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

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.

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

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?

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

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.

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

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

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.

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.

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/Talk:Relation:associatedStreet

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

Hi, hier mal einige Grafiken:

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

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.

Super cool, bitte unbedingt ins Wiki hängen!

Ich glaube, Teile der Hausnummern in Frankreich stammen aus (halb-)automatischen Imports:

http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses
http://cadastre.openstreetmap.fr/?type=adresses

Lustigerweise gibt das Interface sowohl eine addr:street als auch eine associatedStreet-Relation Variante als Ergebnis für den Import her… muss man nicht verstehen :slight_smile:

Im normalen Text oder in der Diskussion?

Habs gemerkt. 0.5 cm mit der bounding box über die Grenze und bäm browser zerschossen :roll_eyes:

Würde fast beides machen. Einmal bei Usage stats und auf talk: eine Neue überschrift.

War mal so frei und habe es im Wiki eingetragen :smiley: