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
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 
(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
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 …
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:
Bin gespannt, ob jemand eine Idee hat, wie man das in OSM abbilden könnte… Gruss, Markus
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?
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.
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.
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 1111111111111222222222222233333333333 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
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…
Nehmen wir als komplexes Beispiel mal das Leuchtturm-Tagging von der Vorseite. Was besseres fällt mir grad nicht ein.
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
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.
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.
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.
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
Hmm … also wirklich übersichtlich sind beide Varianten nicht besonders …
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.
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.