Qualitätssicherung associatedStreet-Relationen

Ich hab mit in meinem südbrandenburgischen Bereich jede einzelne Relation angeschaut. Vor der Erstellung her waren sie mitunter mehrere Jahre alt, nach meiner Einschätzung wurden sie niemals überhaupt gepflegt worden. In der Situation erwarte ich auch nicht, daß ich ggf. eine Antwort vom Ersteller bekommen würde. Sie enthielten in der Regel ein bis zwei Häuser und ein bis zwei Straßensegmente. Die Straße war selten vollständig enthalten. Außer in ein oder zwei Fällen war das Haus zugleich immer nach den addr:* - Schema getaggt. Da wo es Daten zu übertragen gab, hab ich es getan, ansonsten konnten die immer ohne zu Zucken bereinigt werden. Es waren aber auch nicht so viele Relationen und die waren ohnehin sehr verstreut…

Ansonsten meine ich, Bilder sagen mehr als Worte (Danke Andi88 und wambacher):
associatedStreet:

VS
addr:street

Sven

Was hilft es uns jetzt mit einer einmal Aktion das ganze zu reparieren, wenn sich danach wieder keiner drum kümmert?

Die meisten relationen, die ich gefunden habe waren neben dem Terracer-Bug irgendwelche die vor 3+ Jahren erstellt wurden und seitdem nicht mehr angefasst wurden, aber drum herum wurden haufenweise Häuser und Adressen dazugemapped, aber nicht in die relation eingetragen, sondern eben mit addr:street. Die, die komplett waren, habe ich stehen lassen, aber das waren in Bayern ein paar Regionen mit einem dutzend relationen. Keine Ahnung wer mit den Daten etwas anfangen will…

Die exakten Kriterien stehen bei mir jeweils in den Changesets, ebenso wie die Overpass API Query, die zum Vorfiltern benutzt wurde. Diese lauten: es gibt ausschließlich house-Mitglieder als Weg (keine Nodes!) in der Relation, hinter diesen Ways müssen echts Buildings sein, daneben kommen keine anderen Rollenmitglieder wie Street oder auch eine leere Rolle vor. Ebenfalls darf die associatedStreet-Relation ausschließlich das tag type=associatedStreet tragen. Danach wurden die XML-Dateien zunächst sichtgeprüft, ob diese Kriterien auch erfüllt sind und dann erst in JOSM geöffnet und die Relationsmitglieder nachgeladen, diese nochmal geprüft und dann in kleinen Paketen mit einer fest definierten Zahl an Membern gelöscht.

Fragen zur Query beantworte ich natürlich gerne. Ich habe sie auch im Wiki als voll kommentierte Fassung hinterlegt.

Ohne Dir widersprechen zu wollen; aber wenn die bisher keiner repariert (vulgo: vermisst) hat, welchen Nutzen hat sie dann?

50% der relationen kommen wohl aus Frankreich: http://taginfo.openstreetmap.fr/tags/type=associatedStreet

@couchmapper du hattest ja auf der Talk page gefragt wegen QA tools. Soweit ich es von den fr mailingliste herauslese:

http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29
http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR

Doppelter gemoppelt geht wohl nicht:
http://overpass-turbo.eu/s/7iQ
Was rät mir die Community in dem Fall?

Nicht ganz:
Klarastraße 13 und Hindenburgstraße 16 fehlen z.B. in der jeweiligen aS-Relation.
So viel zur Vollständigkeit von aS-Relationen. In DE zumindest sind sie für Anwendungen unbrauchbar.

Solange sie aber keinen Nachteil außer vergeudetem Speicherplatz haben, lohnt sich für mich der Aufwand einer systematischen Beseitigung nicht. Nur wenn ich nebenher auf welche mit Straßensplittern (terracer) oder gar Fehlern stoße, räume ich sie ab.

Können wir beantworten, was das doppelt gemoppelte ist, was überflüssig ist. Die Adressangaben z.B. in http://www.openstreetmap.org/node/3047107651 oder die Relation http://www.openstreetmap.org/relation/3997370

Argument 1 sagt, die vollständige Relation 3997370 erübrige die redundanten Angaben im Node 3047107651
Argument 2 sagt, die Angaben im Node 3047107651 etc erübrige die Relation 3997370

Argument 3 sagt, dass dieser Streit nicht entschieden werden müsse, da beide Tagging-Schemata nebeneinander existieren könnten: sie behindern sich nicht gegenseitig und der gelebte Respekt im Projekt OSM gebiete, konkurrierende/alternative Schemata zu dulden.

Ich bin Anhänger von 2 (und Seichters Posting belegt für mich die Fehleranfälligkeit), habe aber gelernt, dass 3 entscheidend für das Projekt OSM ist.

