Wege mit nur einem Knoten: eine Aufgabe für Wall·E?

Communities Deutschland (Germany)
61

Auch wenn der OSM Inspector noch ein wenig nachhängt: die 1-Knoten-Wege sind (momentan) aus DE komplett verschwunden. Ein Dank an alle, die mitgemacht haben.

Wie gesagt, läßt sich ein großer Teil der neu erzeugten 1NW automatisch bekämpfen; in der Regel handelt es sich um Wege ohne Tags, ohne Historie und ohne Relationszugehörigkeit. Wäre toll, wenn der eine oder die andere in Zukunft mal alle paar Wochen den OSMI-Geometrielayer im Blick behalten könnte, um jene 1NW zu verarzten, die (zumindest nach meinem Verständnis) nicht automatisch gelöscht werden können/sollen.

Das bisher nur manuell gestartete Programm zur 1NW-Beseitigung werde ich früher oder später in den regelmäßigen Ausführungsplan (voraussichtlich 10 Tage) aufnehmen. Die bisher implementierten Löschungsregeln sind sicher; jetzt nach Beseitigung der Altlasten wird es hoffentlich auch einfacher, im verbleibenden Bodensatz weitere Kategorien zu identifizieren, die sicher behandelt werden können und auch tatsächlich vorkommen.

62

Wie nicht anders zu erwarten, war dieser Grad an Sauberkeit von kurzer Dauer. Es ist schon beeindruckend, welcher Nachschub da von den Editoren (hauptsächlich P2, aber Vespucci macht auch das eine oder andere Häufchen) kommt. Aber zumindest konnte ich nach dem Aufräumen und der dadurch verbesserten Übersicht endlich mal die paar Fehler im Programm (*) gezielt angehen. Leider war wohl meine Einschätzung, daß die bisher implementierten Löschregeln jeden Monat nur eine Handvoll Objekte übrig lassen würden, ein wenig optimistisch. Im Moment sind es noch etwa 50, die nicht behandelt werden können - und das schon gut zwei Wochen nach der vorübergehenden Ausrottung. Andererseits wurden im gleichen Zeitraum aber immerhin 216 automatisch gelöscht. Ich könnte auch damit leben, wenn sich keine weiteren ergiebigen Kriterien zur sicheren automatischen Löschung finden lassen sollten. 80 Prozent sind ja schon mal nicht so schlecht.

(*) alle vom Typ “gewollte Änderung wird nicht durchgeführt”. Ein Fehler war sogar so dämlich, daß dadurch alle Kategorien außer 1NW01 (keine Tags, keine Historie, keine Eltern) blockiert wurden - das führte leider zu Extraarbeit für die fleißigen Helfer.

Edit: Ortokraffieh.

63

Besteht denn, wenn du die verbliebenen 50 der letzten Wochen anschaust, noch Hoffnung, dass sich noch gute Kriterien finden lassen oder bisherige Kriterien zu eng gefasst waren?

64

Kann ich noch nicht abschließend beurteilen. Es zeichnet sich aber ab, daß Relationen relativ häufig als Showstopper auftreten. Eine Frage ist also, ob und wann 1NW aus Relationen herausgelöscht werden dürfen. Das Thema hatten wir oben schon einmal angesprochen, aber noch nicht zu Ende gedacht. Dazu kommt noch der Fall nur teilweiser Übereinstimmung von Tags, den ich bislang sehr strikt handhabe; eventuell kann man da in einigen Fällen auch etwas großzügiger herangehen.

Gerade übrigens wieder 51 frische 1NW gelöscht, allesamt erzeugt innerhalb der letzten zwei Tage.

65

Ohne das jetzt oben gelesen zu haben: Für Buslinien (vermutlich für Wanderrouten genauso) würde ich meinen, dass es sicher in Ordnung ist, wenn dieser Knoten ein Endnode des vorherigen und nachfolgenden Weges in der Relation ist.

66

Das dürfte abhängig vom Relationstyp und der Rolle sein. Könntest Du eine Statistik der verwendeten Relationstypen und Rollen machen, damit wir die wichtigen zuerst diskutieren können?

67

Der Großteil der betroffenen Relationen sind type=route; eine weitere Unterscheidung in route=* scheint mir nicht notwendig. Arbeitshypothese: Ein 1NW, nachfolgend als W bezeichnet, kann aus einer Routenrelation herausgelöscht werden, wenn die Relation an der entsprechenden Stelle keine Lücke aufweist. Also entweder gibt es Wege A und B in der Relation, welche den in W enthaltenen Knoten N als ersten oder letzten Knoten enthalten; oder einen durchlaufenden Weg C in der Relation, bei dem N in der Mitte liegt.

