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

Rob Reid rob at robreid.co.nz
Fri Feb 15 06:56:54 GMT 2008

Stefan Keller wrote the following on 15/02/2008 12:57:
> I perhaps should have introduced myself before hand, before making 
> such an "demanding" proposal - which irritating too, because in fact 
> this would have almost no implication for mappers and on the current 
> database.
> I think I made my points (c.f. my posts on 12.02.2008 14:27 and 
> 13.02.2008 09:47). But see below for another attempt.
> This specific use case shows that because of my proposal the whole 
> thing scales up, needs less space, is easier to query and to program, 
> and it's lossless(!) when sync'ing back some data. And you get all 
> this for free and - as I said before - without compromising the 
> freedom of mappers values.
Stefan, at the risk of oversimplifying your position what you are 
proposing from my point of view is that by restricting the range of keys 
and the range of characters used in keys would make things easier for 
developers and make OSM more industry standard.

I sure most of the developers on this list completely understand the 
point you are making and would agree that doing what you suggest would 
make their lives easier.

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.
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 здание=лавка.
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.
Does this make things more difficult for our developers? Of course it 
does, they are aiming at a moving target. The people maintaining the 
editors and renderers are having to add new keys constantly. Why do they 
do it? Because it is one of the *core principals* of OSM, they have been 
coding to allow it from the start.

So while you are saying 'make this simple technical change which will 
have little effect and your life will be easier', in OSM terms what you 
are actually saying is 'reduce your ability to deliver on one of the 
core principles of your project for relatively minor technical reasons'.

I'm afraid just restating your proposal multiple times is going to have 
little effect, you would need a much more compelling and probably 
non-technical argument to make people re-consider this principle.



More information about the dev mailing list