Wall·E: Automatische Korrektur allgemeiner Tagging-Tippfehler?

Oli-Wan · 2013-10-28 23:57:06

EvanE wrote:

Ich war erstaunt, wie wenig Änderungen es gab. Ich hatte mit deutlich mehr gerechnet. Das zeigt meiner Ansicht nach, dass die Editorunterstützung fürs Taggen doch recht gut ist.

Ich denke, daß das Problem der Tippfehler in Tagschlüsseln (und diskreten Werten) in Zukunft eher noch kleiner werden wird. Die Anfänger-Editoren arbeiten sowieso mit Presets, und bei JOSM scheint sich deren Nutzung auch immer mehr durchzusetzen. Manchmal habe ich den Eindruck, ich bin das letzte Fossil, das seine Tags noch selbst eintippt. Andererseits: wenn man gewohnt ist, Presets zu nutzen, ist man mit den Tags weniger vertraut, wenn man sie dann doch mal manuell eintragen muß. Vielleicht verschieben sich also auch nur die Fehlerquellen vom reinen Vertippen zur Unkenntnis der Schreibweise.

EvanE wrote:

power_source ist als Schlüssel veraltet, es sollte generator:source verwendet werden.
Ebenso ist lamp_mount nirgends definiert. Im aktuellen Proposal wird statt dessen support=* (wie bei Uhren) vorgeschlagen.

Berechtigte Anmerkungen. Aber zumindest liegt dann einheitlich z.B. power_source statt Power_Source etc. vor - und ist somit auch einer Änderung leichter zugänglich.

seichter wrote:

Eigentlich lohnt es sich nicht, wegen ein/zwei Fehlern einen Regelsatz aufzustellen.

Stimmt. Aber so können sie zumindest auch in Zukunft korrigiert werden, wenn sie erneut auftreten, und man fängt mit der Suche nach falsch geschriebenen Tags nicht jedes Mal von vorne an.

Wie häufig sich bestimmte Fehler wiederholen, wird man sehen - schlichtweg daran, wieviel der unveränderte Regelsatz einige Wochen nach seinem letzten Einsatz erwischt.

Übrigens ist die Aufnahme in den Regelsatz sogar für einen nur ein Mal auftretenden Fehler im Verhältnis zur "klassischen" Methode längst nicht so aufwendig wie man zunächst vermuten könnte. Ich muß nur zwei Schlüssel (falsch und richtig) in eine einzige Liste eintragen. Alle weiteren Schritte sind nur einmal für den gesamten Regelsatz nötig, unabhängig von der Anzahl der Tags: Liste zu C++-Code für das Filterprogramm konvertieren, Filterprogramm kompilieren, Extrakt durchsuchen, Korrekturprozeß ausführen. Die konventionelle Alternative: herunterladen per Overpass API (Abfrage mit dem falschen Tagschlüssel schreiben - umständlich, wenn man den Objekttyp nicht kennt) oder aus dem Extrakt herausfiltern (dauert aber einige Minuten), Änderung in JOSM vornehmen (Tagschlüssel korrigieren oder Tag löschen, obendrein fehleranfällig), hochladen. Und das ganze für jedes singuläre Tag einzeln.

rayquaza · 2013-10-29 00:30:05

Oli-Wan wrote:

Manchmal habe ich den Eindruck, ich bin das letzte Fossil, das seine Tags noch selbst eintippt. Andererseits: wenn man gewohnt ist, Presets zu nutzen, ist man mit den Tags weniger vertraut, wenn man sie dann doch mal manuell eintragen muß. Vielleicht verschieben sich also auch nur die Fehlerquellen vom reinen Vertippen zur Unkenntnis der Schreibweise.

Bist du nicht, u.A. aus den von dir genannten Gründen. Ausser du zählst die Vervollständigung des Eingetippten mit, die neben den geladenen Objekten auch die Vorlagen nutzt

Oli-Wan wrote:

seichter wrote:
Eigentlich lohnt es sich nicht, wegen ein/zwei Fehlern einen Regelsatz aufzustellen.
Stimmt. Aber so können sie zumindest auch in Zukunft korrigiert werden, wenn sie erneut auftreten, und man fängt mit der Suche nach falsch geschriebenen Tags nicht jedes Mal von vorne an.
Wie häufig sich bestimmte Fehler wiederholen, wird man sehen - schlichtweg daran, wieviel der unveränderte Regelsatz einige Wochen nach seinem letzten Einsatz erwischt.

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

