Das Problem ist das alle Taggingschema die Namen in den Schlüssel verschieben mehr oder weniger kaputt sind (eher mehr).
Namen und namensähnliche Tagwerte (z.b. brand) können praktisch beliebigen Inhalt haben, was natürlich auch sinnvoll ist. Namen müssen insofern auch nicht dokumentiert sein.
Alle anderen Tagschlüssel und Tagwerte sind stilisiert, in OSM ist es üblich das sie “sprechend” sind, sprich entfernt mit UK-Englischen Kategorien und Bezeichnungen zu tun habt (z.B. highway=residental), dass müsste aber überhaupt nicht sein, im Prinzip könnt man genau so gut UUIDs nehmen. Man müsste dann halt mehr dokumentieren.
https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_tags legt die Konventionen für neue Tagschlüssel und Tagwerte fest.
Zurück zum konkreten Fall, eigentlich wäre es ganz einfach:
award=Bett + Bike
und das ganze wäre problemlos gegessen.
Leider gibt es eine Tendenz Tagwerte in den Tagschlüssel zu verschieben, dies ist dann speziell schlecht wenn es sich bei den Werten um die schon angesprochenen Namen und namensähnlichen Werte handelt. Denn wie wir schon gesagt haben sind die Schlüsselwerte per Konvention immer stilisiert, das heisst auch wenn technisch award:Bett + Bike=yes gehen würde, muss man sich jetzt was dazu aus den Fingern ziehen.
Also halt award:bett_und_bike=yes (es ist egal wie stilisiert es ist, der Punkt ist das es nicht mehr der ursprüngliche Namenswert ist).
Dies wiederum hat aber zur Folge dass man das nur auswerten kann wenn dokumentiert ist, dass bett_und_bike tatsächlich Bett + Bike entspricht. Z.B. würde ich gerne eine Rosette auf der Karte anzeigen in dem der Namen des “awards” steht, dass geht mit award=Bett + Bike ganz einfach ohne Zusatzinformationen, mit dem stilisierten Key muss ich den Namen in irgendeiner nachschlagbaren Form vorhalten.
Das übelste Beispiel des Problems ist das payment: Schema.
Die “Werte in den Schlüssel” schieben Taggingschemas haben noch andere Probleme, aber das ist sicher das grösste.