associatedStreet-Relationen entfernen?

Nö, das ist “einfach so” passiert. Kommt bei älteren Leitungen (~40 Jahre?) und feuchter Umgebung schon mal vor. Ca 100-200 Meter weiter sehen die Messwerte auch nicht gut aus (Leckströme?) und daher wird am Do (21.3.) dort gebuddelt. Werde die Rechner dann erneut ausschalten müssen. (*)

Gruss
walter

*) Passt eigentlich ganz gut zum Uploadfilter-Tag :wink:

Ich sehe mir diese highway=service dann einzeln an. Manchmal zeigt sich, dass es sich eigentlich um highway=residential handelt; dann tagge ich diese um in highway=residential, versehe sie mit dem Namen und ggf. mit lanes=1.

Wenn es sich dagegen um tatsächlich highway=service handelt, dann läuft das auf die alte Frage hinaus, ob solche highway=service den Namen der Straße bekommen sollen, von denen sie abzweigen. Dazu hatten wir irgendwo schon einen Thread (oder mehrere), ich finde ihn nur gerade irgendwie nicht …

Ja, das Wiki zu aS ist relativ präzise. Vielleicht hat der Mapper auch type=street gemeint?

OK, würde ich auch erwarten. Dann lag ich da richtig, diese aS in JOSM nicht als obsolet zu markieren.
Aber sollte JOSM dann für solche aS eine andere, neue Warnung produzieren?

Hi,

hab der aS-Karte 2.4.1 ein weiteres Layer spendiert:

Auf Wunsch werden die Admin Boundaries mit AL8 angezeigt. Damit kann man sehen, ob man den “Ort der Begierde” verlassen hat. Ich versuche, komplette Ortschaften zu bereinigen, und das hilft mir dabei.

Gruss
walter

Hier mein Workflow:

  1. Eventuell fehlende Mitglieder der Relation nachladen
  2. Konsistenzchecks
  3. Löschen

Mit JOSM ab r14906 (josm-latest.jar) geht es deutlich einfacher:

  • alle aS Relationen auswählen
  • Prüfung laufen lassen
  • Warnung “Relation is obsolete” (bisher noch nicht eingedeutscht) auswählen und Reparieren anklicken
    Was dann noch an aS existiert bedarf einer genaueren Prüfung.

Danke, werde ich testen. :slight_smile:

Lädt der Check automatisch fehlende Mitglieder nach?

@GerdP: Super, dass es jetzt diese integrierte und assistierte Möglichkeit gibt. Hängen an der Relation aber noch mehr Tags als nur name und type, so wird diese nicht als redundant ausgegeben. Eventuell kann hier eine Verfeinerung auf die dort üblichen addr:-Tags noch deutlich mehr Unterstützung bringen.

Ja, man könnte abgleichen, ob die role=house Member die gleichen Tags haben und die role=street entsprechend andere, aber da wird es halt dann auch schon komplizierter. Soll dann aus addr:city ein is_in:city werden? Kann man alles programmieren, aber die meisten aS würden dann auch nicht als obsolet erkannt. Daher habe ich es bewußt einfach gehalten.
Wenn JOSM sagt, dass die aS obsolet ist, dann kann man sie löschen. Wenn nicht, dann kann man sie nach Kontrolle evtl. auch löschen.
Eine Verbesserung steht aber noch an: Im Moment führt eine Relation als Member dazu, dass JOSM die Relation nicht mehr als obsolet erkennt. Das werde ich noch ändern, so dass ein role=house Multipolygon wie jedes andere building ausgewertet wird.

@GerdP: Ich finde es richtig, so wenig Komplexität wie möglich reinzubringen und die Prüfung so zu gestalten, dass sie im Zweifel als nicht-redudant ausgibt. In Freiburg beispielsweise sind fast alle associatedStreet-Relationen mit addr:-Tags versehen (die dort auch nicht drangehören sondern an die Häuser) und können so leider nicht als redundant erkannt werden.

Was machen wir denn mit den (deutlich selteneren) Relationen mit type=street?

Diejenigen, die ich hier (Landkreis LB, Stadt- und Landkreis HN) finde, könnte man fast schon superredundant nennen: Sie enthalten jeweils nur Straßenabschnitte und als Tags (neben type=street) allein den Straßennamen. Ihr einziger Zweck ist also, die Zusammengehörigkeit der Straßenabschnitte auszudrücken. Das ist ja nett, aber … es geht doch auch ohne, wie die zahllosen anderen Straßen in OSM zeigen, die trotz mehrerer Teilabschnitte ohne eine solche „Wir gehören zusammen!!!“-Relation auskommen. Gebäude o.Ä. sind nie(*) mit enthalten, es gibt keine Rollen. Also irgendwie alles recht witzlos und noch redundanter als die redundanteste associatedStreet-Relation.

Kurz: Ist das Kunst oder kann das weg?

(*) Bis auf eine einzige Ausnahme, soweit ich sehe, und sogar die ist komplett redundant, was die Adressdaten etc. angeht.

@Chrysopras: Ich bin der Meinung, dass diese auch entfernt werden sollten, würde aber ungern in die laufende Abstimmung eingreifen. Ich denke, wenn am Ende der Abstimmung herauskommt, dass type=associatedStreet entfernt werden sollte, dann starten wir dasselbe mit type=street – die Argumente sind ja identisch.

Ja, das klingt überzeugend. Machen wir das so!

Aus gegebenem Anlass (Freiburg) eine Anmerkung:
Das Löschen von as-Relationen ist nicht ganz problemlos. Vor allem beim Übertragen der Adressdaten auf Gebäude und POIs kann es Fehler geben bzw. die Daten in der Relation können falsch gewesen sein. Es gibt z.B. auch in Freiburg keine fünfstelligen PLZ :/.
Immerhin werden die PLZ-Fehler danach bei den “Fools” angezeigt.

Versteh ich nicht.

Tippfehler
Ach ja: Muss vierstellig heißen

Nö, das war nicht der Grund. Ab und zu gibt es dort aS-Rels, deren Member überhaupt keine PLZ haben. Dann muss ich die halt händisch eingeben. Und aus Zeitersparnis Nachlässigkeit fehlte da schon mal eine Ziffer :frowning:

Jo, da sollte ich auch mal wieder reinschauen. ;(

Gruss
walter

Gerade stoplere ich über eine besonders cool-sein-wollende Konstruktion (keine Ahnung, ob es die öfter gibt, ich fürchte es):

Diese Relation vom Typ associatedStreet für den schönen Leonberger Marktplatz enthält zwar alle Gebäude mit der Rolle house, aber nicht direkt die Straßen. Die Rolle street wurde vielmehr dieser Relation vom Typ type=street zugewiesen, die alle Teile des Marktplatzes zusammenfasst.

Warum einfach oder kompliziert, wenn es auch noch komplizierter geht? :roll_eyes:

Naja, die Kreativität der Mapper ist unergründlich :wink:

In Freibug hab ich ab und zu aS-Rels folgender Art:

a) “X-Straße-12345” enthält die Adressen dieser Straße mit PLZ 12345
b) “X-Straße-23456” dito für Adressen der selben Straße mit PLZ 23456

c) aS-Rel “X-Straße” mit X-Straße-12345 und X-Straße-23456 als part.

Muss man nur beim Auslösen aufpassen, da es sonst beim Hochladen Konflikte gibt.

Zuerst X-Straße-12345 und X-Straße-2345 auflösen, löschen und dann alles hochladen. Danach kann man die aS-rel “X-Straße” löschen.

Gruss
walter