Oli-Wan · 2013-10-29 12:03:38

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)

Last edited by Oli-Wan (2013-10-29 12:35:14)

EvanE · 2013-10-29 12:42:54

Oli-Wan wrote:

So, der DE-weite Restputz ist durch. Er ist mit 267 Objekten doch etwas größer ausgefallen als von mir zunächst erwartet. Offenbar hatte der erste Durchgang vor allem in und um Ahaus einige addrPostcode und addrStreet nicht erwischt, ferner waren seit letzter Woche in Solingen einige (43) add:city hinzugekommen.

Da bin ich ja beruhigt, dass doch noch ein paar Korrekturen zusammen gekommen sind. Wieviel waren es denn insgesamt? Über den Daumen gepeilt vermute ich ca. 40-50 je Bundesland / Regierungsbezirk von NRW + das Heute also etwas über tausend.

PS:
Du bist nicht allein, auch ich gehöre zu denen, die die Taggs lieber eintippen. Ausnahme ist das Adress-Preset, da das mittlerweile die Hausnummern schön rauf-/runterzählen kann. Für 3D-Gebäude muss ich mal schauen, ob es da mittlerweile was schönes für gibt.

Edbert (EvanE)

Oli-Wan · 2013-10-29 12:50:13

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

seawolff · 2013-10-30 18:28:12

Oli-Wan wrote:

Und gleich die nächsten Erweiterungskandidaten:
FIXMW (2)
FXIME (2)
aadr:country (1)
abandoned_railway (1)
...

Zunächst vielen Dank für die nützliche Aufräumarbeit.

Bei solchen offensichtlichen Tippfehlern, die sehr selten auftreten (<5), musst du m. E. die Korrektur nicht vorher ankündigen.

hvg (14) --> hgv (24118)

Vermutlich hast du recht. Bei Keys mit drei Buchstaben könnte auch etwas anderes gemeint sein. Nahezu jede Kombination aus drei Buchstaben dürfte irgendwo als Akronym auftreten.
Hier könntest du auf "highway=*" testen.

Oli-Wan · 2013-10-30 19:05:35

seawolff wrote:

hvg (14) --> hgv (24118)
Vermutlich hast du recht. Bei Keys mit drei Buchstaben könnte auch etwas anderes gemeint sein. Nahezu jede Kombination aus drei Buchstaben dürfte irgendwo als Akronym auftreten.
Hier könntest du auf "highway=*" testen.

Die zugehörigen Werte legen nahe, daß in den vorhandenen Fällen tatsächlich hgv gemeint war:

      1     <tag k="hvg:conditional" v="no @ (13:00-15:00, 22:00-07:00)"/>
      2     <tag k="hvg" v="delivery"/>
     12     <tag k="hvg" v="no"/>

Von den 15 Objekten haben 12 bereits ein highway-Tag. Die übrigen sind Parkplätze oder das Tag scheint verirrt.

Oli-Wan · 2013-10-30 21:56:53

Hier fortgesetzt (und sinnwahrend gekürzt), um den Nachbarfaden nicht länger zu kapern:

EvanE wrote:

Oli-Wan wrote:
Mit den verschiedenen Tags mit "_" und ":" machen wir es allerdings den Mappern allgemein ganz schön schwer. Da blickt wahrscheinlich keiner mehr wirklich durch, daher auch die vielen einschlägigen Fehler.
In der Tat ist die Frage "'_' oder ':'" einer der häufigsten Gründe einen Schlüssel im Wiki nachzuschlagen.
Es gibt natürlich ein paar Leitlinien. Besteht ein Begriff eigentlich aus zwei Worten, so werden diese mit Unterstrich statt Leerzeichen geschrieben.
Schwieriger wird es bei Unterschlüsseln mit einem gemeinsamen Wort als Beginn. Früher wurde Hauptschlüssel Unterstrich Unterschlüssel verwendet. Heute bevorzugt man Hauptschlüssel Doppelpunkt Unterschlüssel. Häufig kann man das aber kaum einschätzen. Verlassen kann man sich darauf leider nicht.

Um das zu untermauern, hier einige Korrekturen von Sub-Schlüsseln, wo "_" bzw. ":" "falsch" verwendet wird.

board:type -> board_type
castle:type -> castle_type
generator_method -> generator:method
generator_source -> generator:source
heritage_operator -> heritage:operator
memorial_type -> memorial:type
mtb_scale -> mtb:scale
parking_condition -> parking:condition
roof_colour -> roof:colour
roof_shape -> roof:shape
shelter:type -> shelter_type

