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.

done. 😎 (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.)

Und, wieviel Promille der Relationen waren korrekt? 😎

chris66 wrote:

Und, wieviel Promille der Relationen waren korrekt? 😎

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.

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.

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.

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.

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

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

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.

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

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

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

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.

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.

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?

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.

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

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

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.

wambacher wrote:

Hi, hier mal einige Grafiken:

Super cool, bitte unbedingt ins Wiki hängen!

wambacher wrote:

liegt der Schwerpunkt in Europa und dort in Frankreich und bei uns

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

http://wiki.openstreetmap.org/wiki/Wiki … s_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 🙂

couchmapper wrote:

wambacher wrote:

Hi, hier mal einige Grafiken:

Super cool, bitte unbedingt ins Wiki hängen!

Im normalen Text oder in der Diskussion?

wambacher wrote:

Wie zu erwarten und auch zu erkennen ist, liegt der Schwerpunkt in Europa und dort in Frankreich

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

wambacher wrote:

couchmapper wrote:

Super cool, bitte unbedingt ins Wiki hängen!

Im normalen Text oder in der Diskussion?

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 😄

M.E. die beste differenzierte Betrachtung, die ich bisher gelesen habe:

Polyglot (auf der tagging ML) wrote:

It seems like the biggest issue the proponents of abolishing aS, is that it's hard to keep them up-to-date, and that is where the situation is different over here and in France. Since France (and Spain and the Netherlands too), have access to address data from cadastre.

