Entwurf von hierachischen Tag-Strukturen

@Markus: Du hast den besseren Foren- und Wiki-Ãœberblick - kannst du bitte eine Linkliste posten, wo relevante Seiten zu diesem Thema sind, und kurz zu jedem Link schreiben was sie relevant macht? - ich werde derweil meinen ersten Vorschlag zu einer Struk

Zuerst einmal die Nomenklatur: Ein OSM-Objekt ist ein Element der Menge {Ort, Weg, Fläche}, oder der Menge der OSM-Relationen}. Jedem OSM-Objekt können Eigenschaften zugewiesen werden. Eine Eigenschaft besteht aus einem Schlüssel, der den Namen der Eigenschaft darstellt, und einem Wert, der die Ausprägung der Eigenschaft darstellt. Die Schreibweise für eine Eigenschaft ist: <KEY> = <VALUE> <Schlüssel> = <Wert> Soviel zu OSM wie es jetzt ist :-) Ohne Verletzung der oberen Basis-Struktur sollen folgende Syntaxelement semantisch realisiert werden - später irgendwann soll die Basisstruktur die semantischen Strukturelemente auch syntaktisch unterstützen. A) Hierachischer Schlüssel: <KEY> = <VALUE> <KEY>:<SUBKEY_1>:<SUBKEY_2>:...:<SUBKEY_N> = <SOME_SUB_VALUE> (N sollte natürlich klein sein!) Semantik: der Hauptwert <VALUE> der Eigenschaft mit dem Schlüssel <KEY> wird durch <SOME_SUB_VALUE> entweder: a) parametrisiert (bei Werten, die von Nebenbedingungen abhängig sind - z.B. maxspeed in Abhängigkeit von Fahrzeugen) b) aufgebaut (bei stukturierten Werten - z.b. Adresse) c) attributiert (bei Werten, bei denen der Wert alleine keine eindeutige Aussage hat - z.B. Aufnahme von Maßeinheiten) Im Fall a) dienen die Subkey-Kontruktionen als zusätzliche Parameter von denen ein Schlüsselwert abhängig ist Bei b) bilden die Subkey-Konstruktionen die Struktur des Wertes ab. Bei c) dienen die Subkey-Konstruktionen als Namen für Eigenschaften des Wertes. Abstecher zur Missing-Values-Diskussion ----------------------------------------------- Falls sich mein Konzept für "Missing Values" http://forum.openstreetmap.org/viewtopic.php?id=1233 durchsetzt, sollte in Fall a) eine Kennung wie z.b. "__DEPENDING" (anstatt zum Beispiel "__VARIABLE" für nicht näher spezifizierbare Schwankungen/Änderungen des Wertes) für den Hauptwert benutzt werden. Dann sollte für den Fall b) ein andere Kennung "__STRUCTURE" kennzeichnen, dass sich der Wert aus anderen Werten der untergeordneten Schlüssel zusammen setzt. Denn in beiden Fällen würde der Hauptwert "FEHLEN". ------------------------------------------------ Die Methode ist mit dem aktuellen Tagging-Konzept vereinbar, weil die Hierachie nur semantisch aufgeprägt wird. Es könnte sich jedoch als lästig erweisen, sie per Hand sauber einzuhalten. Daher sollten Regeln der Hierachisierung von Tags zumindest entwickelt und bereitgestellt werden, falls Tagging-unterstützende Software diese Schemata übernehmen möchte. Dies wäre der 1. Entwurf für ein hierachisches Eigenschaften-Schema für OSM-Objekte MfG Mark

Hirarchische Schlüssel in der Form <KEY>:<SUBKEY_1>:<SUBKEY_2>:...:<SUBKEY_N> = <SOME_SUB_VALUE> finde ich sehr sinnvoll. Zumal es ja auch schon an vielen Stellen in OSM so genutzt wird. Zum Beispiel addr:housenumber oder name:de Allerdings stellt sich mir da immernoch die Frage, wie ich ein maxspeed für Fahrzeuge über und unter 3,5t tagge.

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

MADetter wrote:

maxspeed = __DEPENDED maxspeed:above_3.5t = <Geschwindigkeit in km/h> maxspeed:below_3.5t = <Geschwindigkeit in km/h> maxspeed:unit = km/h

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:<Fahrzeugtyp> 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:<Fahrzeugtyp> ist eine Parametrisierung nach Semantik a) - maxspeed wird durch Fahrzeugtyp parametrisiert, ab

MADetter wrote:

maxspeed:unit ist eine Atributisierung nach Semantik c) - hier muss der Wert angegeben werden, der zur Zusatzinformation gehört maxspeed:<Fahrzeugtyp> ist eine Parametrisierung nach Semantik a) - maxspeed wird durch Fahrzeugtyp parametrisiert, aber es ist immernoch maxspeed - daher die Geschwindigkeit. Eventuell könnten wir die 3 Semantiken syntaktisch unterscheiden... aber ich frage mich ob das nötig ist.

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?

MADetter wrote:

Auch deine Kritik bezüglich der Begrenzungen angeht: Wir sind ja noch bei der prinzipiellen Struktur - die genau BEZEICHNUNG von Schlüsseln und untergeordneten Schlüsseln ist dann eine andere (spätere, Schlüsselbezogene) Sache. Meine Frage an dich ist: Willst du "maxspeed:weight>3.5t" als festen Namen oder schlägst du vor, den untergeordneten Schlüssel ":weight" mit einer (theoretisch beliebig wählbaren) Ober- oder Untergrenze zu belegen?

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.