Außer daß "jüngere" Schlüssel eher ":" enthalten, gibt es eigentlich kaum einen als Merkregel taugenden Anhaltspunkt, was nun "richtig" ist. Und im Grunde könnten alle statt als Unterschlüssel auch als einfache Schlüssel aus zwei Worten durchgehen, wenn man nicht weiß, daß sie Teil eines größeren Schemas (roof:colour, roof:shape, roof:levels, roof:gedöns, ...) sind und dabei ":" bevorzugt wird.

EvanE · 2013-10-30 22:31:22

Oli-Wan wrote:

EvanE wrote:
In der Tat ist die Frage "'_' oder ':'" einer der häufigsten Gründe einen Schlüssel im Wiki nachzuschlagen. ...
Um das zu untermauern, hier einige Korrekturen von Sub-Schlüsseln, wo "_" bzw. ":" "falsch" verwendet wird.
board:type -> board_type
castle:type -> castle_type
generator_method -> generator:method
generator_source -> generator:source
heritage_operator -> heritage:operator
memorial_type -> memorial:type
mtb_scale -> mtb:scale
parking_condition -> parking:condition
roof_colour -> roof:colour
roof_shape -> roof:shape
shelter:type -> shelter_type 
Außer daß "jüngere" Schlüssel eher ":" enthalten, gibt es eigentlich kaum einen als Merkregel taugenden Anhaltspunkt, was nun "richtig" ist. Und im Grunde könnten alle statt als Unterschlüssel auch als einfache Schlüssel aus zwei Worten durchgehen, wenn man nicht weiß, daß sie Teil eines größeren Schemas (roof:colour, roof:shape, roof:levels, roof:gedöns, ...) sind und dabei ":" bevorzugt wird.

Die Unterschlüssel zu generator, heritage und 3D-Buildings sind in der Tat recht neu (1-2 Jahre). Ebenso einige Unterschlüssel von historic (memorial:*) während andere Unterschlüssel (castle_type) schon recht lange dabei sind.

Richtig gemein ist mtb:scale im Gegensatz zu sac_scale, ähnlicher Sachverhalt und ähnlich alt, jedoch andere Schreibweise.

Edbert (EvanE)

Oli-Wan · 2013-11-01 14:42:47

EvanE wrote:

Richtig gemein ist mtb:scale im Gegensatz zu sac_scale, ähnlicher Sachverhalt und ähnlich alt, jedoch andere Schreibweise.

Ja, das ist böse. Vielleicht muß man den Korrekturprozeß in einem solchen Zusammenhang weniger als Fehlerkorrektur und mehr als "nachträgliche Mapperunterstützung" sehen.

Ich habe heute noch in zwei Änderungssätzen alles aufgeräumt, was der aktuelle Regelsatz findet (ausgenommen eine Handvoll Fälle, wo "richtiger" und "falscher" Schlüssel sich widersprechen, etwa capacity=5 und caapcity=10). Damit müßten es nun gut 1600 bearbeitete Objekte sein. Jetzt lege ich erst einmal eine Pause von einer oder zwei Wochen ein, um zu sehen, was der unveränderte Regelsatz danach ausspuckt, sprich ob die bereits bekannten Fehler sich mit nennenswerter Häufigkeit wiederholen. Die Suche nach weiteren kaputten Tagschlüsseln geht natürlich weiter (und Hinweise werden gerne angenommen).

Oli-Wan · 2013-11-11 15:19:35

Oli-Wan wrote:

Jetzt lege ich erst einmal eine Pause von einer oder zwei Wochen ein, um zu sehen, was der unveränderte Regelsatz danach ausspuckt, sprich ob die bereits bekannten Fehler sich mit nennenswerter Häufigkeit wiederholen. Die Suche nach weiteren kaputten Tagschlüsseln geht natürlich weiter (und Hinweise werden gerne angenommen).

Nach der genannten Pause ist gestern der bestehende Regelsatz noch einmal über DE gelaufen. Die Ausbeute: nur 15 "neue" Objekte mit bekannten falschen Schreibweisen. Optimistische Lesart: Tippfehler geschehen doch nicht so häufig wie befürchtet. Pessimistische Lesart: Tippfehler sind zu vielfältig, um von einem statischen Regelsatz erfaßt zu werden. Die Wahrheit liegt wahrscheinlich irgendwo dazwischen.

