In der Diskussion: http://forum.openstreetmap.org/viewtopic.php?id=1227 trat die Frage auf, wie man fehlende (nicht eingetragene) Straßennamen von Straßen ohne Namen unterscheiden kann. Ein Vorschlag war, einen Wert für “Wert existiert nicht” zu definieren und zwar nicht nur für Straßennamen sondern für alle Tags. Ich halte es prinzipiell für sinnvoll solche Standardwerte einzufügen. Darum stelle ich in erster Näherung folgende “Values” für tags zur Diskussion und bitte auch weitere sinnvolle Werte vorzuschagen. Die genaue Schreibweise ist natürlich erstmal egal, und kann bei Bedarf angepasst werden. 
A) MISSING VALUE (“Kein Wert”): ====================== NO_VALUE: “Es ist bekannt, dass kein Wert existiert” NOT_KNOWN: “Der Tagger hat versucht, den Namen/Wert rauszufinden, aber hat keinen Anhaltspunkt gefunden” VARIABLE/NOT_FIXED: “Es ist bekannt, dass sich der Wert ändert” (Eine Furt über einen Bach der nur in Frühling und Herbst Wasser führt z.b.?) RESTRICTED: “Es ist aus sicherheitsrelevanten/gesetzlichen Gründen untersagt, diese Information zu veröffentlichen” HIDDEN: “Es ist aus gesetzlichen ect. Gründen FÜR DEN Tagger nicht möglich gewesen, diese Information zu erheben” PRIVACY: “Es ist zum Schutz der Privatsphäre nicht möglich diese Information zu veröffentlichen” TO_DO:USERNAME/DATE: “Der User hat sich fest vorgenommen, das noch in nächster Zeit in Angriff zu nehmen, und es bis spätestens DATE erledigt zu haben” Vielleicht noch: INVALID_SCHEME: “Aus irgendwelchen unerfindlichen Gründen passt ein Standard-Tag/Relation nicht zu dem Objekt (für das der Tag/Relation gedacht war)” (Keine Ahnung - obs sowas geben kann - aber wenn könnte man darauf aufbauend gezielt Fehler im Tagging-Schema finden, die bei der Einführung des Tags nicht bedacht waren). Ein fehlender Tag bedeutet dann, dass sich die bisherigen Tagger nicht darum gekümmert haben, vielleicht weil sie den Tag nicht kennen oder nicht soweit in die Details gehen wollen. B) ERGÄNZUNGEN BEI NUMERISCHEN WERTEN: =============================== Falls man zwar keine sicheren Werte angeben kann, aber vielleicht einen Bereich oder eine obere oder untere Grenze angegeben werden kann, sollte das vermerkbar sein (zum Beispiel bei Unterführungen, die keine Höhenangabe haben, oder bei der obligatorischen Furt durch einen Bach, der unregelmäßig Wasser führt): = {NOT_KNOWN | VARIABLE} // oder jeder andere fehlende Wert, der Sinn macht :UPPERBOUND = // untere Grenze :LOWERBOUND = // obere Grenze LOWERBOUND und UPPERBOUND sollten IMMER zusammen getaggt werden - falls kein oberer/unterer Wert exisitiert wird dieser mit NO_VALUE getaggt, bei nicht bestimmbaren, mit NOT_KNOWN. VARIABLE sollte LOWERBOUND und UPPERBOUND erzwingen. Andere “missing value”-Arten nur bei Bedarf. C) PRÄFIX ZUR UNTERSTÜTZUNG DER NUTZENDEN SOFTWARE: ========================================= Wie die Software welche Werte darstellt ist schwierig vorrauszusagen und hängt von den KEYS und dem Ziel der Anwendung ab. Um bestehende Software auf die weite Verbreitung der vorgeschlagenen Standardwerte leicht abstimmen zu können, wird vorgeschlagen PRÄFIXE zu verwenden, die sicherstellen, dass die Standardwerte keine für den (= JEDEN) KEY gültigen Werte darstellen und eindeutig als Metainformationen verstanden werden. Renderer z.b. könnten diese Werte ignorieren (bis sie bestimmte key-Standardwertkombinationen gezielt darstellen). Als Präfix schlage ich in erster Näherung: “__” vor. ------------------------------------------- Da ich noch ganz neu bin, kenne ich nicht das Verfahren für eine Einführung für die ganze Community - aber darüber kann man sich ja kümmern wenn hier Bedarf gesehen wird. MfG Mark Edits: FR 8.8. 19:45 - Ergänzung des Vorschlags: LOWERBOUND und UPPERBOUND sowie Präfixe
Hallo Mark, finde ich hervorragend! sehr gut strukturiert und ausgearbeitet. Gruss, Markus
Jo, Zustimmung. Grüße René
Ok, dann also mal zur Sache. Ein Grundproblem mit diesen Werten ist natürlich, dass jeder Renderer, Router, … – jede OSM-Daten nutzende Anwendung eben – wissen muss, was sie bedeuten. Sonst sagt der Router ein „Folgen Sie TODO Tordanik Zweitausendacht null-acht zehn für fünfhundert Meter“ an, was wir nicht wollen. Natürlich sollte auch sichergestellt sein, dass nie ein echter Wert mit unseren Pseudowerten identisch ist. Vorschlag für beides: Wert mit einem Unterstrich (_) beginnen, also etwa _NO_VALUE. Gründe: * Das dürfte kaum in einem realen Straßennamen o.ä. vorkommen. * Man muss seinem Programm nur einmal beibringen: Unterstrich => kein echter Wert. Damit ist auch abgedeckt, wenn jemand noch einen neuen Wert dieser Art erfindet. * Wenn der Editor (wie JOSM) Autovervollständigung kann, bekommt man gleich die entsprechende Auswahl. Zu den Einzelwerten:
Zustimmung.
Da weiß ich nicht, ob das wirklich so viel bringt. Das kann man doch als note-Tag reinschreiben, den Anwender interessiert das ja nicht. Dagegen bin ich nicht direkt.
Kannst du dafür einen konkreten Anwendungsfall mit Tagging bringen? Bei allem außer yes/no-Werten ist es außerdem etwas unklar, was es bedeutet. Kann jeder denkbare Wert sein? Kann eine Teilmenge von Werten sein – und zwar welche? Bei der Furt würde ich mir doch lieber irgendwas aussagekräftigeres überlegen, was soll die Software denn sonst damit anfangen? Anzeigen? Nicht anzeigen? Beim Routing ignorieren oder nicht? Für meinen Geschmack nicht hinreichend ausgearbeitet.
Mh, die „das wollen/dürfen wir nicht eintragen“-Werte … würde ich ggf. lieber separat vorschlagen, das ist eine ganz andere Baustelle mit anders gelagertem Konfliktstoff.
Zustimmung.
Ähm, da sollte man sich vielleicht besser eine Lösung ausdenken oder es beim Note belasen. Die Fehler im Tagging-Schema meldet man lieber in der Diskussion zum jeweiligen Tag, sonst bekommts ja doch keiner mit, zumal die Leute sonst ja nicht wissen, worum es sich in der Realität handelt und warum die Tags nicht passen.
Allgemein: Ja wir müssen uns irgendwas überlegen, was auf keinen Fall ein Gültiger Wert sein darf: vielleicht ein “::” oder “!!” als Präfix oder so. zu VARIABLE: Ich glaube es gibt zum Beispiel einen Tag der die Tiefe eine Furt angibt (wenn nicht sollte es ihn geben) - bei dem oben besprochenen Bächlein dass nur zu bestimmten Jahreszeiten Wasser würde kein Wert angegeben werden können der mehr als ein 1/4 Jahr vorhält - da wäre VARIABLE zusammen mit einer note hilfreich. Das Problem ist, dass man nicht generell für jeden Tag sagen kann, ob eine Wertetabelle sinnvoll ist oder spezielle Werte oder eine MIN-MAX-Variante. Für Tags, bei denen das Sinnvoll ist müssten dann entsprechende Zusatzinformationen setzen können (durch ergänzende Tags?) - Selbst dann wäre aber für diese Tags die VARIABLE-Kennung sinnvoll, die dem auswertenden Programm sagt, dass es Ergänzende Informationen nutzen soll. Und bei der späteren obligatorischen Vervollständigung der Karte wird der Tag mit dem Wert Variable nicht vermisst. zu NOT_KNOWN: zu RESTRICTED, HIDE und PRIVACY: Ziel dieser Werte ist es zu beschreiben warum ein Wert fehlt. Wann man welchen Wert setzt ist eine Diskussionssache. Aber wenn man einen Wert nicht setzt sollte es eine Information geben dass es Gründe gab. Unterscheidet einen fehlenden Wert von einem schwer zu erhebenden Wert. Die Gründe dafür können in eine note. zu INVALID_SCHEME: Selbe Gründe wie bei RESTRICTED ect. Zusammenfassend: Ziel dieses Vorschlages ist es, eine gute Beschreibung für fehlende Werte zu bekommen. Bei dem Aufbau von Datensammlungen ist das “Missing Value”-Problem oft essenziell. Warum GENAU die Daten fehlen sollte dringend natürlich in “note” oder sonst wie hinterlegt sein. Denken wir mal an eine spätere Phase - fast alles ist erfasst. Es fehlen aber etliche Werte. Sind die Gründe dafür nur in Notes hinterlegt bräuchte man ein ziemlich cleveres Programm zu Erkennung von natürlichsprachlichen Systemen zu sein um eine TO-DO-Liste zu erstellen. Stattdessen könnte man auf Basis dieser verschiedenen Werte für “Wert fehlt” schnell die Fehlenden Informationen zusammenstellen und motivierten Taggern zur Verfügung stellen (z.b. für NOT_KNOWN), andere könnten ihre Telefonflatrate verwenden um Genehmigungen für HIDE (eventuell auch für RESTRICTED)-Tags zu bekommen. Eine Ansammlung von INVALID_SCHEME kann Hinweise auf die Dringlichkeit der Überarbeitung bestimmter Flags führen… Würde man diese Dinge nur über Kommentare und Hinweise versuchen abzuhandeln würde es schwer machen, die Dinge in späteren Phasen des Projekts effizient zu handhaben. Ist aber nur meine Meinung. MfG Mark
Nun, es sieht so aus, als müsstest du – wenn du das umgesetzt sehen willst – ein Proposal im Wiki erstellen (kann gerne als Draft anfangen und Dinge wie das Präfix zur Diskussion oder Abstimmung stellen). Auf der Mailingliste hat nämlich gerade „Lulu-Ann“ ihren Vorschlag http://wiki.openstreetmap.org/index.php/Proposed_features/maxspeed_none vorgestellt. Ich habe zwar schon mal auf unsere Diskussion hier verwiesen, aber ohne Präsenz auf (idealerweise englischsprachiger) ML oder Wiki wird man das nicht etabliert bekommen. Das Forum ist eine Randgruppe.
Hallo Tordanik, Ja wäre cool, wenn du das Proposal in die Hand nehmen würdest. Ich bin noch nicht so firm in der Community. Oder wollen wir noch ein wenig hier bearbeiten/uns Meinungen holen? Wenn du denkst, das lohnt nicht zwingend, mach das bitte mit dem Proposal! MfG Mark (Das soll aber niemanden davon abhalten hier noch weitere Ideen zu posten insbesondere was man außer fehlenden Werten noch in allen (vielen) Tags gebrauchen könnte)
Ich selbst bin ja nur von einem Teil der Werte überzeugt, und zumindest der Verantwortliche eines Proposals sollte m. E. 100 % hinter der Idee stehen. Ein Proposal ist ja auch kein Hexenwerk. Als Einstiegspunkt einfach mal die Erläuterungen auf http://wiki.openstreetmap.org/index.php/Proposed_features lesen, dir ein paar dort verlinkte Beispiele anschauen[1], einen OSM-Wiki-Account mit deinem OSM-Benutzernamen anlegen (falls du noch keinen hast) und loslegen. Bei Fragen zum Vorgehen oder Unklarheiten einfach im Forum, per Mail an mich oder sonstwie erkundigen. Oder: Ruhig angehen, weitere Kommentare hier abwarten, Ideen reifen lassen (ich hab schon einige erst gut scheinende Ideen nach ein paar Tagen Bedenkzeit wieder verworfen), noch ein paar Wochen mehr Mapping-Erfahrung sammeln – das macht mehr Spaß als die „Politik“, glaub mir –, Mailingliste(n) abonnieren und zusehen, wie ein paar andere Proposals ablaufen. Danach mit den obigen Schritten weitermachen. Ich wollte oben keineswegs den Eindruck erwecken, es müsse jetzt sofort gehandelt werden. Das einzige, woran wir nicht rütteln können, ist: Da Softwareänderungen erforderlich sind, muss die Idee an die Entwickler, und die hängen hier normalerweise nicht rum. Absolut zeitkritisch ist das aber sicher nicht. [1] z.B. mein neuestes Proposal – zu einem eher trivialen Thema – hier: http://wiki.openstreetmap.org/index.php/Proposed_features/Number_of_steps
Hallo Tordanik, ich gebe dir völlig recht - eine “Standardisierung” für fehlende Werte ist nichts was hau-ruck durchgesetzt werden soll (oder ich schätze mal kann). Allerdings hab ich mal ein wenig bei Tagwatch geschaut und oft Markierungen von “missing values” (none, no_name, missing, todo, ect.) gesehen. Ich weiß nicht wie Renderer und andere Software, die auf die Karte zugreifen, damit umgeht. Also Bedarf ist schon da - naja gut. Warten wir noch auf die Meinungen anderer und diskutieren ein wenig. MfG Mark
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