MADetter wrote:

Über dies ist weight ein untergeordneter Schlüssel von maxspeed, wolltest du eine unit von weight wollen, müsste das Tagging lauten: maxspeed:weight:unit = t

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.

MADetter wrote:

ABER ich sehe vor, die symbolische Fahrzeugkathegorie "above_3.5t", einführen, definiert als Unterschlüssel für maxspeed (und nur dafür). Die Semantik was "above_3.5t" bedeutet hat mit deutscher Gesetzgebung zu tun, und die in der OSM-Datenbank vorzuhalten ist schwierig... naja ich denk da nochmal drüber nach.

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 <Key> : <Subkey1> > <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: <Key>:<Subkey1> {>,<,<=,>=,==} <Subkey1_value> = <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 <key> = {__DEPENDING | __STRUCTURE} und <key>:<subkey> = value (Semantik a) oder b)) für Semantik c) schreiben: <key>::<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 <Key>:<Subkey1> {>,<,<=,>=,==} <Subkey1_value> = <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 = <Hausnummer> 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"(tm) 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 … s_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

MADetter wrote:

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"(tm) 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.

Genauso gehts mir mit deimen _DEPENDING und _STRUCTURE ... das gefällt mir irgendwie garnicht, ich kanns aber auch nicht erklähren...

MADetter wrote:

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...

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...

Markus B wrote:

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

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

TEL0000 wrote:

Ein Schema hast du doch grade selber aufgeführt...

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 <rule>s formuliert sind: http://josm.openstreetmap.de/svn/trunk/ … styles.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.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.

MADetter wrote:

@ Markus Wenn die Sektoren bei allen Leuchttürmen gleich sind (also von den Winkel-Ranges) wäre es sinnvoller, diese als feste untergeordnete Schlüssel (z.b. :S_30_90) zu definieren.

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

TEL0000 wrote:

Meiner Meinung nach müsste die Software das automatisch erkennen.

Ja. Dateneingabe muss ohne "in der Hilfe nachlesen" möglich sein. Es darf keine Kenntnis der Struktur vorausgesetzt werden, die Dateneingabe muss regelbasiert und "geführt" erfolgen. Und - basierend auf dem englischsprachigen "Original" muss wahlweise die landessprachliche Übersetzung angeboten werden (Übersetzungs-Datenbank). Dann muss auch keiner mehr überlegen, ob man jetzt "amenity" oder "aminety" schreibt... Gruss, Markus PS: und für die "Proposals" gibt es dann 2 Varianten: a) ein fundiertes regelbasiertes Proposal b) wie bisher: jeder "erfindet irgendetwas Neues", und wenn es sich häuft, dann entwickelt einer die dazugehörigen Regeln unhd macht ein Proposal Und sobald die Regeln eindeutig sind, wird es von den Renderern sofort übernommen (wodurch Variante a bevorzugt wird). Bisher gibt es ja einen scheinbaren Gegensatz zwischen denen, die "totale Freiheit", und denen die "klare Regeln" wollen. Das ist aber nur deshalb scheinbar ein Gegensatz, weil auch bei totaler Freiheit der "Tagger" auf der Eingangsseite, diese durch klare Regeln der Renderer auf der Ausgangsseite aufgefangen wird.

@ MADetter: Hast du dir inzwischen mal Gedanken gemacht? Nicht dass der Thread ohne Ergebnis im Nirvana verschwindet. ;-)

Sorry - bin mit meiner Thesis beschäftigt. - die nächsten 3 Wochen kann ichs nicht in Angriff nehmen. Eine Tag-Nummerierung scheint sinnvoll zu sein - aber ich kann mir darüber gerade keine tieferen Gedanken machen. MfG Mark

Kein Problem. Wollte nur nicht, dass der Thread in Vergessenheit gerät. Vielleicht hat ja auch jemand anderes noch Ideen? ;-) Besonders würde mich auch ein Statement von jemandem interessieren, der sich damit auskennt, wie und ob die Software so ein Schema interpretieren kann, und wo es Probleme mit der momentanen Struktur gibt...

Ehm .. habe mir jetzt noch nicht alles durchgelesen (das braucht offenbar ein bisschen Zeit 😉), aber hat jemand die Möglichkeit, hier mal ein Resume zu ziehen und die Kernpunkte zusammenzufassen in zwei Sätzen, falls es irgendwelchen"Findings" überhaupt gibt? Oder gibt´s eine Wiki, die das Thema fortgeführt hat?

Ich wollte auch mal meinen Senf dazu abgeben. Für Zeitangaben gibt es eine sehr schöne ISO die so gut wie alles abdeckt: http://en.wikipedia.org/wiki/ISO_8601 . Bei den Leuchttürmen werden die Sektoren von der Fahrrinne festgelegt und die ändert sich mit der Zeit. Es wäre besser die Fahrrinne in die Karte zu zeichnen, es sei denn du willst die Fahrrinne über die Winkeldaten des Leuchtturms dynamisch berechnen lassen ;-) Als Index würde ich ein :: (default, Index 0) und :X: (0 <= X >= n) bevorzugen. Die Frage ist aber, wo darf ein Index gesetzt werden. Wenn dynamisch, dann muss der Index auch als Index kenntlich gemacht werden ohne sich mit den Namen zu überschneiden. Grüße.

Kopiert aus http://forum.openstreetmap.org/viewtopic.php?pid=13662

Tordanik wrote:

TEL0000 wrote:

