Zu den Semantiken: ============= Es gibt mindestens 3 Aspekte von Schlüsseln, oder besser gesagt deren Werte, die einer Erweiterung bedürfen. a) Schlüsselwerte sollten in Abhängigkeit von Rahmenbedingungen gesetzt werden können (Parametrisierte Schlüsselwerte - Beispiel: Höchstgeschwindigkeit in Abhängigkeit von Fahrzeugtypen) b) Schlüsselwerte könnten strukturiert sein. Sie sollten daher aus unterschiedlichen Werten zusammensetzbar sein. (Strukturierte Schlüsselwerte - Beispiel: Adressen) c) Schlüsselwerte müssen manchmal näher beschrieben werden Eindeutigkeit herzustellen. (Attributisierte Schlüsselwerte - Beispiel: Maßeinheiten) Diese Semantiken sollte in einem (zu entwickelnden) Tagging-Schema abbildbar sein. Mein Vorschlag ist, alle 3 über dieselbe Syntax abzubilden (wenn möglich), UND dass sie zu dem momentanen Tagging-Schema kompatibel ist. Dein Vorschlag: : {>,<,<=,>=,==} <Subkey1_value> = erfordert eine Definition von Relationen (z.B. “<”), sowie eine Definition frei wählbare Werte für <Subkey1_value>, die wiederum mit Wertebereichen, Maßeinheiten ect versehen werden müssen. - Außerdem schlägst du vor, dass man für ein OSM-Objekt global Maßeinheiten oder Beschreibungen setzen kann, die sich dann auf Untergeordnete Eigenschaften auswirken. Dagegen sprechen meiner Ansicht nach ein paar Dinge: 1.) Wollen wir nicht für jedes OSM-Objekt die komplette Semantik, Definitionsbereiche, Maßeinheiten, ect. der in diesem Objekt benutzten Tags beim einzelnen Objekt hinterlegen, müssen wir (für die Renderer zb.) Regeln, Werte- und Defintionsbereiche als Metainformationen vorhalten. In diesem Fall können wir das ebensogut für eine (gegebenenfalls große Menge von) symbolischen untergeordneten Schlüssel einrichten. 2.) Ein solches Tagging-Schema ist nicht mit dem jetzigen kompatibel. Da wir die Bedeutungen und Regeln für jedes {OSM-Objektklasse;Eigenschaft}-Paar ohnehin extern für die Sofware vorhalten sollten (nur um den Programmierern die Arbeit zu ersparen, selbst das Schema bereit zu stellen) - wie es jetzt schon quasi das Wiki übernimmt 
- könnten wir auch, wenn die Symbolischen Schlüssel Anzahlmäßig überhand nehmen einen räumlichen Namensraum für die Schlüssel definieren (so dass “below_3.5t” in einer Tagging-Unterstützenden Software nur für Straßen in Deutschland existiert). Aber ich gebe dir Recht, für die Semantik der Parametrisierung wäre deine Syntax angemessener… ich möchte jedoch versuchen, ein Schema zu finden, dass eine möglichst saubere Trennung zwischen Schlüssel und Wert gewährleistet. Die Trennlinie ist das “=”. Gerade wegen der Kompatibilität… Wie können die Software die Semantiken unterscheiden: zuersteinmal schließen für denselben Hierachie-Zweig auf derselben Hierachiebene Semantik a) und Semantik b) gegenseitig aus. (per Def.) Semantik a) stellt parallel Alternativen des Wertes (in Abhängigkeit von bestimmten Bereichen) zur Verfügung, Semantik b) stellt EINEN Wert bereit, der sich aus anderen zusammen setzt. Ob die Hierachie-Ebene auf dem Hierachie-Zweig gerade Semantik a) oder b) folgt kann durch den “Wert” festgelegt werden, auf den sich diese bezieht. Der Wert wird als __DEPENDING und __STRUCTURE gekennzeichnet. Um die Attributisierung des Wertes von Semantik a) und b) zu trennen, muss man sich was ausdenken. Z.B. könnte man statt = {__DEPENDING | __STRUCTURE} und : = value (Semantik a) oder b)) für Semantik c) schreiben: ::<Atributisierender Schlüssel> oder irgendwas anderes. Was den Aufwand angeht - so muss man sie sich nicht ausdenken: sie sind bereits durch die Realität gegeben. MfG Mark