In der Zwischenzeit hatte ich noch einige Tags korrigiert, die vom Suchprogramm identifiziert wurden, aber nicht automatisch zu beheben waren (insbesondere Expansion "abgekürzter" Schlüssel). Und auch andere Mapper waren in ähnlicher Mission unterwegs, der eine oder andere wird es bemerkt haben.

Für das weitere Vorgehen bedeutet die obige Zahl: eine regelmäßige automatische Ausführung hat wenig Sinn, weil bekannte Tippfehler sich nur selten wiederholen. Also läuft es wohl darauf hinaus, daß ich in größeren Abständen (Wochen bis Monate - abhängig von Zeit und Lust) das Suchprogramm starte, neue Kandidaten identifiziere, diese hier poste und dann abräume. Möglicherweise kann das Posting langfristig entfallen, denn faktisch ist dieser Korrekturprozeß bei weitem nicht so automatisch wie die anderen (Adressen etc.). Für den nächsten Durchgang sind diese Erweiterungen vorgesehen:

Access (1)
[values: "Private" (1)]
         --> access (520002)
Golf (50)
[values: "bunker" (50)]
         --> golf (9638)
Operator (1)
[values: "Wall AG" (1)]
         --> operator (314730)
acces (2)
[values: "agricultural" (2)]
         --> access (520002)
Wiki:symbol (1)
[values: "Hoehensteig_Klingent..." (1)]
         --> wiki:symbol (4104)
addr:places (12)
[values: "Bienwaldmühle" (10) "Zollhaus" (2)]
         --> addr:place (3786)
amenitiy (1)
[values: "advertising" (1)]
         --> amenity (1194699)
ameniy (1)
[values: "parking" (1)]
         --> amenity (1194699)
barnd (1)
[values: "Volkswagen" (1)]
         --> brand (14632)
bicycle-road (1)
[values: "yes" (1)]
         --> bicycle_road (699)
bicylce (2)
[values: "yes" (2)]
         --> bicycle (693545)
biuilding (1)
[values: "yes" (1)]
         --> building (11944967)
boundary:type (1)
[values: "protected_area" (1)]
         --> boundary_type (264)
building:levens (3)
[values: "2" (3)]
         --> building:levels (124633)
building:min_levels (11)
[values: "1" (1) "13" (1) "2" (1) "22" (1) "3" (1) "4" (4) "5" (1) "8" (1)]
         --> building:min_level (1738)
building:roof:color (8)
[values: "#443c39" (8)]
         --> building:roof:colour (2662)
building;levels (1)
[values: "5" (1)]
         --> building:levels (124633)
building_height (1)
[values: "2" (1)]
         --> building:height (30333)
couisin (2)
[values: "greek" (1) "italian" (1)]
         --> cuisine (54188)
cousine (2)
[values: "ice_cream" (1) "india" (1)]
         --> cuisine (54188)
destination.backward (1)
[values: "Osburger Hof" (1)]
         --> destination:backward (450)
emergeny (1)
[values: "fire_hydrant" (1)]
         --> emergency (81161)
fon (3)
[values: "+49 30 7403-0" (1) "+49 5731 3006992" (1) "02339 - 4800" (1)]
         --> phone (89787)
histoirc (1)
[values: "monument" (1)]
         --> historic (88855)
maxweiht (2)
[values: "7.5" (2)]
         --> maxweight (27741)
motorcycle:condition (1)
[values: "no @ (20:00-06:00)" (1)]
         --> motorcycle:conditional (122)
mtb:sacle (4)
[values: "0" (4)]
         --> mtb:scale (84365)
onway (2)
[values: "no" (1) "yes" (1)]
         --> oneway (478112)
osmc_name (1)
[values: "Bad Bergzabeber Land..." (1)]
         --> osmc:name (587)
postal_codes (7)
[values: "50667-51149" (1) "63768" (1) "66849" (1) "66877" (1) "67685" (1) "67686" (1) "67688" (1)]
         --> postal_code (264238)
sports (1)
[values: "darts" (1)]
         --> sport (116970)
sourche (1)
[values: "survey" (1)]
         --> source (3514137)
source:maxspeeed (11)
[values: "DE:rural" (1) "DE:urban" (10)]
         --> source:maxspeed (105272)
stepps (1)
[values: "60" (1)]
         --> steps (398)
surce (2)
[values: "survey" (2)]
         --> source (3514137)