Wie würdest du denn konkret eine Geschwindigkeitsbegrenzung für LKW zu bestimmten Uhrzeiten taggen?

Etwas in der Art maxspeed:hgv&time=Sa 00:00-18:00 = 70 wobei es mir jetzt nicht um das exakte Zeitformat geht. Und um das Beispiel "maxspeed bei Gewicht über 3.5 t" aus dem verlinkten Thread noch mal aufzugreifen: maxspeed = <Geschwindigkeit in km/h> maxspeed:weight>3.5 = <Geschwindigkeit in km/h> __DEPENDED oder so ist unnötig, da die spezifischste Angabe gültig ist, das ist m.E. mapperfreundlicher. Den Wertebereich für "3.5" (die implizierten Tonnen) hab ich jetzt mal von maxweight übernommen, das könnte man ganz ähnlich auch für length, width, height, axleload etc. machen. Die beiden unterschiedlichen Trenner : und & halte ich deshalb für ok, weil die "Bedingungen" etwas anderes sind als eine hierarchische Struktur. Insbesondere ist dort nämlich die Reihenfolge untereinander egal – anders als bei addr:housenumber oder auch der Trennung zwischen maxspeed und den Bedingungen in meinem Beispiel. Die Verwendung des Doppelpunkts nach maxspeed erfolgt – um mal wieder auf den alten Thread Bezug zu nehmen – im Sinne der Semantik c) "Parametrisierung". Der Parameter ist eben, wenn man so will, ein sehr reduzierter boolescher Ausdruck, den man für eine bestimmte Situation auf "trifft zu" oder "trifft nicht zu" auswerten kann. Deshalb darf der m.E. auch Vergleichsoperatoren enthalten, ohne die Trennung zwischen Schlüssel und Wert zu verletzen, der Post von MADetter überzeugt mich da nicht. (Nebenbei: Ich hätte auch nichts dagegen, für "Parametrisierung" eine eigene Syntax zu verwenden (Klammern z.B.), aber da verlässt man wieder die ausgetretenen Pfade von name:de und Konsorten. Ist vermutlich auch nicht nötig.)

Vielleicht finden wir ja doch noch ein einheitliches Schema... Die Idee mit den &-Trennern finde ich gut. Ein gleichheitszeichen können wir aber nicht verwenden, weil es der offizielle Trenner von Schlüssel und Wert ist... Die Werte mit den den Schlüssel zu übernehmen halte ich (mitlerweile) auch nicht mehr für Ideal. Ich denke eher, dass wir bezüge zwischen den Schlüsseln untereinander herstellen können müssen.

Hallo ...

north wrote:

Bei den Leuchttürmen werden die Sektoren von der Fahrrinne festgelegt und die ändert sich mit der Zeit. Es wäre besser die Fahrrinne in die Karte zu zeichnen

Leuchttürme und Fahrrinnen sind in der Wirklichkeit und auch in der Karte verschiedene Objekte. Ein Leuchtturm wird als Punkt dargestellt, eine Fahrrinne durch die sie begrenzenden Schiffahrtszeichen (Tonne etc.). Ein Leuchtturm kann ein Leuchtfeuer tragen (oder nicht). Ein Leuchtfeuer hat einen oder mehrere Sektoren. Sektoren eines Leuchtfeuers können bei fehlenden Schifffahrtszeichen auch eine Fahrrinne anzeigen. Leuchttürme, Leuchtfeuer und Sektoren werden durch Attribute beschrieben. Hier ein Versuch:

