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

Dave Stubbs osm.list at randomjunk.co.uk
Tue Feb 3 22:14:21 GMT 2009


2009/2/3 Matthias Julius <lists at julius-net.net>:
> Stefan de Konink <stefan at konink.de> writes:
>
>> 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...
>
> Hey, you just said yesterday that the API doesn't care whether the
> tagging makes sense.  Why should it care in this case?  One can always
> tag something "highway=cycleway;footway".  This is equally dumb.  The
> difference is that it probably won't show up on any map.
>

It shouldn't.
But that doesn't mean the API should support every
not-the-easiest-way-of-programming-it feature now does it? :-)

And I should probably point out at some point that it isn't a good
idea to try and use the same key more than once in API 0.5. There's at
least a couple of things that have been refactored at some point and
now probably won't work with duplicate keys. Saving ways to the
history being one of them, and using the API to set them being
another. Both probably still work on nodes.

Basically API 0.5 doesn't really support duplicate keys after all,
although nobody seems to have noticed, so meh. At least 0.6 will make
it official. :-)

Dave




More information about the dev mailing list