Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler?

S-Man42 · 2013-10-10 07:58:09

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.

Oli-Wan · 2013-10-10 11:53:37

errt wrote:

Grundsätzlich scheint mir aber dein Ansatz zur Generierung von Kandidaten nicht schlecht, auch wenn wahrscheinlich ein Verhältnis < 500 und eine Levenshtein-Distanz von 2 noch einige gute Kandidaten bringen könnte - aber natürlich auch wesentlich mehr falsch-positive, die man aussortieren muss.

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.

Last edited by Oli-Wan (2013-10-10 12:11:49)

errt · 2013-10-10 12:39:12

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.

hurdygurdyman · 2013-10-10 13:15:26

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

Netzwolf · 2013-10-10 13:29:07

Nahmd,

Oli-Wan wrote:

Damerau-Levenshtein bis zwei liefert überwiegend eher kuriose als wirklich brauchbare Verbindungen.

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

wambacher · 2013-10-10 14:36:00

hurdygurdyman wrote:

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

PostgreSQL verwendet neben die üblichen Pattern-Mechanismen auch noch andere Fuzzi-Searches: http://www.postgresql.org/docs/current/ … match.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

Gruss
walter

Basstoelpel · 2013-10-10 14:41:03

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

Oli-Wan · 2013-10-10 15:17:36

wambacher wrote:

PostgreSQL verwendet neben die üblichen Pattern-Mechanismen auch noch andere Fuzzi-Searches: http://www.postgresql.org/docs/current/ … match.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

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.

wambacher · 2013-10-10 16:21:26

Oli-Wan wrote:

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.

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 Für mich ist das allerdings ein reizvoller Ansatz.

Gruss
walter

hurdygurdyman · 2013-10-11 06:19:33

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

wambacher · 2013-10-11 06:23:40

hurdygurdyman wrote:

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

Gruss
walter

Oli-Wan · 2013-10-11 08:29:30

hurdygurdyman wrote:

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

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.

chris66 · 2013-10-11 09:35:25

Oli-Wan wrote:

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.

hurdygurdyman · 2013-10-11 09:45:34

Oli-Wan wrote:

