[OSM-dev] One value per key? Why not one pair per object?

Stefan de Konink stefan at konink.de
Mon Feb 2 02:52:40 GMT 2009

Frederik Ramm wrote:
> Stefan de Konink wrote:
>> What is the motivation to go to the one value per key thing again. 
>> Opposed to unique(objectid - key - value)?
> As a client programmer, I say that unique keys make everything simpler 
> for me. It is much easier to check whether "the highway tag has a value 
> of X" that it is to check whether "one of the highway tags has a value 
> of X". I'm basically shifting some of my burden onto the mappers 
> ("please make up your mind what kind of highway you're tagging").

I agree completely and then you might even be thinking about k='bla' 
v='y' & k='bla' v='z' stuff, I agree it will be a major pain, then 
again, if you keep it simple, it would always be a check if something 
has k=x,v=y render with z.

> If two people each implement a renderer that draws cycleways in blue and 
> footways in red, then it is very likely that an object tagged 
> "highway=cycleway" and "highway=footway" will show up blue on one map 
> and red on the other. It is even possible that the same renderer will 
> sometimes draw it red and sometimes blue...

That is, if we are talking about a 'legacy' renderer. Any new renderer 
will just have to issue priority.

> Key uniqueness robs us of some cool things but we get simplicity in 
> return which is a price worth paying in this particular case, I think.

Using the misused thing called relations we are able to do most of the 
things we want. But if there was a vote I would go for the unique k/v 
thing because of the *non* semantics and *non* duplicates for an amenity 
that is 'both'.


More information about the dev mailing list