Was pasiert denn, wenn sowohl nicht alle Buildings/Addr-Nodes in der aS-Rel sind, als auch nicht jede der anderen Adressen den kompletten Karlsruher 5-er Satz enthält? Also ein Teil der Straße so und der andere Teil anders erfaßt ist?

Oder noch schlimmer: wenn sich beide Informationen widersprechen? Wer ist “stärker”? Welche ist dann falsch? Kommen damit “unsere” (Nominatim) als auch “fremde” (osmand, scobbler, …) Anwendungen klar?

Respekt hin und her - aber wenn es zu widersprüchlichen oder falschen Auswertungen komme, was machen wir dann?

Gruss
walter

Da bin ich bei dir, Walter.
Mein Szenario dazu wären irgendwelche Neubauten, die irgendein Mapper nach Karlsruhe-Schema erfasst oder Änderungen von Straßennamen, und schön wäre die schöne Übereinstimmung dahin, wenn die aS-Relation nicht nachgeführt wird. :roll_eyes:

Ich halte es da wie der highlander

Beide Ansätze sind nicht frei von Fehlern und Nachteilen.
Die Hausnummer muss jedenfalls immer an einen Knoten oder Umriss. Beim Beispiel in Rust ist dann nur noch die Straße am Gebäude, der Rest in der Relation. Hier hat man (bis auf die Straße) kein konkurrierendes, sondern ergänzendes Tagging.

Ein Fehler in der PLZ betrifft hier die ganze Straße, leichter gefunden wird er aber vermutlich nicht.
Beim Karlsruher Satz am Gebäude gibt es aber auch Fehler (die Irren lassen grüßen).

Bei Widersprüchen weiß man leider nur eines: Einer von beiden ist falsch.
Wenn nur eine Information vorhanden ist, gibt es zwar keine Widersprüche, aber das ist keine Garantie für Richtigkeit
(auch Highlander können irren).
Der Straßenname kann übrigens viel eleganter in der Relation geändert werden. Das macht sie aber leider auch nicht vollständiger.

Ich klink mich mal aus, da meine Entscheidung steht:

  • wenn ich defekte oder unvollständige aS-Rels finde, kommen die Werte an die Buildings und die aS-rel fliegt raus.
  • wenn ich Widersprüche zwischen den 5-er Adressen und der aS-Rel finde, werden die Buildings falls nötig korrigiert und des aS-rel fliegt raus
  • wenn ich eine klare Minderzahl von aS-rels finde (nur ganz wenige in einer Ecke), kommen die Werte an die Buildings und die aS-rels fliegen raus.
  • wenn die ganze Gegend absolut ok ist, dann lasse ich es so.

Gruss
walter

Wenn ich auf Widersprüche zwischen aS-Relation und addr:street=* am Gebäude stoße, dann ist das eine Einzelfallentscheidung. Eins ist aber klar – einer glaubt dran, entweder die Behauptung der Tags am Gebäude oder die Behauptung der Tags an der Relation. Ich frage dann per Changeset-Diskussionfeature beim Ersteller nach (derzeit warte ich noch auf Antworten in einigen Fälle), wenn ich nicht Logik-basiert entscheiden kann. Ich habe mehrere Fälle gehabt, bei denen ein Eckhaus ein Doppelhaus war und sich die Relationszugehörigkeit des Gebäudes und das addr:street=* am Gebäude widersprachen. Ich habe mal eine Skizze erstellt:

Die Farbe (rot bzw. blau) gibt die Zugehörigkeit zur Straße an. Blaue Ziffer heißt, am Gebäude ist addr:street=Gartenstraße getaggt. Roter Rand heißt, das Gebäude ist Mitglied der associatedStreet-Relation Friedhofstraße. Folglicherweise trugen alle Gebäude ein addr:street=*

Solche Fälle sind mir drei- bis viermal begegnet. Glücklicherweise war die Nummerierung (wie hier im Beispiel) logisch, sodass ich den Tags am Node Glauben geschenkt habe. Ich habe die aS-Relationen dann wegen Widerspruch und unnötiger bzw. gefährlicher Redundanz gelöscht.

Viele Grüße

Michael

Sehe da kein Problem. Wer sagt denn, dass eine aS-Relation alle Häuser einer Straße enthalten muss? Das ist ja KEINE tatsächliche Sammelrelation.

Ich handhabe es so, dass die Angabe am Objekt die Angabe in der Relation überschreibt. Manchmal schaue ich mir auch Widersprüche an und räume auf.

Den Auswertungsprogramm sagen, dass sie in D aS meiden sollen wie der Teufel das Weihwasser - als Beitrag zum Weltfrieden und zur CO2-Vermeidung.