trachtype (2)
[values: "grade4" (2)]
         --> tracktype (1571042)
tracktpe (1)
[values: "grade4" (1)]
         --> tracktype (1571042)
tracktye (3)
[values: "grade2" (1) "grade4" (2)]
         --> tracktype (1571042)
tracktypr (1)
[values: "grade4" (1)]
         --> tracktype (1571042)
wheelchair:description:DE (4)
[values: "Eingang barrierefrei..." (1) "Eingang vorne mit St..." (1) "Toiletten im UG, nur..." (1) "keine Rolli-WC´s" (1)]
         --> wheelchair:description:de (972)
wheelchair:toilet (1)
[values: "yes" (1)]
         --> wheelchair:toilets (324)
wheelchair_access (2)
[values: "eurokey" (2)]
         --> wheelchair:access (214)
wheelchir (1)
[values: "no" (1)]
         --> wheelchair (308160)
vrr:wae (1)
[values: "430" (1)]
         --> vrr:wabe (1392)

(Die Werte in Klammern sind nur die aktuell vorkommenden - die Ersetzung wird nicht darauf beschränkt.)
Daneben gibt es noch unzählige, die überaus fraglich sind, aber manuell überprüft werden müssen. Einige davon sehe ich mir bei Gelegenheit an.

EvanE · 2013-11-11 16:05:12

Oli-Wan wrote:

Oli-Wan wrote:
Jetzt lege ich erst einmal eine Pause von einer oder zwei Wochen ein, um zu sehen, was der unveränderte Regelsatz danach ausspuckt, sprich ob die bereits bekannten Fehler sich mit nennenswerter Häufigkeit wiederholen. ...
Nach der genannten Pause ist gestern der bestehende Regelsatz noch einmal über DE gelaufen. Die Ausbeute: nur 15 "neue" Objekte mit bekannten falschen Schreibweisen. ...
Für das weitere Vorgehen bedeutet die obige Zahl: eine regelmäßige automatische Ausführung hat wenig Sinn, weil bekannte Tippfehler sich nur selten wiederholen. Also läuft es wohl darauf hinaus, daß ich in größeren Abständen (Wochen bis Monate - abhängig von Zeit und Lust) das Suchprogramm starte, ... Für den nächsten Durchgang sind diese Erweiterungen vorgesehen:
...
...

In deiner Liste zeigt sich mal wieder, dass Tippfehler oft im Bündel passieren, also sowohl im Schlüssel als auch beim Wert. Alles was ich gesehen habe macht Sinn, also von meiner Seite aus in deinen Regelsatz aufnehmen.

Ansonsten möchte ich vorerst einmal im Monat als Frequenz für den Bot-Lauf vorschlagen. Wenn sich dann immer noch zeigt, dass es sich kaum lohnt, kannst du immer noch auf alle zwei - drei Monate runter gehen.

Bei der Korrektur von Werten wird es dann wieder spannend. Da liegt ja noch einiges im Argen (z.B. Komma statt Punkt als Dezimaltrenner). Aber das ist wohl eher ein Thema / Projekt für das nächste Jahr.

Edbert (EvanE)

Oli-Wan · 2013-12-27 20:50:34

Nächste vorgesehene Erweiterungen:

FIIXME (2)
[values: "Position" (2)]
         --> FIXME (48920)
From (1)
[values: "A5 Langen/MÃ¶rfelden" (1)]
         --> from (13403)
Phone (3)
[values: "+49 561 8047210" (1) "+49 561 983593" (1) "02204-20140" (1)]
         --> phone (93695)
Tracktype (4)
[values: "grade3" (1) "grade4" (3)]
         --> tracktype (1587874)
URL (1)
[values: "www.lomm-hamburg.de" (1)]
         --> url (7333)
addr_postcode (1)
[values: "40233" (1)]
         --> addr:postcode (4416210)
alt:name (1)
[values: "ICA-Haus" (1)]
         --> alt_name (18085)
amenty (1)
[values: "Bank" (1)]
         --> amenity (1198276)
atl_name (1)
[values: "Altes Audimax" (1)]
         --> alt_name (18085)
biilding (1)
[values: "yes" (1)]
         --> building (12634826)
bivycle_parking (1)
[values: "shed" (1)]
         --> bicycle_parking (10451)
brdige (1)
[values: "yes" (1)]
         --> bridge (239309)
building_colour (1)
[values: "yellow" (1)]
         --> building:colour (36342)
