Ich finde das eine ganz spannende Diskussion! Dabei tauchen bei mir zwei grundlegenden Fragen auf: Formulierung von Regeln Angenommen, wir definieren für alle Attribute, in denen Werte als String oder als Zahl eingegeben werden können (Beispiel: {{Tag|name|}} oder {{Tag|maxspeed|#}} ein weiteres genau definiertes Daten-Set, das das Nicht-Vorhandensein von “richtigen” Daten beschreibt (Beispiel: “_NO_DATA”, und alle für die wir uns noch entscheiden werden) inclusive der kann/soll/ist/muss/darfnicht-Bedeutung der einzelnen Werte Beispiel: alle “_NO…” beginnen mit einem Unterstrich. “_NO_DATA” = obwohl dieser Wert für die meisten Objekte dieser Objektklasse vorliegt, ist er für dieses Objekt nicht vorhanden und das ist eine zulässige Ausnahme, also kein Fehler) Wie beschreiben wir diese Regeln eineindeutig? Wo speichern wir solche Regeln? In welchem Format? Wie werden sie, daraus abgeleitet, für verschiedene Sprachen verfügbar gemacht? Die Regeln müssen ja für jede Anwendung (Renderer, Routing, Datenset-Kombinationen, Statistik, etc) unmissverständlich und zentral und maschinenlesbar zur Verfügung stehen. Daraus ergibt sich die zweite Frage: Maschinenlesbarkeit und Regel-Validität In {{Tag|note|}} wird ja alles (oder nichts) hineingeschrieben, was “irgendwie” interessant ist. Alles Interessante sollte aber möglichst maschinenlesbar zur Verfügung stehen. Gibt es eine Arbeitsgruppe, die diesen Tag (und andere Tags) auf Maschnenlesbarkeit und Stringenz der Regelformulierung prüft? Gruss, Markus
Hallo Markus, ich bin mir nicht ganz sicher, wo dein konkretes Problem liegt. Die Frage WIE mit einem fehlenden Wert umgegangen wird, ist eine Frage der Zielsetzung der Software. Die Regeln sind dementsprechend von den Entwicklern der Software passend zum Anwendungszweck darzustellen. Ich kann garnicht überblicken, welche Software sich später an den Daten zu schaffen macht. 
Was die Maschinenlesbarkeit angeht - ich kenne nicht alle ISO- und DIN-Normen in denen Missing-Values beschrieben sind. Aber ich wette, dass es keine gibt, die unsere differenzierte Sicht voll abbildet. Es bleibt also wieder nichts anderes übrig, als sich selbst ein Schema auszudenken und zu DEFINIEREN. Das bedeutet das, jenes bedeutet jenes. Wir können uns ein Layer dazwischen stricken, indem wir sagen wir, den “VALUE” auf eine Zahl oder was auch immer abbilden. Aber ich sehe nicht wie wir den Anwendungsentwickler helfen können, außer klar für die TAGGER zu beschreiben was ein Wert bedeuten soll. MfG Mark
Hallo Mark, das habe ich glaub schon verstanden. Aber die Anwendungsprogramme können ja höchstens so gut sein wie die Daten, die sie nutzen? Also deren Wahrhaftigkeit und Sinnhaftigkeit einerseits, und deren Strukturiertheit andererseits? Was mir fehlt ist eine Art “Ontologie”, eine Definition darüber was “gilt” und was nicht und wenn ja wie, die irgendwo in einer DB steht und benutzt (und weiterentwickelt) werden kann. Natürlich wollen wir uns nicht an Normen binden, sondern das für OSM optimale Schema entwickeln. Aber auch dieses sollte (zumindest im Kern, sagen wir mal >80%) definiert und definitionsgemäss implementiert sein? Gruss, Markus
Eine Ontologie müsste KEYS und Objekthirachien für die diese KEYS anzwenden sind, mit gültigen Spezial- und Ausnahmewerten verbinden, und so bedeutungstragende Informationen einfügen. Dafür müssten wir ein Gesamtschema haben, dass ca. mehr als deine 80% aller Tags, Objekrelationen usw. enthält. Das ist der Große Wurf und irgendwann muss der getan werden (oder er muss sich evolutionär ergeben). Dem Gegenüber steht, dass wir erstmal überhaupt standardisierte Werte für “kein Wert vorhanden - und zwar, weil…” einbringen sollten, um ein Bewusstsein für solche generelle Strukturen in die Community zu bringen Und die Disziplin sie auch anzuwenden. Dem Großen Wurf auszuarbeiten geschweige denn durchzusetzen, trau ich mir kaum (im Rahmen der Einführung von definierten Missing Values) zu. Ich schätze man bräuchte ein Expertenteam von Kathographen (verschiedener Regionen), Knowledge-Engineering-Experten, Datenbankspezialisten… g Die Dinge müssen getan werden - die Frage ist: Wollen wir parallel das bestehende Schema verbessern (und damit auch leichter überführbar zu machen). MfG Mark
klar! - und Dein Vorschlag ist ein konkreter wertvoller Beitrag. Zum Rest melde ich mich bei Dir per Mail. Gruss, Markus
Zusätzlich schlage ich die Modifikatoren für Zahlenwerte vor (genaue Syntax wie immer vorbehalten): AT_LEAST (WERT) = Es ist mindestens der Wert WERT LESS_THAN (WERT) =Er ist niedriger als Wert WERT BETWEEN(WERT1,WERT2) = Er liegt sicher zwischen WERT1 und WERT2 Alternative: :<keymodifikatoren/Spezialisierungen>…:LOWERBOUND = WERT1/NO_VALUE :<keymodifikatoren/Spezialisierungen>…:UPPERBOUND = WERT2/NO_VALUE NO_VALUE wenn keine Grenze exisitert. Wird zusammen mit :<keymodifikatoren/Spezialisierungen>… = <Generischer Missing Value; zb. UNKNOWN oder VARIABLE> getaggt. MfG Mark
Hallo MADetter, so eine ähnliche Idee hatte ich auch gerade. Vielleicht könnt ihr mich hier unterstützen. http://wiki.openstreetmap.org/index.php/Proposed_features/maxspeed_none Gruß Lulu-Ann
Hallo Lulu-Ann, Ich unterstütze deine Idee voll und ganz - allerdings ist sie ein Spezialfall von der Idee, die wir hier diskutieren. Magst du nicht lieber deine Idee zurückziehen, und mit uns zusammen einen kompletten Vorschlag für fehlende Werte ausarbeiten? Weil Spezialfälle könnten dann später ein integriertes Konzept erschweren. Wenn du auf deinem Spezialfall bestehst werde ich ihn aber gerne unterstützen. MfG Mark
Hallo an alle, gibts noch welche Anmerkungen, Ergänzungen oder Ideen zu diesem Thema? Wenn nicht würde ich euch noch um euere prinzipielle Meinung (dafür/dagegen) bitten; und dann am Wochenende den Vorschlag in die Community zur Beratung/Abstimmung bringen. MfG Mark
Was maxspeed angeht sollten auch die variablen Geschwindigkeitsbegrenzungen berücksichtigt werden… Also maxspeed=variable oder so…
Hallo Mark, ich freue mich über jede Präzisierung von Schlüsseln und den für sie zulässigen Werten! Hilfreich finde ich, wenn die zulässigen Werte auch in deutscher Sprache beschrieben sind, damit keine Verwechslungen stattfinden (so wie Du das bereits machst). So wie ich das System der Schlüssel bisher verstanden habe, gibt es innerhalb der Schlüssel keine Hierarchie, sondern es werden alle einfach “aneinandergereiht”? Und in dieser Aneinanderreihung ist die Reihenfolge nicht geregelt - alles wird sozusagen “auf einen Haufen geschmissen”. Wenn das so ist, fände ich gut, wenn es eine Möglichkeit gäbe, die Schlüssel hierarchisch zu ordnen. Beispiel: Wenn ein Wert für “Strassenbreite” oder “Höchstgeschwindigkeit” angegeben wird, dass dieser dann untergeordnet spezifiziert werden kann: ob der Wert festgeschrieben ist, oder minimal, maximal, für eine bestimmte Tageszeit gilt. Wenn eine Fläche als {{Tag|building|residental}} bezeichnet wird, dann könnte man die Adresse als Subset aus Strasse und Hausnummer darunter packen. Wenn ein Punkt als {{Tag|man_made|lighthouse}} bezeichnet wird, dann könnte man die Daten als Subset aus Höhe_des_Turmes, ist_in_Betrieb und wie_blinkt_das_Ding darunter packen. Gruss, Markus
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…