Hi Markus, Ja so verstehe ich das auch. Nur wie du selbst sagst, ist in OSM im Moment kein hierachisch über einem anderen. D.h. wenn wir hierachische Tags (die sich über hierachische Keys definieren könnten) einführen wollen, müssen wir, bis wir die ganze Community überzeugt haben, wohl oder übel diese Hierachie per Hand “aufprägen”. Schön wäre natürlich die TAG-KEY-SUBKEY- … -VALUE-VALUETYP-VALUERANGE-ect Beziehungen formal nieder zu legen um dann TAGGING-Utilities damit zu füttern. 
Und selbstverständlich ist diese Einteilung eine klassische Struktur. Und wir sollten TAG-Strukturen als Ziel unserer Notation ins Auge fassen. Fakt ist: Es gibt keine verbindliche Vereinbarung. Und solange es die nicht gibt, müssen wir erstmal das ganze per Hand selbst machen (also keine Abkürzungen ) und damit den WUNSCH in der Community nach dieser Art Strukurierung zu wecken, bzw. die Idee zu verankern. Wenn irgendwann hoffentlich sich Tag-Strukturen durchsetzen, sowie Regeln für deren Befüllung kann ein Bot aufräumen. Die zulässigen Werte sind im Augenblick die Werte, die “Common Sense” sind. Das führt in den meisten Fällen nur zu Komplikationen bezüglich der Maßeinheiten (z.b. km/h vs. mph). In zuvielen anderen jedoch zu Wertegulasch. Auch hier bleibt uns nichts übrig als uns gültige Werte und Wertebereiche zu überlegen. Das öffentlich zu machen und zwar super beschrieben im Wiki und dann konsequent benutzen, bis diese Formalie ihre Kritische Masse erreicht hat. Z.B. maxspeed = | Schrittgeschwindigkeit™ maxspeed:Unit = mph | km/h | NOMINAL_VALUE Tja. Viel zu tun würd ich sagen. Lass uns erstmal die definierten missing values durchbringen, und uns dann Tag für Tag vornehmen. Wenn du Lust hast Markus, mach dafür ein explizites Forumsthema auf, in dem wir uns austoben und gezielt mit der Entwicklung von - sagen wir mal - Tag-Strukturen befassen - die sollten meiner Meinung nach in jedes große Schema passen. MfG Mark