collection_time (1)
[values: "Mo-Sa 08:00" (1)]
         --> collection_times (16824)
discription (1)
[values: "Badeinsel" (1)]
         --> description (202135)
discription:en (1)
[values: "Swim platform" (1)]
         --> description:en (248)
escalator:dir (2)
[values: "up" (1) "up;down;down" (1)]
         --> escalator_dir (322)
escelator_dir (3)
[values: "down" (2) "up" (1)]
         --> escalator_dir (322)
genud:de (1)
[values: "Eiche" (1)]
         --> genus:de (6805)
handrail_left (1)
[values: "yes" (1)]
         --> handrail:left (1244)
inscript (1)
[values: "Ehret die Toten, mah..." (1)]
         --> inscription (2612)
lanse:forward (1)
[values: "1" (1)]
         --> lanes:forward (13065)
maxhight (1)
[values: "3.4 m" (1)]
         --> maxheight (14397)
metwork (1)
[values: "VVO" (1)]
         --> network (83488)
motorcycle:condition (1)
[values: "no @ (20:00-06:00)" (1)]
         --> motorcycle:conditional (181)
name:DE (2)
[values: "Deutsch-FranzÃ¶sisch..." (1) "FC/DJK Burgoberbach" (1)]
         --> name:de (6638)
networtk (1)
[values: "VRB" (1)]
         --> network (83488)
nmae:hsb (2)
[values: "PÅ wokolicy" (1) "Zelezniska droga" (1)]
         --> name:hsb (10650)
node:de (2)
[values: "Linien: 595" (1) "SperrgepÃ¤ck" (1)]
         --> note:de (21983)
oenway (1)
[values: "no" (1)]
         --> oneway (488748)
opening-hours (1)
[values: "Tu-Su 11:00-23:00" (1)]
         --> opening_hours (74131)
priority_roard (3)
[values: "designated" (3)]
         --> priority_road (456)
roof.shape (9)
[values: "flat" (1) "gabled" (7) "hipped" (1)]
         --> roof:shape (132391)
roof:oriantation (1)
[values: "across" (1)]
         --> roof:orientation (26494)
roof:shap (7)
[values: "flat" (7)]
         --> roof:shape (132391)
shelter_typ (1)
[values: "public_transport" (1)]
         --> shelter_type (6503)
step:count (1)
[values: "10" (1)]
         --> step_count (12322)
surface_middle (2)
[values: "grass" (2)]
         --> surface:middle (962)
teacktype (2)
[values: "grade2" (2)]
         --> tracktype (1587874)
turn:Lanes:backward (2)
[values: "none|through;right" (1) "none|through|right" (1)]
         --> turn:lanes:backward (5577)
turn:Lanes:forward (1)
[values: "none|left|through" (1)]
         --> turn:lanes:forward (7343)
turn:lanes.backward (2)
[values: "none|merge_to_left" (1) "none|slight_right" (1)]
         --> turn:lanes:backward (5577)
turn:lanesMforward (1)
[values: "through|through|slig..." (1)]
         --> turn:lanes:forward (7343)
turn_lanes:backward (1)
[values: "left|through|through" (1)]
         --> turn:lanes:backward (5577)

gerd_ · 2015-09-13 19:03:33

Vorschlag zur automatischen Korrektur (aus KeepRight entnommen):
- This way is tagged 'hazard=animals_crossing' where "animals_crossing" looks like "animal_crossing"

reneman · 2015-10-04 22:40:50

Hallo, kann Wall-E auf seiner Liste die folgenden korrekturen aufnehmen?

wikimedia:commons -> wikimedia_commons
wikipedia_commons -> wikimedia_commons
Wikimedia_Commons -> wikimedia_commons
media:commons -> wikimedia_commons

Announcement

#76 2013-10-28 23:57:06

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

#77 2013-10-29 00:30:05

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

#78 2013-10-29 12:03:38

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

#79 2013-10-29 12:42:54

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

#80 2013-10-29 12:50:13

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

#81 2013-10-30 18:28:12

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

#82 2013-10-30 19:05:35

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

#83 2013-10-30 21:56:53

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

#84 2013-10-30 22:31:22

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

#85 2013-11-01 14:42:47

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

#86 2013-11-11 15:19:35

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

#87 2013-11-11 16:05:12

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

#88 2013-12-27 20:50:34

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

#89 2015-09-13 19:03:33

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

#90 2015-10-04 22:40:50

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

Board footer