associatedStreet-Relationen entfernen?

Geben wir mal den Hut rum für eine größere USV für Walter. Ein warmes Plätzchen für die Kätzchen :slight_smile:

–ks

Der Safthändler war da - alles wieder ok. Hoffe ich zumindest.

Am Donnerstag wollen die nochmals woanders buddeln :frowning:

Gruss
walter

Wenn der Strom weg ist, läuft auch der Haus-Verstärker/Verteiler von UnityMedia nicht.

Ich kann meine Kisten incl. Router zwar einige Zeit am Laufen halten aber das Internet ist halt weg :frowning:

Gruss
walter

Das war der Übeltäter:

Gruss
walter

Wie geht Ihr mit aS um, die unbenannte highway=service enthalten?
Ist aus meiner Sicht ein Fall, bei dem die Relation halbwegs sinnvoll ist.
Beispiel: https://www.openstreetmap.org/relation/4820787

Das ist aus meiner Sicht ein fragwürdiges Tagging.
Im Wiki steht nur, dass alle Teilstücke einer Straße Mitglieder der as-Relation sein sollen. Von anderen Wegen, die davon abgehen, steht nichts drin. Das wäre mMn eine Erweiterung der as-Relation auf eine dritte Gruppe von Elementen, auch wenn sie ebenfalls die Rolle “street” bekommen.

OT:

Hat da ein Bagger Hunger gehabt? :expressionless:

Also der Elektrolurch war es bestimmt nicht… der sitzt woanders…

GuruGuru: Der Elektrolurch auf Youtube: https://www.youtube.com/watch?v=_YMp9kOsb2k:cool:

Sven

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.