Vorschlag: Einführung von Standard Tag-Values für fehlende Werte ect.

Tordanik · 2008-08-06T13:38:54.000Z

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:

NO_VALUE: “Es ist bekannt, dass kein Wert existiert”

Zustimmung.

NOT_KNOWN: “Der Tagger hat versucht, den Namen/Wert rauszufinden, aber hat keinen Anhaltspunkt gefunden”

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.

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

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.

RESTRICTED […] HIDED [sollte besser „HIDDEN“ heißen?] […] PRIVACY

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.

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”

Zustimmung.

INVALID_SCHEME: "Aus irgendwelchen unerfindlichen Gründen passt ein Standard-Tag/Relation nicht zu dem Objekt (für das der Tag/Relation gedacht war)

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

MADetter · 2008-08-06T13:54:21.000Z

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

Tordanik · 2008-08-06T16:21:13.000Z

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.

MADetter · 2008-08-06T16:55:03.000Z

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)

Tordanik · 2008-08-06T22:02:00.000Z

Ja wäre cool, wenn du das Proposal in die Hand nehmen würdest. Ich bin noch nicht so firm in der Community.

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

MADetter · 2008-08-07T06:22:09.000Z

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

Markus_B · 2008-08-07T07:33:05.000Z

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

MADetter · 2008-08-07T08:02:26.000Z

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

Markus_B · 2008-08-07T10:18:45.000Z

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

MADetter · 2008-08-07T10:37:11.000Z

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

Markus_B · 2008-08-07T10:48:30.000Z

MADetter:

das bestehende Schema verbessern

klar! - und Dein Vorschlag ist ein konkreter wertvoller Beitrag. Zum Rest melde ich mich bei Dir per Mail. Gruss, Markus

MADetter · 2008-08-07T11:30:44.000Z

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

Lulu-Ann · 2008-08-07T11:44:56.000Z

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

MADetter · 2008-08-07T12:08:55.000Z

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

MADetter · 2008-08-13T16:18:56.000Z

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

TEL0000 · 2008-08-13T19:50:57.000Z

Was maxspeed angeht sollten auch die variablen Geschwindigkeitsbegrenzungen berücksichtigt werden… Also maxspeed=variable oder so…

Markus_B · 2008-08-14T06:16:56.000Z

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

MADetter · 2008-08-14T08:26:54.000Z

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

Markus_B · 2008-08-14T09:13:48.000Z

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

MADetter · 2008-08-14T10:32:31.000Z

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