Steve Hill [mailto:[EMAIL PROTECTED] wrote: >Sent: 23 April 2008 11:37 AM >To: Andy Robinson (blackadder) >Cc: 'OJ W'; 'OSM Talk' >Subject: RE: [OSM-talk] Tagging climbing routes and scrambles > >On Wed, 23 Apr 2008, Andy Robinson (blackadder) wrote: > >> The point has been made by others that the namespace here is unnecessary. >We >> know what length= means here so the climbing namespace is superfluous >> because what you are tagging is a climbing route. > >I'm aware the issue is contentious, but no one has said anything to >convince me that namespacing isn't a good thing (certainly nothing showing >why it is a bad thing). > >> Start to end of section as one way (there may be more than one section in >> the route, some climbing and some scrambling etc). > >I had considered specifying that each pitch (section) must be a different >way, but concluded that it probably made things unnecessarilly difficult >since you'd end up with a big cluster of nodes and ways in a very small >(horizontal) area. Of course, there is nothing stopping people from >sticking nodes in the middle of the way if that is sensible for specific >routes (i.e. ones with a large horizontal component). > >> climbing routes are no different. > >They are different in the fact that they have a much greater vertical >component and a much smaller horizontal component to almost any other OSM >features, which makes handling the data in a 2D environment (such as JOSM, >Potlatch, etc) more difficult. This certainly needs to be taken into >consideration. > >> adjectival:gb= (assuming the same route at the same location requires >> alternative country grading, if it only applies within the country where >the >> route is located then the gb would not be required) > >Only the British system has the separate adjectival/technical grades - >other systems have a single grade to describe the route (the exception >being YDS, which has 3 separate grades to describe different aspects of >the route). > >It is common to list several different grading systems for the same route >as well - for example, in the UK, sports routes are often given grades for >both the British and French grading systems. > >> Anything that has lots of namespaces, abbreviations or other non-obvious >> tagging names makes it much more difficult for data contributors to >easily >> add tags. > >On the contrary, namespaces make it easier to look up the definitions of >tags, etc. since there is no chance of being confused with identical tags >from a different context. I really dislike the way that, without prior >knowledge, it is impossible to determine the context of the tags if they >aren't namespaced. > >In your example, the context is given by the "footway=climbing" tag. But >the only way you know this is providing the context of the other tags is >by some fairly arbitrary prior knowledge - how do you know that the >context wasn't provided by the "rock=limestone" tag instead? > >> Simple and logical appears always to work best. > >Indeed, I agree. But we differ on what we believe is "simple and logical" >- I think clearly declaring the context of the tag is much more simple and >logical than having a mess of identically named tags, potentially meaning >totally different things depending on a context provided by another tag >which isn't obviously providing the context. >
I'll guess we will agree to disagree then. If it works for you ane the other climbers amongst the contributors then of course you can do what works for you :-) >If there was a *single* "type=" tag that always describes the context of >the whole object, then I might agree that namespacing is unnecessary, but >there isn't, so I don't. :) > >e.g. type=highway:motorway, type=waterway:river, type=railway:line, >type=piste, etc. We would be back where we started 3 years go. "type" is no different from "class", the previous method of tagging which didn't scale easily. Cheers Andy > > - Steve > xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] >http://www.nexusuk.org/ > > Servatis a periculum, servatis a maleficum - Whisper, Evanescence _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