<!ELEMENT Lighthouse (Position, IntLFNr, NameInt, NameLoc, Function, Hight over Sea, Referenzhöhe, Turmhöhe, Light/Leuchtfeuer)> <!ELEMENT Position (Lat, Lon, Alt)> <!ELEMENT Lat (#PCDATA, ##,#.. Grad> <!ELEMENT Lon (#PCDATA, ###,#.. Grad)> <!ELEMENT Alt (#PCDATA, ### Meter ü.M.)> <!ELEMENT IntLFNr (#PCDATA, A ####)> <!ELEMENT NameInt (#PCDATA)> <!-- english --> <!ELEMENT NameLoc (#PCDATA)> <!-- local language/Lokalsprache --> <!ELEMENT Function (#PCDATA, See-|Leit-|Quermarken-|Orientierungs-|Warn-|Molen-|Nebel-|Einfahrts-|Richt-|Ober-|Unterfeuer)> <!ELEMENT TowerTyp (#PCDATA, round|square|other)> <!ELEMENT TowerHight (#PCDATA, ### Meter)> <!ELEMENT Light (Hight, ReferneceHight, Visability, Sector +, Activ)> <!-- 1..10 Sectors --> <!ELEMENT Hight (#PCDATA, ### meter over sea/Meter ü.M )> <!-- Höhe des Feuers --> <!ELEMENT ReferenceHight (#PCDATA, MLWS|MSL)> <!ELEMENT Visability (Start, End)> <!ELEMENT Start (#PCDATA, ### degree, bearing clockwise/Grad, Peilung rechtsweisend)> <!ELEMENT End (#PCDATA, ### degree, bearing clockwise/Grad, Peilung rechtsweisend)> <!ELEMENT Sektor (Start, Angle, Color, Range, Sichtweite, Characteristic)> <!ELEMENT Start (#PCDATA, ### degree, bearing clockwise/Grad Peilung rechtsweisend)> <!ELEMENT Angle (#PCDATA, ### degree/Grad)> <!ELEMENT Color (#PCDATA, W|R|G|Y)> <!ELEMENT Range (#PCDATA, ## seamiles/Tragweite, Seemeilen)> <!ELEMENT Sichtweite? (#PCDATA, ## seamiles/Seemeilen)> <!ELEMENT Characteristic (Typ, Group c, Period)> <!-- Kennung --> <!ELEMENT Typ (#PCDATA, F|Oc|Iso|Fl|LFl|Q|IQ|IVQ|UQ|Mo(*)|FFl|AI.**)> <!ELEMENT * (#PCDATA, character as mordecode/Buchstabe als Morsezeichen)> <!ELEMENT ** (#PCDATA, W|R|G)> <!ELEMENT Group (#PCDATA, (2)|(3)|(4)|(5)|(6)|(9)|(2+1)|(2+3)|(3+1) )> <!ELEMENT Period (#PCDATA, ## seconds/Wiederkehr Sekunden)> <!ELEMENT Activ (#PCDATA, yes|no)>

Bin gespannt, ob jemand eine Idee hat, wie man das in OSM abbilden könnte... Gruss, Markus

TEL0000 wrote:

Ein gleichheitszeichen können wir aber nicht verwenden, weil es der offizielle Trenner von Schlüssel und Wert ist

Was ist daran offiziell? Im xml steht das jedenfalls als zwei separate Attribute drin. In der DB würde es mich auch unangenehm überraschen -- oder weißt du da mehr als ich?

Die Werte mit den den Schlüssel zu übernehmen halte ich (mitlerweile) auch nicht mehr für Ideal. Ich denke eher, dass wir bezüge zwischen den Schlüsseln untereinander herstellen können müssen.

Tja, und ich denke, dass Verbindungen zwischen den Schlüsseln unnötig komplex sind. Verbindungen haben wir zwischen Objekten (Way, Node, Relation), die haben dafür Objekt-IDs. Ich sehe keinen sinnvollen Anwendungsfall für Verbindungen zwischen Tags*, aber vielleicht kannst du ja mal ein Beispiel bringen. Dein maxspeed-Beispiel ("maxspeed:hgv:time = ...") ist auch m.E. unzulässig einfach. Es kann ja durchaus mehrere hgv-maxspeeds geben, etwa einen für Sonntags und einen anderen sonst. Was dann? * Nur um das mal vorwegzunehmen: Lanes und Einheiten halte ich beides nicht für ideale Anwendungsfälle: Lanes sollten eigene Objekte sein, schon wegen der Möglichkeit, sie dann in Relationen zu stecken. Einheiten wie mph werden bereits sehr oft in den Wert mit eingetragen, und das halte ich eigentlich auch für vertretbar, mit dem zusätzlichen Nutzen, dass es die Eindeutigkeit des Information sicherstellt.

Tordanik wrote:

Lanes sollten eigene Objekte sein, schon wegen der Möglichkeit, sie dann in Relationen zu stecken.

Genau das was in vielen anderen Anwedungsgebieten Standard ist und was ich damit auch meinte. So manche Relation ließe sich damit gleich ganz sparen. Die jeweilige Situation könnte dann direkt an eine "physisch" vorhandene Lane angebracht werden. Wenn man aber dafür ohnehin direkt an die API muss, kann man gleich zwei weitere Punkte mit Abwaschen. Kein Stückwerk mehr. Sprich die Möglichkeit eine Situation zwischen zwei angegebene Nodes beschreiben zu können. Das erübrigt in 90% der Falle das zerhacken von Wegen. Und für Kurven gleich Splines oä. um dem Eiertanz mit vielen Nodes ein Ende zu setzen.

Tordanik wrote:

Lanes sollten eigene Objekte sein, schon wegen der Möglichkeit, sie dann in Relationen zu stecken. Einheiten wie mph werden bereits sehr oft in den Wert mit eingetragen, und das halte ich eigentlich auch für vertretbar, mit dem zusätzlichen Nutzen, dass es die Eindeutigkeit des Information sicherstellt.

Nicht unbedingt ;-). Wenn es denn "MAL" [hallo CHEF] eine eindeutige Malrichtung geben würde könnte man den Abschnitt mit mehreren Lanes kennzeichnen und dann über diese, die wieder als Objekte auftauchen, weiter in die Tiefe gehen. Mal ein Beispiel: Gemalt: * - Node 1/2/3 (als Beispiel eine Nummer) der Teilabschnitt des gemalten Weges, also Abschnitt 1,2 und 3 *1111111111111*2222222222222*33333333333* Jeder Abschnitt bekommt seine eindeutige Richtung (HAUPTRICHTUNG) und über DIESE werden weitere RICHTUNGSBEDINGTE Eigenschaften definiert. Die Richtung (HAUPTRICHTUNG) ist beim erstellen definiert und kann danach nicht mehr geändert werden. Alle weiteren Eigenschaften, bei denen Richtungsänderungen entgegen oder mit der HAUPTRICHTUNG auftreten, werden über Hilfstags realisiert (das kennen dann wieder alle) und/oder über die Software abgefangen. Hier geht es meiner Meinung nach nicht ohne grafische Hilfsmittel. So haben wir einen Weg gemalt der eine eindeutige Richtung hat. Nun hat der gemalte Weg erstmal nichts weiter. Jetzt müssen wir dem Weg "lanes" hinzufügen, einen Radweg und einen Fußweg, wenn vorhanden und die bekannten tags für die einzelnen Abschnitte. So stelle ich mir das vor, ohne mir groß Gedanken darüber gemacht zu haben. Evtl. gibt es noch konkretere Meinungen zu diesem Thema. Grüße.

