[OSM-talk] Tagging climbing routes and scrambles

[Christopher Schmidt]

On Thu, Apr 24, 2008 at 12:51:13PM +0100, Steve Hill wrote:
> > piste:lift:occupancy -- wtf? this can only ever happen on a piste:lift
> > right? there is absolutely zero point in this tag.. call it occupancy
> > -- the result is 100% identical. This is purely namespace wanking for
> > the sake of it. It serves no purpose. None. Zip. Nada. The only thing
> > this does is make the tag name very long,
> 
> Of course it serves a purpose - it tells you that the value of the tag 
> describes the occupancy of a lift.  An "occupancy" tag could be used to 
> describe attributes of different types of object - number of people in a 
> building, number of fish in a pond, etc.  Without the name space you need 
> to get the context from somewhere else (one of the other tags... which 
> one?) to make it meaningful.

I think that this is the crux of the entire difference in opinions.
There appear to be two main points of view:
 
 * The tags describe an instance of an object
 * The usage of the tags on an object should be looked at as a whole
 * There is no need for namespacing except in cases where (on a single
   object) the same key can be used multiple times (a la name:en,
   name:cy, etc.)

And the other:
 * Tags are properties in a global namespace
 * A given tag should have a single meaning throughout all of the data;
   if something has a piste:lift:capacity tag, you can tell it is a
   piste:lift
 * There is need for namespacing in order to prevent collisions on 
   tags of the same name on different types of objects.

I can't claim to have the right answer, but I will state that it is not
common in geographic software to have namespaced attributes: in general,
when this is the case, it is a namespace based only on the object type
which has a specific schema. (In this case, that would be something like
pisteLift, since the dataset would be a list of pisteLifts.) That use
case can be trivially built up when it's needed based on the other data
in the OSM database.

I don't really understand why there is a need to have a global
definition that a given 'key' has a specific meaning in all contexts,
which appears to be the reason for namespacing. It seems to me that
creating 'object' definitions that describe objects and their
common/useful keys would be most useful from a 'geo' point of view. 

I can give more examples of what I mean by this if it's
neccesary/helpful.
   
Regards,
-- 
Christopher Schmidt
MetaCarta