Beispiel 1: Weg W=49423499 würde in Abwesenheit von Relationen durch das Kriterium 1NW04 abgedeckt. Die Tags des kaputten Weges sind identisch zu denen von Weg 7753839, welcher auch den einzig noch in Weg 49423499 verbliebenen Knoten N=531992674 enthält. Allerdings ist Weg 49423499 Mitglied von gleich vier Relationen:

  • “Linie 72” (318252) ist zwar ziemlich kaputt, aber an der betreffenden Stelle spielt Weg 7753839 die C-Rolle.

  • “Niedersächsische Mühlen-Tour” (17300979): analog zu “Linie 72”.

  • “Linie 71 - Belm Astruper Heide - Bahnhof Sutthausen” (1152752): allgemein ziemlich kaputt, aber insbesondere an der fraglichen Stelle gibt es weder A/B noch C-Wege. Augenscheinlich müßte Weg 7753839 in die Relation eingefügt werden.

  • “Linie 71 - Bahnhof Sutthausen - Belm Astruper Heide” (289316): dito.

Das vorgeschlagene Kriterium verbietet hier eine Löschung.

Beispiel 2: Weg W=55682205 (N=704842436) kann schon wegen abweichender Tags nicht gelöscht werden, aber lassen wir das für die Diskussion mal außen vor. Er ist Mitglied folgender Relationen:

  • “Europäischer Fernwanderweg E1, Deutschland, Niedersachsen” (373059) - Fall A/B mit den Wegen A=56160295 und B=56160273. Hier könnte W herausgelöscht werden.

  • “Heidschnuckenweg” (2127742) enthält keine anderen Wege mit Knoten N. Herauslöschen nicht möglich.

Auch in diesem Fall kann W nicht gelöscht werden.

Beispiel 3: Weg W=151379206 (N=1642068493): Löschung wird durch abweichende Tags verhindert, aber dies einmal beiseite. Der Weg gehört drei Relationen an: “U 64 (A 8)” (2674812), “U 39 (A 8)” (59975) und “B 16 Kaufbeuren - Günzburg” (397354). Letztere ist eine type=TMC; diese kann m.E. synonym zu type=route behandelt werden. Alle drei Relationen enthalten ebenfalls Weg C=151379205; nach dem vorgeschlagenen Kriterium könnte W herauspräpariert werden.

Beispiel 4: Sandkrugbrücke, Weg W=232431886, 2407839894. Die Tags sind identisch zu Weg 36260393; in Abwesenheit von Relationen könnte W gelöscht werden. W gehört insgesamt 12 Relationen an, kann jedoch aus diesen herausgelöscht werden: A=36260393, B=229562965. In diesem Fall erlaubt das Kriterium die Entfernung des Weges aus allen Relationen und seine anschließende Entsorgung.

Nach diesen Beispielen neige ich in jedem Fall dazu, die Löschung und das Herausoperieren des 1NW aus Relationen zu entkoppeln: Zuerst den Weg aus Relationen entfernen, unabhängig davon, ob der Weg selbst gelöscht werden kann. Im Falle von Beispiel 3 etwa müßte ein menschlicher Korrekteur nur noch prüfen, ob die vorhandenen Tags von W auf C übernommen werden sollten, müßte sich aber nicht mehr mit den Relationen herumschlagen, und diese hätten einen Defekt weniger. Auch in den Beispielen 1 und 2 könnten so mehrere Relationen (teilweise) repariert werden, auch wenn der 1NW noch stehen bleibt (und noch in einem Teil der Relationen enthalten ist).

Edit: wie ich gerade etwas überrascht festgestellt habe, stellen die obigen Beispiele die Gesamtheit der aktuell vorhandenen Fälle dar, wo Routenrelationen beteiligt sind. Daneben gibt es nur noch einen weiteren Weg, der in admin-Grenzen steckt. Beim großen Aufräumen neulich hatte ich den Eindruck, daß Relationen wesentlich häufiger die Löschung blockierten. In jedem Fall sollte es in Bezug auf Relationen reichen, eine Lösung für type=route (und Verwandte wie type=TMC) zu finden.

Es gibt aber eine Gruppe, bei der wohl nichts zu machen ist: 1NW im Nichts, häufig solche mit highway=path|footway|track|steps oder building=yes, die mit nichts verbunden sind.

68

