Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler?

Communities Deutschland (Germany)
61

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! :slight_smile:

62

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.

63

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.

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.

64

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:slight_smile: 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.
65

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)

66

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

67

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.

68

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)

69
  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!
70

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.

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.

71

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.

72

Danke!

73

Schaut gut aus!

74

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.

75

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)

76

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.

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.

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.

77

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 :wink:

Wenn ein Fehlertyp häufig an unterschiedlichen Tags auftritt und keine false-positives erzeugt könnte man ja auch überlegen etwas aggressiver vorzugehen.

78

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

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)

80

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