Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler?

Oli-Wan · 2013-10-16T18:51:07.000Z

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

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

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

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

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

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

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

EvanE · 2013-10-16T19:39:23.000Z

Oli-Wan:

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

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

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

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

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

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

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

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

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

Edbert (EvanE)

FvGordon · 2013-10-20T15:48:48.000Z

Hallo,

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

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

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

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

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

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

Franz

EvanE · 2013-10-20T21:19:51.000Z

FvGordon:

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)

Oli-Wan · 2013-10-20T21:34:59.000Z

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:

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:

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-21T12:31:22.000Z

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/changeset/18467617/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.)

EvanE · 2013-10-21T14:49:58.000Z

Oli-Wan:

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-21T14:52:34.000Z

EvanE:

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.

EvanE · 2013-10-21T15:39:43.000Z

Oli-Wan:

EvanE:

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-21T19:09:29.000Z

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-21T19:53:32.000Z

seichter:

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-21T20:38:04.000Z

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-21T21:31:04.000Z

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-21T21:47:56.000Z

Oli-Wan:

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:

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-21T22:29:08.000Z

Oli-Wan:

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-22T07:37:33.000Z

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-22T08:04:11.000Z

MasiMaster:

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:

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-22T13:09:47.000Z

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-22T14:48:15.000Z

Oli-Wan:

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-22T17:57:21.000Z

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