Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler?

Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 07.10.2013 21:10 · [flux]
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. Ein gewisses Aufkommen falsch geschriebener Tags ist jedenfalls nicht zu verneinen, wenn man etwa mittels der /browse/changesets-Seite verfolgt, in welchem Umfang entsprechende Korrekturen händisch durchgeführt werden. Eine gewisse Entlastung scheint mir schon sinnvoll, eingeschränkt natürlich auf Fälle, die nach menschlichem Ermessen eindeutig sind.

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.

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? Oder Neuerungen einfach ohne Diskussion/Vorstellung einpflegen, solange sie sich in das Muster der bereits vorhandenen einfügen? Die aktuell verwendete Liste müßte natürlich in jedem Fall offenliegen.

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 (in Klammern jeweils die Häufigkeit im Geofabrik-Extrakt):
```
key␣add:city␣(72)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣adddr:city␣(35)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣adde:city␣(138)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣addr.city␣(38)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣addr::city␣(3)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣addr:ciry␣(2)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣addr:ciy␣(2)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣addr:dity␣(1)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣addr:sity␣(5)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣addr;city␣(2)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣addr_city␣(16)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣adr:city␣(16)␣might␣be␣a␣misspelling␣of␣key␣addr:city␣(3887819)
key␣add:country␣(57)␣might␣be␣a␣misspelling␣of␣key␣addr:country␣(3398437)
key␣addr.country␣(63)␣might␣be␣a␣misspelling␣of␣key␣addr:country␣(3398437)
key␣addr:counry␣(1)␣might␣be␣a␣misspelling␣of␣key␣addr:country␣(3398437)
key␣addr:county␣(50)␣might␣be␣a␣misspelling␣of␣key␣addr:country␣(3398437)
key␣addr:coutry␣(7)␣might␣be␣a␣misspelling␣of␣key␣addr:country␣(3398437)
key␣addr:ountry␣(1)␣might␣be␣a␣misspelling␣of␣key␣addr:country␣(3398437)
key␣addr_country␣(7)␣might␣be␣a␣misspelling␣of␣key␣addr:country␣(3398437)
key␣adr:country␣(1)␣might␣be␣a␣misspelling␣of␣key␣addr:country␣(3398437)
key␣add:housename␣(1)␣might␣be␣a␣misspelling␣of␣key␣addr:housename␣(30914)
key␣addr:housenumber2␣(1)␣might␣be␣a␣misspelling␣of␣key␣addr:housenumber␣(4554402)
key␣addr:housenumberf␣(2)␣might␣be␣a␣misspelling␣of␣key␣addr:housenumber␣(4554402)
key␣add:postcode␣(4)␣might␣be␣a␣misspelling␣of␣key␣addr:postcode␣(3963213)
key␣add:street␣(3)␣might␣be␣a␣misspelling␣of␣key␣addr:street␣(4497705)
key␣addr::street␣(1)␣might␣be␣a␣misspelling␣of␣key␣addr:street␣(4497705)
key␣addr:street2␣(1)␣might␣be␣a␣misspelling␣of␣key␣addr:street␣(4497705)
key␣add:suburb␣(277)␣might␣be␣a␣misspelling␣of␣key␣addr:suburb␣(292765)
key␣addR:suburb␣(1)␣might␣be␣a␣misspelling␣of␣key␣addr:suburb␣(292765)
key␣addr_suburb␣(13)␣might␣be␣a␣misspelling␣of␣key␣addr:suburb␣(292765)
```
Auch bei Gebäuden, insbesondere den neumodischen 3D-Tags, gibt es einige recht klare Fälle:
```
key␣Building␣(1)␣might␣be␣a␣misspelling␣of␣key␣building␣(11592169)
key␣bulding␣(2)␣might␣be␣a␣misspelling␣of␣key␣building␣(11592169)
key␣building:coulor␣(2)␣might␣be␣a␣misspelling␣of␣key␣building:color␣(3474)
key␣building_color␣(1)␣might␣be␣a␣misspelling␣of␣key␣building:color␣(3474)
key␣building;colour␣(1)␣might␣be␣a␣misspelling␣of␣key␣building:colour␣(28846)
key␣building_height␣(1)␣might␣be␣a␣misspelling␣of␣key␣building:height␣(30333)
key␣building;levels␣(1)␣might␣be␣a␣misspelling␣of␣key␣building:levels␣(118554)
key␣building_levels␣(2)␣might␣be␣a␣misspelling␣of␣key␣building:levels␣(118554)
key␣builging:levels␣(1)␣might␣be␣a␣misspelling␣of␣key␣building:levels␣(118554)
key␣bulding:material␣(10)␣might␣be␣a␣misspelling␣of␣key␣building:material␣(22029)
key␣building_part␣(3)␣might␣be␣a␣misspelling␣of␣key␣building:part␣(15636)
key␣building_type␣(3)␣might␣be␣a␣misspelling␣of␣key␣building:type␣(26642)
key␣building_type:de␣(1)␣might␣be␣a␣misspelling␣of␣key␣building:type:de␣(993)
```
Gegenbeispiele: Bei Sprachzusätzen (:XX) versagt das Suchkriterium völlig.
```
key␣name:dv␣(11)␣might␣be␣a␣misspelling␣of␣key␣name:de␣(5837)
key␣name:dz␣(11)␣might␣be␣a␣misspelling␣of␣key␣name:de␣(5837)
key␣name:sn␣(1)␣might␣be␣a␣misspelling␣of␣key␣name:en␣(2887)
```
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 (das auch als Argument, warum ich keine Änderung allein anhand der Editierdistanz vornehmen möchte):
```
key␣biking␣(2)␣might␣be␣a␣misspelling␣of␣key␣hiking␣(39475)
```
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Thomas8122 (Gast) · 07.10.2013 21:21 · [flux]
  
  Oli-Wan wrote:
  
  key building:coulor (2) might be a misspelling of key building:color (3474)
  
  Da wir British English verwenden, sollte es wohl eher colour heißen. Ansonsten bin ich dafür.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · seichter (Gast) · 07.10.2013 21:40 · [flux]
  
  Generell sinnvoll.
  Ich weiß nicht, ob es einen Vorteil brächte, wenigstens ein paar reguläre Ausdrücke zu verwenden, um die Liste zu verkleinern.
  Beispiel: Schlüssel addr*city (* aus :: ; _ u.ä).
  Levenshtein allein halte ich auch für zu gefährlich (für einen Bot).
  
  building:colour ist mit 28846 gelistet, color (3474) liegt aber näher an coulor, Handarbeit ist also nicht zu vermeiden.
  
  Zusatz: Es sei denn, man schaltet in diesem Fall einen Durchgang building:color -> building:colour vor.
  Über mehrere konsekutive Durchläufe ließe sich die Liste vermutlich verkürzen.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 08.10.2013 01:20 · [flux]
  
  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)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · FvGordon (Gast) · 08.10.2013 07:20 · [flux]
  
  Hallo,
  
  mir ist aufgefallen, dass z.B. in Deutschland auch häufig fälschlicherweise das Komma als Dezimaltrenner verwendet wird - bei width=* habe ich das sehr oft bemerkt. Da könnte der Bot ja auch in der ersten Zeit (z.B. einige Wochen) alle Vorkommen eines Kommas im Value sammeln, um dann von Hand zu entscheiden, welche Werte für den Key verwendet werden sollen, in denen er bei gefundenem Komma dieses durch Punkt ersetzt werden soll (width, height, ...).
  
  Franz
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · hurdygurdyman (Gast) · 08.10.2013 07:26 · [flux]
  
  @Oli-Wan.
  Ich finde das eine super Idee.
  Denk bitte auch an den ganzen turn:lanes-Bereich. Keys wie "turn:lanes:backward" oder values wie "left|slight_left|through|through;right" sind nicht nur aufgrund der vielfältigen Kombinationsmöglichkeiten sehr fehleranfällig, wie ich aus eigener Erfahrung weiß.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · PeterPablo (Gast) · 08.10.2013 08:50 · [flux]
  
  Oli-Wan, bezüglich der Sprachzusätze in den Tags wäre ein denkbarer Ansatz (der sich auch in einen regulären Ausdruck gießen lassen sollte), dass vor der Levenshtein-Distanz-Überprüfung zunächst sichergestellt wird, dass Bestandteile vor/nach Doppelpunkten aus mehr als zwei (Parameter) Zeichen bestehen.
  
  Ein Tag "turn:lanes:backward" würde in die drei Bestandteile "turn", "lanes", "backward" zerlegt werden. Jeder dieser Bestandteile kann einzeln der Levenshtein-Distanz-Überprüfung unterzogen werden, da er jeweils aus mehr als zwei (Parameter) Zeichen besteht.
  
  Gegenbeispiel: Ein Tag "namee:dk" wird zunächst in die Bestandteile "namee" und "dk" zerlegt. Der Bestandteil "namee" ist lang genug und wird überprüft und auf "name" korrigiert. Der Bestandteil "dk" ist zu kurz und wird folglich nicht modifiziert.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · errt (Gast) · 08.10.2013 11:04 · [flux]
  
  Ich halte das für eine sehr gute Idee.
  
  Auf jeden Fall ist klar ersichtlich, dass es eine feste Liste braucht, eine vollautomatische Korrektur scheidet aus, wie man an verschiedenen Beispielen sieht. Außerdem würde es das sonst völlig unmöglich machen, neue Tags einzuführen, die etablierten sehr ähnlich sind.
  
  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.
  
  EvanE wrote:
  
  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.
  
  Da muss man aber aufpassen, dass man z.B. addr:country=Deutschland nicht in addr:county=Deutschland ändert, weil der Wert ja kein Ländercode ist.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 08.10.2013 13:30 · [flux]
  An dem Algorithmus für die Suche nach möglichen Vertippern (der, wie gesagt, nur Kandidaten für die anschließend noch manuell zu prüfende Liste liefern soll) bastle ich noch; die angegebenen Parameter waren der allererste Versuch (abgesehen von Testläufen auf kleineren Extrakten). Zum einen war das Programm noch zu langsam, was aber mittlerweile halbwegs unter Kontrolle ist (gestern etwa 2 Stunden für DE, heute 5 Minuten).
  zum anderen müssen die Kriterien und Parameter noch verbessert werden. Als ersten Schritt bin ich von Levenshtein auf Damerau-Levenshtein umgestiegen, sodaß nun auch die wichtige Klasse der Nachbartranspositionen als nur ein Schritt zählt. Übereinstimmung bis auf Groß-/Kleinschreibung etwa wäre auch noch interessant, oder "Abkürzungen" (mit bui könnte eher building als bus gemeint gewesen sein). Ob die dann letztendlich in der Korrekturliste landen oder nur helfen, Ambiguitäten zu finden (konkret: die Ersetzung bui->bus auszuschließen), ist eine andere Frage. Ein Abfallprodukt könnte in der Tat, wie von EvanE skizziert, eine Sammlung nicht automatisch korrigierbarer Fehler sein, auf daß Mapper sich gezielt darum kümmern können.
  
  Edit: Beispiele. Vertauschungen:
```
key␣caapcity␣(1)␣might␣be␣a␣misspelling␣of␣key␣capacity␣(8450)
key␣cosntruction␣(2)␣might␣be␣a␣misspelling␣of␣key␣construction␣(1839)
key␣shpo␣(1)␣might␣be␣a␣misspelling␣of␣key␣shop␣(45652)
```
  "Abkürzungen"; der Algorithmus liefert natürlich alle, nicht nur die naheliegendsten - was aber auch kein Nachteil ist, sondern gerade die Mehrdeutigkeit aufzeigt.
