Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler?

Oli-Wan wrote:

Mahlzeit. Nach einigen Monaten relativer Ruhe habe ich noch einmal einen möglichen Vorschlag für eine Korrektur durch Wall·E, und zwar die Korrektur falsch geschriebener Tagschlüssel und -werte, also Dinge wie maxspeeed->maxspeed.
xybot hat seinerzeit ähnliche Bearbeitungen durchgeführt. Bei dem Meinungsbild vor knapp einem Jahr hatte ich diese Korrekturgruppe nicht aufgeführt; insofern stellt sich als erstes die Frage, ob derlei überhaupt wünschenswert ist. ...

Sinnvoll ist das meiner Meinung nach auf jeden Fall und von meiner Seite auch erwünscht.

Oli-Wan wrote:

Angenommen, es gibt ein positives Votum: wie sollen die Korrekturprozesse strukturiert werden? In einem der anderen Fäden zu Wall·E ist mal der Vorschlag angeklungen, man könnte die Korrekturen gleich anhand unscharfer Übereinstimmung mit dem Zielwert vornehmen: also etwa alles, was beispielsweise eine Editierdistanz von 1 zu building hat, durch building ersetzen. Ich bin da zurückhaltend und würde lieber mit einer expliziten Liste zu ersetzender Zeichenketten arbeiten, um unliebsamen Überraschungen zu entgehen. Nachteil: was nicht auf der Liste steht, wird auch nicht korrigiert. Die Liste müßte also kontinuierlich erweitert werden.

Explizite Liste dürfte besser sein (denken wir nur an Gleis-trasse versus Glei-straße).

Oli-Wan wrote:

Es gibt eine Liste von xybot. Die möchte ich aber lieber nicht benutzen, weil sie auch einige Reinterpretationen enthält. Stattdessen würde ich basierend auf dem tatsächlichen, aktuellen Aufkommen eine komplett neue Liste aufsetzen (erste Kandidaten dafür siehe unten).

Ferner wäre zu klären, wie der Regelsatz aufgestellt und diskutiert werden soll. Die Liste der Ersetzungsregeln wird sukzessive wachsen; muß jede Neuaufnahme vorgestellt und diskutiert werden? Oder reicht es, das grundsätzliche Einverständnis des Forums einzuholen, und Ergänzugen nur in größeren Abständen in größeren Paketen vorzustellen? ...

In der Fixbot-Liste sind in der Tat einige eigenwillige Zuordnungen wie amenity=Parkplatz -> amenity=parking (fiktives Beispiel).

Für den Anfang sollten neue Regeln erst einmal diskutiert werden. Wenn sich das Verfahren stabilisiert hat, reicht vielleicht eine Ankündigung.
Man sollte für jede Änderung eine Testphase einbauen, in der die Treffer zwar gelistet, jedoch noch nicht geändert werden. So hat man die Chance falsche Treffer vor Änderung zu finden. Dabei würde kleine Änderungen ein kurze Testphase und umfangreichere Änderungen eine ausführlichere Testpase bedeuten.

Oli-Wan wrote:

Um dem ganzen etwas Substanz zu verleihen, einige Beispiele. Falsche Schreibweisen gibt es sowohl in Schlüssel als auch in Werten. Ich habe mir als ersten Schritt die in DE vorkommenden Schlüssel angesehen und nach Paaren von Schlüsseln gesucht, die eine Levenshtein-Distanz von 1 aufweisen und von denen einer mindestens 500mal häufiger vorkommt als der andere. Dieses Kriterium dient nur der Suche und muß noch ein wenig verfeinert werden, liefert aber bereits einige interessante Kandidaten.

Die meisten der folgenden aus dem Feld der Adresstags scheinen mir ziemlich eindeutig (...): ... Adressen ...
Auch bei Gebäuden, insbesondere den neumodischen 3D-Tags, gibt es einige recht klare Fälle: ... Gebäude ...
Gegenbeispiele: Bei Sprachzusätzen (:XX) versagt das Suchkriterium völlig. ... ...

In anderen Fällen müßte man mal näher hinsehen, Beispiele:
key marking (12) might be a misspelling of key parking (113651)
key tower (156) might be a misspelling of key power (545828)

Oder man findet zwar ein falsches Tag, aber die Zuordnung durch den Algorithmus muß nicht notwendigerweise stimmen (...):
key biking (2) might be a misspelling of key hiking (39475)

Dein Kriterium zur Suche einer Kandidaten-Liste scheint mir durchaus geeignet.
Ob nun genau 1:500 die Schwelle sein muss, darüber kann man diskutieren. Fürs Erste würde ich das so lassen. Man kann das später immer noch auf 1:400 oder weniger reduzieren.

Da hast du ja bereits so einige problematische / nicht zwingend eindeutige Fälle gefunden. EIn klarer Hinweis

Für Schlüsseln die als <Hauptschlüssel><Trennzeichen><Unterschlüssel> aufgebaut sind (wie addr:*= oder building:*=), würde ich ein mehrstufiges Vorgehen vorschlagen:
- Testen auf die Struktur
- Übernahme/Korrektur Hauptschlüssel
- Übernahme/Korrektur Trennzeichen
- Übernahme/Korrektur Unterschlüssel

Bei Adressen gibt es ja einen Fall, der schwierg zu lösen sein wird: addr:country (Land) und addr:county (Kreis) liegen sehr nahe beieinander. Da der erste aber nur formale Werte (ISO-Ländercodes) enthalten soll und der zweite im Wesentlichen Freitext enthält, kann man da gegebenenfalls doch etwas retten. Solange du nur Deutschland behandelst, entfällt addr:county, da Kreise in DE nicht für die Adresse verwendet werden.

PS: Wie bisher wäre eine Liste mit Fällen, die der Algorythmus nicht lösen kann, hilfreich für händische Korrekturen (z.B. addr:xyz=*).

Edbert (EvanE)