[OSM-dev] Restrict key names on order to retain reusability of OSM
gerv-gmane at gerv.net
Fri Feb 15 07:59:48 GMT 2008
Rob Reid wrote:
> The point they are making that you seem to be missing is that one of the
> *basic core principals* of OSM is that anyone, at any time, can tag
> anything they want to put on a map, *using any set of keys and values*
> they want.
Right. But I think he's asking whether the "keys and" part of that basic
core principle is really the important bit.
Clearly, if you say "anyone should be able to tag anything they want",
then values must be entirely unrestricted. But saying that keys have to
be from a small set is a bit like programming language variable names
also being from a small set. There are advantages to this.
I don't care too much either way; but it seems to me that this should be
a pragmatic decision (based on what's easiest for people and tools) and
not a principled one. Values, by contrast, should be UTF-8 and
unrestricted on principle.
> You use building=shop in your examples but there is absolutely nothing
> to stop someone using (apologies in advance for my lack of language
> skills) construcción=almacén or здание=лавка.
Apart from the fact that allowing this just makes the job of a renderer
which wants to render the entire world massively harder, because they
don't just have to learn "highway", they have to learn in in 200
In fact, it's not harder, it's almost impossible. If someone writing a
renderer wants to do China better, they look at the tagging and they see:
<more characters>=<extra characters>
<weird characters>=<single character>
How are they supposed to start making their renderer work with that if
they don't read Chinese?
is a tractable problem.
> The fact that most of the existing data is in english and is using a
> limited character set is just a side-effect of country where OSM began.
> We are just starting to get data being entered in Chinese, Hebrew and
> Arabic (to name just a few recent examples mentioned on talk) and any of
> the people mapping this data could, if they come across something that
> does not directly translate onto an existing key, create their own keys
> in their own language if they so choose.
They could. But one point of the Map Features and Proposed Features page
is to have some consistency between tags _across_countries_. And, like
it or not, the basic Latin character set with Arabic numerals is the one
best understood worldwide. So tags on Map Features for features which
appear in lots of countries are going to (and should) use that subset.
More information about the dev