Ik heb meerdere dagboekberichten gewijd aan het feit dat er behoorlijk wat tags (een tag is een key=value paar) zeer zeldzaam zijn.
Maar de meest zeldzame is toch wel deze:
[----------]=[----------]
En je vindt hem hier:
http://overpass-turbo.eu/s/aTT
Wie begrijpt wat de maker bedoelde?
En bij deze lijkt er een probleem met de juiste karakterset:
En hier nog een paar voorbeelden van zeldzaamheid:
Marc is een deel van die dingen (tags) geen foutje van de mapper of een gebrekkige vertaling ???
Die 2 foobars lijken me testen. Buiten het feit dat ze de databank groter maken, zijn ze verder onschuldig, niet ? Je zou hier de mapper kunnen wijzen op het feit dat alle wijzigingen “life” zijn.
De re111… zou dat ook een test zijn ?
Bij de Meuleveldoop=drain, daar gaat natuurlijk door de slechte tagging wel wat informatie verloren.
Is die multipolygon verder goed getagged ? Indien niet, zou de juiste actie hier zijn om de mapper te leren multupolygonen te maken. 't zou ook kunnen dat de originele tagging fout was en iemand die verbeterd heeft, zonder die meervoudige polygoon tag weg te doen.
Volgens mij is de meest waardevolle manier om deze “rariteiten” te behandelen, de mapper in kwestie te contacteren en te vragen wat de bedoeling is, wijzen op mogelijke correcties, enz. Een heel tijdrovende bezigheid, dat wel.
Het gaat me allang niet meer om het feit of ze een belasting vormen voor de database, want dat doen ze absoluut niet. Het commentaar van Simon Poole bij mijn dagboek is wat dat betreft helder.
Maar waar het mij omgaat is dat bij sommige keys een ware wildgroei ontstaat waar niemand wat aan heeft.
Kijk bv. eens naar het gebruik van de fixme=* tag: (het zijn ze nog niet eens allemaal!)
In de 1e kolom zien we bovenaan de 2 meestgebruikte manieren om deze key te gebruiken:
fixme=* (962160 keer gebruikt)
FIXME=* (180833 keer gebruikt)
waarbij het natuurlijk al een raadsel is waarom we ineens een HOOFDLETTER versie erbij hebben gekregen??
Maar bovenstaande chaos is toch wel heel bijzonder vind ik.
De bedoeling van de fixme (zie ook mijn dagboekbericht daarover) is dat hij een waarschuwing/opmerking is voor anderen (of de mapper zelf) om aan de betreffende node/way/rel nog iets te corrigeren.
Wat er gecorrigeerd moet worden geef je dan mee als waarde van die key.
Als ik dus zie dat ergens een amenity niet klopt, dan kan ik toevoegen:
fixme=deze amenity is onjuist getagd als bench. Het is een ATM.
Maar niet:
fixme:amenity=onjuist getagd. Moet ATM zijn.
Weliswaar is die 2e korter, maar het maakt het zoeken naar alle fixme’s weer lastiger.
Als je op zoek gaat naar shop, dan wil je toch ook niet hoeven zoeken naar Shop, sHop, shOp, shoP, SHop enz enz?
Bij bijna alle fixme’s hierboven is de oplossing met een enkelvoudige key goed mogelijk en duidelijker.
Er zijn vast gevallen waarbij een uitbreiding van de key nuttig lijkt (bv. fixme:nsl wordt 3208 keer gebruikt), maar ook daar kan het anders.
Stel je de beginnende mapper (maar ook de gevorderde) eens voor die die chaos onder ogen komt!
(Gelukkig krijgt hij die chaos alleen maar onder ogen als hij hier meeleest, want er is toch niemand zo gek om die hele taginfo database thuis te gaan analyseren? 
:P)
Vandaar dat ik ook schreef: 
Alternatief is een mechanische edit, maar dan moet je weet zo’n hele procedure doorworstelen.
Welke methode je ook kiest, het is altijd tijdrovend en levert niet het resultaat op dat je wilt, omdat het toevoegen van zinloze tags aan de database een fluitje van een cent is en door geen enkele procedure of protocol effectief wordt gecontroleerd.
Dat is inherent aan het gekozen datamodel en de structuur van de OSM wereld.
Ik doe er verder geen moeite voor om dat nog te verbeteren, ik blijf alleen wel steeds al die onzin melden… 