Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler?

Hm, sieht soweit gut aus, wobei bei manchen rein theoretisch andere sinnvolle Wörter (nicht aber gebräuchliche Schlüssel) in der Nähe liegen. Höchstens hgb ist ein bisschen gefährlich, weil es wirklich sehr kurz ist - aber die Fehlerquote dürfte auch hier sehr gering sein.

In deiner bewährten ruhigen Art ein Schritt nach dem anderen.
So ist es sinnvoll und vor allem sicher.

Wie oben bereits gesagt, erst einmal auf der sicheren Seite bleiben.

Ich hätte anemity (vertauschtes ‘n’ und ‘m’ statt amenity) noch bei den Fehlern erwartet. Das scheint aber häufiger vorzukommen, als 1:200 zulässt.

Bei building/roof:colour könnte man noch building/roof:color ergänzen. Das passt nicht wirklich zu deinem Kriterium von 1:200, weil es ein verbreiteter Fehler ist. (color = amerikanisches Englisch, statt colour = britisches Englisch). Man kann das eventuell auch erst später ergänzen.

Was die Korrektur der Schlüssel hgb → hgv betrifft, könnte man das absichern, indem man auf die Existenz eines Highway-Taggs prüft. Auch das kann man später ergänzen.

Insgesamt werden bei den falschen Trennzeichen sicher noch einige Varianten (" ", “_”, “:”, “;”, …) dazu kommen, wenn man die Auswahl-Kriterien weiter verfeinert.

Man sollte auch versuchen gerade häufige Fehler zu finden und zu korrigieren (solange das eindeutig geht).

Edbert (EvanE)

Das Mapnik Rendering ist zwar ein wichtiger Faktor, jedoch nur für das Auffinden von Fehlern nach dem Hochladen.
Eine optische Auffälligkeit des Fehlers direkt im Eingabefeld ist dagegen ein Faktor, der die Wahrscheinlichkeit des Auffindens vor dem Hochladen beeinflusst. Ich denke, dass die meisten Tippfehler direkt bei der Eingabe hier korrigiert werden.