Ich denke jetzt doch, dass für das Lane-Thema muss ein neuer Thread her muss, sonst entstehen hier wieder zwei völlig verschiedene Diskussionen

Tordanik wrote:

TEL0000 wrote:

Ein gleichheitszeichen können wir aber nicht verwenden, weil es der offizielle Trenner von Schlüssel und Wert ist

Was ist daran offiziell? Im xml steht das jedenfalls als zwei separate Attribute drin. In der DB würde es mich auch unangenehm überraschen -- oder weißt du da mehr als ich?

Puh ... das weiß ich jetzt leider auch nichtmehr ... irgendwie hab ich sowas im Kopf, dass ein = irgendwie in === umgewandelt wird. Ob das jetzt die API war, keine Ahnung..

Die Werte mit den den Schlüssel zu übernehmen halte ich (mitlerweile) auch nicht mehr für Ideal. Ich denke eher, dass wir bezüge zwischen den Schlüsseln untereinander herstellen können müssen.

Tja, und ich denke, dass Verbindungen zwischen den Schlüsseln unnötig komplex sind. Verbindungen haben wir zwischen Objekten (Way, Node, Relation), die haben dafür Objekt-IDs. Ich sehe keinen sinnvollen Anwendungsfall für Verbindungen zwischen Tags*, aber vielleicht kannst du ja mal ein Beispiel bringen.

Nehmen wir als komplexes Beispiel mal das Leuchtturm-Tagging von der Vorseite. Was besseres fällt mir grad nicht ein.

Dein maxspeed-Beispiel ("maxspeed:hgv:time = ...") ist auch m.E. unzulässig einfach. Es kann ja durchaus mehrere hgv-maxspeeds geben, etwa einen für Sonntags und einen anderen sonst. Was dann?

Dazu hatte ich Vorgeschlagen etwas wie eine Nummerierung einzuführen, um Tags mehrfach verwenden zu können. Und zu den Zeitentagging gabs auf der Vorseite auch schon einen Vorschlag. Aber da sich da anscheinend schon was anderes durchzusetzen scheint nehme ich das einfach mal als Beispiel: maxspeed:hgv:time = Mo-Fr 12:00-18:00; Su 13:00-15:00

Nehmen wir als komplexes Beispiel mal das Leuchtturm-Tagging von der Vorseite. Was besseres fällt mir grad nicht ein.

Das verwendet "Pseudo-IDs", was du ja anscheinend auch für maxspeed verwenden willst, und wirkt recht kompliziert (Genau weiß ichs nicht, habs nie verwendet. Werden die großflächig manuell eingegeben?). Das würde ich mir für ein Tagging in Nicht-Spezialisten-Themen nicht wünschen. Für den Fall kann man es allerdings unter Beschränkung auf Tags wirklich nicht anders machen, und Relationen etc. wären wohl auch nicht grad einfach. Anscheinend gibts doch einen gewissen Bedarf an "bezogenen" Tags, obwohl es auch hier nicht alternativlos gewesen wäre. Areas hätte ich wahrscheinlich zuerst vorgeschlagen (leichter renderbar). Natürlich hätte man auch das mit &-Ausdrücken machen können 😉 : seamark:light:color:radius>270&radius<320&range<20 = white seamark:light:color:radius>340&radius<020&range<20 = white seamark:light:color:radius>030&radius<100&range<20 = white statt 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 Hier finde ich das aber nicht die bessere Lösung, zu lang, v.a. wegen der "immer gültigen" 20.

maxspeed:hgv:time = Mo-Fr 12:00-18:00; Su 13:00-15:00

Kannst du das Beispiel bitte vollständig bringen? Wie genau würdest du die Aussage "So 00:00-24:00 gilt für hgv maxspeed 70, sonst 100. Für alle anderen Fahrzeuge gilt immer 120" taggen? Bei mir sähe das zum Vergleich so aus: maxspeed = 120 maxspeed:hgv = 100 maxspeed:hgv&time=So 00:00-24:00 = 70 //den = jetzt mal ignorierend... (Auch wenns hier nicht um maxspeed geht, aber es macht sich als Beispiel imo ganz gut.)

Für solche Sachen müsste man eigentlich auch wieder ein bissel weiter denken. Am Ende haben wir Schlüssel die einen Meter überschreiten und damit immer fehleranfälliger sind. Kein Editor der sich an die Breite Masse wendet, me. auch immer mehr Editoren welche sich an Fachleute wenden, verlangen heutzutage noch irgendwelche elendig langen Zeilen, die sich der User zudem noch ausdenken muss. Dafür wird heute normal einmalig ein Script ausgearbeitet und geschrieben, was dann fester Bestandteil der eigentlichen Software wird. Alles was der Anwender zu sehen bekommt, macht JOSM eigentlich zum Teil vor. Eine Maske in der nur die Angaben gemacht werden und die eigentliche Arbeit passiert woanders. Das geht zum einen schneller, ist Anwenderfreundlich und reduziert deutlich Fehler. Die können nicht mehr im Schlüssel selbst sondern nur noch bei den eigentlichen Angaben passieren. Wer Tagwatch beobachtet kennt das Problem. Dutzende Fehler nur rein von händisch falsch verfassten Schlüsseln kommend. Das würde auch gleichzeitig die Datenmenge etwas reduzieren. Da die Interpretation der Schlüssel rein technisch erfolgt, die menschliche Komponente entfällt, kann das ganze komprimiert gespeichert und übermittelt werden. Solche Monsterkettenbriefe wären hinfällig. Man hat also z.B. die Maske für Geschwindigkeitsbgrenzungen offen. Dort erstellt man eine Regel für alles in kmh, hier 120 ohne weitere Beschränkungen und Situationen, was dann erstmal für alles gilt. Dann klickt man z.B. auf Regel hinzufügen um den hgv seine 100 zu verpassen. Dann kommt die dritte Regel mit 70 am Sonntag ganztägig. Der gespeicherte und übermittelte Wert kann dann im Klartext meitwegen so aussehen "kmh120hgv100hgvsu70". Geht natürlich mit anderen Verfahren kürzer. Ist im grunde auch eigentlich egal. Denn der Anwender muss sich mit derlei Problemen nicht mehr herumschlagen. Einziges Problem ist hier die etwas unglückliche Lösung das vieles nur über die API geht, die leider anders wie bei vielen anderen Anwendungen nicht offen ist, man allen Anwendern die komplette Lönsungsfindung überlässt und selbige auf die Gnade eine implementierung hoffen müssen.