hurdygurdyman wrote:
Bekommt man mit Wall-E auch die Singular>Plural-Problematik in den Griff? Ich denke da z.B. an access=customer>customers und so.
Technisch: ja, mühelos (allerdings erst im späteren zweiten Schritt, wenn es um Tagwerte zu gegebenen Schlüsseln geht).
...(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 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.

Last edited by hurdygurdyman (2013-10-11 10:29:25)

Oli-Wan · 2013-10-11 10:25:27

hurdygurdyman wrote:

Und konkurrierende Schemata sollten wir doch im Interesse einer sauberen Datenbank, der Verhinderung von Redundanzen und von vermeidbarem Auswertungsaufwand zu verhindern suchen.

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:

Das wird man sich aber für jeden Wert näher ansehen müssen, ...

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.

Oli-Wan · 2013-10-11 11:44:04

Oli-Wan wrote:

wambacher wrote:
PostgreSQL verwendet neben die üblichen Pattern-Mechanismen auch noch andere Fuzzi-Searches: http://www.postgresql.org/docs/current/ … match.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
Danke für den Tipp. Habe mir gerade mal ein Soundex geschrieben und ausprobiert; leider mit mäßigen Ergebnissen. ... Eventuell ist Metaphone hier besser, werde ich bei Gelegenheit evtl. auch noch ausprobieren.

Gerade getan. Metaphone findet in der Tat weniger totalen Unfug als Soundex, aber die sinnvollen Zuordnungen stehen größtenteils bereits auf der Liste. Insbesondere der Austausch von Vokalen ändert auch den Metaphone-Code häufig überhaupt nicht.
War in jedem Fall interessant, sich einmal mit diesen Algorithmen zu befassen. Eventuell behalte ich Metaphone auch im Programm drin, ein paar Kandidaten hat er ja doch noch geliefert. Hier nochmal einige weitere Ergänzungen für den Regelsatz; die meisten wurden zwar mit den anderen Methoden auch schon gefunden, ich habe sie aber im großen Haufen übersehen.

amnety (1)
         --> amenity (1180611)
baoat (4)
         --> boat (21156)
cliub (1)
         --> club (392)
cuiseine (1)
         --> cuisine (53559)
intermittend (7)
         --> intermittent (1417)
operater (1)
         --> operator (308297)
propsoed (1)
         --> proposed (5113)
tactilie_paving (8)
         --> tactile_paving (15116)
trycktape (2)
         --> tracktype (1551734)
whitwater (1)
         --> whitewater (756)
tinnel (1)
         --> tunnel (125528)

Zur allgemeinen Unterhaltung auch noch einige ausgewählte Kuriositäten aus dem Hause Metaphone:

bascule (1)
         --> bicycle (683084)
bit (30)
         --> boat (21156)
casino (1)
         --> cuisine (53559)
cats (2)
         --> goods (4507)
coins (2)
         --> genus (7045)
died (3)
         --> TODO (1964)
         --> todo (1212)
diet (5)
         --> TODO (1964)
         --> todo (1212)
highres (3)
         --> horse (67616)
litter (2)
         --> ladder (439)
lotterie (1)
         --> ladder (439)
police (9)
         --> place (119095)

errt · 2013-10-11 16:43:47

Sieht doch gut aus. Hätte nicht gedacht, dass so ein Ansatz wirklich was bringt (letztendlich sind ja auch die gefundenen wohl eher Tippfehler als von Leuten produziert, die soz. geschrieben haben, was sie sprechen). Die Kuriositäten find ich garnicht mal so kurios, mal abgesehen von den todos hört sich das bei mir, wenn ich (gezielt) ein wenig 'schlabberig' spreche, schon sehr ähnlich an. Nachdem ich Soundex schon kannte (und für reichlich unbrauchbar halte), bin ich doch erstaunt, dass es da doch auch Algorithmen gibt, die halbwegs vernünftig sind. Wenn auch in dem Fall nur für die englische Sprache, aber das reicht hier ja.

Oli-Wan · 2013-10-14 14:57:53

Ich habe gerade einen größeren Testlauf mit dem gesamten obigen Regelsatz durchgeführt, im Gegenzug auf einem deutlich kleineren Gebiet (Saarland) als später vorgesehen.
Das ganze ist auf dem dev-Klon der API mit zuvor dorthin kopierten OSM-Originaldaten erfolgt (d.h. im Unterschied zu Simulationen wird das Hochladen nicht ausgespart, sondern erfolgt bloß zu einem anderen Server; dieser Test ist also völlig äquivalent zu einem Test gegen die echte API).
Dies ist der Änderungssatz: http://api06.dev.openstreetmap.org/brow … eset/32240
Log:

osm-mechedit-fix-misspell run Mon Oct 14 15:39:56 2013
created changeset #32240, http://www.openstreetmap.org/browse/changeset/32240
editing node 4295798690: http://www.openstreetmap.org/browse/node/4295798690
	replacing misspelt tag key "addr.city" -> "addr:city"
editing node 4295798691: http://www.openstreetmap.org/browse/node/4295798691
	replacing misspelt tag key "add:city" -> "addr:city"
editing way 4295042659: http://www.openstreetmap.org/browse/way/4295042659
	replacing misspelt tag key "Source" -> "source"
editing way 4295042660: http://www.openstreetmap.org/browse/way/4295042660
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042661: http://www.openstreetmap.org/browse/way/4295042661
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042662: http://www.openstreetmap.org/browse/way/4295042662
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042663: http://www.openstreetmap.org/browse/way/4295042663
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042664: http://www.openstreetmap.org/browse/way/4295042664
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042665: http://www.openstreetmap.org/browse/way/4295042665
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042666: http://www.openstreetmap.org/browse/way/4295042666
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042667: http://www.openstreetmap.org/browse/way/4295042667
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042668: http://www.openstreetmap.org/browse/way/4295042668
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042669: http://www.openstreetmap.org/browse/way/4295042669
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042670: http://www.openstreetmap.org/browse/way/4295042670
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042671: http://www.openstreetmap.org/browse/way/4295042671
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042672: http://www.openstreetmap.org/browse/way/4295042672
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042673: http://www.openstreetmap.org/browse/way/4295042673
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042674: http://www.openstreetmap.org/browse/way/4295042674
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042675: http://www.openstreetmap.org/browse/way/4295042675
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042676: http://www.openstreetmap.org/browse/way/4295042676
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042677: http://www.openstreetmap.org/browse/way/4295042677
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042678: http://www.openstreetmap.org/browse/way/4295042678
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042679: http://www.openstreetmap.org/browse/way/4295042679
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042680: http://www.openstreetmap.org/browse/way/4295042680
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042681: http://www.openstreetmap.org/browse/way/4295042681
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042682: http://www.openstreetmap.org/browse/way/4295042682
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042683: http://www.openstreetmap.org/browse/way/4295042683
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042684: http://www.openstreetmap.org/browse/way/4295042684
	removing misspelt tag key "buidling:use" (tag "building:use" present with identical value)
editing way 4295042685: http://www.openstreetmap.org/browse/way/4295042685
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042686: http://www.openstreetmap.org/browse/way/4295042686
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042687: http://www.openstreetmap.org/browse/way/4295042687
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042688: http://www.openstreetmap.org/browse/way/4295042688
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042689: http://www.openstreetmap.org/browse/way/4295042689
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042690: http://www.openstreetmap.org/browse/way/4295042690
	replacing misspelt tag key "buidling:use" -> "building:use"
editing way 4295042691: http://www.openstreetmap.org/browse/way/4295042691
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042692: http://www.openstreetmap.org/browse/way/4295042692
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042693: http://www.openstreetmap.org/browse/way/4295042693
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042694: http://www.openstreetmap.org/browse/way/4295042694
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042695: http://www.openstreetmap.org/browse/way/4295042695
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042696: http://www.openstreetmap.org/browse/way/4295042696
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042697: http://www.openstreetmap.org/browse/way/4295042697
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042698: http://www.openstreetmap.org/browse/way/4295042698
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042699: http://www.openstreetmap.org/browse/way/4295042699
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042700: http://www.openstreetmap.org/browse/way/4295042700
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042701: http://www.openstreetmap.org/browse/way/4295042701
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042702: http://www.openstreetmap.org/browse/way/4295042702
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042703: http://www.openstreetmap.org/browse/way/4295042703
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042704: http://www.openstreetmap.org/browse/way/4295042704
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042705: http://www.openstreetmap.org/browse/way/4295042705
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042706: http://www.openstreetmap.org/browse/way/4295042706
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042707: http://www.openstreetmap.org/browse/way/4295042707
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042708: http://www.openstreetmap.org/browse/way/4295042708
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042709: http://www.openstreetmap.org/browse/way/4295042709
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042710: http://www.openstreetmap.org/browse/way/4295042710
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042711: http://www.openstreetmap.org/browse/way/4295042711
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042712: http://www.openstreetmap.org/browse/way/4295042712
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042713: http://www.openstreetmap.org/browse/way/4295042713
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042714: http://www.openstreetmap.org/browse/way/4295042714
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042715: http://www.openstreetmap.org/browse/way/4295042715
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042716: http://www.openstreetmap.org/browse/way/4295042716
	removing misspelt tag key "adddr:city" (tag "addr:city" present with identical value)
editing way 4295042717: http://www.openstreetmap.org/browse/way/4295042717
	replacing misspelt tag key "adddr:city" -> "addr:city"
editing way 4295042718: http://www.openstreetmap.org/browse/way/4295042718
	replacing misspelt tag key "MTB:scale" -> "mtb:scale"
editing way 4295042719: http://www.openstreetmap.org/browse/way/4295042719
	replacing misspelt tag key "MTB:scale" -> "mtb:scale"
editing way 4295042720: http://www.openstreetmap.org/browse/way/4295042720
	replacing misspelt tag key "MTB:scale" -> "mtb:scale"
total number of objects modified: 64

Erste reale Bearbeitungen würde ich mal für nächste Woche ansetzen, falls sich bis dahin nicht doch noch Widerspruch regt.

MasiMaster · 2013-10-15 21:02:03

EvanE wrote:

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.

+1
Oder man nimmt den hgb-value als Referenz hinzu. Bei destination deutet es auf "hgv" hin, bei #ff00ff oder so könnte es vielleicht "rgb" sein. Die values "yes" & "no" sind natürlich ein schlechter Indikator.

seichter · 2013-10-15 21:26:07

MasiMaster wrote:

EvanE wrote:
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.
+1
Oder man nimmt den hgb-value als Referenz hinzu. Bei destination deutet es auf "hgv" hin, bei #ff00ff oder so könnte es vielleicht "rgb" sein. Die values "yes" & "no" sind natürlich ein schlechter Indikator.

Das erscheint mir ein bisschen wackelig (und aufwendig) für einen Bot-Lauf.
Das würde ich allerhöchstens für eine spätere Verfeinerung in Betracht ziehen (so denn dieser Fall im unbearbeiteten Rest häufig genug auftritt).

Der Aufwand für die letzten Prozent an Fehlern dürfte wie so oft exponentiell ansteigen.

EvanE · 2013-10-15 21:34:02

Oli-Wan wrote:

Ich habe gerade einen größeren Testlauf mit dem gesamten obigen Regelsatz durchgeführt, im Gegenzug auf einem deutlich kleineren Gebiet (Saarland) als später vorgesehen.
Das ganze ist auf dem dev-Klon der API mit zuvor dorthin kopierten OSM-Originaldaten erfolgt (d.h. im Unterschied zu Simulationen wird das Hochladen nicht ausgespart, sondern erfolgt bloß zu einem anderen Server; ...).
Dies ist der Änderungssatz: http://api06.dev.openstreetmap.org/brow … eset/32240
...
Erste reale Bearbeitungen würde ich mal für nächste Woche ansetzen, falls sich bis dahin nicht doch noch Widerspruch regt.

Sieht gut aus.
Interessant finde ich, dass du Taggs mit falsch geschriebenenem Schlüssel entfernst, wenn die richtige Schreibweise bereits mit dem gleichen Wert existiert.

Von meiner Seite also ein klares GO!

Edbert (EvanE)

Oli-Wan · 2013-10-16 19:51:07

Neues für den Regelsatz (bisher übersehen, erst durch Metaphone aufgetaucht oder schlicht ganz neu im Datenbestand):

abondened (1)
         --> abandoned (3071)
attraktion (1)
         --> attraction (1420)
attrection (13)
         --> attraction (1420)
cemetry (4)
         --> cemetery (675)

chnage:lanes (1)
         --> change:lanes (2541)
communication:mobile_phones (5)
         --> communication:mobile_phone (928)
contact:mobil (1)
         --> contact:mobile (193)
couisin (3)
         --> cuisine (53725)

crossing:ref (1)
         --> crossing_ref (13739)
drive-through (1)
         --> drive_through (703)
est_hight (3)
         --> est_height (379)

fecne_type (1)
         --> fence_type (5433)
fence_typ (1)
         --> fence_type (5433)
fench_type (1)
         --> fence_type (5433)
footway=right (2)
         --> footway:right (475)

oeprator (1)
         --> operator (309730)
opeartor (1)
         --> operator (309730)
payment:credit_card (3)
         --> payment:credit_cards (2605)
payment:debit_card (1)
         --> payment:debit_cards (2009)
payment:mastercar (1)
         --> payment:mastercard (362)

playgroung (1)
         --> playground (2385)
tactile_pafing (2)
         --> tactile_paving (15252)
traffic_signals:sounds (2)
         --> traffic_signals:sound (1378)
whelchair (1)
         --> wheelchair (304396)

EvanE · 2013-10-16 20:39:23

Oli-Wan wrote:

Neues für den Regelsatz (bisher übersehen, erst durch Metaphone aufgetaucht oder schlicht ganz neu im Datenbestand):
abondened (1) --> abandoned (3071)
attraktion (1) --> attraction (1420)
attrection (13) --> attraction (1420)
cemetry (4) --> cemetery (675)
chnage:lanes (1) --> change:lanes (2541)
communication:mobile_phones (5) --> communication:mobile_phone (928)
contact:mobil (1) --> contact:mobile (193)
couisin (3) --> cuisine (53725)
crossing:ref (1) --> crossing_ref (13739)
drive-through (1) --> drive_through (703)
est_hight (3) --> est_height (379)
fecne_type (1) --> fence_type (5433)
fence_typ (1) --> fence_type (5433)
fench_type (1) --> fence_type (5433)
footway=right (2) --> footway:right (475)
oeprator (1) --> operator (309730)
opeartor (1) --> operator (309730)
payment:credit_card (3) --> payment:credit_cards (2605)
payment:debit_card (1) --> payment:debit_cards (2009)
payment:mastercar (1) --> payment:mastercard (362)
playgroung (1) --> playground (2385)
tactile_pafing (2) --> tactile_paving (15252)
traffic_signals:sounds (2) --> traffic_signals:sound (1378)
whelchair (1) --> wheelchair (304396)

Mit "abandoned" habe ich auch so meine Schwierigkeiten.
Ich muss die genaue Schreibweise oft nachsehen.

Ansonsten sind das typische Problemfälle mit Trennzeichen, Einzahl/Mehrzahl, fehlenden Buchstaben oder Buchstabendreher.
Von meiner Seite aus gibt es keine Einwände, das wie aufgelistet in die Regeln zu übernehmen.

Edbert (EvanE)

FvGordon · 2013-10-20 16:48:48

Hallo,

um nochmals auf meinen Vorschlag von Post #5 zu kommen, das Komma, das fälschlicherweise als Dezimaltenner in der Datenbank steht, per Bot (Wall·E) zu korrigieren (z.B. per Regular Expression: "0 bis 5 Ziffern, ',', 1 bis 12 Ziffern, beliebige Zeichen (z.B. Einheit - meist 'm' für Meter)", denn es gibt auch Vorkmmen wie z.B. ",95") habe ich bei Taginfo die Häufigkeit dieses (Tipp-)Fehlers nachgesehen (am Beispiel von width=*):

2.5: 27 511 mal ok (als 7. Eintrag)
2,5: 11 092 mal fehlerhaft (als 13. Eintrag) (28,7 % bei diesem Wert)

1.5: 22 036 mal ok
1,5: 5 395 mal fehlerhaft (19,7 %)

0.5: 18 480 mal ok
0,5: 6 292 mal fehlerhaft (25,4 %)

Die allermeisten der mit Komma geschriebenen Werte befinden sich in Deutschland - deshalb finde ich Wall·E hier den idealen Bot, diese Tippfehler zu korrigieren, denn die etwa 11000 falschen Einträge des Wertes 2,5 möchte ich nicht von Hand korrigieren - das wird dann vermutlich auf einen Revert von Frederik hinauslaufen (wie beim Thema Hauseingänge geschehen: building=entrance -> entrance=yes).

Bei height=* kommen die ersten Werte mit Komma erst ab etwa Eintrag 300 der Taginfo mit Häufigkeiten in den 70-ern vor.

Franz

EvanE · 2013-10-20 22:19:51

FvGordon wrote:

um nochmals auf meinen Vorschlag von Post #5 zu kommen, das Komma, das fälschlicherweise als Dezimaltenner in der Datenbank steht, per Bot (Wall·E) zu korrigieren (z.B. per Regular Expression: "0 bis 5 Ziffern, ',', 1 bis 12 Ziffern, beliebige Zeichen (z.B. Einheit - meist 'm' für Meter)", denn es gibt auch Vorkommen wie z.B. ",95") habe ich bei Taginfo die Häufigkeit dieses (Tipp-)Fehlers nachgesehen (am Beispiel von width=*):
2.5: 27 511 mal ok 2,5: 11 092 mal fehlerhaft
1.5: 22 036 mal ok 1,5: 5 395 mal fehlerhaft
0.5: 18 480 mal ok 0,5: 6 292 mal fehlerhaft
Die allermeisten der mit Komma geschriebenen Werte befinden sich in Deutschland - deshalb finde ich Wall·E hier den idealen Bot, diese Tippfehler zu korrigieren, denn die etwa 11000 falschen Einträge des Wertes 2,5 möchte ich nicht von Hand korrigieren - das wird dann vermutlich auf einen Revert von Frederik hinauslaufen (wie beim Thema Hauseingänge geschehen: building=entrance -> entrance=yes).

Hallo Franz

Vorab: In diesem Thread reden wir über die Korrektur von Schlüsseln.
Das ist also eigentlich der falsche Platz für die Korrekur von Werten.
Wir/du sollten dafür besser einen eigenen Thread starten.

Generell ist diese Sache sicher eines der größeren Probleme bei den Werten, wie deine Zahlen eindrücklich belegen.
Warum das in Deutschland so viel häufiger als in anderen Ländern passiert ist leicht erklärt:
Im Ziffernblock ist bei deutscher Tastatur-Belegung das Komma als Dezimaltrenner kodiert und nicht der Punkt, wie bei den meisten anderen Belegungen.

Du könntest das durchaus einmalig (oder auch auf Dauer) selber machen, wenn du es vorab ankündigst, diskutierst (mindestens Forum und talk-de), dokumentierst und ausgiebig testest. Dann hättest du wohl kaum etwas von Frederik oder einem anderen Mitglied der Data Working Group (DWG) zu befürchten. Die Regeln für automatisierte Edits sind für so etwas Umfangreiches eben zu beachten.

Ich denke, dass die Zeit dafür durchaus reif ist, da in der nächsten stabilen JOSM Version (endlich!) ein Test auf numerische Werte eingebaut sein wird. Damit wird sich die Situation wahrscheinlich auch ohne Bot (wenn auch langsam) bessern.

Edbert (EvanE)

Announcement

#26 2013-10-10 07:58:09

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

#27 2013-10-10 11:53:37

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

#28 2013-10-10 12:39:12

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

#29 2013-10-10 13:15:26

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

#30 2013-10-10 13:29:07

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

#31 2013-10-10 14:36:00

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

#32 2013-10-10 14:41:03

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

#33 2013-10-10 15:17:36

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

#34 2013-10-10 16:21:26

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

#35 2013-10-11 06:19:33

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

#36 2013-10-11 06:23:40

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

#37 2013-10-11 08:29:30

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

#38 2013-10-11 09:35:25

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

#39 2013-10-11 09:45:34

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

#40 2013-10-11 10:25:27

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

#41 2013-10-11 11:44:04

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

#42 2013-10-11 16:43:47

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

#43 2013-10-14 14:57:53

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

#44 2013-10-15 21:02:03

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

#45 2013-10-15 21:26:07

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

#46 2013-10-15 21:34:02

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

#47 2013-10-16 19:51:07

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

#48 2013-10-16 20:39:23

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

#49 2013-10-20 16:48:48

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

#50 2013-10-20 22:19:51

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

Board footer