Das dürfte auch damit zusammenhängen, dass diese an Objekten hängen, die sehr selten weiter bearbeitet werden (insbesondere bezüglich der Tags, so dass man die Tagliste im Editor beachtet.

Auch wenn diese Falschschreibung eine große optische Ähnlichkeit hat, dürfte sie schon durch das Kriterium mit der Editierdistanz gefallen sein.

+1

+1
Daher denke ich, dass man das 1:200 Kriterium völlig verwerfen sollte oder lediglich nutzen sollte, um bei Nichteinhaltung besonders sorgfältig zu kontrolieren, ob die Ersetzung wirklich sinnvoll ist.

Meiner Erachtens ist das 1:200 Kriterium anfangs schon in Ordnung. Hierdurch schafft man zunächst einen Grundstock von nicht so häufigen Vertippern, der zum Test des Programms geeignet ist - auch unter Echtbedingungen. Und nur weil es seltene Vertipper sind, sind es trotzdem Vertipper.
Die Quote sollte im Laufe der Zeit natürlich gesenkt werden, außerdem sehe ich keinen Grund, nicht einzelne, häufigere und erkannte Fehler wei das genannte building:color auf Zuruf und nach Diskussion mit aufzunehmen.

Hm, ich würde auch auf jeden Fall das “color” noch mit reinnehmen, auch wenn es der 1:200 widerspricht. Aber das ist mMn absolut eindeutig und dem Nichtwissen um BE statt AE geschuldet, denke ich.

Mit den Parametern habe ich inzwischen ein bißchen herumgespielt. Die Reduktion des geforderten Häufigkeitsverhältnisses hat relativ wenig Einfluß: “häufige” Fehler scheint es bis auf wenige Ausnahmen nicht wirklich zu geben, bzw. nur bei “häufigen” Tags, sodaß das Verhältnis groß bleibt. Damerau-Levenshtein bis zwei liefert überwiegend eher kuriose als wirklich brauchbare Verbindungen. Beispiele:

cost (7)
         --> boat (3863)
         --> foot (160866)
floor (1)
         --> color (839)
         --> foot (160866)
inscription (195)
         --> description (153499)
hotel (3)
         --> note (42013)
motorway (6)
         --> motorcar (22536)
relation (14)
         --> religion (9129)
site (228)
         --> lit (66113)
tomb (7)
         --> to (3459)
zoo (37)
         --> foot (160866)
         --> wood (10842)
roof (92)
         --> foot (160866)
         --> ref (157665)
babies (2)
         --> cables (25648)

Ausnahmen bestätigen die Regel:


maxspeed:backwarck (1)
         --> maxspeed:backward (1000)
track_visibility (4)
         --> trail_visibility (6456)
amanety (1)
         --> amenity (1180611)
avvess (2)
         --> access (511802)
bycicle (18)
         --> bicycle (683084)
demonination (1)
         --> denomination (36818)
hieight (1)
         --> height (68402)

Letztere sind in der folgenden Erweiterung der gestrigen Liste enthalten, daneben noch einige mit niedrigerem Limit gefundene und einzelne “auf Zuruf”.

(list "bicycle"
      '("bycicle"))
(list "building:colour"
      '("building:color" "building:coulor"))
(list "roof:colour"
      '("roof:color"))
(list "roof:height"
      '("roof:heigth"))
(list "roof:levels"
      '("roof:level" "roof:llevels"))
(list "roof:orientation"
      '("roof_orientation"))
(list "roundtrip"
      '("rountrip"))
(list "nudism"
      '("Nudism"))
(list "addr:city"
      '("adddr:city"))
(list "addr:housename"
      '("add:housename"))

(list "addr:postcode"
      '("addrPostcode"))
(list "addr:street"
      '("addrStreet"))
(list "construction"
      '("constuction"))
(list "official_name"
      '("oficial_name"))
(list "trail_visibility"
      '("trail_visibilty" "track_visibility"))
(list "maxspeed:backward"
      '("maxspeed:backwarck"))
(list "amenity"
      '("anemity" "ameity" "amanety"))
(list "access"
      '("avvess"))
(list "barrier"
      '("barreier"))
(list "denomination"
      '("demonination"))

(list "height"
      '("hieight"))
(list "maxspeed"
      '("maspeed" "max:speed" "max_speed"))
(list "maxspeed:forward"
      '("maxspeed:fordward" "maxspeed:foreward"))
(list "opening_hours"
      '("openning_hours" "openind_hours"))
(list "osmc:symbol"
      '("osmc:Symbol" "osm:symbol"))
(list "public_transport"
      '("publick_transport" "public_transprt"))
(list "seasonal"
      '("saisonal"))
(list "shelter_type"
      '("shelter:type" "shelter-Type"))

(list "short_name"
      '("shot_name"))
(list "smoothness"
      '("smothness"))
(list "tracktype"
      '("trackttype" "tracktxpe" "track type" "trycktype")
(list "tourism"
      '("turism"))

“hgb” habe ich erst einmal herausgenommen.

Edit: denomination ↔ demonination vertauscht.

Gut, bei Damerau-Levenshtein macht eine Entfernung von 2 natürlich mehr aus, während du mit der Entfernung von 1 schon einiges gefunden hast, was bei reinem Levenshtein nicht gefunden worden wäre. Schön, dass trotzdem noch ein bisschen was dabei war.

Erweiterung sieht gut aus, über track_visibility und saisonal könnte man evtl. diskutieren, da ist ein bisschen Interpretation dabei. osm:symbol ist etwas kritischer, das könnte ja auch ein gültiger, sinnvoller Schlüssel sein.

Da sich keiner traut, zu fragen was denn Damerau-Levenshtein ist:
http://de.wikipedia.org/wiki/Levenshtein-Distanz
Was man hier so alles lernt :sunglasses:

Nahmd,

Ich begrenze bei unscharfer Suche die maximal akzeptierte Distanz (also hier: den Parameter) auf einen bestimmten Bruchteil (z.B. ⅓) der Länge des Vergleichsstrings. Das vermeidet den blöden Effekte, dass bei erlaubter Distanz 2 ein String der Länge 2 auf alles passt.

Ob das hier nützlich oder überhaupt anwendbar ist, weiß ich natürlich nicht.

Gruß Wolf

PostgreSQL verwendet neben die üblichen Pattern-Mechanismen auch noch andere Fuzzi-Searches: http://www.postgresql.org/docs/current/static/fuzzystrmatch.html

Nur mal so als Idee was es sonst noch gibt. Ich verwende die natürlich, da ich PostgreSQL benutze, aber das wäre hier wohl etwas zuviel verlangt :wink:

Gruss
walter

building:colour ist nur ein Spezialfall fuer diesen Fehler. Es gibt auch einfach colour (IIRC) fuer Routen-Relationen oder roof:colour. Sobald die Korrektur von color allgemein akzeptiert ist, sollten alle Versionen korrigiert werden.

Gruesse,

Basstoelpel

Danke für den Tipp. Habe mir gerade mal ein Soundex geschrieben und ausprobiert; leider mit mäßigen Ergebnissen. Ein Problem ist die Definition von Soundex - “bike” und “bus” sind nicht wirklich ähnlich, aber in Soundex beide B2. Eventuell ist Metaphone hier besser, werde ich bei Gelegenheit evtl. auch noch ausprobieren. Soundex findet “zufällig” alle Schlüssel, bei denen ein Tippfehler hinter dem dritten/vierten Konsonant auftritt, aber leider ebenso alle Schlüsselpaare, die sich weit hinten stärker unterscheiden (restaurant und restriction, R236). Das andere Problem liegt in der Tagstruktur von OSM mit seinen Subtags: addr in addr:* schöpft den Soundex-Raum bereits komplett aus; alle addr:*-Tags (gültig oder nicht) gelten damit als ähnlich. Da müßte man Soundex also abschnittsweise einsetzen - oder Tags mit Trennzeichen kurzerhand außen vor lassen.

Und ja, PostgreSQL wäre mir zuviel Aufwand. Wenn ich innerhalb von fünf Minuten Geofabrik-DE (als PBF) komplett durchsuchen und sämtliche Tags darin auswerten kann, reicht mir das völlig. Tests laufen mit Münster (5 Sekunden) oder NRW (1 Minute). Meinetwegen kann sich die Laufzeit durch komplexere Tests auch gerne noch verdreifachen, denn später wird das Programm ja nur noch alle paar Wochen ausgeführt werden, um nach neuen Kandidaten zur Erweiterung der Liste zu suchen.

Stimmt völlig. Wenn du nicht bereits PostgreSQL oder gar PostGIS in deinen Projekten einsetzt, wäre das in etwa so als ob ein Bauer einen Ferrari vor seinen Pflug spannt, damit es schneller geht :wink: Für mich ist das allerdings ein reizvoller Ansatz.

Gruss
walter

Bekommt man mit Wall-E auch die Singular>Plural-Problematik in den Griff? Ich denke da z.B. an access=customer>customers und so.

dann aber auch POIS → POI :wink:

Gruss
walter

Technisch: ja, mühelos (allerdings erst im späteren zweiten Schritt, wenn es um Tagwerte zu gegebenen Schlüsseln geht).
Das wird man sich aber für jeden Wert näher ansehen müssen, weil es sich nicht notwendigerweise um einen Tippfehler oder Irrtum handeln muß, sondern der vermeintlich falsche Wert womöglich ganz bewußt genutzt wird. (Das war ein Grund für das Verhältniskriterium im Suchprogramm: je häufiger der “falsche” Schlüssel im Verhältnis zum richtigen, desto höher die Wahrscheinlichkeit, daß er bewußt verwendet wird.) Und dann sind wir im Bereich des Umtaggens konkurrierender Schemata, wovon ich eigentlich die Finger lassen will. Womöglich ist es in solchen Fällen sinnvoller, customer/customers etc. kurzerhand als synonym anzusehen und dies auch Auswertern beizubringen.

Ich finde man sollte customers so langsam mal ins Wiki aufnehmen bei 37000 Verwendungen.

Ich lasse mal die Antwort auf die Frage offen, ob "falsche"Schlüssel bewusst verwendet oder unbewusst abgeschrieben werden. Und konkurrierende Schemata sollten wir doch im Interesse einer sauberen Datenbank, der Verhinderung von Redundanzen und von vermeidbarem Auswertungsaufwand zu verhindern suchen. Wir brauchen keine verschiedene Begrifflichkeiten für denselben Sachverhalt. Ein Minimum an Datendisziplin sollte auch in der OSM-crowd möglich sein. Die Zeiten, in denen man wegen fehlender keys und values auf die Phantasie der crowd angewiesen war, sind ja wohl vorbei, da mindestens 99% der möglichen Fälle wohl existieren (Exoten und neue Ideen für micromapping usw. mal ausgenommen.

Mein Fazit:
Sobald wir einen eindeutigen Schüssel oder einen eindeutigen Wert haben, müssen die in der Wiki auch eindeutig hinterlegt sein und so angewendet werden.

Ja, unbestritten. Allerdings nicht dadurch, daß wir (d.h. eine kleine Minderheit der gesamten Mappergemeinde) eines der Schemata für falsch erklären und ein Umtaggen damit zur Fehlerkorrektur deklarieren. Das mehrhunderttausendfache Umtaggen building=entrance → entrance=* ist mir diesbezüglich noch in schlechter Erinnerung.
Ich will nicht sagen, daß das Umtaggen von Schema A in Schema B, nachdem sich Schema B klar durchgesetzt hat, nicht im Einzelfall sinnvoll sein kann. Es liegt aber außerhalb des Aufgabengebietes, das ich mir vorgenommen habe, nämlich der Korrektur (weitestgehend) eindeutiger Fehler. [1]

Bezüglich des speziellen Falls access=customer(s) will ich mich an dieser Stelle gar nicht festlegen, das ist für mich ferne Zukunftsmusik (wenn die Werte drankommen [2]) und das von Dir angedeutete “unbewußte Abschreiben” (dazu: automatische Textergänzung in JOSM) ist auch nicht von der Hand zu weisen. Deswegen auch:

Anschließend wollte ich nur einige der Überlegungen andeuten, die dabei eine Rolle spielen könnten.

[1] Wenn sich jemand (zurecht) fragt, wie die Abgrenzung zwischen Fehlern und Nicht-Fehlern (also verschiedenen Schemata, absichtlich verwendeten untypischen Tags/Schreibweisen, …) aussehen soll, dies ist meine Definition: Einen Fehler wird derjenige, der ihn begangen hat, in der Regel (an)erkennen und - sofern dem nicht seine Persönlichkeitsstruktur entgegensteht - eingestehen, wenn man ihn darauf hinweist und ihm ggf. noch erklärt, warum es sich um einen Fehler handelt; bei einem Nicht-Fehler wird er sagen: nein, das ist Absicht.
Beziehungsweise, da ich bei den automatischen Korrekturen ja gerade nicht nachfrage: bei einem Fehler kann ich mit gutem Gewissen davon ausgehen, daß der Verursacher höchstwahrscheinlich mit der Korrektur einverstanden wäre, denn würde er auf den Fehler aufmerksam (gemacht), würde er einer Korrektur zustimmen oder sie selbst durchführen. Wo ich mit Widerspruch rechnen muß, handelt es sich nicht um einen Fehler.

[2] Ich hätte auch nichts dagegen, wenn sich jemand anders um Werte kümmern würde. Eigentlich möchte ich Werte erst angehen, wenn der Regelsatz für Schlüssel halbwegs stabil ist, und wie gesagt erwarte ich für diesen ein eher schlechtes Konvergenzverhalten.

PS. track_visibility, saisonal und osm:symbol sind raus (aus dem Regelsatz auf meiner Festplatte, nicht aus dem obigen Posting). Wenn noch jemand andere Probleme findet, immer her damit.