Tordanik wrote:

Nehmen wir als komplexes Beispiel mal das Leuchtturm-Tagging von der Vorseite. Was besseres fällt mir grad nicht ein.

Anscheinend gibts doch einen gewissen Bedarf an "bezogenen" Tags, obwohl es auch hier nicht alternativlos gewesen wäre. Areas hätte ich wahrscheinlich zuerst vorgeschlagen (leichter renderbar). Natürlich hätte man auch das mit &-Ausdrücken machen können 😉 : seamark:light:color:radius>270&radius<320&range<20 = white seamark:light:color:radius>340&radius<020&range<20 = white seamark:light:color:radius>030&radius<100&range<20 = white

Wär auf jeden Fall ne Idee. Da gäbs halt wieder das Problem mit dem "color" mitten in der Mitte, obwohl es eigentlich der Tag ist zu dem der Wert gehört. Außerdem müsste die Software um an die anderen Werte zu kommen erstmal den Key zerlegen. Wobei das bei den anderen Vorschlägen eigentlich auch so ist. Und wie du schon selber sagst, auf die abhängigen Schlüssel kann man nicht immer verzichten. Wegen den Pseudo-IDs ... ich denke mitlerweile wieder, dass "color[1]" doch übersichtlicher wär. Quasi wie so ne Art Array. Wenn man einen Tag mehrfach verwenden will, dann macht man einfach ein [1] oder [2] and den Tag. Stell dir mal vor der Leuchtturm hätte noch ein zweites Licht mit anderen Radien und Farben. Ok, unwahrscheinlich, aber soll ja auch nur ein Beispiel sein um für alle Eventualitäten gerüstet zu sein.

maxspeed:hgv:time = Mo-Fr 12:00-18:00; Su 13:00-15:00

Kannst du das Beispiel bitte vollständig bringen? Wie genau würdest du die Aussage "So 00:00-24:00 gilt für hgv maxspeed 70, sonst 100. Für alle anderen Fahrzeuge gilt immer 120" taggen?

Ach, mit unterschiedlichen Maxspeeds... Da wären bei mir dann wieder die Pseudo-IDs drin, also: maxspeed = 120 maxspeed:hgv[1] = 100 maxspeed:hgv[2] = 70 maxspeed:hgv[2]:time = So 00:00-24:00

Bei mir sähe das zum Vergleich so aus: maxspeed = 120 maxspeed:hgv = 100 maxspeed:hgv&time=So 00:00-24:00 = 70 //den = jetzt mal ignorierend...

Hmm ... also wirklich übersichtlich sind beide Varianten nicht besonders ...

Mirko Küster wrote:

Man hat also z.B. die Maske für Geschwindigkeitsbgrenzungen offen. Dort erstellt man eine Regel für alles in kmh, hier 120 ohne weitere Beschränkungen und Situationen, was dann erstmal für alles gilt. Dann klickt man z.B. auf Regel hinzufügen um den hgv seine 100 zu verpassen. Dann kommt die dritte Regel mit 70 am Sonntag ganztägig. Der gespeicherte und übermittelte Wert kann dann im Klartext meitwegen so aussehen "kmh120hgv100hgvsu70". Geht natürlich mit anderen Verfahren kürzer. Ist im grunde auch eigentlich egal. Denn der Anwender muss sich mit derlei Problemen nicht mehr herumschlagen.

So stelle ich mir das auch vor... Der Editor hat eine Maske, und setzt daraus die Keys und Values zusammen. Nur damit jemand sowas einbaut muss erstmal ein Schema für die Keys und Values feststehen. Der übermittelte String sähe dann halt so aus: "maxspeed:hgv:time = Mo-Fr 12:00-18:00; Su 13:00-15:00" Das ganze manuell einzugeben ist nur was für Entwickler. Die Anwender brauchen so oder so eine Software, die das übernimmt. Noch ist die Software halt nicht soweit.

Einziges Problem ist hier die etwas unglückliche Lösung das vieles nur über die API geht, die leider anders wie bei vielen anderen Anwendungen nicht offen ist, man allen Anwendern die komplette Lönsungsfindung überlässt und selbige auf die Gnade eine implementierung hoffen müssen.

Perfekt ist die API wirklich noch nicht. Alles was man da machen kann ist mit den Entwicklern zu Diskutieren. Oder vielleicht eine Vorschlagsseite zu Verbesserung der API ins Wiki stellen, da sind die Chancen groß, dass die Entwickler das lesen. Aber damit kenne ich mich zu wenig aus.

