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

Matthias Julius lists at julius-net.net
Tue Feb 3 19:03:13 GMT 2009


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.

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

I would say relations are not misused, they are misnamed.  They should
have been named "object" and a relation would only be one kind of
object.  Then everything could be made into an object that references
ways and/or nodes.

Matthias




More information about the dev mailing list