associatedStreet-Relationen entfernen?

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

Ich hatte auch schon eine, die sich selbst als Member enthielt…

Nur interessehalber: In welcher Rolle? :laughing:

‚Äďks