[OSM-talk] Tagging hierarchies

[Andy Robinson (blackadder)]

Dair Grant wrote:
>Sent: 12 January 2008 4:10 PM
>To: talk at openstreetmap.org
>Subject: Re: [OSM-talk] Tagging hierarchies (was: RFC - lake)
>
>Frederik Ramm wrote:
>
>>I'm not saying that "natural=water" should be deprecated. I'm just
>>saying that if someone wants to introduce a tagging for lakes or
>>other *special* kinds of water, then there is no technical
>>requirement to tag everything that is tagged with the new lake tag
>>(say, water=lake) as natural=water *also*, because the fact that
>>"water=lake implies natural=water" could be stored externally.
>
>There is definitely benefit in being able to say "X is a kind of Y".
>
>Any client software using OSM has its own internal model (roads
>can be drawn in one of 7 styles, say) and has to map OSM's tags
>to that model to use it.
>
>At present that means a big list of explicit tag matches, and
>anything unrecognised just has to be discarded.
>
>
>Another approach would be to have a "conforms to" page, like Map
>Features, which describes how tags related to each other.
>
>Software might not know what a reservoir or a dam were, but if
>it can fetch some rules that teach it what they're similar to
>(say a general body of water) then it can do something sensible
>with them.
>
>
>>Obviously the option of vague tagging must remain, otherwise the
>>lake tag would have to go once the biologists start differentiating
>>between various types of lakes, and in the end we'd end up with a
>>system where nobody can tag anything unless he's one of the world's
>>three experts.
>
>In the above case the software wouldn't have to care about what
>kind of sub-types of lake people wanted to define - if they all
>conformed to "it's a lake" then they can be processed as such.
>
>I've been careful to say "conforms to" rather than hierarchy
>here, since I think that might be the bridge between
>pre-defining every tag for mappers (bad) vs every client having
>to hard-wire a list of stuff they understand and ignoring the
>rest (also bad).
>
>The idea of conformance is that things conform to properties of
>something less specific than them - this is a "like a"
>relationship, not an "is a", so things can have multiple ancestors.
>
>
>We kind of have this today, where something might be tagged with
>multiple tags to indicate different aspects of its nature.
>
>That helps people capture things as they are on the ground, but
>building the inverse would make it easier to actually do things
>with the data.
>
>
>I'm not sure what the best way to see if this is feasible would
>be; perhaps just sifting through the tags in planet to see what
>values people actually use.
>
>My guess is that people often use the tags supported by the
>renderers, both because they're common things in reality but
>also because making something appear on screen is more
>fulfilling than capturing lots of data nobody ever sees.
>
>A conforms-to system would allow renderers to use the small
>hierarchy of tags that they have rules for, but also allow
>people to tag things however they liked (provided their tags
>relate to something else, they don't need to adjust their
>tagging to match a renderer).
>
>On the subject of tagging, was there any more development on the
>STAGS idea from SOTM?
>
>


Well, yes. There has. But actually not quite in the direction that I was
taking STAGS.

I spend a lot of time observing and reading the discussions on tagging to
see what the different opinions are and the sort of tags that come up for
discussion. From it all I've learnt a number of useful things:

Tags definitely work best when they are not in a regimented format. There
are some users of course that would rather be using an OSM "Standard" for
tags. There are also those who prefer to create the tags on the fly just
using logic. If we spend time creating an all encompassing "standard" only a
small percentage of the potential OSM user base will be at all interested in
using it, partly because it's too dictatorial and partly because its making
the process over complicated and therefore removes the fun. Also by the time
we have agreed one the world will have moved on. Standards wanking is not
the OSM way of getting things done.

However, if we have no tagging "guidance" (ie there was no Map Features for
instance) then users are unsure of where to start or indeed how to tag at
all. The very concept of a key/value pair to non programmers can't always be
assumed.

We can and have pre-seeded tags into the editors and this seems to work ok
for the basics.

What I've been observing is that there is a real benefit of encouraging the
use of a core set of keys. We do this now to a large extent with the Map
Features root keys (highway, waterway etc). It's interesting to see that
since I put the original Map Features out there has not been a big push for
more "root" keys and the majority (but not all) of the new proposals are for
new values or keys that logically form a subkey.

I've also seen that the proposals for new tags are not always logical,
either because they don't stand alone very well (poor word description) or
because they cause fragmentation or conflict with other tags. Oh, and I'm
not suggesting for one minute that the original Map Features was perfect
either because it wasn't in a number of areas.

So what I keep coming back to is a need to make some enhancements to the way
that tags are created rather than what the tags actually are. This seems to
be the best way to provide guidance on existing and potential tags and also
a level of loose structure that provides guidance for use and creation.

So, son of Map Features does exist in various forms and I know I need to get
it out in the open asap so I'll devote some time to doing that, hopefully
for the benefit of everyone.

While we are talking about tags I want to thank all those who take the time
and effort to put up proposals and make comments on them. The process is
very useful in seeing what users need and wish to tag. Personally though I
feel the process is more complicated than it need be, so I have some ideas
to simplify it without loosing the ability to propose and comment. I also
believe that we can learn a lot form the tags that are in the database
already. Not all tags need to a proposal/comment process if they are logical
and users simply get on an use them.

As many of you know I'm not fond of the voting process. I see why some feel
it's important but I'll always maintain that 6 votes of approval for a tag
is not a quorum of 2,000+ editors so we should never blindly assume that an
"approved" tag is the best way of doing things.

I'm also not in favour of "deprecating" tags, apart from this being wholly
the wrong word in the first place (obsolete is better) because this implies
that there was something wrong with the original tagging. The obsolete tags
are still just as valid as information so let's not blindly disapprove of
them by using the word "deprecate".

I'll start to post some more info.

Cheers

Andy