Wenn du nun schon lokalisiert hast, dass die neuen 1NW nur bzw. gehäuft bei (Routen-)Relationen auftreten, wäre es da nicht besser das Problem bei der Wurzel zu packen? Also festzustellen, bei welchen Editierschritten die 1NW auftreten und den Programmierern der Editoren einen Fehlerbericht schreiben? Ist zwar vielleicht etwas mehr aufwand, aber mit der Zeit rechnet es sich und verbessert auch gleichzeitig die Editoren.

Sind bei den neuen Fehlern auch einige von JOSM erzeugt worden?

69

1NW werden seit jeher von Potlatch 1/2 erzeugt. Ein Ticket zum Thema gibt es seit vier Jahren, hatte für den Autor von Potlatch aber eher geringe Priorität. Und da die Entwicklung von Potlatch inzwischen weitestgehend zum Erliegen gekommen ist, habe ich wenig Hoffnung, da etwas bewegen zu können.
Für Vespucci gibt es ebenfalls ein Issue, Simon hat aber offenbar das Problem noch nicht eingrenzen können.
Andere Editoren, etwa JOSM, sind nach meiner Kenntnis nicht beteiligt. Insbesondere iD erzeugt meines Wissens keine 1NW, sondern “nur” Wege mit wiederholten Knoten, seit Freigabe von 1.1.1 sogar grob dreimal so viele wie zuvor in 1.0.1 (Issue existiert.) Aber die lassen sich ja zumindest weitaus einfacher reparieren.

Im Übrigen treten 1NW nicht gehäuft im Zusammenhang mit Relationen auf, im Gegenteil: rund 80 % der kaputten Wege können bereits bearbeitet werden und sind somit nicht Element einer Relation. Aber an den restlichen Fällen sind auch Relationen beteiligt - nach meinem ursprünglichen Eindruck sogar recht häufig (diese Einschätzung muß ich wohl revidieren). Insgesamt dürften eher in höchstens 5 % der Fälle Relationen betroffen sein - aber diese hätte ich gerne aus dem Weg.

70

+1

Unterscheidung halte ich schon für nötig. Beispielsweise sollte man nicht eine durch den 1NW definierte Haltestelle (platform oder stop) nur deshalb löschen, weil sie Kontakt zum an dieser Stelle nicht kaputten Fahrweg hat.

Das halte ich für ok soweit die Rollen von 1NW, A, B und C alle in die Gruppe leer, forward und backward fallen.

Hat der 1NW die Rolle platform, so ist dies ebenfalls ok, soweit A, B und C die Rollen platform oder platform:number haben. Hier sollte aber auch schon einer der Wege A oder B zum Löschen ausreichen.

Hat der 1NW die Rolle platform:number so muss man wohl für A,B und C die gleiche Rolle mit gleicher Nummer fordern.

Liegt ein unverbundener Weg in der Nähe eines normalen Weges, so sollte man ihn so behandeln können, als wenn dieser Weg über den Knoten des 1NW verlaufen würde. Gibt es mehrere Wege in der Nähe, darf man meines Erachtens denjenigen auswählen, der zur Löschung des 1NW führt.

71

Danke für den Hinweis, die Komplexität des OSM-ÖPNV hatte ich mal wieder verdrängt. Ich denke, daß ich role=platform etc. einfach außen vor lasse - zu selten. D.h. die obige Konzeption nur anwenden, wenn W die Rolle forward, backward oder keine Rolle besitzt und die Wege A/B, C ebenfalls eine dieser Rollen haben.

72

So, ich habe mal ein bißchen Code gebastelt. Bevor ich ihn einsetze, werde ich noch eventuelle weitere Wortmeldungen abwarten (und den Algorithmus nötigenfalls modifizieren).

Die Erweiterung sieht vor, 1NW aus Routenrelationen herauszupräparieren, sofern die betroffene Relation an der Stelle durchgängig ist. Dies geschieht vor jeder weiteren Untersuchung des Weges selbst und unabhängig davon, ob dieser gelöscht werden kann.

Bearbeitet werden Relationen mit type=route und type=TMC (letzteres sehe ich in diesem Zusammenhang als synonym zu type=route). Das Programm schleift durch alle Elternrelationen des Weges W, im folgenden betrachte ich eine einzelne Relation R. Der Knoten des Weges W heißt N.