```
key␣bui␣(8)␣might␣be␣a␣misspelling/shortcut␣of␣key␣building␣(2409980)
key␣bui␣(8)␣might␣be␣a␣misspelling/shortcut␣of␣key␣building:colour␣(13175)
key␣bui␣(8)␣might␣be␣a␣misspelling/shortcut␣of␣key␣building:levels␣(35453)
key␣bui␣(8)␣might␣be␣a␣misspelling/shortcut␣of␣key␣building:material␣(9846)
key␣bui␣(8)␣might␣be␣a␣misspelling/shortcut␣of␣key␣building:roof␣(5353)
key␣bui␣(8)␣might␣be␣a␣misspelling/shortcut␣of␣key␣building:roof:shape␣(4901)
key␣bui␣(8)␣might␣be␣a␣misspelling/shortcut␣of␣key␣building:type␣(6072)
key␣bui␣(8)␣might␣be␣a␣misspelling/shortcut␣of␣key␣building:use␣(11707)
key␣bui␣(8)␣might␣be␣a␣misspelling␣of␣key␣bus␣(20048)
```
  @PeterPablo: die Idee der Trennung in Subtags werde ich mal im Hinterkopf behalten, danke dafür. Für den Moment schaue ich nur auf die kompletten Schlüssel. Aber letztlich müssen gar nicht alle Tippfehler gefunden werden; die zu erstellende Liste von Korrekturregeln kann ja jederzeit manuell erweitert werden.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 08.10.2013 14:58 · [flux]
  
  errt wrote:
  
  EvanE wrote:
  
  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.
  
  Da muss man aber aufpassen, dass man z.B. addr:country=Deutschland nicht in addr:county=Deutschland ändert, weil der Wert ja kein Ländercode ist.
  
  In Deutschland und vermutlich den meisten Ländern in Mitteleuropa ist das wie gesagt kein reales Problem, da die Kreise anders als z.B. in den USA nicht für Adressen verwendet werden.
  
  Unabhängig davon, bleibt festzuhalten, dass eine Korrektur von addr:country nach addr:county nicht sinnvoll wäre. Die Adress-Korrekturen beheben ja zum Glück eine Vielzahl von addr:country-Fehlern, dort wo diese ausgeführt werden.
  
  Die Frage bleibt, ob es sinvoll wäre addr:county=DE/UK/FR/... zu addr:country=* zu korrigieren. Na ja, das gehört wohl eher zu den Adress-Korrekturen.
  
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · errt (Gast) · 08.10.2013 20:35 · [flux]
  
  Es ist ja nicht nur country<->county. Was würde denn ein automatisches System aus add:count=Deutschland machen? Distanz zu addr:county ist 1, zu addr:country 2 und der Inhalt ist offensichtlich kein Ländercode. Also im Umfeld dieser beiden Tags wäre ich vorsichtig. Höchstens wenn wirklich ein Ländercode im Wert steht, könnte man auf addr:country schließen - aber auch da ist die Frage, ob es nicht Kürzel für Landkreise gibt, die wie Ländercodes aussehen.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 08.10.2013 23:07 · [flux]
  
  errt wrote:
  
  Es ist ja nicht nur country<->county. Was würde denn ein automatisches System aus add:count=Deutschland machen? Distanz zu addr:county ist 1, zu addr:country 2 und der Inhalt ist offensichtlich kein Ländercode. Also im Umfeld dieser beiden Tags wäre ich vorsichtig.
  
  Ich denke, es kommt auf den ursprünglichen Schlüssel an. Bei add:country, addr_country und ähnlichen kommt meines Erachtens nur addr:country als Ersetzungsziel in Frage. addr:count bleibt dagegen wegen der Ambiguität country/county außen vor (wobei country OSM-weit laut Taginfo sogar noch 100-mal häufiger ist als county, in Geofabrik-DE gar 68k-mal, sodaß die Fehlerquote bei Ersetzung durch country vermutlich minimal wäre).
  Auf eine Kontrolle des Wertes (hier: Ländercode oder nicht) würde ich in diesem Zusammenhang lieber verzichten, da dies den Algorithmus enorm verkomplizieren würde. Ohne solche Sonderfälle kann einfach der vorhandene Tagschlüssel gegen eine Liste abgeglichen und ggf. die Ersetzung vorgenommen werden. Der Algorithmus ist klein (bereits implementiert: inklusive rudimentärer Dokumentation, Buchhaltung und Output 22 Zeilen Emacs Lisp), groß wird nur die Liste der Ersetzungsregeln. Mit allerlei Sonderfällen wird auch der Algorithmus groß und die Programmierung fehleranfällig. Vor diesem Hintergrund überlasse ich addr:count und ähnliche Beispiele lieber einem stärker spezialisierten Werkzeug oder gleich menschlichen Mappern.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · slhh (Gast) · 08.10.2013 23:13 · [flux]
  
  Grundsätzlich halte ich die automatische Korrektur insbesondere in Schlüsseln und Werten von Festwert-Tags für sehr sinnvoll, da es dort sehr viel mehr sichere Korrekturmöglichkeiten als bei Straßennamen etc. geben dürfte.
  
  Einige Ideen dazu:
  
  • Es ist nicht nur die Wahrscheinlichkeit des Tippfehlers, sondern auch die Wahrscheinlichkeit relevant, dass dieser nicht erkannt wurde. Zur Beurteilung einer unscharfen Übereinstimmung sollte man daher wohl nicht nur die Editierdistanz, sondern auch die optische Ähnlichkeit berücksichtigen.
  Beispielsweise soll eine Abweichung beim ersten und letzten Buchstaben besonders auffällig sein.
  • Bei der Beurteilung der unscharfen Übereinstimmung von Schlüsseln sollte man auch die Unscharfe übereinstimmung mit aus Festwerten gebildeten Tags einbeziehen. Beispielsweise könnte für ein surface=gravel das surface durch Tippfehler schon arg verunstaltet sein und immer noch sicher erkannt werden.
  • Könnte der Bot das Wiki nach gültigen Schlüsseln und Tags absuchen? Dies könnte z.B. als Sicherheitsmechanismus eingesetzt werden.
  • Wieviel verschiedene Schlüssel haben wir überhaupt in der Datenbank? Dies könnte eine ungefähre Abschätzung ergeben, wie lang die Ersetzungsliste sein muss, da man wohl davon ausgehen kann, dass die meisten Schlüssel Tippfehler sind.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 09.10.2013 01:25 · [flux]
  
  Oli-Wan wrote:
  
  errt wrote:
  
  Es ist ja nicht nur country<->county. Was würde denn ein automatisches System aus add:count=Deutschland machen? Distanz zu addr:county ist 1, zu addr:country 2 und der Inhalt ist offensichtlich kein Ländercode. Also im Umfeld dieser beiden Tags wäre ich vorsichtig.
  
  Ich denke, es kommt auf den ursprünglichen Schlüssel an. Bei add:country, addr_country und ähnlichen kommt meines Erachtens nur addr:country als Ersetzungsziel in Frage. addr:count bleibt dagegen wegen der Ambiguität country/county außen vor (...).
  
  Auf eine Kontrolle des Wertes (hier: Ländercode oder nicht) würde ich in diesem Zusammenhang lieber verzichten, da dies den Algorithmus enorm verkomplizieren würde. Ohne solche Sonderfälle kann einfach der vorhandene Tagschlüssel gegen eine Liste abgeglichen und ggf. die Ersetzung vorgenommen werden. Der Algorithmus ist klein (... 22 Zeilen Emacs Lisp), groß wird nur die Liste der Ersetzungsregeln.
  
  Mit allerlei Sonderfällen wird auch der Algorithmus groß und die Programmierung fehleranfällig. Vor diesem Hintergrund überlasse ich addr:count und ähnliche Beispiele lieber einem stärker spezialisierten Werkzeug oder gleich menschlichen Mappern.
  
  Ich stimme errt und dir zu, addr:count(r)y sollte man einfach nicht bearbeiten, damit passieren zu leicht Fehler (addr:contry -> addr:country mag noch gehen).
  
  Ebenso stimme ich dir zu, dass die Berücksichtigung von Werten für Schlüssel-Korrekturen in der Regel zu aufwändig wären. Fürs Erste das also außen vor lassen. Auf Dauer vielleicht bei speziellen Fällen.
  
  Wenn es an die Korrektur von Werten geht, sollte man die Schlüssel natürlich berücksichtigen (tootway -> footway, nur wenn der Schlüssel highway ist. Sonst wäre das Ergebnis oft unklar. Bei etwas anderem als highway (z.B. name als Schlüssel), könnte auch Toothway gemeint sein. Aber auch Schlüssel/Wert-Paare können mitsamt der Korrektur in einer Liste erfasst werden. Mit einer Schlüssel/Wert-Liste wäre dann auch eine Korrektur addr:county=DE/DK/FR/.. zu addr:country=DE/DK/FR/.. möglich. Wenn der Wert auch Probleme hat, dann unterbleibt eben die Korrektur.
  
  Noch eine Überlegung: Sowohl KeepRight als auch der Validator von JOSM prüfen auf falsche/unbekannte Schlüssel und Werte. Dort kann man sich noch einige Anregungen für die Kandidaten-Liste holen. Man muss ja nicht alles übernehmen.
  
  PS: Schönes Beispiel aus den letzten Tagen: service=gravel.
  Gemeint war wahrscheinlich surface=gravel (falsche Vervollständigung).
  
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Netzwolf (Gast) · 09.10.2013 10:49 · [flux]
  
  Moins,
  
  slhh wrote:
  
  [*]Wieviel verschiedene Schlüssel haben wir überhaupt in der Datenbank? Dies könnte eine ungefähre Abschätzung ergeben, wie lang die Ersetzungsliste sein muss, da man wohl davon ausgehen kann, dass die meisten Schlüssel Tippfehler sind.[/*]
  
  Daumenwert: dreißigtausend.
  
  Gruß Wolf
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 09.10.2013 11:41 · [flux]
  
  slhh wrote:
  
  Es ist nicht nur die Wahrscheinlichkeit des Tippfehlers, sondern auch die Wahrscheinlichkeit relevant, dass dieser nicht erkannt wurde. Zur Beurteilung einer unscharfen Übereinstimmung sollte man daher wohl nicht nur die Editierdistanz, sondern auch die optische Ähnlichkeit berücksichtigen.
  
  Ich gehe davon aus, daß die meisten Fehler mit ähnlich hoher Wahrscheinlichkeit unbemerkt bleiben, sodaß sich keine Hierarchie bilden läßt. Lediglich jene, die unmittelbare Auswirkungen aufs (Mapnik-)Rendering haben, haben eine größere Chance, entdeckt zu werden. Etwa Adresstags werden in der Regel einmal eingetragen und nie wieder angesehen. Gerendert wird nur addr:housenumber; Fehler in den übrigen Schlüsseln und Werten fallen - außer evtl. spezialisierten Mappern, die mit entsprechenden QS-Werkzeugen gezielt danach suchen - nie auf. Aber auch veihcle, food oder masxpeed auf Straßen schlagen sich nicht im Rendering nieder (auch dann nicht, wenn sie richtig geschrieben sind).
  
  Edit/Nachtrag: für diese Sichtweise spricht insbesondere, daß es kaum falsche Schreibweisen von addr:housenumber zu geben scheint (2 Mal addr:housenumberf, 1 Mal addr:housenumber2 - vermutlich Absicht), kein Vergleich zu country und city.
  
  Wie schon mehrfach gesagt ist die automatische Suche anhand von Editierdistanz und Verhältnis der Häufigkeiten nur ein erster Schritt. Danach kommt neben der Eindeutigkeit natürlich die Frage, ob die Entstehung etwa von zracktype aus tracktype tatsächlich plausibel ist (ja, denn t und z liegen auf QWERTZ direkt nebeneinander).
  
  slhh wrote:
  
  Bei der Beurteilung der unscharfen Übereinstimmung von Schlüsseln sollte man auch die Unscharfe übereinstimmung mit aus Festwerten gebildeten Tags einbeziehen. Beispielsweise könnte für ein surface=gravel das surface durch Tippfehler schon arg verunstaltet sein und immer noch sicher erkannt werden.
  
  Möglicherweise in einem späteren Schritt. Ich hatte oben schon begründet, warum ich Werte erst einmal heraushalten möchte. Fehlerhafte Schlüssel, die ohne Untersuchung der Werte (oder gar der übrigen Tags eines Objektes) keinem korrekten Schlüssel eindeutig zugeordnet werden können, bleiben halt unkorrigiert.
  
  slhh wrote:
  
  Könnte der Bot das Wiki nach gültigen Schlüsseln und Tags absuchen? Dies könnte z.B. als Sicherheitsmechanismus eingesetzt werden.
  
  Eher nicht. Die Prüfung, ob etwa "webside" oder "tunnerl" (AT?) doch als "richtige" Schlüssel vorkommen können, muß vorher erfolgen.
  
  slhh wrote:
  
  Wieviel verschiedene Schlüssel haben wir überhaupt in der Datenbank?
  
  Geofabrik-DE: 12571, weltweit siehe Taginfo.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 09.10.2013 13:40 · [flux]
  Mal ein Beispiel, wie der Korrektuprozeß aussehen könnte. Folgendes ist das Log eines Testlaufs ohne Hochladen mit einem sehr beschränkten Regelsatz, ausgeführt auf zuvor aus germany.osm.pbf ausgefilterten Daten (ebenfalls mit einem sehr beschränkten Tagfilter).
```
osm-mechedit-fix-misspell␣run␣Wed␣Oct␣␣9␣14:39:04␣2013
editing␣node␣1323451144:␣http://www.openstreetmap.org/browse/node/1323451144
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣node␣2250017114:␣http://www.openstreetmap.org/browse/node/2250017114
replacing␣misspelt␣tag␣key␣"add:postcode"␣->␣"addr:postcode"
replacing␣misspelt␣tag␣key␣"add:street"␣->␣"addr:street"
editing␣node␣2320100082:␣http://www.openstreetmap.org/browse/node/2320100082
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣node␣2433660679:␣http://www.openstreetmap.org/browse/node/2433660679
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109622780:␣http://www.openstreetmap.org/browse/way/109622780
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109622883:␣http://www.openstreetmap.org/browse/way/109622883
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109622895:␣http://www.openstreetmap.org/browse/way/109622895
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109623001:␣http://www.openstreetmap.org/browse/way/109623001
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109623213:␣http://www.openstreetmap.org/browse/way/109623213
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109623359:␣http://www.openstreetmap.org/browse/way/109623359
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109623773:␣http://www.openstreetmap.org/browse/way/109623773
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109623806:␣http://www.openstreetmap.org/browse/way/109623806
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109623839:␣http://www.openstreetmap.org/browse/way/109623839
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109623933:␣http://www.openstreetmap.org/browse/way/109623933
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109624224:␣http://www.openstreetmap.org/browse/way/109624224
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109624293:␣http://www.openstreetmap.org/browse/way/109624293
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109624356:␣http://www.openstreetmap.org/browse/way/109624356
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109624365:␣http://www.openstreetmap.org/browse/way/109624365
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣109624439:␣http://www.openstreetmap.org/browse/way/109624439
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣132417216:␣http://www.openstreetmap.org/browse/way/132417216
replacing␣misspelt␣tag␣key␣"addr:sity"␣->␣"addr:city"
editing␣way␣147334135:␣http://www.openstreetmap.org/browse/way/147334135
replacing␣misspelt␣tag␣key␣"addr.country"␣->␣"addr:country"
editing␣way␣206806592:␣http://www.openstreetmap.org/browse/way/206806592
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣212616891:␣http://www.openstreetmap.org/browse/way/212616891
replacing␣misspelt␣tag␣key␣"add:country"␣->␣"addr:country"
editing␣way␣212732786:␣http://www.openstreetmap.org/browse/way/212732786
replacing␣misspelt␣tag␣key␣"add:country"␣->␣"addr:country"
editing␣way␣212732797:␣http://www.openstreetmap.org/browse/way/212732797
replacing␣misspelt␣tag␣key␣"add:country"␣->␣"addr:country"
editing␣way␣212732801:␣http://www.openstreetmap.org/browse/way/212732801
removing␣misspelt␣tag␣key␣"add:country"␣(tag␣"addr:country"␣present␣with␣identical␣value)
editing␣way␣212732805:␣http://www.openstreetmap.org/browse/way/212732805
removing␣misspelt␣tag␣key␣"add:country"␣(tag␣"addr:country"␣present␣with␣identical␣value)
editing␣way␣212732807:␣http://www.openstreetmap.org/browse/way/212732807
removing␣misspelt␣tag␣key␣"add:country"␣(tag␣"addr:country"␣present␣with␣identical␣value)
editing␣way␣212732809:␣http://www.openstreetmap.org/browse/way/212732809
removing␣misspelt␣tag␣key␣"add:country"␣(tag␣"addr:country"␣present␣with␣identical␣value)
editing␣way␣212732812:␣http://www.openstreetmap.org/browse/way/212732812
removing␣misspelt␣tag␣key␣"add:country"␣(tag␣"addr:country"␣present␣with␣identical␣value)
editing␣way␣212732814:␣http://www.openstreetmap.org/browse/way/212732814
removing␣misspelt␣tag␣key␣"add:country"␣(tag␣"addr:country"␣present␣with␣identical␣value)
editing␣way␣212732815:␣http://www.openstreetmap.org/browse/way/212732815
removing␣misspelt␣tag␣key␣"add:country"␣(tag␣"addr:country"␣present␣with␣identical␣value)
editing␣way␣212732816:␣http://www.openstreetmap.org/browse/way/212732816
removing␣misspelt␣tag␣key␣"add:country"␣(tag␣"addr:country"␣present␣with␣identical␣value)
editing␣way␣212732821:␣http://www.openstreetmap.org/browse/way/212732821
removing␣misspelt␣tag␣key␣"add:country"␣(tag␣"addr:country"␣present␣with␣identical␣value)
editing␣way␣215610573:␣http://www.openstreetmap.org/browse/way/215610573
replacing␣misspelt␣tag␣key␣"add:postcode"␣->␣"addr:postcode"
replacing␣misspelt␣tag␣key␣"add:street"␣->␣"addr:street"
editing␣way␣219480497:␣http://www.openstreetmap.org/browse/way/219480497
replacing␣misspelt␣tag␣key␣"addr.city"␣->␣"addr:city"
editing␣way␣222045378:␣http://www.openstreetmap.org/browse/way/222045378
replacing␣misspelt␣tag␣key␣"addr;city"␣->␣"addr:city"
replacing␣misspelt␣tag␣key␣"adr:country"␣->␣"addr:country"
editing␣way␣223428023:␣http://www.openstreetmap.org/browse/way/223428023
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣223428024:␣http://www.openstreetmap.org/browse/way/223428024
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣223428025:␣http://www.openstreetmap.org/browse/way/223428025
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣223428030:␣http://www.openstreetmap.org/browse/way/223428030
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣223428032:␣http://www.openstreetmap.org/browse/way/223428032
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣223428033:␣http://www.openstreetmap.org/browse/way/223428033
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣223428034:␣http://www.openstreetmap.org/browse/way/223428034
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣223428035:␣http://www.openstreetmap.org/browse/way/223428035
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣223428037:␣http://www.openstreetmap.org/browse/way/223428037
replacing␣misspelt␣tag␣key␣"add:city"␣->␣"addr:city"
editing␣way␣237377780:␣http://www.openstreetmap.org/browse/way/237377780
replacing␣misspelt␣tag␣key␣"addr:ciry"␣->␣"addr:city"
editing␣way␣237377781:␣http://www.openstreetmap.org/browse/way/237377781
replacing␣misspelt␣tag␣key␣"addr:ciry"␣->␣"addr:city"
editing␣way␣240491850:␣http://www.openstreetmap.org/browse/way/240491850
replacing␣misspelt␣tag␣key␣"addr:sity"␣->␣"addr:city"
editing␣way␣240491855:␣http://www.openstreetmap.org/browse/way/240491855
replacing␣misspelt␣tag␣key␣"addr:sity"␣->␣"addr:city"
editing␣way␣240491860:␣http://www.openstreetmap.org/browse/way/240491860
replacing␣misspelt␣tag␣key␣"addr:sity"␣->␣"addr:city"
editing␣way␣240491866:␣http://www.openstreetmap.org/browse/way/240491866
replacing␣misspelt␣tag␣key␣"addr:sity"␣->␣"addr:city"
editing␣way␣240553355:␣http://www.openstreetmap.org/browse/way/240553355
replacing␣misspelt␣tag␣key␣"addr:ountry"␣->␣"addr:country"
total␣number␣of␣objects␣modified␣(not␣really):␣53
```
  Unterschieden werden drei Fälle, beispielhaft für den falschen Schlüssel adr:country: a) adr:country wird einfach durch addr:country ersetzt; b) wenn addr:country bereits vorhanden ist und der Wert mit dem von adr:country übereinstimmt, wird adr:country gelöscht. Sind c) beide Schlüssel vorhanden, aber ihre Werte stimmen nicht überein, unterbleibt eine Änderung. Der Spielzeug-Regelsatz für obigen Test war folgender:
```
(("addr:city"
("add:city"␣"adr:city"␣"adde:city"␣"addr.city"␣"addr::city"␣"addr:ciry"
"addr:ciy"␣"addr:dity"␣"addr:sity"␣"addr;city"␣"addr_city"␣"adr:city"))
("addr:street"
("add:street"␣"addr::street"))
("addr:country"
("add:country"␣"addr.country"␣"addr_country"␣"addr:ountry"
"addr:coutry"␣"adr:country"))
("addr:postcode"
("add:postcode")))
```
  Aufgeführt ist jeweils das Ersetzungsziel mit allen Urbildern, d.h. add:city, adr:city, adde:city usw. werden durch addr:city ersetzt.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · errt (Gast) · 09.10.2013 15:26 · [flux]
  
  Schaut doch ganz passabel aus. Dann warten wir einfach mal auf den realen Test mit größerem Regelsatz.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 09.10.2013 20:23 · [flux]
  Mit einem realen Testlauf werde ich mir noch etwas Zeit lassen (obwohl das Programm startklar wäre). Die Idee ist gerade mal zwei Tage in der Welt; vielleicht kommt ja noch der eine oder andere grundsätzliche - und möglicherweise durchaus berechtigte - Einwand.
  
  Hier ist jedenfalls schon mal ein Entwurf für die erste Generation eines Regelsatzes mit der Bitte, einmal drüber zu schauen. Das Format ist das gleiche wie oben: erst das Ersetzungsziel, dann die Menge seiner Urbilder (allesamt dem Datenbestand entnommen). Wer nicht die ganze Liste durchackern will: lieber zwei bis drei der (etwa gleich großen, mehr oder weniger alphabetisch sortierten) Blöcke gründlich überprüfen als alles nur oberflächlich. Entweder zufällig welche herausgreifen (nicht jeder die ersten zwei) oder z.B. jene Blöcke, welche die ersten Buchstaben den eigenen Vornamens enthalten.
  
  Die Urbilder enthalten überwiegend Tippfehler wie vertauschte Buchstaben, falsche Großbuchstaben oder durch abgerutschte Finger eingefügte Buchstaben. Zu kurz geratene Tags sind nur in Ausnamefällen ("landu" ist ziemlich eindeutig, "lan" nicht) dabei. Basis des Entwurfs war diese Auswertung des Geofabrik-DE-Extrakts, wobei ich nach einem Verhältnis der Häufigkeiten von mindestens 200 (statt 500) gesucht habe.
  
  Dieser erste Entwurf wird in jedem Fall kontinuierlich erweitert werden müssen. Ich befürchte allerdings angesichts der bereits jetzt gefundenen Breite ein ziemlich schlechtes Konvergenzverhalten, d.h. bereits aufgetretene Fehler werden sich nur selten wiederholen und stattdessen wird es neue geben.
```
(("abandoned"␣("abandonde"␣"abandones"))
("addr:city"␣("add:city"␣"adr:city"␣"adde:city"␣"addr.city"␣"addr::city"
"addr:ciry"␣"addr:ciy"␣"addr:dity"␣"addr:sity"␣"addr;city"
"addr_city"))
("addr:country"␣("add:country"␣"addr.country"␣"addr_country"␣"addr:ountry"
"addr:coutry"␣"adr:country"))
("addr:housenumber"␣("addr:housenumberf"))
("addr:postcode"␣("add:postcode"))
("addr:street"␣("add:street"␣"addr::street"))
("addr:suburb"␣("addr_suburb"␣"addr:subrub"␣"addR:suburb"))
("amenity"␣("amenit"))
```
```
("bridge"␣("brigde"))
("building"␣("Building"␣"bulding"))
("building:colour"␣("buidling:colour"␣"building;colour"))
("building:levels"␣("buidling:levels"))
("building:use"␣("buidling:use"))
```
```
("capacity"␣("caapcity"))
("castle_type"␣("castel_type"␣"castle_typ"␣"castle:type"))
("cemetery"␣("cemetary"))
("construction"␣("cosntruction"␣"Construction"))
("cuisine"␣("cuosine"))
```
```
("denotation"␣("denatation"))
("drinkable"␣("dringable"))
("entrance"␣("entramce"))
("fuel:cng"␣("fuel:CNG"))
("fuel:e10"␣("fuel:E10"))
```
```
("generator:method"␣("generator_method"))
("generator:source"␣("generator_source"))
("genus:de"␣("genus:DE"))
("height"␣("heigth"␣"heihgt"␣"hieght"␣"hright"))
("heritage"␣("heirtage"))
("heritage:operator"␣("heritgae:operator"␣"heritage_operator"))
("hgv"␣("hgb"))
("highway"␣("higwhay"))
```
```
("incline"␣("inclien"))
("information"␣("Information"))
("landuse"␣("landu"))
("layer"␣("LAYER"␣"Layer"))
```
```
("man_made"␣("man␣made"))
("maxheight"␣("maxheigth"))
("maxspeed:backward"␣("maxspeed:backeard"))
("maxspeed:forward"␣("maxspeed:forwad"␣"maxspeed.forward"))
("maxweight"␣("maxweigth"␣"Maxweight"))
("memorial"␣("menorial"))
("memorial:type"␣("menorial_type"))
("motorroad"␣("motorraod"))
("mtb:scale"␣("MTB:Scale"␣"MTB:scale"␣"mtb_scale"␣"mtb.scale"␣"mtb:scael"))
```
```
("name"␣("Name"))
("natural"␣("Natural"␣"natrual"␣"naturan"␣"naturaql"␣"naturel"))
("network"␣("Network"␣"networt"))
("noexit"␣("NOEXIT"␣"moexit"))
("note"␣("Note"␣"NOTE"␣"noet"))
("phone"␣("phoen"))
("population"␣("ppoulation"))
("public_transport"␣("public_tranpsort"))
```
```
("ref"␣("Ref"))
("reservoir_type"␣("reservior_type"))
("roof:colour"␣("roof_colour"))
("roof:material"␣("roof_material"␣"roof:mateiral"␣"roof:materials"))
("roof:shape"␣("roof:shade"␣"roof_shape"␣"rrof:shape"␣"coof:shape"))
```
```
("shop"␣("shpo"))
("source"␣("Source"␣"soruce"␣"suorce"))
("surface"␣("surfacw"␣"surfcae"))
("tourism"␣("tourisme"))
("tracktype"␣("trakctype"␣"traxktype"␣"zracktype"␣"Tracktype"␣"tracktyp"
"trackty"␣"tarcktype"))
("traffic_calming"␣("traffic_claming"))
("tunnel"␣("tunne"␣"tunnerl"␣"Tunnel"))
("turn:lanes"␣("turn_lanes"␣"turn:lane"␣"turn|lanes"))
```
```
("vehicle"␣("vehicles"))
("website"␣("Website"␣"webside"␣"websi"␣"websit"))
("wheelchair"␣("wheelshair"))
("width"␣("widht"␣"widh"))
)
```
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · seichter (Gast) · 09.10.2013 21:00 · [flux]
  
  Mir ist nichts aufgefallen.
  Eine Anregung für später: Wenn neue Items dazukommen, sollte das zu erkennen sein (vielleicht in einer zweiten Liste), denn die sind ja dann noch "unerprobt".
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · errt (Gast) · 09.10.2013 21:32 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 09.10.2013 23:45 · [flux]
  Oli-Wan wrote:
  
  Mit einem realen Testlauf werde ich mir noch etwas Zeit lassen (obwohl das Programm startklar wäre). Die Idee ist gerade mal zwei Tage in der Welt; vielleicht kommt ja noch der eine oder andere grundsätzliche - und möglicherweise durchaus berechtigte - Einwand.
  
  In deiner bewährten ruhigen Art ein Schritt nach dem anderen.
  So ist es sinnvoll und vor allem sicher.
  
  Oli-Wan wrote:
  
  Hier ist jedenfalls schon mal ein Entwurf für die erste Generation eines Regelsatzes mit der Bitte, einmal drüber zu schauen. Das Format ist das gleiche wie oben: erst das Ersetzungsziel, dann die Menge seiner Urbilder (allesamt dem Datenbestand entnommen). ...
  
  Die Urbilder enthalten überwiegend Tippfehler wie vertauschte Buchstaben, falsche Großbuchstaben oder durch abgerutschte Finger eingefügte Buchstaben. Zu kurz geratene Tags sind nur in Ausnamefällen ("landu" ist ziemlich eindeutig, "lan" nicht) dabei. Basis des Entwurfs war diese Auswertung des Geofabrik-DE-Extrakts, wobei ich nach einem Verhältnis der Häufigkeiten von mindestens 200 (statt 500) gesucht habe.
  
  Wie oben bereits gesagt, erst einmal auf der sicheren Seite bleiben.
  
  Oli-Wan wrote:
  Dieser erste Entwurf wird in jedem Fall kontinuierlich erweitert werden müssen. Ich befürchte allerdings angesichts der bereits jetzt gefundenen Breite ein ziemlich schlechtes Konvergenzverhalten, d.h. bereits aufgetretene Fehler werden sich nur selten wiederholen und stattdessen wird es neue geben.
  
  (<korrekte␣Schreibweise>␣(<Liste␣von␣falschen␣Schreibweisen>)) (...␣(...)) ("amenity"␣("amenit"))
  
  ("bridge"␣("brigde")) ("building"␣("Building"␣"bulding")) ("building:colour"␣("buidling:colour"␣"building;colour")) ("building:levels"␣("buidling:levels")) ("building:use"␣("buidling:use"))
  
  (...␣(...)) ("roof:colour"␣("roof_colour"))
  
  (...␣(...))
  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)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · slhh (Gast) · 10.10.2013 01:40 · [flux]
  
  Oli-Wan wrote:
  
  Ich gehe davon aus, daß die meisten Fehler mit ähnlich hoher Wahrscheinlichkeit unbemerkt bleiben, sodaß sich keine Hierarchie bilden läßt. Lediglich jene, die unmittelbare Auswirkungen aufs (Mapnik-)Rendering haben, haben eine größere Chance, entdeckt zu werden.
  
  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.
  
  Oli-Wan wrote:
  
  Etwa Adresstags werden in der Regel einmal eingetragen und nie wieder angesehen.
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · slhh (Gast) · 10.10.2013 02:12 · [flux]
  
  EvanE wrote:
  
  Ich hätte anemity (vertauschtes 'n' und 'm' statt amenity) noch bei den Fehlern erwartet.
  
  Auch wenn diese Falschschreibung eine große optische Ähnlichkeit hat, dürfte sie schon durch das Kriterium mit der Editierdistanz gefallen sein.
  
  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
  
  EvanE wrote:
  
  Man sollte auch versuchen gerade häufige Fehler zu finden und zu korrigieren (solange das eindeutig geht).
  
  +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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · RvdtG (Gast) · 10.10.2013 07:24 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · S-Man42 (Gast) · 10.10.2013 07:58 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 10.10.2013 11:53 · [flux]
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · errt (Gast) · 10.10.2013 12:39 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · hurdygurdyman (Gast) · 10.10.2013 13:15 · [flux]
  
  Da sich keiner traut, zu fragen was denn Damerau-Levenshtein ist:
  http://de.wikipedia.org/wiki/Levenshtein-Distanz
  Was man hier so alles lernt 😎
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Netzwolf (Gast) · 10.10.2013 13:29 · [flux]
  
  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
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · wambacher (Gast) · 10.10.2013 14:36 · [flux]
  
  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
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Basstoelpel (Gast) · 10.10.2013 14:41 · [flux]
  
  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
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 10.10.2013 15:17 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · wambacher (Gast) · 10.10.2013 16:21 · [flux]
  
  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
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · hurdygurdyman (Gast) · 11.10.2013 06:19 · [flux]
  
  Bekommt man mit Wall-E auch die Singular>Plural-Problematik in den Griff? Ich denke da z.B. an access=customer>customers und so.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · wambacher (Gast) · 11.10.2013 06:23 · [flux]
  
  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
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 11.10.2013 08:29 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · chris66 (Gast) · 11.10.2013 09:35 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · hurdygurdyman (Gast) · 11.10.2013 09:45 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 11.10.2013 10:25 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 11.10.2013 11:44 · [flux]
  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)
```
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · errt (Gast) · 11.10.2013 16:43 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 14.10.2013 14:57 · [flux]
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · MasiMaster (Gast) · 15.10.2013 21:02 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · seichter (Gast) · 15.10.2013 21:26 · [flux]
  
  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.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 15.10.2013 21:34 · [flux]
  
  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)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 16.10.2013 19:51 · [flux]
  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)
```
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 16.10.2013 20:39 · [flux]
  
  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)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · FvGordon (Gast) · 20.10.2013 16:48 · [flux]
  
  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
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 20.10.2013 22:19 · [flux]
  
  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)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 20.10.2013 22:34 · [flux]
  
  Entschulding vorab: einige Aussagen überschneiden sich inhaltlich mit denen von EvanE, der mir eine Viertelstunde zuvorgekommen ist. Ich verzichte darauf, das Posting à la "wie Edbert oben schon schrieb" umzudekorieren.
  
  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 ...
  
  Sorry - ich hatte das Posting zwar gelesen, aber nicht beantwortet und zugegebenermaßen auch schon wieder vergessen. Die Idee halte ich durchaus für sinnvoll, dennoch muß ich dafür in die unbestimmte Zukunft verweisen. Wie schon mehrfach gesagt, kümmere ich mich zunächst nur um Schlüssel und möchte mit Werten erst anfangen, wenn der Regelsatz für die Schlüssel einigermaßen steht. Wie lange das dauert, vermag ich nicht vorherzusagen - Wochen, vielleicht auch Monate.
  Bei den Werten hatte ich bisher eigentlich nur an Korrekturen nach ähnlichem Schema wie bei den Schlüsseln gedacht, aber in Abhängigkeit vom Tagschlüssel kann man durchaus über spezielle Korrekturen numerischer Werte (Trennzeichen, Standard-Einheiten) nachdenken. Aber wie gesagt, nicht in nächster Zeit; es sei denn, jemand anders erbarmt sich.
  
  FvGordon wrote:
  
  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).
  
  Die hohe Prävalenz in DE ist durchaus plausibel: erstens ist hier einfach das Komma als Dezimaltrenner üblich; zweitens ist hierzulande die Basiserfassung weitgehend abgeschlossen, sodaß man sich eben mit solchen Details befassen kann. Wo kaum die wichtigsten Straßen vorhanden sind und Tags wie maxheight gar nicht existieren, besteht auch keine Gelegenheit, sie falsch zu schreiben.
  Ich glaube allerdings, daß width=2,5->2.5 mit dem damaligen Umtaggen der Eingänge (und vielen vergleichbaren Aktionen auf kleinerer Skala) nicht zu vergleichen ist. Mit Diskussion hier und/oder auf talk-de wäre das durchaus auch "manuell" (also nicht per Regex etc., sondern wirklich nur einen bestimmten Wert ersetzen, und im nächsten Changeset den nächsten) machbar, da es wirklich um einen eindeutigen Fehler geht. Etliche Mapper nehmen vergleichbare Bearbeitungen auch ohne jede Konsultation vor, und solange alles gut geht, sagt auch die DWG selten etwas. Aber die schiere Zahl von 11000 Objekten nur für einen einzigen Wert schreckt einen verantwortungsvollen Mapper natürlich schon ab, und das zurecht.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 21.10.2013 13:31 · [flux]
  Zwei erste Durchgänge auf dem echten Datenbestand:
  http://www.openstreetmap.org/browse/changeset/18467617 (Regierungsbezirk Münster, 52 Objekte)
  http://www.openstreetmap.org/browse/changeset/18467728 (Regierungsbezirk Köln, 51 Objekte)
  Von dem ersten fehlt leider das Log. (Eigentlich sollte der erst noch ohne Hochladen laufen, wegen einer falsch gesetzten Option wurde dann aber doch direkt in die Datenbank geschrieben. Als ich das gemerkt habe, hatte ich schon den Buffer mit dem Log geschlossen.) Am besten lassen sich die Bearbeitungen noch nachvollziehen, indem man in JOSM "Adresse öffnen" mit http://www.openstreetmap.org/api/0.6/ch … 7/download füttert. Anschließend "Daten aktualisieren", Suche nach user:Wall·E und Objekthistorie aufrufen (möglichst nicht gleich für alle 52).
  Hier wurden in erster Linie add:*, addr;*, addr:ountry, addr:sity und ähnliche Tags ersetzt oder entfernt (v.a. in Detmold, Marl, Münster und Wuppertal).
  
  Das Log des zweiten Änderungssatzes folgt (und ist auch in dem bekannten Wall·E-Log enthalten). Häufigste Tags: landu, NOTE, Name, Ref, roof:color, building:color, castle_typ.
```
osm-mechedit-fix-misspell␣run␣Mon␣Oct␣21␣12:05:16␣2013␣(Emacs␣running␣in␣batch␣mode␣on␣nightshade.toolserver.org)
created␣changeset␣#18467728,␣http://www.openstreetmap.org/browse/changeset/18467728
editing␣node␣1668928390:␣http://www.openstreetmap.org/browse/node/1668928390
replacing␣misspelt␣tag␣key␣"landu"␣->␣"landuse"
editing␣way␣32300556:␣http://www.openstreetmap.org/browse/way/32300556
replacing␣misspelt␣tag␣key␣"NOTE"␣->␣"note"
editing␣way␣37906197:␣http://www.openstreetmap.org/browse/way/37906197
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣38281538:␣http://www.openstreetmap.org/browse/way/38281538
replacing␣misspelt␣tag␣key␣"NOTE"␣->␣"note"
editing␣way␣39209898:␣http://www.openstreetmap.org/browse/way/39209898
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣39209900:␣http://www.openstreetmap.org/browse/way/39209900
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣50905297:␣http://www.openstreetmap.org/browse/way/50905297
replacing␣misspelt␣tag␣key␣"Ref"␣->␣"ref"
editing␣way␣95816081:␣http://www.openstreetmap.org/browse/way/95816081
replacing␣misspelt␣tag␣key␣"roof:color"␣->␣"roof:colour"
editing␣way␣95816087:␣http://www.openstreetmap.org/browse/way/95816087
replacing␣misspelt␣tag␣key␣"roof:color"␣->␣"roof:colour"
editing␣way␣105000636:␣http://www.openstreetmap.org/browse/way/105000636
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣106480373:␣http://www.openstreetmap.org/browse/way/106480373
replacing␣misspelt␣tag␣key␣"building:color"␣->␣"building:colour"
replacing␣misspelt␣tag␣key␣"roof:color"␣->␣"roof:colour"
editing␣way␣119231732:␣http://www.openstreetmap.org/browse/way/119231732
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣119849051:␣http://www.openstreetmap.org/browse/way/119849051
replacing␣misspelt␣tag␣key␣"roof:color"␣->␣"roof:colour"
editing␣way␣146986002:␣http://www.openstreetmap.org/browse/way/146986002
removing␣misspelt␣tag␣key␣"building:color"␣(tag␣"building:colour"␣present␣with␣identical␣value)
editing␣way␣146986045:␣http://www.openstreetmap.org/browse/way/146986045
removing␣misspelt␣tag␣key␣"building:color"␣(tag␣"building:colour"␣present␣with␣identical␣value)
editing␣way␣147329387:␣http://www.openstreetmap.org/browse/way/147329387
replacing␣misspelt␣tag␣key␣"building:color"␣->␣"building:colour"
editing␣way␣147329388:␣http://www.openstreetmap.org/browse/way/147329388
replacing␣misspelt␣tag␣key␣"building:color"␣->␣"building:colour"
editing␣way␣147329392:␣http://www.openstreetmap.org/browse/way/147329392
replacing␣misspelt␣tag␣key␣"building:color"␣->␣"building:colour"
editing␣way␣147334135:␣http://www.openstreetmap.org/browse/way/147334135
replacing␣misspelt␣tag␣key␣"addr.country"␣->␣"addr:country"
editing␣way␣160956311:␣http://www.openstreetmap.org/browse/way/160956311
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣160956314:␣http://www.openstreetmap.org/browse/way/160956314
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣168868456:␣http://www.openstreetmap.org/browse/way/168868456
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣168868457:␣http://www.openstreetmap.org/browse/way/168868457
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣173569233:␣http://www.openstreetmap.org/browse/way/173569233
replacing␣misspelt␣tag␣key␣"Ref"␣->␣"ref"
editing␣way␣176783457:␣http://www.openstreetmap.org/browse/way/176783457
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣198923912:␣http://www.openstreetmap.org/browse/way/198923912
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣206371196:␣http://www.openstreetmap.org/browse/way/206371196
replacing␣misspelt␣tag␣key␣"roof:color"␣->␣"roof:colour"
editing␣way␣206421980:␣http://www.openstreetmap.org/browse/way/206421980
replacing␣misspelt␣tag␣key␣"roof:color"␣->␣"roof:colour"
editing␣way␣208097195:␣http://www.openstreetmap.org/browse/way/208097195
replacing␣misspelt␣tag␣key␣"roof:color"␣->␣"roof:colour"
editing␣way␣217209481:␣http://www.openstreetmap.org/browse/way/217209481
removing␣misspelt␣tag␣key␣"building:color"␣(tag␣"building:colour"␣present␣with␣identical␣value)
editing␣way␣217209483:␣http://www.openstreetmap.org/browse/way/217209483
removing␣misspelt␣tag␣key␣"building:color"␣(tag␣"building:colour"␣present␣with␣identical␣value)
editing␣way␣217994356:␣http://www.openstreetmap.org/browse/way/217994356
removing␣misspelt␣tag␣key␣"landu"␣(tag␣"landuse"␣present␣with␣identical␣value)
editing␣way␣220141860:␣http://www.openstreetmap.org/browse/way/220141860
removing␣misspelt␣tag␣key␣"Name"␣(tag␣"name"␣present␣with␣identical␣value)
editing␣way␣220141874:␣http://www.openstreetmap.org/browse/way/220141874
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣220141878:␣http://www.openstreetmap.org/browse/way/220141878
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣220141880:␣http://www.openstreetmap.org/browse/way/220141880
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣220141881:␣http://www.openstreetmap.org/browse/way/220141881
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣223459322:␣http://www.openstreetmap.org/browse/way/223459322
removing␣misspelt␣tag␣key␣"building:color"␣(tag␣"building:colour"␣present␣with␣identical␣value)
editing␣way␣223459323:␣http://www.openstreetmap.org/browse/way/223459323
replacing␣misspelt␣tag␣key␣"building:color"␣->␣"building:colour"
editing␣way␣224029176:␣http://www.openstreetmap.org/browse/way/224029176
replacing␣misspelt␣tag␣key␣"soruce"␣->␣"source"
editing␣way␣224962046:␣http://www.openstreetmap.org/browse/way/224962046
replacing␣misspelt␣tag␣key␣"websi"␣->␣"website"
editing␣way␣227342330:␣http://www.openstreetmap.org/browse/way/227342330
replacing␣misspelt␣tag␣key␣"building:color"␣->␣"building:colour"
editing␣way␣227802940:␣http://www.openstreetmap.org/browse/way/227802940
replacing␣misspelt␣tag␣key␣"Ref"␣->␣"ref"
editing␣way␣230424612:␣http://www.openstreetmap.org/browse/way/230424612
replacing␣misspelt␣tag␣key␣"castle_typ"␣->␣"castle_type"
editing␣way␣230424619:␣http://www.openstreetmap.org/browse/way/230424619
replacing␣misspelt␣tag␣key␣"castle_typ"␣->␣"castle_type"
editing␣way␣230424626:␣http://www.openstreetmap.org/browse/way/230424626
replacing␣misspelt␣tag␣key␣"castle_typ"␣->␣"castle_type"
editing␣way␣230424628:␣http://www.openstreetmap.org/browse/way/230424628
replacing␣misspelt␣tag␣key␣"castle_typ"␣->␣"castle_type"
editing␣way␣230424630:␣http://www.openstreetmap.org/browse/way/230424630
replacing␣misspelt␣tag␣key␣"castle_typ"␣->␣"castle_type"
editing␣way␣237262848:␣http://www.openstreetmap.org/browse/way/237262848
replacing␣misspelt␣tag␣key␣"barreier"␣->␣"barrier"
editing␣way␣239076802:␣http://www.openstreetmap.org/browse/way/239076802
replacing␣misspelt␣tag␣key␣"Name"␣->␣"name"
editing␣way␣239988840:␣http://www.openstreetmap.org/browse/way/239988840
replacing␣misspelt␣tag␣key␣"NOTE"␣->␣"note"
total␣number␣of␣objects␣modified:␣51
```
  Soweit ich sehen kann, hat es keine Probleme gegeben. Wenn nicht doch noch welche auftauchen - bitte mal durchsehen! -, geht es in den nächsten Tagen portionsweise mit dem Rest der Republik weiter. Ich werde allerdings nicht jedes Mal ein neues Posting hier aufmachen. Die Änderungssätze finden sich hier und das Protokoll sollte nun dort angehängt werden.
  
  Übersicht über die Änderungssätze:
  Regierungsbezirk Münster (21.10.)
  Regierungsbezirk Köln (21.10.)
  
  Weitere per Nachtrag (Edit):
  Saarland (21.10.)
  Nach Deaktivierung von building:color und roof:color (siehe weiterer Diskussionsverlauf):
  Rheinland-Pfalz (22.10.)
  Regierungsbezirk Düsseldorf (22.10.)
  Niedersachsen (22.10.)
  Hessen (23.10.)
  Regierunsgbezirk Detmold (23.10.)
  Baden-Württemberg (24.10.)
  Schleswig-Holstein (24.10.)
  Regierungsbezirk Arnsberg (25.10.)
  Mecklenburg-Vorpommern (25.10.)
  Bayern (27.10.)
  Brandenburg inklusive Berlin (27.10.)
  Sachsen (28.10.)
  Sachsen-Anhalt (28.10.)
  Thüringen (28.10.)
  
  DE (Rest) (29.10.)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 21.10.2013 15:49 · [flux]
  Oli-Wan wrote:
  Zwei erste Durchgänge auf dem echten Datenbestand:
  http://www.openstreetmap.org/browse/changeset/18467617 (Regierungsbezirk Münster, 52 Objekte)
  http://www.openstreetmap.org/browse/changeset/18467728 (Regierungsbezirk Köln, 51 Objekte)
  Von dem ersten fehlt leider das Log. ...
  
  Das Log des zweiten Änderungssatzes folgt (...). Häufigste Tags: landu, NOTE, Name, Ref, roof:color, building:color, castle_typ.
  
  osm-mechedit-fix-misspell␣run␣Mon␣Oct␣21␣12:05:16␣2013␣(Emacs␣running␣...␣on␣nightshade.toolserver.org) created␣changeset␣#18467728,␣http://www.openstreetmap.org/browse/changeset/18467728 ... replacing␣misspelt␣tag␣key␣"NOTE"␣->␣"note" ... replacing␣misspelt␣tag␣key␣"NOTE"␣->␣"note" ... replacing␣misspelt␣tag␣key␣"NOTE"␣->␣"note"␣... total␣number␣of␣objects␣modified:␣51
  
  Soweit ich sehen kann, hat es keine Probleme gegeben. Wenn nicht doch noch welche auftauchen - bitte mal durchsehen! -, geht es in den nächsten Tagen portionsweise mit dem Rest der Republik weiter. ...
  Einspruch!
  Das Tagg note=* gehört ebenso wie fixme=* zu den sogenannten Annotations (zu deutsch Anmerkungen), haben also (anders als name, landuse, addr:*, ...) keinen Einfluss auf die Bedeutung eines Objektes.
  
  Nun gibt es mittlerweile häufig den Fall, das Objekte mehr als 10/15/20 Taggs (Eigenschaften) besitzen (Adresse, 3D-Infos, ...). Dabei gehen note=* oder fixme=* (beides Notizen an andere Mapper) leicht in der Menge der anderen Taggs unter. Von daher schreiben manche Mapper note und/oder fixme in Großbuchstaben, damit diese in der Tagg-Liste möglichst weit oben stehen und auf diese Weise nicht übersehen werden.
  
  Daher finde ich, dass die Groß-/Kleinschreibung bei NOTE=* und FIXME=* nicht korrigiert werden sollte.
  (Andere Probleme sind mir nicht aufgefallen.)
  
  Heute in Großschreibung
  EDBERT (EVANE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 21.10.2013 15:52 · [flux]
  
  EvanE wrote:
  
  Daher finde ich, dass die Groß-/Kleinschreibung bei NOTE=* und FIXME=* nicht korrigiert werden sollte.
  
  Ich habe NOTE für die Zukunft rausgenommen. Was ist mit Note?
  
  PS/Edit. FIXME1, FIXME2, FXIME, FixMe und Fixme werden nicht angerührt. Eine Ersetzung von FIXME zu fixme wird vom Suchprogramm erst gar nicht vorgeschlagen, da FIXME häufiger ist. Die exotischen Schlüssel COMMENT, INFO und STATUS bleiben ebenfalls stehen.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 21.10.2013 16:39 · [flux]
  
  Oli-Wan wrote:
  
  EvanE wrote:
  
  Daher finde ich, dass die Groß-/Kleinschreibung bei NOTE=* und FIXME=* nicht korrigiert werden sollte.
  
  Ich habe NOTE für die Zukunft rausgenommen. Was ist mit Note?
  
  PS/Edit. FIXME1, FIXME2, FXIME, FixMe und Fixme werden nicht angerührt. Eine Ersetzung von FIXME zu fixme wird vom Suchprogramm erst gar nicht vorgeschlagen, da FIXME häufiger ist. Die exotischen Schlüssel COMMENT, INFO und STATUS bleiben ebenfalls stehen.
  
  Wenn ich so etwas (in der Regel bei FIXME) mache, dann bin ich konsequent und schreibe alles groß (ist aufälliger).
  Unabhängig davon würde ich dazu neigen, alle Varianten von Groß-/Kleinschreibung unverändert zu lassen.
  
  (wieder mit 'richtiger' Schreibweise)
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · seichter (Gast) · 21.10.2013 20:09 · [flux]
  
  Ich bin der Meinung, dass sich Wall-E zunächst auf seine eigentliche neue Aufgabe, die Korrektur von Tagging-Tippfehlern (siehe Überschrift), konzentrieren sollte.
  Die Angleichung von Varianten unterschiedlichen Geschmackes würde ich erst machen, wenn ein Konsens vorzuliegen scheint.
  Generelle Kennzeichnung von Annotationen (keine Objekteigenschaft) per alles Großbuchstaben fände ich z.B. sinnvoll. Wenn Note korrigieren, dann in diesem Sinne zu NOTE.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 21.10.2013 20:53 · [flux]
  
  seichter wrote:
  
  Ich bin der Meinung, dass sich Wall-E zunächst auf seine eigentliche neue Aufgabe, die Korrektur von Tagging-Tippfehlern (siehe Überschrift), konzentrieren sollte.
  Die Angleichung von Varianten unterschiedlichen Geschmackes würde ich erst machen, wenn ein Konsens vorzuliegen scheint.
  Generelle Kennzeichnung von Annotationen (keine Objekteigenschaft) per alles Großbuchstaben fände ich z.B. sinnvoll. Wenn Note korrigieren, dann in diesem Sinne zu NOTE.
  
  Ich habe "Note" nun auch herausgenommen.
  Bei Tippfehlern vs. Geschmacksvarianten bin ich nicht sicher, ob wir da evtl. eine unterschiedliche Definition vor Augen haben. Bei FIXME und NOTE (sowie weiteren Varianten) sehe ich sein, daß das häufig Absicht ist. Wegen der geringen Häufigkeit war mir das bei NOTE zunächst nicht in den Sinn gekommen; es gibt ja schließlich auch LAYER und NOEXIT, die kaum absichtlich gesetzt worden sein dürften, sondern etwa durch Caps Lock. FIXME habe ich im Übrigen selbst früher benutzt (und zwar aus der von Edbert skizzierten Überlegung).
  
  Die aktuelle Fassung des Regelsatzes ist inzwischen im Volltext im Wiki dokumentiert.
  
  Ich gehe davon aus, daß alle Elemente des Regelsatzes (nach Streichung von NOTE und Note) tatsächlich Fehler (Vertipper, Sprachfehler, Germanismen, außerdem AmE/BrE) sind und keine Geschmacksvarianten. Wenn Du welche siehst, streiche ich die gerne raus.
  
  Einzige mögliche Ausnahme, und damit kommen wir zu einem anderen Thema, das ich ohnehin noch ansprechen wollte, sind die color/colour-Tags. In der Datenbank sind building:color und roof:color ungefähr im Verhältnis 1:10 zu building:colour und roof:colour vertreten. Allein in Berlin beträfe die Korrektur etwa 2700 Objekte. Im Grunde sind wir da schon im Bereich des Umtaggens, wovon ich mich ja eigentlich fernhalten möchte - die color-Variante könnte ja durchaus Absicht sein. Andererseits ist die Definition auf den 3D-Wikiseiten eindeutig, und die zugrundeliegende Regel, sich nach der britischen Rechtschreibung zu richten, ist uralt und auch akzeptiert. Von daher bin ich trotz Bauchschmerzen geneigt, building:color und roof:color im Regelsatz zu belassen - aber die Größenordnung sollte uns bewußt sein.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · errt (Gast) · 21.10.2013 21:38 · [flux]
  
  Ich glaube nicht, dass (in Deutschland zumindest) eine nennenswerte Anzahl von Mappern absichtlich color verwendet. Es ist halt so, dass man meist eher dem amerikanisch-englischen zugeneigt ist, das aber halt in OSM aus historischen Gründen unüblich ist. Persönlich fände ich ja amerikanisches Englisch sinnvoller - aber wenn wir hier ausnahmsweise schonmal einen Standard haben, sollte man den nicht aufweichen. Also: Ja, gerade color->colour halte ich für sinnvoll und notwendig, auch wenn es natürlich hier kein Tippfehler im eigentlich Sinne ist (zumindest in den meisten Fällen wohl nicht).
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · seichter (Gast) · 21.10.2013 22:31 · [flux]
  
  Selbst wenn jemand absichtlich color geschrieben hat, ist der Informationsgehalt der gleiche wie bei colour. Ein Umtaggen würde ich nur ablehnen, wenn mir irgend jemand eine unterschiedliche Bedeutung der beiden Schreibweisen plausibel machen könnte.
  Geschmacksfrage ist es mE nicht, da die Regeln (AE vs. BE) eigentlich eindeutig sind (sofern es in OSM überhaupt Regeln gibt 😉).
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 21.10.2013 22:47 · [flux]
  
  Oli-Wan wrote:
  
  Die aktuelle Fassung des Regelsatzes ist inzwischen im Volltext im Wiki dokumentiert.
  
  Ich gehe davon aus, daß alle Elemente des Regelsatzes (nach Streichung von NOTE und Note) tatsächlich Fehler (Vertipper, Sprachfehler, Germanismen, außerdem AmE/BrE) sind und keine Geschmacksvarianten. Wenn Du welche siehst, streiche ich die gerne raus.
  
  Das ist soweit ohne Auffälligkeit.
  Das hat man alles so oder so ähnlich schon mal selber beim Mappen gesehen.
  
  Oli-Wan wrote:
  
  Einzige mögliche Ausnahme, und damit kommen wir zu einem anderen Thema, das ich ohnehin noch ansprechen wollte, sind die color/colour-Tags. In der Datenbank sind building:color und roof:color ungefähr im Verhältnis 1:10 zu building:colour und roof:colour vertreten. Allein in Berlin beträfe die Korrektur etwa 2700 Objekte. Im Grunde sind wir da schon im Bereich des Umtaggens, wovon ich mich ja eigentlich fernhalten möchte - die color-Variante könnte ja durchaus Absicht sein. Andererseits ist die Definition auf den 3D-Wikiseiten eindeutig, und die zugrundeliegende Regel, sich nach der britischen Rechtschreibung zu richten, ist uralt und auch akzeptiert. Von daher bin ich trotz Bauchschmerzen geneigt, building:color und roof:color im Regelsatz zu belassen - aber die Größenordnung sollte uns bewußt sein.
  
  Ich denke, da die Regeln sowohl allgemein (BE-Schreibweise) als auch bei Simple 3D Buildings eindeutig ist, kann und soll man das als Tippfehler betrachten. Weiter muss man davon ausgehen, dass vielen der Unterschied AmE / BE gerade bei dem Wort colour nicht geläufig ist. Und das ist letztlich ja auch eine Art von Schreibfehler.
  
  Die reine Menge ist natürlich ein Problem. Gegebenenfalls eine Bremse einbauen (100-200 Treffer?), falls das in einem Gebiet (größere Städte) häufig vorkommt und dann in mehreren Läufen ändern.
  
  Eventuell mag es sinnvoll sein, die DWG bzw. deren deutsch Mitglieder vorab darüber zu informieren, dass in den Stadtstaaten dieses Problem gehäuft auftritt und um Rat bitten, ob es a) Einwände gibt und b) ob man besondere Maßnahmen ergreifen soll.
  Da du alles sauber diskutiert, dokumentiert und getestet hast, erwarte ich für Deutschland jedoch keine Probleme.
  Wenn das irgendwann mal auf mehr als Deutschland ausgedehnt werden soll, dann muss man sowieso mit einem breiteren Kreis neu diskutieren.
  
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · MasiMaster (Gast) · 21.10.2013 23:29 · [flux]
  
  Oli-Wan wrote:
  
  Einzige mögliche Ausnahme, und damit kommen wir zu einem anderen Thema, das ich ohnehin noch ansprechen wollte, sind die color/colour-Tags. In der Datenbank sind building:color und roof:color ungefähr im Verhältnis 1:10 zu building:colour und roof:colour vertreten. Allein in Berlin beträfe die Korrektur etwa 2700 Objekte. Im Grunde sind wir da schon im Bereich des Umtaggens, wovon ich mich ja eigentlich fernhalten möchte - die color-Variante könnte ja durchaus Absicht sein. Andererseits ist die Definition auf den 3D-Wikiseiten eindeutig, und die zugrundeliegende Regel, sich nach der britischen Rechtschreibung zu richten, ist uralt und auch akzeptiert. Von daher bin ich trotz Bauchschmerzen geneigt, building:color und roof:color im Regelsatz zu belassen - aber die Größenordnung sollte uns bewußt sein.
  
  Kurz und knapp: ich finde color besser.
  Es ist richtig, dass sich bei den Tags im allgemeine auf BE geeinigt wurde. Ich kann mich aber noch dunkel erinnern, dass ein Tag (oder Tag-Vorschlag) aus dem BE nicht verwendet werden sollte/wurde, weil es nur eingefleischte Briten kennen. Es wurde dann der Einfachheit halber ein anderes Tag gefunden, was auch nicht Muttersprachler gut verstehen. Gut, coulor versteht man schon, doch ist es deutlich einfacher bei diesem Tag das "einfachere" und kürzere color zu verwenden.
  
  Wenn ich color verwenden würde, dann immer ohne "u". Ich nehme mal an dass die 3D Experten die building:colour Tags erzeugt haben und sich auch an die Vorschläge der 3D-Wikiseite halten, deswegen die große Anzahl mit "u". Vermutlich würden alle anderen eher color verwenden.
  
  So, das ist meine Meinung zu dem Thema. Deswegen würde ich es lieber sehen, wenn sich color durchsetzt.
  
  Gegenargumente: Feuer frei! 🙂
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · errt (Gast) · 22.10.2013 08:37 · [flux]
  
  Es gibt da aber einen Unterschied zwischen "Dieses Wort kennt außerhalb von England niemand" - dann nimmt man halt ein anderes, ob man den Schlüssel jetzt so oder so nennt, ist ja relativ wurscht - und "Dieses Wort schreibt sich in AE und BE unterschiedlich" - dafür haben wir nämlich eine allgemeine Regel und die sollte man nicht einfach so über Bord werfen. Selbst wenn sie meist auf die kompliziertere Schreibweise führt, kann ich dann wenigstens, wenn ich mir gerade unsicher bin, eindeutig sagen, welche Schreibweise offiziell richtig sein muss.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 22.10.2013 09:04 · [flux]
  
  MasiMaster wrote:
  
  Kurz und knapp: ich finde color besser.
  Es ist richtig, dass sich bei den Tags im allgemeine auf BE geeinigt wurde. Ich kann mich aber noch dunkel erinnern, dass ein Tag (oder Tag-Vorschlag) aus dem BE nicht verwendet werden sollte/wurde, weil es nur eingefleischte Briten kennen.
  
  Da dürften aber zwei ganz unterschiedliche Begriffe zur Auswahl gestanden haben, nicht zwei Schreibweisen. In so einem Fall bin ich auch dafür, den weltweit verständlicheren Begriff zu nehmen, egal ob er aus BrE, AmE oder sonstwoher kommt (soweit ich mich erinnere, bezieht sich auch die BrE-Konvention nur auf die Schreibweise). Das einzige, was mir gerade dazu einfällt: footway gegen sidewalk. Letzteres ist amerikanisch, sagt aber deutlich, daß der Streifen am Straßenrand gemeint ist, was aus ersterem nicht hervorgeht. Wozu es führt, wenn man Tags einführt (und weltweit im Editor anbietet), die nur in einer begrenzten Region bzw. auf einer bestimmten Insel eine wohldefinierte Bedeutung haben und für den Rest der Welt nach etwas ganz anderem klingen, sieht man an designation.
  
  MasiMaster wrote:
  
  Wenn ich color verwenden würde, dann immer ohne "u". Ich nehme mal an dass die 3D Experten die building:colour Tags erzeugt haben und sich auch an die Vorschläge der 3D-Wikiseite halten, deswegen die große Anzahl mit "u". Vermutlich würden alle anderen eher color verwenden.
  
  Letzteres halte ich für eine recht gewagte Vermutung. Wer die BrE-Konvention und die britische Schreibweise kennt und beachtet, schreibt colour. Das Problem ist eher, daß wegen der Marktdominanz amerikanischer Softwarehersteller und Internetkonzerne die amerikanische Schreibweise so allgegenwärtig ist, daß die Unterschiede in der Schreibweise in Vergessenheit geraten. Im Fall color/colour kommt dazu, daß das "u" nicht in der Aussprache reflektiert wird und insofern nicht gerade "naheliegend" ist.
  In "alle anderen" sind natürlich auch jene Mapper enthalten, die die BrE-Konvention gar nicht kennen; von diesen werden viele sicher zu color neigen. Andererseits würde ich erwarten (auch dies eine unbewiesene Vermutung), daß diese tendentiell weniger versierten Mapper auch häufiger Editorpresets bzw. gleich Preset-basierte Editoren benutzen und daher gar nicht in die Verlegenheit kommen, den Schlüssel selbst einzutippen.
  
  building:color und roof:color sind jedenfalls erst einmal auskommentiert, bis eine Lösung gefunden ist.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 22.10.2013 14:09 · [flux]
  
  Ich habe einmal die Objekte mit /.*:color/ aus dem DE-Extrakt ausgefiltert. Die Idee war: wenn ein großer Teil dieser Tags von wenigen Mappern stammt, könnte man die gezielt ansprechen. Entweder antworten sie dann "hoppla, das war in der Tat ein Fehler" und ändern entweder die Tags selbst oder stimmen dem Umtaggen zu; oder es stellt sich heraus, daß ein signifikanter Teil der - nach gültiger Definition - falschen Tags mit Absicht gesetzt wurde, und das Thema ist erledigt.
  
  Zuerst die absoluten Zahlen. In (Geofabrik-)DE kommt gibt es 3464 building:color, 1091 roof:color, 150 fire_hydrant:color (größtensteils in Erlangen), 140 building:facade:color, 128 ref:color, 45 tee:color (auf einem brandenburgischen Golfplatz), 22 beacon:color (Seezeichen - an 14 davon ist zugleich beacon:colour gesetzt) und ein paar seltene Exemplare (piste:color, network:color, note:color, lit:color).
  
  Die folgenden Zahlen beziehen sich in der Regel auf den letzten Bearbeiter. Nur in Einzelfällen (s.u.) habe ich nachgesehen, ob dieser auch tatsächlich das fragliche Tag eingetragen hat; ich gehe anhand der Stichprobe jedoch davon aus, daß dies auch in den übrigen Fällen meist so ist.
  
  Der hier kontroverse Schlüssel building:color liegt zu 75% (2606 Stück) auf den Stelen des Berliner Holocaust-Mahnmals und ist damit einem einzelnen Mapper zuzuordnen. (Ob das Tagging als Gebäude für die Betonklötze angebracht ist, soll nicht zum Thema dieses Fadens werden.) Die vier fleißigsten Verwender von building:color bringen 2937 Verwendungen (85%) zusammen, die 13 fleißigsten bringen es auf 3308 (95%). Der fünfte auf der Liste (weitere 2%) ist nur zufällig letzter Anfasser und hat sogar im Gegenteil an diesen Objekten building:roof:color zu building:roof:colour korrigiert (aber building:color wohl übersehen).
  
  Bei roof:color ist die Verteilung breiter, aber 14 Mapper erreichen zusammen einen Anteil von immerhin 85% (923 Stück). Die übrigen 48 Mapper sind jeweils bei höchstens 13 Objekten der letzte Bearbeiter, 26 von ihnen bei nicht mehr als zwei Objekten. Zu letzteren gehören u.a. Wall·E und wheelmap_visitor, die ganz sicher keine 3D-Tags gesetzt haben, also nur zufällig als letzter Bearbeiter in Erscheinung treten.
  
  Mein Lösungsvorschlag ist, die betreffenden Mapper wie eingangs skizziert einzubinden. Wenn die Antwort einhellig lautet, daß die Verwendung von /.*:color/ unabsichtlich erfolgt ist, kann building:color bzw. roof:color geändert werden: zum einen ist dann gesichert, daß der Großteil der Verwendungen irrtümlich erfolgt ist, und es bleibt nur ein kleiner Teil, bei dem nicht ausgeschlossen ist, daß der User bewußt "color" geschrieben hat. Zum anderen verschiebt sich das Zahlenverhältnis, sodaß von konkurrierenden Tags nicht einmal mehr ansatzweise die Rede sein kann und nicht die Gefahr besteht, eine laufende "Abstimmung mit den Füßen" zwischen beiden Varianten abzuwürgen. (Nicht nur, aber vor allem @MasiMaster:) Einverstanden?
  
  Dies sind die fleißigsten Verwender (91%) von building:color. Bei ihnen habe ich stichprobenartig geprüft, daß sie tatsächlich die betreffenden Objekte erstellt bzw. building:color hinzugefügt haben, also nicht nur zufällig letzter Bearbeiter sind.
  
  • Tronikon (2606)
  • Kallischmann (154)
  • rehwald (95)
  • MartinSt87 (82)
  • ~~user_5359 (69)~~ zufällig letzter Bearbeiter, s.o.
  • projecter63 (51)
  • kilt (48)
  • Oberaffe (46)
  
  Vielleicht hat jemand ohnehin Kontakt zu einem der Mapper und mag ihn auf diese Diskussion (und seine mögliche Rolle darin) hinweisen. Falls jemand das Anschreiben insgesamt übernehmen möchte, ist mir das auch sehr recht.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 22.10.2013 15:48 · [flux]
  
  Oli-Wan wrote:
  
  building:color und roof:color sind jedenfalls erst einmal auskommentiert, bis eine Lösung gefunden ist.
  
  Schade. Die Schreibweise ohne "u" sehe ich persönlich als Schreibfehler an.
  Jedoch kann ich nachvollziehen, dass du dich zur Zeit nicht auf das Problem "Massen-Umtaggen" einlassen willst.
  
  Also gehen wir diesen speziellen Fehler erst später und nach einer ausführlichen Diskussion an.
  Wie ich in der Vorschau gesehen habe, hast du ja bereits einen Ansatz gefunden. Hoffen wir mal, dass der eine Hauptnutzer mit 75% an building:color an einem Ort, mit der Änderung einverstanden ist, am besten sogar selber korrigiert.
  
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · seichter (Gast) · 22.10.2013 18:57 · [flux]
  
  Ich persönlich wäre da nicht ganz so behutsam, ich finde es aber ok, bei Massentaggings sehr zurückhaltend vorzugehen.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · BFX (Gast) · 22.10.2013 21:22 · [flux]
  
  Mir ist bei deinen Teständerungen gerade wieder aufgefallen, das bei vielen korrigierten keys auch häufiger auch in den values oder bei anderen Tags des Objektes etwas nicht koscher ist.
  
  Negativ an den Tests ist mir nichts aufgefallen.
  
  An der Stelle wo Keep-Right die Verwendung von colour statt color vorschlägt habe ich sofern ich es nicht selbst verbockt hatte bisher auch nichts gemacht.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 22.10.2013 21:25 · [flux]
  
  seichter wrote:
  
  Ich persönlich wäre da nicht ganz so behutsam, ich finde es aber ok, bei Massentaggings sehr zurückhaltend vorzugehen.
  
  Bevor man dem Master of "color" heftig auf die Füße tritt, sollte man auf jeden Fall einmal mit ihm reden.
  Falls der einer Änderung zustimmt, sehen die Zahlen dann ja deutlich anders aus.
  
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · MasiMaster (Gast) · 23.10.2013 00:59 · [flux]
  
  Oli-Wan wrote:
  
  Mein Lösungsvorschlag ist, die betreffenden Mapper wie eingangs skizziert einzubinden. Wenn die Antwort einhellig lautet, daß die Verwendung von /.*:color/ unabsichtlich erfolgt ist, kann building:color bzw. roof:color geändert werden: zum einen ist dann gesichert, daß der Großteil der Verwendungen irrtümlich erfolgt ist, und es bleibt nur ein kleiner Teil, bei dem nicht ausgeschlossen ist, daß der User bewußt "color" geschrieben hat. Zum anderen verschiebt sich das Zahlenverhältnis, sodaß von konkurrierenden Tags nicht einmal mehr ansatzweise die Rede sein kann und nicht die Gefahr besteht, eine laufende "Abstimmung mit den Füßen" zwischen beiden Varianten abzuwürgen. (Nicht nur, aber vor allem @MasiMaster:) Einverstanden?
  
  1. Alles richtig was ihr sagt, es handelte sich bei dem einen Fall um ein ganz anderes Wort. Es ging nur/auch darum, dass bei einer möglichen Änderung auf color gesagt wird: color wird nur 20x verwendet, coulor 20.000x, also nix mit ändern...
  2. Aber da anscheinend eh niemand anderes außer mir das einfacherer color präferiert, bin ich ohnehin überstimmt.
  3. Deswegen mag ich einer Umbenennung auch nicht im Weg stehen. Dafür ist die Arbeit die du machst zu gut! EINE Schreibweise ist auf jeden Fall viel sinnvoller als mehrere!
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 23.10.2013 11:52 · [flux]
  
  BFX wrote:
  
  Mir ist bei deinen Teständerungen gerade wieder aufgefallen, das bei vielen korrigierten keys auch häufiger auch in den values oder bei anderen Tags des Objektes etwas nicht koscher ist.
  
  Das beobachte ich bei den bereits etablierten Korrekturprozessen auch. Es ist (nicht nur in OSM) einfach so, daß Fehler nicht unabhängig auftreten, sondern zu Häufungen neigen. Wer einen Fehelr mcaht, mahct häufgi(er) aich npch eimen. Bei den einer Adresskorrektur unterzogenen Objekten sind manchmal welche dabei, wo man eigentlich fast alle Tags überarbeiten müßte. Ich beschränke mich meistens darauf, die übrigen Adresstags so weit wie möglich geradezubiegen.
  
  MasiMaster wrote:
  
  2. Aber da anscheinend eh niemand anderes außer mir das einfacherer color präferiert, bin ich ohnehin überstimmt.
  
  Naja, bei der Diskussion über mechanische Edits in OSM liegt die Schwelle etwas höher als etwa bei einer gewöhnlichen Wahl. Im Grunde sollte allen fundierten Einwänden abgeholfen und nicht bloß der "Kritiker" überstimmt werden. Ich hoffe, daß der obige Vorschlag in diesem Fall die genannte Abhilfe leistet.
  
  Wenn die Frage color/colour völlig isoliert stünde, würde ich übrigens auch (aus Gewohnheit und weil es kürzer ist) color bevorzugen; und wenn ich mal in OSM ein colour-Tag setze, muß ich selbst aufpassen, nicht das u zu vergessen. Aber die allgemeine BrE-Regel hilft vor allem, bei der Einführung neuer Tags unnötiges Durcheinander zu vermeiden, und bietet auch dem Mapper eine Merkhilfe. Daher sollte sie nicht durch Abweichungen kompromittiert werden.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 28.10.2013 16:52 · [flux]
  Inzwischen ist der vorhandene Regelsatz in kleinen Portionen einmal über (fast) ganz DE gelaufen. Die betreffenden Änderungssätze sind weiter oben verlinkt. Ob außer mir sonst noch jemand in die Logs oder Änderungssätze geschaut hat, weiß ich nicht; mir sind jedenfalls in den gut 1000 Bearbeitungen keine Probleme aufgefallen. Eventuell mag der eine oder andere noch einen Blick (mindestens) auf den Lauf in seinem Bundesland werfen.
  
  Voraussichtlich morgen wird es noch einen (kleinen) DE-weiten Restputz mit dem bestehenden Regelsatz geben.
  
  Ferner habe ich eine Reihe von Kandidaten zur Erweiterung des Regelsatzes, die mein Suchprogramm ausgespuckt hat. Dies sind noch längst nicht alle; der Geofabrik-Extrakt hat noch den Stand vor den letzten Bundesland-Läufen, daher ist die Ausgabe des Programms noch etwas unübersichtlich.
```
Highway␣(2)
-->␣highway␣(7962000)
Power_Source␣(1)
-->␣power_source␣(5434)
WATERWAY␣(1)
-->␣waterway␣(373899)
Wikipedia␣(1)
-->␣wikipedia␣(36339)
abondoned␣(9)
-->␣abandoned␣(3101)
addr:usburb␣(1)
-->␣addr:suburb␣(307921)
anmial_keeping:type␣(2)
-->␣animal_keeping:type␣(597)
artsit␣(2)
-->␣artist␣(202)
bicycle␣parking␣(1)
-->␣bicycle_parking␣(9932)
building.part␣(1)
-->␣building:part␣(16644)
capacity:disable␣(1)
-->␣capacity:disabled␣(10420)
describtion␣(1)
-->␣description␣(198908)
description.de␣(1)
-->␣description:de␣(5292)
detout␣(1)
-->␣detour␣(1922)
diet:vegatarian␣(1)
-->␣diet:vegetarian␣(158)
emergeny␣(1)
-->␣emergency␣(79548)
entarnce␣(1)
-->␣entrance␣(185170)
inclide␣(4)
-->␣incline␣(43485)
ficme␣(1)
-->␣fixme␣(70153)
is:in:township␣(1)
-->␣is_in:township␣(114)
is_in:townahip␣(1)
-->␣is_in:township␣(114)
is_n␣(1)
-->␣is_in␣(90450)
lamp:mount␣(3)
-->␣lamp_mount␣(16132)
lanes.backward␣(1)
-->␣lanes:backward␣(9961)
lanes.forward␣(2)
-->␣lanes:forward␣(11460)
lanes;backward␣(3)
-->␣lanes:backward␣(9961)
lanes_backward␣(12)
-->␣lanes:backward␣(9961)
lanes_forward␣(12)
-->␣lanes:forward␣(11460)
lurn:lanes␣(1)
-->␣turn:lanes␣(14314)
narural␣(1)
-->␣natural␣(830096)
old_addr:housenummer␣(1)
-->␣old_addr:housenumber␣(240)
payment:coin␣(1)
-->␣payment:coins␣(12448)
sidewald␣(4)
-->␣sidewalk␣(45690)
smoking_outside␣(1)
-->␣smoking:outside␣(427)
smotthness␣(5)
-->␣smoothness␣(86873)
wikipedia.de␣(1)
-->␣wikipedia:de␣(13924)
xmas:features␣(1)
-->␣xmas:feature␣(449)
xmas:loaction␣(1)
-->␣xmas:location␣(214)
```
  Daneben gibt es einen Haufen Tagschlüssel, die zwar ungemein faul riechen, für die eine automatische Korrektur aber nicht in Frage kommt. Nur für den Fall, daß jemand sich dieser per Overpass API und JOSM annehmen will, einige Beispiele:
```
add␣(7)
add:␣(1)
biking␣(2)
bui␣(29)
build␣(61)
cycle␣(6)
day␣(2)
des␣(7)
fuel:octane␣(2)
maxspeed:␣(1)
mea␣(1)
nam␣(18)
opening␣(10)
oper␣(4)
sour␣(3)
wikimedia␣(1)
```
  Edit: Satzbau.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · poppei82 (Gast) · 28.10.2013 18:12 · [flux]
  
  Oli-Wan wrote:
  
  Inzwischen ist der vorhandene Regelsatz kleinen Portionen einmal über (fast) ganz DE gelaufen.
  
  Danke!
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · errt (Gast) · 28.10.2013 20:38 · [flux]
  
  Schaut gut aus!
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · seichter (Gast) · 28.10.2013 21:05 · [flux]
  
  Oli-Wan wrote:
  
  Power_Source (1) --> power_source (5434)
  
  Eigentlich lohnt es sich nicht, wegen ein/zwei Fehlern einen Regelsatz aufzustellen. Aber wenn der Bot sowieso schon unterwegs ist, erspart er einem menschlichen Tagger die Suche. Die Energie kann man dann statt dessen in die Bot-untauglichen Reste stecken. Die Verdachtsliste halte ich für einen guten Ansatz.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 28.10.2013 23:10 · [flux]
  
  Oli-Wan wrote:
  
  Inzwischen ist der vorhandene Regelsatz in kleinen Portionen einmal über (fast) ganz DE gelaufen. ... Ob außer mir sonst noch jemand in die Logs oder Änderungssätze geschaut hat, weiß ich nicht; mir sind jedenfalls in den gut 1000 Bearbeitungen keine Probleme aufgefallen. Eventuell mag der eine oder andere noch einen Blick (mindestens) auf den Lauf in seinem Bundesland werfen.
  
  ...
  Ferner habe ich eine Reihe von Kandidaten zur Erweiterung des Regelsatzes, die mein Suchprogramm ausgespuckt hat. Dies sind noch längst nicht alle; der Geofabrik-Extrakt hat noch den Stand vor den letzten Bundesland-Läufen, daher ist die Ausgabe des Programms noch etwas unübersichtlich.
  ...
  
  Ich habe mir den Regierungsbezirk Köln angeschaut. Da war nichts auffälliges dabei, was nicht schon besprochen / gelöst worden wäre.
  
  Die anderen Changsets habe ich (ohne mir die Details anzusehen) durchgeblättert. Ich war erstaunt, wie wenig Änderungen es gab. Ich hatte mit deutlich mehr gerechnet. Das zeigt meiner Ansicht nach, dass die Editorunterstützung fürs Taggen doch recht gut ist.
  
  In deiner Kandidatenliste sind mir zwei Dinge aufgefallen:
  - Power_Source (1) --> power_source (5434)
  - lamp:mount (3) --> lamp_mount (16132)
  
  power_source ist als Schlüssel veraltet, es sollte generator:source verwendet werden.
  Ebenso ist lamp_mount nirgends definiert. Im aktuellen Proposal wird statt dessen support=* (wie bei Uhren) vorgeschlagen.
  
  Aber beides geht über Tippfehler Korrektur weit hinaus und muss von dir daher nicht beachtet werden.
  
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 28.10.2013 23:57 · [flux]
  
  EvanE wrote:
  
  Ich war erstaunt, wie wenig Änderungen es gab. Ich hatte mit deutlich mehr gerechnet. Das zeigt meiner Ansicht nach, dass die Editorunterstützung fürs Taggen doch recht gut ist.
  
  Ich denke, daß das Problem der Tippfehler in Tagschlüsseln (und diskreten Werten) in Zukunft eher noch kleiner werden wird. Die Anfänger-Editoren arbeiten sowieso mit Presets, und bei JOSM scheint sich deren Nutzung auch immer mehr durchzusetzen. Manchmal habe ich den Eindruck, ich bin das letzte Fossil, das seine Tags noch selbst eintippt. Andererseits: wenn man gewohnt ist, Presets zu nutzen, ist man mit den Tags weniger vertraut, wenn man sie dann doch mal manuell eintragen muß. Vielleicht verschieben sich also auch nur die Fehlerquellen vom reinen Vertippen zur Unkenntnis der Schreibweise.
  
  EvanE wrote:
  
  power_source ist als Schlüssel veraltet, es sollte generator:source verwendet werden.
  Ebenso ist lamp_mount nirgends definiert. Im aktuellen Proposal wird statt dessen support=* (wie bei Uhren) vorgeschlagen.
  
  Berechtigte Anmerkungen. Aber zumindest liegt dann einheitlich z.B. power_source statt Power_Source etc. vor - und ist somit auch einer Änderung leichter zugänglich.
  
  seichter wrote:
  
  Eigentlich lohnt es sich nicht, wegen ein/zwei Fehlern einen Regelsatz aufzustellen.
  
  Stimmt. Aber so können sie zumindest auch in Zukunft korrigiert werden, wenn sie erneut auftreten, und man fängt mit der Suche nach falsch geschriebenen Tags nicht jedes Mal von vorne an.
  
  Wie häufig sich bestimmte Fehler wiederholen, wird man sehen - schlichtweg daran, wieviel der unveränderte Regelsatz einige Wochen nach seinem letzten Einsatz erwischt.
  
  Übrigens ist die Aufnahme in den Regelsatz sogar für einen nur ein Mal auftretenden Fehler im Verhältnis zur "klassischen" Methode längst nicht so aufwendig wie man zunächst vermuten könnte. Ich muß nur zwei Schlüssel (falsch und richtig) in eine einzige Liste eintragen. Alle weiteren Schritte sind nur einmal für den gesamten Regelsatz nötig, unabhängig von der Anzahl der Tags: Liste zu C++-Code für das Filterprogramm konvertieren, Filterprogramm kompilieren, Extrakt durchsuchen, Korrekturprozeß ausführen. Die konventionelle Alternative: herunterladen per Overpass API (Abfrage mit dem falschen Tagschlüssel schreiben - umständlich, wenn man den Objekttyp nicht kennt) oder aus dem Extrakt herausfiltern (dauert aber einige Minuten), Änderung in JOSM vornehmen (Tagschlüssel korrigieren oder Tag löschen, obendrein fehleranfällig), hochladen. Und das ganze für jedes singuläre Tag einzeln.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · rayquaza (Gast) · 29.10.2013 00:30 · [flux]
  
  Oli-Wan wrote:
  
  Manchmal habe ich den Eindruck, ich bin das letzte Fossil, das seine Tags noch selbst eintippt. Andererseits: wenn man gewohnt ist, Presets zu nutzen, ist man mit den Tags weniger vertraut, wenn man sie dann doch mal manuell eintragen muß. Vielleicht verschieben sich also auch nur die Fehlerquellen vom reinen Vertippen zur Unkenntnis der Schreibweise.
  
  Bist du nicht, u.A. aus den von dir genannten Gründen. Ausser du zählst die Vervollständigung des Eingetippten mit, die neben den geladenen Objekten auch die Vorlagen nutzt 😉
  
  Oli-Wan wrote:
  
  seichter wrote:
  
  Eigentlich lohnt es sich nicht, wegen ein/zwei Fehlern einen Regelsatz aufzustellen.
  
  Stimmt. Aber so können sie zumindest auch in Zukunft korrigiert werden, wenn sie erneut auftreten, und man fängt mit der Suche nach falsch geschriebenen Tags nicht jedes Mal von vorne an.
  
  Wie häufig sich bestimmte Fehler wiederholen, wird man sehen - schlichtweg daran, wieviel der unveränderte Regelsatz einige Wochen nach seinem letzten Einsatz erwischt.
  
  Wenn ein Fehlertyp häufig an unterschiedlichen Tags auftritt und keine false-positives erzeugt könnte man ja auch überlegen etwas aggressiver vorzugehen.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 29.10.2013 12:03 · [flux]
  So, der DE-weite Restputz ist durch. Er ist mit 267 Objekten doch etwas größer ausgefallen als von mir zunächst erwartet. Offenbar hatte der erste Durchgang vor allem in und um Ahaus einige addrPostcode und addrStreet nicht erwischt, ferner waren seit letzter Woche in Solingen einige (43) add:city hinzugekommen.
  
  Und gleich die nächsten Erweiterungskandidaten:
```
FIXMW␣(2)
-->␣FIXME␣(48448)
FXIME␣(2)
-->␣FIXME␣(48448)
aadr:country␣(1)
-->␣addr:country␣(3494847)
abandoned_railway␣(1)
-->␣abandoned:railway␣(140)
board:type␣(3)
-->␣board_type␣(13682)
building;part␣(2)
-->␣building:part␣(16670)
building_part␣(3)
-->␣building:part␣(16670)
builging:levels␣(1)
-->␣building:levels␣(122818)
castlestype␣(1)
-->␣castle_type␣(1649)
delivers␣(1)
-->␣delivery␣(410)
hvg␣(14)
-->␣hgv␣(24118)
hvg:conditional␣(1)
-->␣hgv:conditional␣(105)
intermitten␣(1)
-->␣intermittent␣(1448)
laayer␣(1)
-->␣layer␣(503116)
maxheigh␣(1)
-->␣maxheight␣(14038)
maxspeed:fo␣(1)
-->␣maxspeed:forward␣(6481)
maxspeed;backward␣(2)
-->␣maxspeed:backward␣(6327)
maxweight:condition␣(1)
-->␣maxweight:conditional␣(519)
megalith_typ␣(1)
-->␣megalith_type␣(357)
mtb:scale;uphill␣(1)
-->␣mtb:scale:uphill␣(11119)
note.de␣(1)
-->␣note:de␣(21558)
parking:condition:area;customers␣(1)
-->␣parking:condition:area:customers␣(130)
parking:condition:left.residents␣(1)
-->␣parking:condition:left:residents␣(270)
parking:condition:left:time_intervall␣(1)
-->␣parking:condition:left:time_interval␣(385)
parking:condition:right:time_intervall␣(4)
-->␣parking:condition:right:time_interval␣(545)
parking:condition:rigth␣(1)
-->␣parking:condition:right␣(3008)
parking:condition_both␣(1)
-->␣parking:condition:both␣(1952)
parking:lane:rigth:parallel␣(1)
-->␣parking:lane:right:parallel␣(762)
parking_condition␣(1)
-->␣parking:condition␣(217)
parking_lane:left␣(6)
-->␣parking:lane:left␣(5612)
parking_lane:left:parallel␣(2)
-->␣parking:lane:left:parallel␣(686)
patking␣(1)
-->␣parking␣(115270)
relig␣(1)
-->␣religion␣(54833)
rer␣(1)
-->␣ref␣(826099)
source:gemoetry␣(20)
-->␣source:geometry␣(15771)
source:geom␣(2)
-->␣source:geometry␣(15771)
source:heigth␣(7)
-->␣source:height␣(855)
source:maxpseed␣(25)
-->␣source:maxspeed␣(104027)
suirface␣(4)
-->␣surface␣(1757099)
tracktyper␣(1)
-->␣tracktype␣(1563506)
```
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 29.10.2013 12:42 · [flux]
  
  Oli-Wan wrote:
  
  So, der DE-weite Restputz ist durch. Er ist mit 267 Objekten doch etwas größer ausgefallen als von mir zunächst erwartet. Offenbar hatte der erste Durchgang vor allem in und um Ahaus einige addrPostcode und addrStreet nicht erwischt, ferner waren seit letzter Woche in Solingen einige (43) add:city hinzugekommen.
  
  Da bin ich ja beruhigt, dass doch noch ein paar Korrekturen zusammen gekommen sind. Wieviel waren es denn insgesamt? Über den Daumen gepeilt vermute ich ca. 40-50 je Bundesland / Regierungsbezirk von NRW + das Heute also etwas über tausend.
  
  PS:
  Du bist nicht allein, auch ich gehöre zu denen, die die Taggs lieber eintippen. Ausnahme ist das Adress-Preset, da das mittlerweile die Hausnummern schön rauf-/runterzählen kann. Für 3D-Gebäude muss ich mal schauen, ob es da mittlerweile was schönes für gibt.
  
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 29.10.2013 12:50 · [flux]
  
  1330 stehen im Logfile, dazu 52 aus dem nicht protokollierten Lauf im Regierungsbezirk Münster. (Daneben habe ich noch 282 Source->source mit JOSM über meinen normalen Account geändert, sonst wären für den Regierungsbezirk Arnsberg mehrere Durchgänge nötig gewesen.)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · seawolff (Gast) · 30.10.2013 18:28 · [flux]
  
  Oli-Wan wrote:
  
  Und gleich die nächsten Erweiterungskandidaten:
  
  FIXMW (2)
  FXIME (2)
  aadr:country (1)
  abandoned_railway (1)
  ...
  
  Zunächst vielen Dank für die nützliche Aufräumarbeit.
  
  Bei solchen offensichtlichen Tippfehlern, die sehr selten auftreten (<5), musst du m. E. die Korrektur nicht vorher ankündigen.
  
  hvg (14) --> hgv (24118)
  
  Vermutlich hast du recht. Bei Keys mit drei Buchstaben könnte auch etwas anderes gemeint sein. Nahezu jede Kombination aus drei Buchstaben dürfte irgendwo als Akronym auftreten.
  Hier könntest du auf "highway=*" testen.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 30.10.2013 19:05 · [flux]
  seawolff wrote:
  
  hvg (14) --> hgv (24118)
  
  Vermutlich hast du recht. Bei Keys mit drei Buchstaben könnte auch etwas anderes gemeint sein. Nahezu jede Kombination aus drei Buchstaben dürfte irgendwo als Akronym auftreten.
  Hier könntest du auf "highway=*" testen.
  
  Die zugehörigen Werte legen nahe, daß in den vorhandenen Fällen tatsächlich hgv gemeint war:
```
␣␣␣␣␣1␣␣␣␣␣<tag␣k="hvg:conditional"␣v="no␣@␣(13:00-15:00,␣22:00-07:00)"/>
2␣␣␣␣␣<tag␣k="hvg"␣v="delivery"/>
12␣␣␣␣␣<tag␣k="hvg"␣v="no"/>
```
  Von den 15 Objekten haben 12 bereits ein highway-Tag. Die übrigen sind Parkplätze oder das Tag scheint verirrt.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 30.10.2013 21:56 · [flux]
  Hier fortgesetzt (und sinnwahrend gekürzt), um den Nachbarfaden nicht länger zu kapern:
  
  EvanE wrote:
  
  Oli-Wan wrote:
  
  Mit den verschiedenen Tags mit "_" und ":" machen wir es allerdings den Mappern allgemein ganz schön schwer. Da blickt wahrscheinlich keiner mehr wirklich durch, daher auch die vielen einschlägigen Fehler.
  
  In der Tat ist die Frage "'_' oder ':'" einer der häufigsten Gründe einen Schlüssel im Wiki nachzuschlagen.
  Es gibt natürlich ein paar Leitlinien. Besteht ein Begriff eigentlich aus zwei Worten, so werden diese mit Unterstrich statt Leerzeichen geschrieben.
  Schwieriger wird es bei Unterschlüsseln mit einem gemeinsamen Wort als Beginn. Früher wurde Hauptschlüssel Unterstrich Unterschlüssel verwendet. Heute bevorzugt man Hauptschlüssel Doppelpunkt Unterschlüssel. Häufig kann man das aber kaum einschätzen. Verlassen kann man sich darauf leider nicht.
  
  Um das zu untermauern, hier einige Korrekturen von Sub-Schlüsseln, wo "_" bzw. ":" "falsch" verwendet wird.
```
board:type␣->␣board_type
castle:type␣->␣castle_type
generator_method␣->␣generator:method
generator_source␣->␣generator:source
heritage_operator␣->␣heritage:operator
memorial_type␣->␣memorial:type
mtb_scale␣->␣mtb:scale
parking_condition␣->␣parking:condition
roof_colour␣->␣roof:colour
roof_shape␣->␣roof:shape
shelter:type␣->␣shelter_type
```
  Außer daß "jüngere" Schlüssel eher ":" enthalten, gibt es eigentlich kaum einen als Merkregel taugenden Anhaltspunkt, was nun "richtig" ist. Und im Grunde könnten alle statt als Unterschlüssel auch als einfache Schlüssel aus zwei Worten durchgehen, wenn man nicht weiß, daß sie Teil eines größeren Schemas (roof:colour, roof:shape, roof:levels, roof:gedöns, ...) sind und dabei ":" bevorzugt wird.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 30.10.2013 22:31 · [flux]
  Oli-Wan wrote:
  EvanE wrote:
  
  In der Tat ist die Frage "'_' oder ':'" einer der häufigsten Gründe einen Schlüssel im Wiki nachzuschlagen. ...
  
  Um das zu untermauern, hier einige Korrekturen von Sub-Schlüsseln, wo "_" bzw. ":" "falsch" verwendet wird.
  
  board:type␣->␣board_type castle:type␣->␣castle_type generator_method␣->␣generator:method generator_source␣->␣generator:source heritage_operator␣->␣heritage:operator memorial_type␣->␣memorial:type mtb_scale␣->␣mtb:scale parking_condition␣->␣parking:condition roof_colour␣->␣roof:colour roof_shape␣->␣roof:shape shelter:type␣->␣shelter_type
  
  Außer daß "jüngere" Schlüssel eher ":" enthalten, gibt es eigentlich kaum einen als Merkregel taugenden Anhaltspunkt, was nun "richtig" ist. Und im Grunde könnten alle statt als Unterschlüssel auch als einfache Schlüssel aus zwei Worten durchgehen, wenn man nicht weiß, daß sie Teil eines größeren Schemas (roof:colour, roof:shape, roof:levels, roof:gedöns, ...) sind und dabei ":" bevorzugt wird.
  Die Unterschlüssel zu generator, heritage und 3D-Buildings sind in der Tat recht neu (1-2 Jahre). Ebenso einige Unterschlüssel von historic (memorial:*) während andere Unterschlüssel (castle_type) schon recht lange dabei sind.
  
  Richtig gemein ist mtb:scale im Gegensatz zu sac_scale, ähnlicher Sachverhalt und ähnlich alt, jedoch andere Schreibweise.
  
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 01.11.2013 14:42 · [flux]
  
  EvanE wrote:
  
  Richtig gemein ist mtb:scale im Gegensatz zu sac_scale, ähnlicher Sachverhalt und ähnlich alt, jedoch andere Schreibweise.
  
  Ja, das ist böse. Vielleicht muß man den Korrekturprozeß in einem solchen Zusammenhang weniger als Fehlerkorrektur und mehr als "nachträgliche Mapperunterstützung" sehen.
  
  Ich habe heute noch in zwei Änderungssätzen alles aufgeräumt, was der aktuelle Regelsatz findet (ausgenommen eine Handvoll Fälle, wo "richtiger" und "falscher" Schlüssel sich widersprechen, etwa capacity=5 und caapcity=10). Damit müßten es nun gut 1600 bearbeitete Objekte sein. Jetzt lege ich erst einmal eine Pause von einer oder zwei Wochen ein, um zu sehen, was der unveränderte Regelsatz danach ausspuckt, sprich ob die bereits bekannten Fehler sich mit nennenswerter Häufigkeit wiederholen. Die Suche nach weiteren kaputten Tagschlüsseln geht natürlich weiter (und Hinweise werden gerne angenommen).
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 11.11.2013 15:19 · [flux]
  Oli-Wan wrote:
  
  Jetzt lege ich erst einmal eine Pause von einer oder zwei Wochen ein, um zu sehen, was der unveränderte Regelsatz danach ausspuckt, sprich ob die bereits bekannten Fehler sich mit nennenswerter Häufigkeit wiederholen. Die Suche nach weiteren kaputten Tagschlüsseln geht natürlich weiter (und Hinweise werden gerne angenommen).
  
  Nach der genannten Pause ist gestern der bestehende Regelsatz noch einmal über DE gelaufen. Die Ausbeute: nur 15 "neue" Objekte mit bekannten falschen Schreibweisen. Optimistische Lesart: Tippfehler geschehen doch nicht so häufig wie befürchtet. Pessimistische Lesart: Tippfehler sind zu vielfältig, um von einem statischen Regelsatz erfaßt zu werden. Die Wahrheit liegt wahrscheinlich irgendwo dazwischen.
  
  In der Zwischenzeit hatte ich noch einige Tags korrigiert, die vom Suchprogramm identifiziert wurden, aber nicht automatisch zu beheben waren (insbesondere Expansion "abgekürzter" Schlüssel). Und auch andere Mapper waren in ähnlicher Mission unterwegs, der eine oder andere wird es bemerkt haben.
  
  Für das weitere Vorgehen bedeutet die obige Zahl: eine regelmäßige automatische Ausführung hat wenig Sinn, weil bekannte Tippfehler sich nur selten wiederholen. Also läuft es wohl darauf hinaus, daß ich in größeren Abständen (Wochen bis Monate - abhängig von Zeit und Lust) das Suchprogramm starte, neue Kandidaten identifiziere, diese hier poste und dann abräume. Möglicherweise kann das Posting langfristig entfallen, denn faktisch ist dieser Korrekturprozeß bei weitem nicht so automatisch wie die anderen (Adressen etc.). Für den nächsten Durchgang sind diese Erweiterungen vorgesehen:
```
Access␣(1)
[values:␣"Private"␣(1)]
-->␣access␣(520002)
Golf␣(50)
[values:␣"bunker"␣(50)]
-->␣golf␣(9638)
Operator␣(1)
[values:␣"Wall␣AG"␣(1)]
-->␣operator␣(314730)
acces␣(2)
[values:␣"agricultural"␣(2)]
-->␣access␣(520002)
Wiki:symbol␣(1)
[values:␣"Hoehensteig_Klingent..."␣(1)]
-->␣wiki:symbol␣(4104)
addr:places␣(12)
[values:␣"Bienwaldmühle"␣(10)␣"Zollhaus"␣(2)]
-->␣addr:place␣(3786)
amenitiy␣(1)
[values:␣"advertising"␣(1)]
-->␣amenity␣(1194699)
ameniy␣(1)
[values:␣"parking"␣(1)]
-->␣amenity␣(1194699)
barnd␣(1)
[values:␣"Volkswagen"␣(1)]
-->␣brand␣(14632)
bicycle-road␣(1)
[values:␣"yes"␣(1)]
-->␣bicycle_road␣(699)
bicylce␣(2)
[values:␣"yes"␣(2)]
-->␣bicycle␣(693545)
biuilding␣(1)
[values:␣"yes"␣(1)]
-->␣building␣(11944967)
boundary:type␣(1)
[values:␣"protected_area"␣(1)]
-->␣boundary_type␣(264)
building:levens␣(3)
[values:␣"2"␣(3)]
-->␣building:levels␣(124633)
building:min_levels␣(11)
[values:␣"1"␣(1)␣"13"␣(1)␣"2"␣(1)␣"22"␣(1)␣"3"␣(1)␣"4"␣(4)␣"5"␣(1)␣"8"␣(1)]
-->␣building:min_level␣(1738)
building:roof:color␣(8)
[values:␣"#443c39"␣(8)]
-->␣building:roof:colour␣(2662)
building;levels␣(1)
[values:␣"5"␣(1)]
-->␣building:levels␣(124633)
building_height␣(1)
[values:␣"2"␣(1)]
-->␣building:height␣(30333)
couisin␣(2)
[values:␣"greek"␣(1)␣"italian"␣(1)]
-->␣cuisine␣(54188)
cousine␣(2)
[values:␣"ice_cream"␣(1)␣"india"␣(1)]
-->␣cuisine␣(54188)
destination.backward␣(1)
[values:␣"Osburger␣Hof"␣(1)]
-->␣destination:backward␣(450)
emergeny␣(1)
[values:␣"fire_hydrant"␣(1)]
-->␣emergency␣(81161)
fon␣(3)
[values:␣"+49␣30␣7403-0"␣(1)␣"+49␣5731␣3006992"␣(1)␣"02339␣-␣4800"␣(1)]
-->␣phone␣(89787)
histoirc␣(1)
[values:␣"monument"␣(1)]
-->␣historic␣(88855)
maxweiht␣(2)
[values:␣"7.5"␣(2)]
-->␣maxweight␣(27741)
motorcycle:condition␣(1)
[values:␣"no␣@␣(20:00-06:00)"␣(1)]
-->␣motorcycle:conditional␣(122)
mtb:sacle␣(4)
[values:␣"0"␣(4)]
-->␣mtb:scale␣(84365)
onway␣(2)
[values:␣"no"␣(1)␣"yes"␣(1)]
-->␣oneway␣(478112)
osmc_name␣(1)
[values:␣"Bad␣Bergzabeber␣Land..."␣(1)]
-->␣osmc:name␣(587)
postal_codes␣(7)
[values:␣"50667-51149"␣(1)␣"63768"␣(1)␣"66849"␣(1)␣"66877"␣(1)␣"67685"␣(1)␣"67686"␣(1)␣"67688"␣(1)]
-->␣postal_code␣(264238)
sports␣(1)
[values:␣"darts"␣(1)]
-->␣sport␣(116970)
sourche␣(1)
[values:␣"survey"␣(1)]
-->␣source␣(3514137)
source:maxspeeed␣(11)
[values:␣"DE:rural"␣(1)␣"DE:urban"␣(10)]
-->␣source:maxspeed␣(105272)
stepps␣(1)
[values:␣"60"␣(1)]
-->␣steps␣(398)
surce␣(2)
[values:␣"survey"␣(2)]
-->␣source␣(3514137)
trachtype␣(2)
[values:␣"grade4"␣(2)]
-->␣tracktype␣(1571042)
tracktpe␣(1)
[values:␣"grade4"␣(1)]
-->␣tracktype␣(1571042)
tracktye␣(3)
[values:␣"grade2"␣(1)␣"grade4"␣(2)]
-->␣tracktype␣(1571042)
tracktypr␣(1)
[values:␣"grade4"␣(1)]
-->␣tracktype␣(1571042)
wheelchair:description:DE␣(4)
[values:␣"Eingang␣barrierefrei..."␣(1)␣"Eingang␣vorne␣mit␣St..."␣(1)␣"Toiletten␣im␣UG,␣nur..."␣(1)␣"keine␣Rolli-WC´s"␣(1)]
-->␣wheelchair:description:de␣(972)
wheelchair:toilet␣(1)
[values:␣"yes"␣(1)]
-->␣wheelchair:toilets␣(324)
wheelchair_access␣(2)
[values:␣"eurokey"␣(2)]
-->␣wheelchair:access␣(214)
wheelchir␣(1)
[values:␣"no"␣(1)]
-->␣wheelchair␣(308160)
vrr:wae␣(1)
[values:␣"430"␣(1)]
-->␣vrr:wabe␣(1392)
```
  (Die Werte in Klammern sind nur die aktuell vorkommenden - die Ersetzung wird nicht darauf beschränkt.)
  Daneben gibt es noch unzählige, die überaus fraglich sind, aber manuell überprüft werden müssen. Einige davon sehe ich mir bei Gelegenheit an.
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · EvanE (Gast) · 11.11.2013 16:05 · [flux]
  Oli-Wan wrote:
  Oli-Wan wrote:
  
  Jetzt lege ich erst einmal eine Pause von einer oder zwei Wochen ein, um zu sehen, was der unveränderte Regelsatz danach ausspuckt, sprich ob die bereits bekannten Fehler sich mit nennenswerter Häufigkeit wiederholen. ...
  
  Nach der genannten Pause ist gestern der bestehende Regelsatz noch einmal über DE gelaufen. Die Ausbeute: nur 15 "neue" Objekte mit bekannten falschen Schreibweisen. ...
  
  Für das weitere Vorgehen bedeutet die obige Zahl: eine regelmäßige automatische Ausführung hat wenig Sinn, weil bekannte Tippfehler sich nur selten wiederholen. Also läuft es wohl darauf hinaus, daß ich in größeren Abständen (Wochen bis Monate - abhängig von Zeit und Lust) das Suchprogramm starte, ... Für den nächsten Durchgang sind diese Erweiterungen vorgesehen:
  
  ...
  
  ...
  In deiner Liste zeigt sich mal wieder, dass Tippfehler oft im Bündel passieren, also sowohl im Schlüssel als auch beim Wert. Alles was ich gesehen habe macht Sinn, also von meiner Seite aus in deinen Regelsatz aufnehmen.
  
  Ansonsten möchte ich vorerst einmal im Monat als Frequenz für den Bot-Lauf vorschlagen. Wenn sich dann immer noch zeigt, dass es sich kaum lohnt, kannst du immer noch auf alle zwei - drei Monate runter gehen.
  
  Bei der Korrektur von Werten wird es dann wieder spannend. Da liegt ja noch einiges im Argen (z.B. Komma statt Punkt als Dezimaltrenner). Aber das ist wohl eher ein Thema / Projekt für das nächste Jahr.
  
  Edbert (EvanE)
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · Oli-Wan (Gast) · 27.12.2013 20:50 · [flux]
  Nächste vorgesehene Erweiterungen:
```
FIIXME␣(2)
[values:␣"Position"␣(2)]
-->␣FIXME␣(48920)
From␣(1)
[values:␣"A5␣Langen/MÃ¶rfelden"␣(1)]
-->␣from␣(13403)
Phone␣(3)
[values:␣"+49␣561␣8047210"␣(1)␣"+49␣561␣983593"␣(1)␣"02204-20140"␣(1)]
-->␣phone␣(93695)
Tracktype␣(4)
[values:␣"grade3"␣(1)␣"grade4"␣(3)]
-->␣tracktype␣(1587874)
URL␣(1)
[values:␣"www.lomm-hamburg.de"␣(1)]
-->␣url␣(7333)
addr_postcode␣(1)
[values:␣"40233"␣(1)]
-->␣addr:postcode␣(4416210)
alt:name␣(1)
[values:␣"ICA-Haus"␣(1)]
-->␣alt_name␣(18085)
amenty␣(1)
[values:␣"Bank"␣(1)]
-->␣amenity␣(1198276)
atl_name␣(1)
[values:␣"Altes␣Audimax"␣(1)]
-->␣alt_name␣(18085)
biilding␣(1)
[values:␣"yes"␣(1)]
-->␣building␣(12634826)
bivycle_parking␣(1)
[values:␣"shed"␣(1)]
-->␣bicycle_parking␣(10451)
brdige␣(1)
[values:␣"yes"␣(1)]
-->␣bridge␣(239309)
building_colour␣(1)
[values:␣"yellow"␣(1)]
-->␣building:colour␣(36342)
collection_time␣(1)
[values:␣"Mo-Sa␣08:00"␣(1)]
-->␣collection_times␣(16824)
discription␣(1)
[values:␣"Badeinsel"␣(1)]
-->␣description␣(202135)
discription:en␣(1)
[values:␣"Swim␣platform"␣(1)]
-->␣description:en␣(248)
escalator:dir␣(2)
[values:␣"up"␣(1)␣"up;down;down"␣(1)]
-->␣escalator_dir␣(322)
escelator_dir␣(3)
[values:␣"down"␣(2)␣"up"␣(1)]
-->␣escalator_dir␣(322)
genud:de␣(1)
[values:␣"Eiche"␣(1)]
-->␣genus:de␣(6805)
handrail_left␣(1)
[values:␣"yes"␣(1)]
-->␣handrail:left␣(1244)
inscript␣(1)
[values:␣"Ehret␣die␣Toten,␣mah..."␣(1)]
-->␣inscription␣(2612)
lanse:forward␣(1)
[values:␣"1"␣(1)]
-->␣lanes:forward␣(13065)
maxhight␣(1)
[values:␣"3.4␣m"␣(1)]
-->␣maxheight␣(14397)
metwork␣(1)
[values:␣"VVO"␣(1)]
-->␣network␣(83488)
motorcycle:condition␣(1)
[values:␣"no␣@␣(20:00-06:00)"␣(1)]
-->␣motorcycle:conditional␣(181)
name:DE␣(2)
[values:␣"Deutsch-FranzÃ¶sisch..."␣(1)␣"FC/DJK␣Burgoberbach"␣(1)]
-->␣name:de␣(6638)
networtk␣(1)
[values:␣"VRB"␣(1)]
-->␣network␣(83488)
nmae:hsb␣(2)
[values:␣"PÅ␣wokolicy"␣(1)␣"Zelezniska␣droga"␣(1)]
-->␣name:hsb␣(10650)
node:de␣(2)
[values:␣"Linien:␣595"␣(1)␣"SperrgepÃ¤ck"␣(1)]
-->␣note:de␣(21983)
oenway␣(1)
[values:␣"no"␣(1)]
-->␣oneway␣(488748)
opening-hours␣(1)
[values:␣"Tu-Su␣11:00-23:00"␣(1)]
-->␣opening_hours␣(74131)
priority_roard␣(3)
[values:␣"designated"␣(3)]
-->␣priority_road␣(456)
roof.shape␣(9)
[values:␣"flat"␣(1)␣"gabled"␣(7)␣"hipped"␣(1)]
-->␣roof:shape␣(132391)
roof:oriantation␣(1)
[values:␣"across"␣(1)]
-->␣roof:orientation␣(26494)
roof:shap␣(7)
[values:␣"flat"␣(7)]
-->␣roof:shape␣(132391)
shelter_typ␣(1)
[values:␣"public_transport"␣(1)]
-->␣shelter_type␣(6503)
step:count␣(1)
[values:␣"10"␣(1)]
-->␣step_count␣(12322)
surface_middle␣(2)
[values:␣"grass"␣(2)]
-->␣surface:middle␣(962)
teacktype␣(2)
[values:␣"grade2"␣(2)]
-->␣tracktype␣(1587874)
turn:Lanes:backward␣(2)
[values:␣"none|through;right"␣(1)␣"none|through|right"␣(1)]
-->␣turn:lanes:backward␣(5577)
turn:Lanes:forward␣(1)
[values:␣"none|left|through"␣(1)]
-->␣turn:lanes:forward␣(7343)
turn:lanes.backward␣(2)
[values:␣"none|merge_to_left"␣(1)␣"none|slight_right"␣(1)]
-->␣turn:lanes:backward␣(5577)
turn:lanesMforward␣(1)
[values:␣"through|through|slig..."␣(1)]
-->␣turn:lanes:forward␣(7343)
turn_lanes:backward␣(1)
[values:␣"left|through|through"␣(1)]
-->␣turn:lanes:backward␣(5577)
```
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · gerd_ (Gast) · 13.09.2015 19:03 · [flux]
  
  Vorschlag zur automatischen Korrektur (aus KeepRight entnommen):
  - This way is tagged 'hazard=animals_crossing' where "animals_crossing" looks like "animal_crossing"
- Re: Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler? · reneman (Gast) · 04.10.2015 22:40 · [flux]
  
  Hallo, kann Wall-E auf seiner Liste die folgenden korrekturen aufnehmen?
  
  • wikimedia:commons -> wikimedia_commons
  • wikipedia_commons -> wikimedia_commons
  • Wikimedia_Commons -> wikimedia_commons
  • media:commons -> wikimedia_commons