In der Sache sind wir nicht auseinander. Hier in D sind, wohl mangels zentraler Adressimporte, die aS händische erstellte Konstrukte mit allerlei Fehlermöglichkeiten. Wenn ich als Auswerterprogramm also aus Sicherheitsgründen eh zudem addr:* auswerten sollte, dann kann ich aS besser gleich bleiben lassen und mich auf ein Modell konzentrieren. (Vorausgesetzt, ich habe nicht Dateninseln, wo ich diese Angaben nur in aS finde).

Ich habe am Wochenende vielleicht 100 aS-Relationen durchgeflöht und war niedergeschmettert von der Vielzahl der offensichtlich ernstgemeinten Tagging-Varianten (der Krönung war eine Straße, in der einzelne Häuser so getaggt waren: Stadt und PLZ als Node, Straße am way-building, Hausnummer an einem Ecknode des Building, Entrance-Node leer). Wären die Auswerterprogramm Menschen, würde die alle in Therapie sein. Ich habe vielleicht fünf aS gefunden (und stehen gelassen) die >80% vollständig waren. Der Rest war so kaputt (weitestgehend unvollständig, aber auch: mehrere aS für eine Straße, highway=* als house, kein Rolle street, abweichende Adressangaben im Relationsheader …), dass eine Reparatur in keinem Verhältnis zum Aufwand stünde.

In anderen Länder scheint das anders zu sein. Wenn ich die Diskussion auf der Mailingliste richtig verfolgt habe (user polyglot schrieb dort IIRC so etwas), dann kann man das an dem Muster “die Region hat zentrale Adressimporte” festmachen. Da wo das passiert (und hoffentlich auch ab und an aktualisiert wird), empfindet man aS als nützlich bzw. datensparsam und versteht uns wiederum nicht.

Die Auswertungen, die Nakander, Couchmapper und andere gebastelt haben, zeigt in meinen Augen ein bestimmtes Bild: Es gibt in D einige (anscheinend nicht viele) aktive Mapper, die aS benutzen und teilweise “doppelt gemoppelt” taggen - wahrscheinlich unwissend, dass sie sich vergebens Mühe machen. Da reicht es dann doch nicht zu sagen “weg mit dem Scheiß”. Der erste Schritt muss dann sein, diesen Leuten zu erklären, dass das hier in D völlig überflüssig ist. Dann versiegt hoffentlich der Nachwuchs an aS. Zentrale (deutschlandweite) Löschaktionen provozieren nur Stress und Streit.

+1

Genau so sollte es sein - reden, erklären, Wissen schaffen, verändern, gemeinsam das Ziel erreichen. Und: Das Problem an der Wurzel gepackt :wink:

Stefan

Hallo,

ich habe nach vier Tagen wieder eine Relationszählung durchgeführt. Die Ergebnisse sind sehr unterschiedlich. In manchen Ländern meint man, da wäre Entf-Taste hängen geblieben (Sachsen), in anderen scheint sich niemand für das Thema zu interessieren. Ich denke, dass es in Schleswig-Holstein ähnlich viele kaputte Relationen gibt wie in anderen Ländern. Aber seht selbst:


Land                     Ist      Differenz zum 22.01.2014 
---------------------------------------------
Sachsen                   11    -238    -96 %
Mecklenburg-Vorpommern   151    -240    -61 %
Hamburg                  327    -375    -53 %
Brandenburg              486    -425    -47 %
Berlin                   240    -104    -29 %
Bayern                  2534    -847    -25 %
Rheinland-Pfalz         1410    -348    -20 %
Sachsen-Anhalt           350     -76    -18 %
Baden-Württemberg       9503   -1186    -11 %
Nordrhein-Westfalen    21025   -1940     -8 %
Niedersachsen           1695     -52     -3 %
Bremen                   171      -4     -2 %
Thüringen                447      -5     -1 %
Hessen                  4242     -22     -1 %
Saarland                   2       0      0 %
Schleswig-Holstein       276       0      0 %
---------------------------------------------
Summe                 42.870   -5862    -12 %

Viele Grüße

Michael

Mag sich jemand um Freiburg kümmern? Ich stolperte beim Qualitätssichern anderer Daten über dieses schöne Beispiel des Nutzens von associatedStreet-Relationen. 22 Stück, die nur Straßen enthielten, habe ich entsorgt, aber mein Augenmerk liegt eher auf anderen Sachen.

Wenn man nach dem Nutzen fragt kann man gerne 80% der Daten löschen.

CU
Jörg

Wobei dann jeder jeweils andere 80% löschen würde ;).