[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