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

bvh bvh-osm at irule.be
Fri Feb 15 10:20:15 GMT 2008


On Fri, Feb 15, 2008 at 07:59:48AM +0000, Gervase Markham wrote:
> 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.

It is supposedly 'easier' for developers. But clearly not for our
current set of developers (me being one of them)

> 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.

No one is proposing that everyone should use his/her localized term for
highway as the keyname for 'highway'.

But what we are saying is that if you want to add highly local
information (like for example a type of jurisdiction that only exists
in your country), that you can then use the language that is most
convenient for that case as the keyname, possibly including non-ascii.

> By contrast:
> name=<characters>
> authority=<characters>
> highway=yes
> is a tractable problem.

Yes, and no one is proposing that those should become

naam=
authoriteit=
wegtype=

in the Netherlands.

What we are saying is that in the Netherlands we are free to add
a key for a very specific authority dealing with matters of water
level management with the name

waterschap=aa en maas

Now this keyname does not happen to use accents, but I can easily
image the same thing in Poland, China or Russia where the need for
a local key with non-ascii<127 characters is needed.

> 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.

And again: this thread has NEVER been about things that exists
everywhere and consistency is feasible. Yes, let's keep those in
English by all means. Our concern has always been local unicity...

cu bart




More information about the dev mailing list