Der aktuelle Entwurf für den Algorithmus innerhalb der Schleife arbeitet wie folgt:

  1. Prüfe, ob die Relation ein type-Tag hat und dieses den Wert route oder TMC enthält.

  2. Finde alle Referenzen auf W in R, speichere deren Rollen in einer duplikatbereinigten Liste. (Zwei Vorkommen als “forward” und eines als “backward” ergeben die Liste '(“forward” “backward”).) Im Normalfall sollte W nur einmal in R referenziert sein, aber bei kaputten Editoren weiß man nie.

  3. Prüfe die erhaltene Rollenliste: alle gefundenen Rollen müssen leer, “forward” oder “backward” sein. (Hierdurch sollen Haltestellen ausgeschlossen werden: Hat W in R etwa die Rolle “platform”, bricht der Algorithmus ab.)

  4. Suche die übrigen Elternwege von N, welche selbst keine 1NW sind, in der Elementliste von R (d.h. welche an W anschließenden Wege ebenfalls in R enthalten sind). Weiter in Abhängigkeit von deren Anzahl:

    • Sind zwei N-Elternwege in R enthalten, muß die oben als A/B bezeichnete Konstellation vorliegen. Prüfe daher für jeden der beiden Wege, ob N hier entweder als erster oder als letzter Knoten vorkommt.

    • Ist nur ein Elternweg von N in R enthalten, muß dies ein “C-Weg” sein. Prüfe, daß N in der Mitte dieses Weges liegt (nicht erster oder letzter Knoten).

    • Abbruch in allen anderen Fällen (keine Elternwege von N in R, oder mehr als zwei).

[/*] [*]Entferne W aus R.[/*]

Edit: Beschreibung des Algorithmus korrigiert, vgl. #78.

73

Erstmal Lob, dass du dich einem weiteren Problem hier annimmst.
Punkt 4 (der ja der Kern ist) scheint mir aber noch Verbesserungspotential zu haben:
Wenn es zwei Elternwege gibt, in denen N Endpunkt ist, gehst du von der A/B Konstellation aus. Es könnte aber auch sein, dass beide Wege sozusagen auf einer Seite des Punktes liegen und sich gegenseitig überschneiden.
Wenn an einem Punkt mehrere 1-Node-Ways sind, entfernst du keinen aus der Relation (und kannst daher keinen löschen), weil es dann mehr als 2 Elternwege gibt.
Eine A/B ähnliche Konstellation könnte auch mit N nicht am Ende der beiden Wege auftreten, wenn beide Wege überlappen (womit es dann fast eine C Konstellation wäre, aber eben mit mehr Elternwegen)

Ob das jetzt alles erkennbar und sinnvoll ist, will ich nicht beurteilen, sind nur Anhaltspunkte. Nur mein erster Punkt würde zu falschen Entfernungen führen, wenn er nicht beachtet wird.

74

Ich weiß nicht, ob ich Deine Anmerkung richtig verstehe. Richtig ist: ich habe keine Ahnung, wie die Wege weiter verlaufen, und ob die Relation ansonsten in Ordnung ist. (Tatsächlich dürften die meisten Routenrelationen in OSM mehr oder weniger defekt sein, jedenfalls wenn ich von den von mir gepflegten Routen ausgehe, die in schöner Regelmäßigkeit kaputtgehen.)
Was ich testen will ist, daß die Relation am Punkt N bzw. in einer ϵ-Umgebung davon stetig ist. In dem Fall kann ich davon ausgehen, daß W in der Relation überflüssig ist und entfernt werden kann. Was jenseits meines ϵ-Horizonts sonst noch alles kaputt ist, ist unabhängig von W und interessiert mich insofern nicht.
Wenn die Wege A/B sich anschließend (also quasi außerhalb meiner ϵ-Umgebung) schneiden, liegt dort zwar ein Fehler vor, hat aber nichts mit W zu tun und auch nur indirekt mit R. (Der Fehler in den Wegen kann i.d.R. korrigiert werden, ohne R anzufassen.)

Du meinst, wenn es zwei 1NW W und V gibt, die auch beide Element von R sind, dazu Wege A/B (oder C)? Das stimmt, in dem Fall ist bei der Untersuchung der Frage, ob W entfernt werden kann, V der dritte Weg und verhindert die Entfernung von W. Edit: Diese Aussage ist falsch, vgl. #78.
Allerdings ist mir so ein ein Fall noch nicht begegnet: 1NW, die Element von Relationen sind, stammen meist von Potlatch (neu erstellt oder falsch gekürzt), aber Potlatch scheint in der Regel nur je einen 1NW zu generieren. Die Neigung, gleich dutzendfach (komplett neue) 1NW am selben Knoten zu erzeugen, findet sich bei Vespucci, und dort landen sie nicht in Relationen. Insofern ist der Einwand richtig, scheint aber in der Praxis nicht von allzu großer Bedeutung zu sein.

Also Weg A: …-L-M-N und Weg B: M-N-O-… d.h. ein gemeinsamer Abschnitt M-N, dann erfüllt B die Bedingung nicht. Das dürfte in den seltensten Fällen so gewollt (und richtig) sein. Insofern wäre es durchaus sinnvoll, den 1NW nicht anzurühren und die ordentliche Korrektur einem Menschen zu überlassen.

75

Bei ÖPNV-Linien nicht. D.h. eine Relation könnte z.B. die Wegfolge U-V-W-X-Y-W-V-T enthalten. Da das zu einer Nichtlöschung führen würde (Punkt 4.3) sollte das aber nicht davon abhalten das wie von dir beschrieben in Betrieb zu nehmen.

76

Das stimmt natürlich. Bisher ist mir aber noch kein Fall begegnet, wo ein 1NW mehrfach in einer Relation enthalten war, insofern halte ich diesen Fall für sehr selten. Eventuell ist es dennoch besser, den Algorithmus bei mehr als einer Referenz von R auf W abbrechen zu lassen. Wahrscheinlich verliert man damit nichts, schließt aber unliebsame Überraschungen aus.

Edit: Posting versehentlich mit Edit statt Quote verhunzt, danach wiederhergestellt.

77

Stell dir vor, du hast eine Relation mit einer Lücke mit einem 1NW an einer Seite der Lücke. Wenn jetzt (wie auch immer) alle Wege (außer dem 1NW) oder doch zumindest der anschließende Weg verdoppelt würden, dann hast du immer noch eine Lücke, aber dein A/B Kriterium ist erfüllt. Könnte man evtl. verhindern, indem man bei diesem Kriterium noch den in A und B jeweils benachbarten Knoten anschaut und den 1NW nur aus der Relation herausnimmt, wenn das nicht zweimal der gleiche ist.

Für die anderen (und auch diesen Punkt) mag gelten, dass sie praktisch nicht vorkommen, deshalb sage ich ja, es sind nur Anregungen. Zumindest könnte ich mir aber vorstellen, Kriterium 4.2 darauf zu erweitern, dass es schon dann greift, wenn es beliebig viele Elternwege gibt, solange N bei wenigstens einem davon ‘in der Mitte’ liegt.

78

Danke, jetzt hab ich’s verstanden. Wenn Weg A die Folge …-M-N oder N-M-… enthält und B die Folge …-L-N oder N-L-…, muß L!=M sein. Das macht Sinn und ist leicht umzusetzen.

Und auch diese sind durchaus willkommen. Folgendes hat mich gerade noch auf ein Problem aufmerksam gemacht:

In der Beschreibung des Algorithmus oben steckt ein Fehler. Es muß in Punkt 4 heißen: “Suche die übrigen Elternwege von N, welche selbst keine 1NW sind, in der Elementliste von R …” (Edit: geändert.) Damit ist auch meine erste Antwort auf die Anmerkung falsch. 1NW werden nicht zu den ABC-Wegen gezählt, das ist soweit auch sinnvoll. Sollte es am Punkt N mehrere 1NW W1, W2, W3, … geben, die allesamt in R enthalten sind, werden diese sukzessive aus R herauspräpariert (falls intakte ABC-Wege vorhanden sind). Dies geht ggf. mit mehreren Bearbeitungen von R einher, weil das Programm sich immer nur mit einem Weg beschäftigt: d.h. zuerst wird W1 aus R entfernt und ggf. auch selbst gelöscht, dann wird W2 aus R entfernt und ggf. auch selbst gelöscht und so weiter. Nicht schön, aber es gibt schlimmeres, zumal der Fall mindestens sehr selten ist.

79

Ok, dann verstehe ich das^^ Ich würde trotzdem behaupten, dass auch bei mehr Elternwegen eine Entfernung problemlos ist, so lange wenigstens einer das C Kriterium erfüllt (oder zwei zussamen das A/B Kriterium, aber alle Paare durchzuprobieren könnte umständlich sein). Oder hast du einen bestimmten Fall im Kopf, warum du bei mehr Elternwegen abbrechen willst?

80

Nein, reine Vorsicht. In allen Fällen, die ich bisher gesehen habe (zu den obigen Beispielen sind in den letzten Tagen doch noch ein paar dazu gekommen), lag entweder A/B oder C vor, oder die Route hatte eine Lücke. In diesen Fällen glaube ich zu verstehen, was (nicht) zu tun ist, bei mehr Elternwegen nicht unbedingt. Beispiele für eine solche Situation habe ich andererseits noch nicht gesehen; ich gehe davon aus, daß sie, wenn überhaupt, sehr selten vorkommen. Insofern verliere ich wohl auch nichts, wenn ich sie außen vor lasse.