Ich hätte ja einige ex. Kollegen und Bekannte an der Hand, die sowas schon für andere Software gescriptet haben. Ich kann sowas selber nicht umsetzen, ich komme aus der 3D Ecke und beschränke mich auf Animationen und kleinere Geschichten. So Geschwindigkeitsgeschichten und vieles anderes liegt aber auf Halde, auch mit so individuellen Dingen Schlupf usw. für konkrete Anwendungsgebiete. Das ist ansich kein Hexenwerk, da stand man schon vor weitaus schwereren Nüssen. Das Problem ist die fehlende Offenheit des eigentlichen Backends. Die treten mich in den Hintern wenn ich sie jetzt darum bitte sich einen Kopf über die Umsetzung für hier zu machen, am Ende aber vor verschlossene Türen rennen. Mein Versuch bei den Railways hat mich da vorsichtig werden lassen. Ausser der typisch deutschen Marotte erstmal alles anzumeckern was nicht geht, kam da nichts weiter. Also lieber garnichts ändern anstatt sich mal irgendwas bewegt. Von daher muss ich erstmal wissen, ob und inwieweit sich die Überlegung überhaupt lohnt. Wenn man lieber weiterhin 3 Jahre oder länger an irgendwelchen Schlüsseln herumdocktert, nur um festzustellen, das ganze ist noch immer unzureichend, lohnt es sich nicht. Ich kann nur anregen darüber nachzudenken und lange gängige Standards in ähnlichen Anwendungsgebieten aufzeigen, von denen man hier im Moment noch Lichtjahre entfernt ist. Wenn das nicht auf Interesse stößt dann kann man halt nichts machen.

Mirko Küster wrote:

Ich kann nur anregen darüber nachzudenken und lange gängige Standards in ähnlichen Anwendungsgebieten aufzeigen, von denen man hier im Moment noch Lichtjahre entfernt ist. Wenn das nicht auf Interesse stößt dann kann man halt nichts machen.

Ich weiß jetzt nicht, was du schon versucht hast, aber ich denke das ist schon der richtige Weg... Grade, was die gängigen Standards in änlichen Anwendungsgebieten betrifft. Ich kenne mich damit nicht aus, und weiß auch nicht, ob sich die Entwickler wissen wie es "andere" gelöst haben. Gibt es denn schon eine Wikiseite zu dem Thema?

Mirko Küster wrote:

Man hat also z.B. die Maske für Geschwindigkeitsbgrenzungen offen. Dort erstellt man eine Regel für alles in kmh, hier 120 ohne weitere Beschränkungen und Situationen, was dann erstmal für alles gilt. [...]

Selbstverständlich kann wo immer möglich komplexes Tagging vor dem "gewöhnlichen" Anwender versteckt werden. Bei Tag-Strukturen wie in diesem Thread gehts also nur um das, was ein "Early Adopter" oder Entwickler zu sehen bekommt. Das kann ruhig etwas länger und komplexer sein, aber man sollte es durchaus noch manuell eingeben und besonders auch verstehen können. Übrigens ist das Erstellen von Eingabemasken Aufgabe der Editorprogrammierer, und die werden normalerweise erst tätig, nachdem sich ein Konzept einigermaßen etabliert hat.

TEL0000 wrote:

Wegen den Pseudo-IDs ... ich denke mitlerweile wieder, dass "color[1]" doch übersichtlicher wär. Quasi wie so ne Art Array.

Ich halte das im Allgemeinen schon für einen gangbaren Weg, wenn es mehrere gleichzeitig gültige und gleichartige Dinge eines Typs an einem OSM-Objekt gibt, man könnte sich z.B. überlegen, das für Häuser/Hauseingänge mit mehreren Hausnummern zu nehmen. Oder für die Leuchttürme halt, wo es ja, wenn ich das richtig verstehe, auch mehrere "Lichter" an einem Turm gibt, die voneinander unabhängig sind. In solchen Fällen modelliert man damit quasi Mehrwertigkeit, nur, dass man sogar ganze Key-Gruppen damit mehrfach existent machen kann. Im konkreten Fall "maxspeed" drängt sich mir eine Array-Lösung nicht wirklich auf. Wirklich unabhängige Datengruppen will man dort ohnehin nicht, denn maxspeed:hgv[1] = 100 maxspeed:hgv[2] = 120 wird mir dann nur noch durch zusätzliche Prüfungen verunmöglicht. (Allerdings kann ich bei mehreren Bedingungen durch Umordnung auch ohne Indizes Mist bauen.) Wirklich entscheidende Argumente sehe ich bei maxspeed momentan weder für eine Indexlösung, noch für eine reine "Bedingungskette", ich halte die Bedingungskette aber tendenziell für leichter auswertbar, zumal eine Indexlösung in der von dir vorgeschlagenen Variante ja auch lokale Bedingungen (das hgv in deinem Beispiel) hat. Wenn es diesbezüglich keine neuen Impulse mehr gibt, erstelle ich erstmal einen vorläufigen Entwurf (Draft) für ein Proposal, auf dessen Grundlage man dann nochmal diskutieren kann, vielleicht sieht man dann auch ein paar bisher nicht erkannte Probleme.

