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

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): <key> = {NOT_KNOWN | VARIABLE} // oder jeder andere fehlende Wert, der Sinn macht <key>:UPPERBOUND = <unterer Wert> // untere Grenze <key>:LOWERBOUND = <oberer Wert> // 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