On Thu, Apr 24, 2008 at 9:47 AM, Steve Hill <[EMAIL PROTECTED]> wrote: > On Thu, 24 Apr 2008, Ari Torhamo wrote: > > > on the other hand because some of the argumenting has been based on > > how the use of namespaces would affect the inexperienced OSM:ers - like > > me. > > Thanks for your input - you're *exactly* the sort of person we need to > hear from, rather than reasoning on a purely technical level or making > assumptions about how good/bad things are for inexperienced people. > > > > I had to go to > > Wikipedia to find out what a namespace stands for > ... > > > I do understand the idea of a namspace > > now, but I would need to know more about the practical implementation to > > know if using namespaces would feel too complicated to me. > > Well, it is important to realise that there is no real need to know what a > namespace is to use namespaced tags, and there isn't really any > implementation as such - it is purely a convention for tag names. So > instead of having a tag such as "grade", which is fairly meaningless > without further context (which is provided by the other tags on the node), > you call the tag "climbing:grade", making it really obvious that it is a > climbing grade (i.e. how difficult the climbing route is). Nothing is > different, other than the tag name. > > In my view, this simplifies things since it makes tags unique - you know > that "climbing:grade" is always going to be a climbing grade and you need > no further information to do things like look up the definition of the tag > on the wiki. > > For people who don't know or care what a namespace is, this is really no > different from the existing system - you want to tag something so you look > it up in the wiki to see what the convention is and the wiki tells you > what tag name to use.
There a couple of scenarios where you might want them: a) We have tags that mean two different things under different contexts. This is really easy to resolve. I've seen some random arguments in this thread already about context but it comes down to this: either you're a human in which case most of the time you'll engage your brain and figure out what makes sense... or you're a computer in which case some nice human has programmed you with the relevant domain knowledge, so you know that highway=climbing happens to be what you're looking for. Confusing good tag naming with adding namespaces doesn't help. b) You want to give specific information about a specific topic, but on a general feature. ie: whitewater:description came up on the wiki. This can easily be read as whitewater_description... it's not really a namespace so much as a longer tag name. The other place this happens might be with ref, or name... if I have a cycle route on a primary road for instance: a real world scenario we use highway=primary, ncn_ref=4, ref=A219, name=Putney Bridge. ncn_ here can effectively be seen as a namespace (although not being called one). Frequently this isn't a particularly comprehensive solution -- in the case of the cycle route, what happens if another cycle route goes over the same road? So for this use case we're tending towards relations. Now lets look at some of the places where namespaces, motivated by the desire to use namespaces have actually been suggested/used: piste:lift -- fine, makes sense as piste_lift too, is a description of a unique feature type. You might be able to get away with lift, but frankly life's too short to worry about that one. 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, and add a pile of annoying colons. climbing:rock -- omg! just what other type of rock is there exactly? It's a flipping rock, nobody gives a monkey that you intend to climb it, limestone is still limestone. Plus it's on a climbing route so people might just get the idea that you're interested in the rock type for a reason. climbing:length -- just what exactly do you think we were measuring? length is length. it's the length of the feature you're tagging, and the namespace adds nothing. So why is it necessary to type this stuff? Your average user is quite happily going to type exactly what you tell them to. The chance of them remembering the key is probably reduced, and the chance of them thinking it's ok to come up with new unnamespaced tags is also reduced which will either mean they won't propose things or else they'll attach meaningless drivel to the start of every tag as a substitute. The chance of someone putting up a proposal getting spammed by people who like typing is also massively increased. And worst of all? You'll wear out my colon key. Complexity-wise I'm actually not that worried -- I think people will just see it as irrelevant text they've been told to add. They'll probably just start using cut'n'paste more (thus getting lots more random spaces). I'm much more worried about the completely bogus technical arguments I've seen people put forward for this. I'm convinced that you guys have been told namespaces are great and will stop your kittens getting run over by lorries, so are desperately trying to save your kittens by increasing the colon density of the planet. Ho hum, rant over, Dave _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk