Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler?

Oli-Wan · 2013-10-20 22:34:59

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.

Oli-Wan · 2013-10-21 13:31:22

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.)

Last edited by Oli-Wan (2013-10-29 11:57:06)

EvanE · 2013-10-21 15:49:58

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)

Oli-Wan · 2013-10-21 15:52:34

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.

Last edited by Oli-Wan (2013-10-21 16:23:12)

EvanE · 2013-10-21 16:39:43

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)

seichter · 2013-10-21 20:09:29

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.

Oli-Wan · 2013-10-21 20:53:32

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.

errt · 2013-10-21 21:38:04

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).

seichter · 2013-10-21 22:31:04

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 ).

EvanE · 2013-10-21 22:47:56

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)

MasiMaster · 2013-10-21 23:29:08

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!

errt · 2013-10-22 08:37:33

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.

Oli-Wan · 2013-10-22 09:04:11

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.

Oli-Wan · 2013-10-22 14:09:47

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.

EvanE · 2013-10-22 15:48:15

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)

seichter · 2013-10-22 18:57:21

Ich persönlich wäre da nicht ganz so behutsam, ich finde es aber ok, bei Massentaggings sehr zurückhaltend vorzugehen.

BFX · 2013-10-22 21:22:39

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.

EvanE · 2013-10-22 21:25:17

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)

MasiMaster · 2013-10-23 00:59:35

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!

Oli-Wan · 2013-10-23 11:52:48

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.

Oli-Wan · 2013-10-28 16:52:49

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.

Last edited by Oli-Wan (2013-10-28 18:14:40)

poppei82 · 2013-10-28 18:12:50

Oli-Wan wrote:

Inzwischen ist der vorhandene Regelsatz kleinen Portionen einmal über (fast) ganz DE gelaufen.

Danke!

errt · 2013-10-28 20:38:05

Schaut gut aus!

seichter · 2013-10-28 21:05:51

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.

EvanE · 2013-10-28 23:10:16

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)

Announcement

#51 2013-10-20 22:34:59

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

#52 2013-10-21 13:31:22

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

#53 2013-10-21 15:49:58

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

#54 2013-10-21 15:52:34

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

#55 2013-10-21 16:39:43

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

#56 2013-10-21 20:09:29

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

#57 2013-10-21 20:53:32

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

#58 2013-10-21 21:38:04

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

#59 2013-10-21 22:31:04

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

#60 2013-10-21 22:47:56

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

#61 2013-10-21 23:29:08

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

#62 2013-10-22 08:37:33

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

#63 2013-10-22 09:04:11

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

#64 2013-10-22 14:09:47

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

#65 2013-10-22 15:48:15

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

#66 2013-10-22 18:57:21

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

#67 2013-10-22 21:22:39

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

#68 2013-10-22 21:25:17

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

#69 2013-10-23 00:59:35

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

#70 2013-10-23 11:52:48

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

#71 2013-10-28 16:52:49

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

#72 2013-10-28 18:12:50

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

#73 2013-10-28 20:38:05

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

#74 2013-10-28 21:05:51

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

#75 2013-10-28 23:10:16

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

Board footer