Exakt das ist der Unterschied: wenn ich fertige Daten importieren kann (siehe #27), stellt sich ein komplett anderes Bild dar. Dann kann ich auch prima mit aS-Relationen Redundanzen vermeiden (was glaube ich hier niemand ernsthaft anzweifelt). Manuelle Updates durch die lokale Community sind wohl eher weniger notwendig und damit gehen auch deutlich seltener die Relationen kaputt. Alles prima.

Anders z.B. in DE: da "vergammeln" die aS-Relationen, sind unvollständig, inkonsistent, verwirren Newbies etc. - denn hier werden die Sachen in der Breite nicht einfach importiert, sondern manuell eingetragen. Und wie es ausschaut, sind die Relationen für einen Masseneinsatz einfach etwas zu fragil. Die Gründe dafür mögen vielschichtig sein, das Ergebnis ist aber nicht ideal.

couchmapper wrote:

Anders z.B. in DE: da "vergammeln" die aS-Relationen, sind unvollständig, inkonsistent, verwirren Newbies etc. - denn hier werden die Sachen in der Breite nicht einfach importiert, sondern manuell eingetragen. Und wie es ausschaut, sind die Relationen für einen Masseneinsatz einfach etwas zu fragil. Die Gründe dafür mögen vielschichtig sein, das Ergebnis ist aber nicht ideal.

Ja, damit triffst du den Nagel voll auf den Kopf:

in DE: unvollständig, instabil, unzuverlässig => nicht verwendbar ==> sinnlos ===> Schrott ====> raus

Gruss
walter

Hi,

ich war bisher der Meinung das, wenn irgendwo Fehler in den Daten sind, die entsprechenden Ersteller angeschrieben und um Verbesserung gebeten werden.

Persönlich empfinde ich es als Verachtung gegenüber den Mappern Daten einfach zu löschen. Es gibt bei OSM mehr wie ein Beispiel dafür, das unterschiedliche Arten zu taggen nebeneinander existieren.
Ich denke das sollte auch bei den aS-Relationen möglich sein.

CU
Jörg

Foxxi59 wrote:

Persönlich empfinde ich es als Verachtung gegenüber den Mappern Daten einfach zu löschen. Es gibt bei OSM mehr wie ein Beispiel dafür, das unterschiedliche Arten zu taggen nebeneinander existieren.
Ich denke das sollte auch bei den aS-Relationen möglich sein.

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

Foxxi59 wrote:

Persönlich empfinde ich es als Verachtung gegenüber den Mappern Daten einfach zu löschen.

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,

wambacher wrote:

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.

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

couchmapper wrote:

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.

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

Foxxi59 wrote:

Ob die Relationen nutzlos sind liegt wohl im Auge des Betrachters. Und wenn ist IMHO reparieren besser wie blindwütiges löschen.

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.

couchmapper wrote:

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,

Foxxi59 wrote:

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.

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.

Foxxi59 wrote:

Bei der Datenbasis würde ich das nicht entscheiden wollen.

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

Foxxi59 wrote:

Und wenn ist IMHO reparieren besser wie blindwütiges löschen.

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

Foxxi59 wrote:

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.

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.

Foxxi59 wrote:

Ob die Relationen nutzlos sind liegt wohl im Auge des Betrachters. Und wenn ist IMHO reparieren besser wie blindwütiges löschen.

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/ty … atedStreet

@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/Wiki … %28BANO%29
http://wiki.openstreetmap.org/wiki/FR:K … FR:FANTOIR

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

hurdygurdyman wrote:

Doppelter gemoppelt geht wohl nicht:

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.

Swen Wacker wrote:

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

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

wambacher wrote:

Swen Wacker wrote:

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

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

wambacher wrote:

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?

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

wambacher wrote:

Swen Wacker wrote:

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

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?

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

wambacher wrote:

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?

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.

wambacher wrote:

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

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.

Swen Wacker wrote:

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

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.

MKnight wrote:

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

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

CU
Jörg

Foxxi59 wrote:

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

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

seichter wrote:

Foxxi59 wrote:

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

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

Das streite ich nicht ab..

CU
Jörg

Hi,

nachdem jetzt auch vollständige und den Regeln entsprechende aS-Relationen gelöscht wurden habe ich die DWG informiert.

CU
Jörg

Foxxi59 wrote:

Hi,

nachdem jetzt auch vollständige und den Regeln entsprechende aS-Relationen gelöscht wurden habe ich die DWG informiert.

CU
Jörg

wo? Wurden die Daten vorher an die Buildings übertragen? Waren es gar "deine"?

Gruss
Walter

Zum ersten Post: Ich glaube prominent (Nr. 1) Tipps zu geben wie man vollständige Relationen umstellt ist unglücklich und wird einigen auf den Schlips treten.
Auch Nr. 2 mit unvollständigen Relationen sollte nicht mit "Kaputtes pflege ich nicht" einfach gelöscht werden. Hier kann man doch gern alles mit addr:street taggen, kann die Relation aber doch belassen. Zwischen nicht pflegen und löschen ist ein weiter Weg. Was macht es denn aus wenn sie so unvollständig da drin ist? Ich hab in Stuttgart mal alle Relationen ohne street-Member gelöscht. Dabei werde ich es aber belassen.

Wer auch immer die aS Relationen, die ich im letzten Jahr gelöscht habe vermißt, möge sich doch hier bitte mal melden.

Baßtölpel

Basstoelpel wrote:

Wer auch immer die aS Relationen, die ich im letzten Jahr gelöscht habe vermißt, möge sich doch hier bitte mal melden.

Dito,

mir gingen '13/'14 auch viele auf den Keks. '15 war ich aus Zeitgründen aber noch "lieb" 😉

Gruss
walter

wambacher wrote:

wo? Wurden die Daten vorher an die Buildings übertragen? Waren es gar "deine"?

Ich sehe 4 Reverts mit 6 wiederhergestellten aS-Relationen. Auf den ersten Blick (Stichprobe) wurden die Sachen zuvor sauber auf die Buildings übertragen.

couchmapper wrote:

wambacher wrote:

wo? Wurden die Daten vorher an die Buildings übertragen? Waren es gar "deine"?

Ich sehe 4 Reverts mit 6 wiederhergestellten aS-Relationen. Auf den ersten Blick (Stichprobe) wurden die Sachen zuvor sauber auf die Buildings übertragen.

Jetzt kann ich den Ärger verstehen: hatten wir uns nicht - zugegebenerweise stillschweigend - darauf geeignet,. dass die Aktion nur bei uns stattfinden soll? Oder zählt Luxemburg etwa auch mit?

Wenn, dann bitte auch noch das Elsass dazu 😠

Gruss
walter

edit: Zurückgezogen.

wambacher wrote:

couchmapper wrote:

wambacher wrote:

wo? Wurden die Daten vorher an die Buildings übertragen? Waren es gar "deine"?

Ich sehe 4 Reverts mit 6 wiederhergestellten aS-Relationen. Auf den ersten Blick (Stichprobe) wurden die Sachen zuvor sauber auf die Buildings übertragen.

Jetzt kann ich den Ärger verstehen: hatten wir uns nicht - zugegebenerweise stillschweigend - darauf geeignet,. dass die Aktion nur bei uns stattfinden soll?

Das "Voting" und die Diskussion zur Deprecation im Wiki haben das impliziert, ja.

ähm, die Sachen sind in Wittlich, nicht in LUX.

couchmapper wrote:

ähm, die Sachen sind in Wittlich, nicht in LUX.

Jau!

Tut mir leid, aber da ist mein jugendlichen Eifer wieder durchgebrochen 🙁

Hallo,

hat jemand Lust, in Düsseldorf einige falsche Relationen zu löschen?

Dort gibt es Hausnummerobjekte mit korrekter addr:street (z.B. Gebäude mit addr:street="Elsa-Brändström-Straße" mit way id #88715197), dieses und einige andere Objekte sind aber auch noch in einer associatedStreet Relation, in diesem Beispiel in einer mit dem Namen "Elsa-Brändström-Straße 20-42".

Die Liste der Fehlerkandidaten kann in meiner Düsseldorfer Gesamtauswertung gefunden werden [1], dort in die Spalte "Anz. nur in OSM" einmal klicken und nach dem sortieren nocheinmal, damit andersherum sortiert wird. Dann kommen zuerst die "Straßen", die keinen offiziellen Treffer haben.

Noch besser wäre natürlich eine passende Overpass Abfrage, die nach einer Zahl im Name einer associatedStreet Relation innerhalb Düsseldorf sucht, aber die kann ich zumindest nicht erstellen.

viele Grüße

Dietmar

[1] http://regio-osm.de/hausnummerauswertun … BCsseldorf

Hallo,

bitte noch nicht die falschen Relationen in Düsseldorf entfernen, ich schreibe erstmal den User an.

viele Grüße

Dietmar

okilimu wrote:

Noch besser wäre natürlich eine passende Overpass Abfrage

Folgende Abfrage für overpass turbo liefert associatedStreet-Relationen, deren name-Wert andere als die angegebenen Zeichen enthält oder wo das name-tag fehlt. Die Ergebnisse können nach JOSM exportiert werden.

<osm-script␣output="xml">
<union>
<query␣type="relation">
<bbox-query␣{{bbox}}/>
<has-kv␣k="type"␣v="associatedStreet"␣/>
<has-kv␣k="name"␣regv="^[-A-Za-zÄÖÜäöüß␣\.\']{1,}$"␣modv="not"/>
</query>
</union>
<union>
<item/>
<recurse␣type="relation-relation"/>
</union>
<union>
<item/>
<recurse␣type="down"/>
</union>
<print␣limit=""␣mode="meta"/>
</osm-script>

Hallo zusammen,

die Sache mit den von mir vor Jahren in Düsseldorf erstellten Relationen habe ich gestern schon mit Dietmar geklärt. Allerdings sollte folgender Punkt vielleicht noch einmal ins allgemeine Gedächtnis zurückgerufen werden:
associatedStreet-Relationen konnten laut Definition im Wiki (http://wiki.openstreetmap.org/w/index.p … did=480213) bis zum 3. Mai 2011 nur ein Mitglied des Typs "street" haben. Mehr streets wurden von JOSM seinerzeit auch als "falsch" gemeldet. Ab 2011 hieß es dann im Karlsruher Schema dass "one ore more" Mitglieder des Typs "street" existieren können. Entsprechend war die Art und Weise wie ich die Relationen seinerzeit angelegt hatte ab diesem Zeitpunkt zwar unnötig, aber nicht falsch und sind es imho bis heute nicht, denn im Wiki steht nirgends geschrieben, dass es nicht mehrere Relationen für gleichnamige Straßenabschnitte geben kann.
Gleichwohl benutze ich selbst seit geraumer Zeit asscoiatedStreet-Relationen nicht mehr, da ich auch der Meinung bin, dass sie keinen Mehrwert gegenüber den addr-Tags bringen. Entsprechend werde ich die fraglichen Relationen in den nächsten Tagen löschen.

Beste Grüße aus Düsseldorf

Alex