Ich sehe das nicht als Verachtung der Leistung einiger Mapper an, da die Daten eben nicht gelöscht, sondern an die einzelnen Objekte (hier Buildings) übernommen werden. Erst danach kann die dann redundante aS-Rel gelöscht werden.
Haben wir bei den Admin- und PLZ-Grenzen auch so gemacht und dem vorherigen Stand weint keiner auch nur eine Träne nach.
Gruss
walter
Da auf talk-de schon massenhaftes Löschen angesprochen wurde: bitte den Thread hier komplett lesen. Bisher wurden in größerem Umfang nur nutzlose aS-Relationen gelöscht, die das Terracer-Plugin in JOSM erzeugt hat. Verantwortlich dafür war ein Bug, der inzwischen behoben wurde. Damit ist keinerlei Informationsverlust verbunden!
Das Thema wurde sogar auf talk-de angesprochen: bitte dort den letzten Beitrag von Klumbumbus vom 22.01.2015 lesen.
Hi,
Hier ist das wohl etwas anderes. Beim Voting ist die Tendenz eher zu behalten.
Also ich denke mal es ist nur fair gegenüber allen erst das Voting abzuwarten und erst dann Fakten zu schaffen.
Und bisher war es kein Argument wenn Daten redundant vorhanden sind, es sollte hier also auch möglich sein.
CU
Jörg
Ob die Relationen nutzlos sind liegt wohl im Auge des Betrachters. Und wenn ist IMHO reparieren besser wie blindwütiges löschen.
CU
Jörg
Nochmal, es war völlig zweifelsfrei ein Softwarefehler in JOSM. Es gibt da nichts zu reparieren. Das Terracer-Plugin hat einfach Müll produziert.
Als Referenz hier noch der Verweis auf das entsprechende Fehlerticket: https://josm.openstreetmap.de/ticket/10253
Edit: typo.
Ah, Du endscheidest also ob die Daten von dem Bug kommen und nicht von einem Fehler des Mappers?
Bei der Datenbasis würde ich das nicht entscheiden wollen.
CU
Jörg
Hallo Jörg,
Diese Overpass-Abfrage (mit Attic-Feature, die Relationen habe ich alle repariert/gelöscht!) zeigt dir ein paar dieser “Terracer-Relationen”. Die Gebäude haben alle schon Adressen, die Relation selbst enthält keine Information.
Noch so ein Beispiel. Da hat jemand ganz kreativ dieses Plugin für einen Tennisplatz verwendet.
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. 
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:
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