Bernd Wurst wrote:
>> Ich bin dafür, dass die keys nur aus Kleinbuchstaben bestehen. Hier zu
>> viele Sonderzeichen zu erlauben erzeugt doch nur Verwirrung.
>> Brauchen wir diese Freiheit wirklich?
> Ich bin dafür, dass jeder, der die Daten nutzt (und folglich weiß, ob er
> case-sensitive Infos erwartet) einfach ggf. ein "lower()" [je nach Sprache]
> aufruft. Das schränkt niemanden ein und löst das Problem auch.
Du entwickelst keine Software, oder?
Das Problem ist, dass die Schnittstellen definiert sein müssen, bzw. das
genaue Format der Daten. Die Semantik muss klar sein.
Beispiel:
Wenn ein Programm "building=yes" verarbeiten kann, dann kann nicht
einfach ein "Building=yes" gleich behandelt werden. Das Programm (bzw.
der Autor) kann nicht wissen was "Building" bedeutet. Es könnte sein,
dass dieser Key dazu verwendet wird um öffentliche Gebäude zu
kennzeichnen, damit diese in einer Spezialkarte farblich anders gezeigt
werden.
Wenn "Building" bekannt ist, dass es eine andere Bedeutung hat als
"building", das der Autor weiß und es nur gleich behandeln will, dann
wird er auch genau nach diesen beiden Strings suchen. Es könnte ja mal
jemand auf die Idee kommen den Key "BUilding" zu erfinden, der dann noch
eine ganz andere Bedeutung hat.
Ein Lösungsvorschlag war so eine Art Alias-Tabelle.
Meine Idee wäre es Namespaces einzuführen. Diese können einen Satz von
Schlüsselwörtern definieren denen auch eine eindeutige Bedeutung
zugeordnet werden kann.
Das würde auch die MapFeatures-Problematik beenden.
Alle die einen "Starken Führer" wollen einigen sich auf einen Namespace
der von diesem spezifiziert wird, andere verwenden einen Namespace
dessen Bedeutung sie in demokratischen Gremien definieren. Und andere
verwenden einfach keinen Namespace weil es ihnen nicht frei genug ist.
Die API müsste dazu jedem Element einen/mehrere Namespace(-Identifier)
zuordnen können.
Auf Tag-Ebene könnte das ein weiteres Attribut sein ("n" für namespace).
Ein Node könnte dann solche tags haben
<tag n="osmf-namespace" k="name" v="eine Bedeutung für name" />
<tag n="fossgis-namespace" k="name" v="andere Bedeutung für name" />
<tag n="incubation" k="neuerKey" v="exotischer Schlüssel" />
Editoren/Renderer blenden die Namespaces aus, die sie nicht
anzeigen/editieren wollen, bzw. wählen die Namespaces deren Semantik sie
kennen.
Ein Renderer mit der Intelligenz eines HAL 9000 kann auch einfach alles
nehmen und erkennen was der Nutzer gemeint hat als er einen neuen Key
erfunden hat ;)
Stephan
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