Vielleicht sollte man auch einfach nur die Tags nummerieren, die mit weiteren Bedingungen verknüpft sind. Also Etwa: maxspeed:hgv = 100 maxspeed:hgv[1] = 120 maxspeed:hgv[1]:time = Mo-Fr 12:00-18:00 Dann braucht die Software nicht auf Bedingugen zu prüfen, wenn man nur an den allgemeinen Wert will... Und da hab ich mir noch ein paar Gedanken gemacht, bezüglich dazu wie man es für Mensch und Maschine möglichst leicht gestaltet. Es geht da im Prinzip nur darum den Zusammenhang zwischen zwei Schlüsseln darzustellen. Da ist es nur unnötig Kompliziert den Index mitten im Key stehen zu haben. Vielleicht ist es so besser: maxspeed:hgv = 100 [1]maxspeed:hgv = 120 [1]maxspeed:hgv:time = Mo-Fr 12:00-18:00 [2]maxspeed:hgv = 80 [2]maxspeed:hgv:time = Su 13:00-15:00 Das macht es für die Software wesentlich einfacher den String zu zerlegen. Und ungeübte User müssen sich nicht immer fragen an welche Stelle der Index kommt. Mir fallen da auch noch mehr Beispiele ein. So sehe ich häufig Straßen mit Straßenbahnschienen: [1]highway = secondary [1]name = Wilhelmsruher Damm [2]electrified = contact_line [2]name = Tram M1 [2]railway = tram Hier würde das funktionieren, ist aber nicht wirklich verwendbar da nichts mehr gerendert werden würde... Daher denke ich jetzt eher, dass von API-Seite eine Verknüpfung zwischen den Schlüsseln hergestellt werden können muss.

TEL0000 wrote:

Vielleicht sollte man auch einfach nur die Tags nummerieren, die mit weiteren Bedingungen verknüpft sind. Also Etwa: maxspeed:hgv = 100 maxspeed:hgv = 100 maxspeed:hgv[1] = 120 maxspeed:hgv[1]:time = Mo-Fr 12:00-18:00 Dann braucht die Software nicht auf Bedingugen zu prüfen, wenn man nur an den allgemeinen Wert will...

Woran genau machst du fest, "hgv" nicht als Bedingung aufzufassen? Dass es nur ein einzelner Terminus ist? Würdest du das bei anderen Modifikatoren (das vorgeschlagene "wet" etwa) dann auch so machen oder hier ein weiteres Tag mit wet=yes oder so was anhängen? Noch was: Wie würdest du das hier maxspeed:weight>3.5 = 80 in dein Schema überführen?

Vielleicht ist es so besser: maxspeed:hgv = 100 [1]maxspeed:hgv = 120 [1]maxspeed:hgv:time = Mo-Fr 12:00-18:00 [2]maxspeed:hgv = 80 [2]maxspeed:hgv:time = Su 13:00-15:00

Spontan finde ich es "seltsam", liegt aber wahrscheinlich nur an der Gewöhnung an Array-Syntax. Müsst ich noch mal drüber nachdenken, aber wahrscheinlich kann man die "Trennstelle" wirklich auch durch die anderen Tags finden.

Mir fallen da auch noch mehr Beispiele ein. So sehe ich häufig Straßen mit Straßenbahnschienen:

Das ist wieder eine Lane-Frage, schließlich ist die Straßenbahn genauso Teil des gesamten Verkehrsbündels wie, sagen wir, ein Radweg oder eine Abbiegespur. Da sollte man m.E. gar nicht erst mit Taghaufen anfangen, sondern mehrere Objekte anlegen (wie auch immer die letztendlich sich durchsetzende Lane-Lösung aussieht).

Schaut euch bitte mal die ISO-Zeitangaben an, das würde evtl. etwas bringen !

north wrote:

Schaut euch bitte mal die ISO-Zeitangaben an, das würde evtl. etwas bringen !

Welche ISO meinst du denn? Die Zeitangaben beziehen sich momentan auf diese Richtlinien: http://wiki.openstreetmap.org/wiki/DE:Key:opening_hours

Die ISO 8601 http://en.wikipedia.org/wiki/ISO_8601 http://de.wikipedia.org/wiki/ISO_8601

north wrote:

Die ISO 8601

Die ist sehr gut geeignet, um Zeitpunkte anzugeben, dafür würde ich sie definitiv auch verwenden. Um wiederkehrende Zeitintervalle, wie wir sie hier oft brauchen, ("immer Samstags und Sonntags", "jeden Montag zwischen 8 und 18 Uhr", "zwischen Juli und Oktober") anzugeben -- und das nach Möglichkeit auch noch leserlich -- sehe ich dort keine Syntax. Darfst mich da gerne korrigieren.

Sehe ich genauso. Für unsere konkreten Beispiele (Mo-Fr 12:00-18:00) finde ich dort nichts.

Das geht mit der ISO nicht, richtig. Dort wurden aber einheitlich Zeitangaben definiert, an die mal sich halten kann. Eine Erweiterung auf der ISO-Basis kann auch nicht schaden. Es wird also ein wöchentliches Intervall genötigt, das sich wöchentlich 5 mal wiederholt, am Montag (Wochentag 1) anfängt, 6 Stunden, ab 12Uhr, dauert und mit einem Computer verarbeitet werden kann.

TEL0000 wrote:

maxspeed:hgv:time = Mo-Fr 12:00-18:00; Su 13:00-15:00

Meinst du Saturday oder Sunday, wo wir mal wieder bei einigen praktischen Problem sind ...

Sunday, sonst hätte ich ja "Sa" geschrieben. 😉 Die englischen Wochennamen sind da unverwechselbar. 😉 Kannst du mal ein konkretes Taggingbeispiel geben, wie du das taggen würdest?