Dair Grant wrote: >Sent: 12 January 2008 4:10 PM >To: [email protected] >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 _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
