Hallo Markus, Wenn die Schlüssel nicht hierachisch sind, hindert es uns jedoch nicht daran, ihnen eine Hierachie aufzuprägen, durch die Konstruktion ::…, wobei : erstmal reicht. 
Um das durchzusetzen, sollten wir bisherige Keys “sinnvoll erweitern™” - also erstmal als “Speziallösungen” bis sich das Konzept in den Köpfen der Mapper festgesetzt hat. - Darum sollten wir uns mal ein Schema als Ziel überlegen, das wir dann nach und nach durchsetzen. Ich denke - wie auch immer das Schema aussehen soll - der aktuelle Vorschlag geht in “ALLE RICHTUNGEN” Gibt es noch themennahe Erweiterungen des Vorschlags? Ich grüble gerade noch über Möglichkeiten eine Menge gültiger Werte bei einem kategorischen Wertebereich (mal abgesehen davon, dass es bei OSM keine definierten Wertebereiche für Keys gibt) zu setzen. Schlüsselerweiterung wäre dann: “VALUE_SET” oder vielleicht “POSSIBLE_VALUES” oder so. Es soll ausdrücken dass, der Wert zwar nicht bekannt/schwankend ist, aber garantiert nur bestimmte Werte einnimmt, z.B. wenn sich Bodenbeschaffenheit durchsetzt, dass ein Weg in Sibirien entweder Schlammpiste, Staubpiste oder Eispiste ist. = VARIABLE | NOT_KNOWN | ect :VALUE_SET = WERT1;WERT2;WERT3… Leider hat mich in einer anderen Diskussion jemand darauf hingewiesen, dass eine “;”-separierte Wertliste (Wie sie bei ref-Tags verwendet werden kann(?)) in OSM nur als STRING abgelegt wird, und nicht als Werteliste - was die Auwertung dann völlig behindert. MfG Mark
Ich habe eine Frage zur Nomenklatur, also wie denn die Variablen verständlich beschrieben werden können. Wenn ich richtig verstehe: “tag” bedeutet “Eigenschaft” und setzt sich zusammen aus einer *Variable *und ihrem Wert. “key” bedeutet “Schlüssel” und ist der Name einer Variable. “value” bedeutet “Wert” und ist der Inhalt einer Variable. Geschrieben wird sowas beispielsweise als building=yes oder als {{Tag|building|yes}} Bei einer hierarchisch untergeordneten Variable wird der Variablenname zusammengesetzt aus dem Variablennamen der übergeordneten Variable und dem Variablennamen der untergeordneten Variable, getrennt durch einen Doppelpunkt. Beispielsweise: {{Tag|building:addr:housenumber|124}} Könnte man dies nicht als Struktur definieren und diese langen Namen dadurch vermeiden? Und wie werden die zulässigen Werte beschrieben? Und wie der zulässige Bereich der einzelnen Werte? Und wie die Masseinheit? Gruss, Markus
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
Hallo Mark,
Da fände ich gut, wenn Du exemplarisch gleich eine verständliche eindeutige Notation verwendest. Diese Notation könntest Du im Wiki beschreiben. Dann könnten wir sie als Vorlage für alle künftigen Beschreibungen benutzen.
Finde ich gut! Siehe auch: Vorschlag: Qualitätskontrolle-Tag für Tags zentrale Datenbank für Objekte, Schlüssel, Werte und Regeln Willkür bei der Kennzeichnung von Wald Kombination von Schlüsseln das System der Schlüssel HowTo map Schlüssel finden Punkt Line oder Fläche? oder alles zusammen? Korrekte Bezeichnung von Objekten Als “zentrale” und schon recht strukturierte Seite finde ich de:Howto_Map_A Aber da muss dringend eine Datenbank her, damit nicht bei jeder Sortierung eine neue widersprüchliche Redundanz entsteht. Gruss, Markus
Hi Markus: Ok: Ich schlage folgende Struktur vor (im Zweifelsfall von dir übernommen): ============================================== TAG := =-pair, which represents an property of an OSM-objekt || Schlüsselwertpaar, dass eine Eigenschaft eines OSM-Objekts darstellt. := unique name, that specifies the property || Eindeutiger Name, der die Eigenschaft festlegt := a suitable value, which represents the state of the property || Wert, der Ausprägung der Eigenschaft beschreibt. A TAG is written as || Ein TAG wird geschrieben als: = if a suitable is somehow structured, or needs further specification, than an hierachical structured should be intruduced || Ist ein passender Wert () für eine Eigenschaft strukturiert, oder Bedarf näherer Beschreibungen, sollte ein strukturierter Schlüssel () eingeführt werden: : = Based on this structure I propose an set of standardized values for all (ok - let’s say most) TAGs which express a “missing value”, and make it distinguishable from forgotten/missing tags || Basierend auf dieser (gedanklichen) Struktur schlage ich eine Sammlung von einheitlichen Werten für alle (naja für die meisten) TAGs um einen “fehlenden Wert” zu beschreiben und ihn von einem fehlenden TAG zu unterscheiden. … <und dann würde ich den Vorschlag für die Missing Values vorstellen> Ist für die Missing Values noch etwas sinnvolles zu ergänzen? MFG Mark
Finde ich ausgezeichnet! Verständlich, eindeutig, umfassend. Im deutschsprachigen Text würde ich tag=Eigenschaft, key=Schlüssel, value=Wert verwenden, damit auch die deutschsprachigen Texte eindeutig sind. Wir sollten grundsätzlich alle OSM-Begriffe eindeutig übersetzen (laut OSM-Glossar). Gruss, Markus
Hi Markus, Hmmm. Es ist für dich verständlich - allerdings hab ich das Gefühl, dass wir uns leicht auf der gleichen Abstraktionsebene verständigen wollen. Wäre interessant ob ich mich auch verständlich, eindeutig, und umfassend genug für die Mehrheit der User ausdrücke. MfG Mark
Hi Leute, um das Thema mal wieder aufzufrischen. Ich würde gerne ein Proposal erstmal zu den Missing Values gerne ausarbeiten, wenn das noch hier eine hinreichende Zustimmung hat. Den Rest muss denke ich nochmal gründlich durchdacht werden… - Allerdings blicke ich die Proposals-Systematik nicht so ganz Also: 1) Hat jemand noch etwas zu den Fehlenden Werten beizusteuern? 2) Kann mir jemand helfen ein Proposal zu entwerfen? MfG Mark
Gibt es dazu eigentlich schon ein proposal im wiki? Oder irgendetwas zum Thema maxspeed=variable/signals? Ich hab nämlich gestern diese Karte entdeckt, und mir fiel auf, dass es nach aktuellem Schema überhaupt nicht möglich wär sowas zu rendern: http://www.autobahnatlas-online.de/Limitkarte.pdf Die Legende dazu gibts hier: http://www.autobahnatlas-online.de/LegendeLimit.pdf Man müsste also auch bei variablem Maxspeed eine Obergrenze setzen können, also sowas wie maxspeed=80 maxspeed:variable=yes oder so…