<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-01-05 12:32 GMT+01:00 Tom Pfeifer <span dir="ltr"><<a href="mailto:t.pfeifer@computer.org" target="_blank">t.pfeifer@computer.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":1il" class="" style="overflow:hidden">My conclusion is that a majority of mappers prefers a better structure and move<br>
away from tag fragmentation when they have a chance. This then helps the data<br>
consumers which do not need to run after each new duck tag to be implemented to<br>
cover a certain class of features.<br>
</div></blockquote></div><br><br><br clear="all"></div><div class="gmail_extra">I believe we will need both, tags at a reasonable level of detail, and structure to distribute different properties on different tags (reusable on other kind of objects).<br><br>The whole discussion is about what is a reasonable level of detail, and which are the attributes/properties we want to store, and which are the words we use to represent them ;-)<br><br><br></div><div class="gmail_extra">Duck tagging has the problem that it only works locally / within the same cultural and legal background. When everybody tags the cycleways in his town as highway=cycleway, it forces a global dataconsumer to know all local/regional/national legislation in order to understand who else besides cyclists can use this way (e.g. pedestrians) and what other implications there might be.<br>Duck tagging tends (I guess) also to people tagging less explicit because they feel that everything relevant is already implicitly contained in the one tag they use (and likely these asumed implications will be different in their details between different mappers).<br>Applied consistently to all tagging this would inavoidably lead to tag fragmentation, because for every small property that changes, a whole new main tag will have to be created.<br><br></div><div class="gmail_extra">On the other hand, being too generic with the tags leads to unusable tags as well (on their own), it makes tags superfluous at the first level, because everything relevant is only revealed on the second (and further) level(s). A recent example that was discussed here is the tag tourism=information. This was first used for tourist information offices, then extended to information boards and maps, and then included even guide posts and trail_blazes: <a href="http://taginfo.osm.org/keys/information#values">http://taginfo.osm.org/keys/information#values</a><br></div><div class="gmail_extra">If you want to make sense of these objects, you have to look at the information key, the content of the tag tourism=information is so generic that it has become useless.<br><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Martin<br> </div></div>