[OSM-dev] Restrict key names on order to retain reusability of OSM

Gervase Markham 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 
different languages.

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:

<characters>=<other characters>
<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?

By contrast:


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 mailing list