Naja - es ist noch nichts spruchreich 
Aber bei diesem Schema könnte man einen SUBKEY von maxspeed entsprechend Semantik a) einführen: maxspeed = __DEPENDING maxspeed:above_3.5t = <Geschwindigkeit in km/h> maxspeed:below_3.5t = <Geschwindigkeit in km/h> maxspeed:unit = km/h Im Moment wäre dass allerdings eher schlecht. In deinem Fall würde ich ein paar Stunden Wiki und Forum durchsuchen. Dann würde ich darüber im Forum und Wiki jammern. Und paralell sowas wie: maxspeed = <Geschwindigket1 in km/h> maxspeed:above_3.5t = <Geschwindigkeit2 in km/h> maxspeed:below_3.5t = <Geschwindigkeit1 in km/h> auf eigene Faust taggen und eine FIX-ME-Eigenschaft (Tag) setzen in dem ich nochmal jammern würde MfG Mark
Meiner meinung nach ist das maxspeed = __DEPENDED unnötig, wenn sich das hirarchische tagging durchsetzt. Wegen dem “above_3.5t” … da is ja nicht klar was die 3.5t ausdrücken … gehen wir mal davon aus es gäbe eine Begrenzung für Autos über 2m breite, und eine andere Begrenzung für Autos mit über 4m höhe. Ein “below_4m” wüde da nicht klar machen, ob höhe oder breite gemeint ist. Ich würde daher folgendes vorschlagen: maxspeed:weight<3.5 = <Geschwindigkeit in km/h> maxspeed:weight>3.5 = <Geschwindigkeit in km/h> maxspeed:unit = km/h weight:unit = t
dabei fällt mir grad auf, dass wir uns unbedingt einigen müssen, ob wir den wert vom ersten Key angeben, oder vom letzten Key … Bei addr:housenumber wird die Hausnummer angegeben. Bei name:de wird allerdings der name angegeben. Genauso wird bei maxspeed: der maxspeed angegeben, bei maxspeed:unit allerdings die unit.
@TEL0000 maxspeed:unit ist eine Atributisierung nach Semantik c) - hier muss der Wert angegeben werden, der zur Zusatzinformation gehört maxspeed: ist eine Parametrisierung nach Semantik a) - maxspeed wird durch Fahrzeugtyp parametrisiert, ab
Wozu denn überhaupt die verschiedenen Semantiken? Lässt sich nicht alles über eine semantik abbilden? Woher soll eine Software denn wissen, welche Semantik verwendet wurde?
Ich würde das ganze frei wählbar anlegen. Mir geht es hier nur um die Tag-Struktur, und nicht um die genaue Bezeichnung von schlüsseln. Und da fällt mir nix besseres ein, als einen > oder < operator zu benutzen, damit eine Software das auch versteht.
maxspeed:weight:unit = t würde ja nur auf das maxspeed-tag auswirkungen haben, während sich weight:unit auf alles tags, die weight enthalten, auswirkt.
Das wäre ein enormer Aufwand sich für alle Länder der Welt entsprechende Bezeichnungen für solche schlüssel auszudenken. Zumal bei “above_3.5t” nicht klar wird, dass es sich hier um eine rein deutsche Regelung handelt. Wobei : > <Subkey1_Value> universal einsetzbar wär.
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
Ich muss dir Recht geben, dass dein Tagging-Schema das einzige wär, was mit dem momentanen Schema 100% kompatibel wär. Was die Semantiken angeht verstehe ich allerdings immernoch nicht, wie man dem Renderer beibringen soll welchen Key er rendern soll, und welcher nur zur Unterordnung oder Beschreibung dient. Was wäre denn dies für eine Semantik?: waterway = river waterway:name:de = Oder waterway:name:pl = Odra boundary = administrative boundary:name:de = Deutschland - Polen boundary:name:pl = Niemcy - Polska Ich wüsste jetzt zwar nicht, warum man eine Grenze benennen soll, aber es soll ja auch nur ein Beispiel sein. zu meinem Vorschlag : {>,<,<=,>=,==} <Subkey1_value> = : Du meinst also die Values sollten immer hinter dem = stehen. Klingt logisch, und daher ein neuer Vorschlag: maxspeed[1]:weight = <3.5 maxspeed[1] = 130 maxspeed[2]:weight = >3.5 maxspeed[2] = 80 Ist wieder nur eine spontane Idee, aber vielleicht bringt es uns ja weiter…
Also zu deinem Beispiel: =============== waterway = river eine einfache Eigenschaft mit dem Wert “river” - gültig für Flächen und Wege(?) (waterway:name = __DEPENDING) - Attributierung des Wertes “river”, d.h. Zusatzinformation mit den Namen des Flusses. (Semantik c)) - der Wert von waterway:name ist abhängig von bestimmten Nebenbedindungen - der Sprache (Semantik a)) waterway:name:de = Oder waterway:name:pl = Odra - de und pl sind untergeordnete Schlüssel von “name” nach Semantik a), die den Namen in Abhängigkeit von der Sprache parametrisieren. Der Renderer muss ohnehin die meisten Schlüssel kennen, um sie zu rendern - er muss wissen, das “name” ein Name ist, der schön auszusehen hat, und “river” eine blaue Linie/Fläche ist. - Kennt er “name” weiß er, dass wenn “name” __DEPENDING gesetzt ist, er den Namen passend zu Zusatzinformationen aus den untergeordneten Schlüsseln . Würde dort __STRUCTURE stehen, würde er den Namen (hoffentlich nach einer Regel, ansonsten irgendwie) zusammensetzen. __STRUCTURE und __DEPENDING können als gegenseitig ausschließend betrachtet werden. Das einzige Problem ist halt noch wenn ne Attributierung zusätzlich vorhanden ist. Also Zum Beispiel eine Adresse adress = _STRUCT adress:Street = <Straßenname | oder coole noch nicht durchdachte Referenz auf den Namen der Straße> adress:number = adress:postal_code = <PLZ | oder coole noch nicht durchdachte Referenz auf PLZ des Ortes in dem die STraße liegt> //und dann: adress:advertise = yes “Darf Werbung zustellt werden” adress:advertise ist eine Attributierung von adress - kein Teil ihrer Struktur. Man könnte das durch eine andere Symbolik für den Renderer oder die Software klar machen: adress::advertise = yes Man beachte die “::”. Aber das ist noch so ein Gedanke, der noch nicht reif ist. Dies dient ohnehin dazu es Renderern einfacher zu machen, wenn sie nicht die von uns bereitgestellten Regeln zu jeder Eigenschaft voll eingearbeitet haben hüstel Wegen deines Vorschlages zum taggen von maxspeed: wieder ergeben sich diverse Schwierigkeiten. 1) maxspeed[1] und maxspeed[2] sind 2 Schlüssel, die die gleiche Art Information tragen. Sie sind zwar dem Namen nach anders, was formal die Eindeutigkeit wieder herstellt… naja irgendwas schmeckt mir da gehörig nicht - aber heute abend finde ich die "guten Gründe"™ nicht - werde das Gefühl nicht los, dass wir mit dieser Struktur sowohl Tagger als auch Software-Entwickler foltern, aber heute abend krieg ichs nicht auseinander dividiert. 2) Das Problem mit einer sauberen Definition von Relationen, denen eine saubere Defintion von Wertebereichen ect vorrangeht, kriegst du mit dieser Konstruktion auch nicht behoben. Du musst immernoch das “>”-Zeichen sauber “erklären” Eventuell könnte das mit den Subschlüsseln: weight:exact weight:above weight:below gemacht werden, aber das ist wieder sehr holperig… Naja. Ich denk da nochmal nach. MfG Mark
Ich hab hier schonmal sowas ähnliches geschrieben: http://wiki.openstreetmap.org/index.php/Proposed_features/Properties_for_Tags Vielleicht könnt ihr es euch ja mal ansehen und in eure Überlegungen einbeziehen. Gruß
Also ich finde die Ideen richtig gut! Dazu mal ein praktisches Anwendungsbeispiel: Leuchtfeuer An der Küste steht ein Leuchtturm. Oben auf dem Leuchtturm sitzt ein Leuchtfeuer. Es weist die Schiffe auf den direkt unterhalb liegende Hafen “Timbuktu” hin. Das Licht ist weiss. Damit die Bewohner an der Küste nicht gestört werden, leuchtet das Feuer nur zum Meer hin. Zum Hafen hin führt eine ausgebaggerte Fahrwasserrinne. Damit die Schiffe diese erkennen, hat das Leuchtfeuer einen grünen Sektor, genau über der Fahrwasserrinne. Vor der Küste gibt es noch eine Untiefe. Damit die Schiffe dieser ausweichen können, hat das Leuchtfeuer hier einen roten Sektor. Das weisse Licht leuchtet, da ungefiltert, weiter als das grüne, und das grüne weiter als das rote. Die **Sektoren **sind also wie folgt sichtbar: Gesamt-Sichtbarkeit: 270° - 100° Weiss: 270° - 320°, Tragweite 20 Seemeilen Rot: 320° - 340°, Tragweite 6 Seemeilen Weiss: 340° - 020°, Tragweite 20 Seemeilen Grün: 020° - 030°, Tragweite 8 Seemeilen Weiss: 030° - 100°, Tragweite 20 Seemeilen Wie würde das dargestellt? {{Tag|man_made|lighthouse}} {{Tag|seamark|light}} {{Tag|seamark:light:name|Hafen Timbuktu}} {{Tag|seamark:light:InternationalCodeNumber|12345.6}} … Es gibt Leuchtfeuer, die rundum strahlen, solche mit einem einzigen weissen Sektor, solche mit bis 10 Sektoren in unterschiedlichen Farben und Tragweiten. Gruss, Markus
Genauso gehts mir mit deimen _DEPENDING und _STRUCTURE … das gefällt mir irgendwie garnicht, ich kanns aber auch nicht erklähren…
Genau den selben Gedanken hatte ich heute morgen auch, und da ist mir dann auch gleich eingefallen, wie man so eine Zeitbeschränkung umsetzen könnte. Also erstmal noch ein vorschlag für die Geschwindigkeitsbeschränkung: maxspeed[1]:weight:below = 3.5 maxspeed[1] = 120 maxspeed[2]:weight:above = 3.5 maxspeed[2] = 80 Die Schlüssel aufzuteilen in mehrere Teile hab ich mir schon an mehreren Stellen gewünscht. Hier mal ein Beispiel für das taggen einer zeitlich eingeschränkten Geschwindigkeitsbegrenzung: maxspeed = 30 maxspeed:times:days:from = Mo maxspeed:times:days:to = Fr maxspeed:times:hours:from = 9 maxspeed:times:hours:to = 17 sollte es zusätzlich noch eine andere Geschwindigkeitsbegrenzung für einen anderen Tag geben könnte man das so machen: maxspeed:times[2]:day = Sa maxspeed:times[2]:hours:from = 8 maxspeed:times[2]:hours:to = 12 Die Schlüssel hab ich mir jetzt nur spontan ausgedacht. Aber auch hier sehe ich keine andere Lösung als den Schlüssel mit times[2] aufzuteilen.
Hab grad hier noch eine neue idee gehabt: http://forum.openstreetmap.org/viewtopic.php?id=1297 also quasi maxspeed:2:weight:above = 3.5 maxspeed:2 = 80 oder maxspeed:times:2:hours:from = 9 Das würde in die hirarchische Struktur passen, und die Zahl wär quasi ein variabler Schlüssel, der nur der Aufteilung dient…
Sorry für die vielen Posts, aber ich will hier nochmal auf Markus eingehen…
Meine Idee wär: man_made = lighthouse seamark = light seamark:light:name = Hafen Timbuktu seamark:light:InternationalCodeNumber = 12345.6 seamark:light:radius:from = 270 seamark:light:radius:to = 100 seamark:light:color:1 = white seamark:light:color:1:range = 20 seamark:light:color:1:radius:1:from = 270 seamark:light:color:1:radius:1:to = 320 seamark:light:color:1:radius:2:from = 340 seamark:light:color:1:radius:2:to = 020 seamark:light:color:1:radius:3:from = 030 seamark:light:color:1:radius:3:to = 100 seamark:light:color:2 = red seamark:light:color:2:range = 6 seamark:light:color:2:radius:from = 320 seamark:light:color:2:radius:to = 340 seamark:light:color:3 = green seamark:light:color:3:range = 8 seamark:light:color:3:radius:from = 020 seamark:light:color:3:radius:to = 030 Zugegebenermaßen ein sehr kompliziertes Beispiel, aber dennoch mit dem Schema umsetzbar… (auch hier die tags nur spontan erfunden) Edit: hatte die Tragweite (von mir als “range” bezeichnet) vergessen…
Das klingt gut. Von der inneren Logik sind die Feuer nach Sektoren geordnet: seamark:light:name = Hafen Timbuktu seamark:light:sector:1:angle:from = 270 seamark:light:sector:1:angle:to = 320 seamark:light:sector:1:color = white seamark:light:sector:1:range = 20 seamark:light:sector:2:angle:from = 320 seamark:light:sector:2:angle:to = 340 seamark:light:sector:2:color = green seamark:light:sector:2:range = 8 … Es gibt Regeln: Leuchtfeuer:Sektoren = 1:n sector = {angle:from, angle:to, color, range} color = {white|green|red|yellow} Wie könnte man das Ganze als **Schema **definieren? Gruss, Markus
@Markus: Das ganze in Sectoren einzuteilen funktioniert natürlich auch. Du hast bei dir aber einen Fehler drin. Es müsste natürlich “seamark:light:sector:2:color = green” heißen. (ohne “from”) 
Deine Frage verstehe ich nicht ganz. Ein Schema has
schon, aber das muss sowohl für Osmarender und Mapnik (für die Ausgabe), als auch für JOSM (Validator bei der Eingabe) noch als “Regel” formuliert werden, damit sie es “verstehen”. Dafür gibts z.B. bei JOSM eine xml-Datei, in der s formuliert sind: http://josm.openstreetmap.de/svn/trunk/styles/standard/elemstyles.xml Ich habe aber keine Ahnung, wie man in xlm hierarchische Mehrfach-Attribute beschreibt. Gruss, Markus
Du meinst sicher diese Datei: http://josm.openstreetmap.de/svn/trunk/styles/standard/elemstyles.xml Leider kenne ich mich mit josm und osmarender nicht aus. So wie ich das sehe akzeptieren beide als Key momentan nur eine Zeichenkette, und keine Variablen oder Hirarchien. Ich denke da müssten die Programmierer etwas zu sagen…
@ TEL0000 Das mit dem __DEPENDING und __STRUCTURE ist eine systematische Erweiterung meines Vorschlags zu “Missing Values”. Die unterschiedlichen Semantiken müssen irgendwie behandelt werden, und den quasi fehlenden Wert als Anzeichen zu verwenden, wie
Ich befürchte, dass es für viele hart zu verstehen ist wann mann nun __DEPENDING und wann __STRUCTURE schreiben muss, und welchem hirarchischen Key er diesen Wert zuweisen muss. Bei einer komplizierten Konstruktion wie der Leuchtturmstruktur wär es selbst für mich schwer das umzusetzen. Meiner Meinung nach müsste die Software das automatisch erkennen.
Variante a) seamark:light:sector:1:angle:from = 270 seamark:light:sector:1:angle:to = 320 Variante b) seamark:light:sector:1:angle = 270 bis 320 Variante c) seamark:light:visibility:from = 270 seamark:light:visibility:to = 360 seamark:light:sector:1:start = 270 seamark:light:sector:2:start = 320 ich brauche die Werte einzeln, um daraus auf der Karte einen Kreisbogen mit unterschiedlichen farbigen Sektoren konstruieren zu können. Bei Variante b müsste der Renderer aus dem Attribut zwei Werte herausrechnen. Variante c verzichtet auf Redundanz, aber der Renderer muss nun jedesmal prüfen, ob noch ein weiterer Sektor kommt um den Winkel zu bestimmen. Ich fürchte, da gibt es Fehler, wenn beispielsweise nach dem Start des letzten Sektors kein Ende angegeben ist, oder sich dieses nicht aus “visibility” errechnen lässt. Die Dateneingabe muss also regelbasiert erfolgen und geprüft werden. Gruss, Markus