[OSM-talk] Tagging climbing routes and scrambles

[Andy Robinson (blackadder)]

Steve Hill [mailto:steve at nexusuk.org] wrote:
>Sent: 23 April 2008 1:08 PM
>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:
>
>> Because it was difficult for the "layman freeform tagger contributor" to
>> decide what the root "class" should be, for instance is it class=waterway
>or
>> class=river.
>
>I think I'd be inclined to try and make things a bit hiararchical - e.g.
>"waterway:river" or "waterway/river".  But really this sounds like a
>documentation issue more than anything - if there is documentation
>providing reasonable guidance, and a good set of existing classes all
>following the same "standard", this seems like a good way of doing things.
>
>> Just going back to namespaces (trying not to nag you), the use of
>namespaces
>> is very useful in certain contexts, where true separation within a
>dataset
>> is desirable.
>
>My main concern with a lack of namespaces is that you can end up with a
>single tag key meaning very different things depending on the context it
>is used in, and the context is not always obvious.  This makes
>interpretting the tag, looking it up in the wiki, etc. a problem.  And if
>you attempt to unify the meanings of these tags so that they are not so
>ambiguous when you don't know the context, you end up having to coordinate
>far too many bits of the project.

As I think AndyA pointed out you are not normally looking at a tag out of
context, e.g. on its own without any of the other tags applying to the same
feature.

Take the ref tag for instance. It's easy to use because it's just three
letters and obvious. We use ref to mean anything from the reference number
of a post_box to the number designated to a road and lots more besides.
Making each of these explicit is just making it over complicated for the
contributor (and editor software that has to know about such things).

I accept there is a downside, in that if someone deletes some of the keys
the context might be lost, but that doesn't appear to have been at all an
issue to date.

Standards wanking aside there is I believe some benefit in evaluating the
way tags are delivered in xml output so that some hierarchical information
can be relayed. At present there is no logic to the xml delivery of tags and
perhaps users of the xml data might benefit if there were. But then again,
passing the xml through a stylesheet can introduce structure and hierarchy
if it's needed by the end user. I don't see a strict hierarchical structure
ever working at the contributor end.

Cheers

Andy

>
>> Using a string of namespaces in front of each and every tag (the key
>getting
>> longer and longer as the data gets more complex) doesn't really in my
>view
>> give the same flexibility that I think is needed for OSM.
>
>To some extent, this is about presentation - if the editors presented this
>string of namespaces in a nicer way, rather than just a big string of
>namespaces then it would suddenly become much nicer to work with.
>
>  - Steve
>    xmpp:steve at nexusuk.org   sip:steve at nexusuk.org
>http://www.nexusuk.org/
>
>      Servatis a periculum, servatis a maleficum - Whisper, Evanescence