<br>First off, calm down a bit. Tisn't the end of the world yet :-)<br><br>On 06/02/07, <b class="gmail_sendername">Ben Robbins</b> <<a href="mailto:ben_robbins_@hotmail.com">ben_robbins_@hotmail.com</a>> wrote:<div>
<span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Bridge=yes and Tunnel=yes and all the other=yes.   Why are they keys not
<br>values?  Its not primary=yes, hamlet=yes, or parking=yes.  They have all<br>been sorted into cleanly orgransied catagories.  I can understand why the<br>_=yes excists, becuase somethings that seem alike will be needed together.
<br>(e.g. layers)  I think the method of putting yes/true after somethign is<br>very messy though.</blockquote><div><br>Isn't messy when you consider some of the alternatives. Now we could happily have something like something=bridge or something=tunnel instead, with the minor problem that for the life of me I can't think up a generic enough word for the key. You're completely screwed if you get a bridge which is also a tunnel, but that doesn't happen very often. But it's specialised enough that frankly it doesn't matter if there's a bridge=yes tag. What's a very bad idea is degenerating the scheme to something like highway=primarybridge, highway=footbridge -- it's a multiplicative expansion in the possible tag values with no gain in expressiveness -- it just makes it hard to do anything with programmatically.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I proposed features/structures=xyz as a over all catagorie a while ago after<br>
discussion in the IRC.<br></blockquote><div><br>I don't do IRC so missed this one. But if you mean something like features=some_feature;another_feature etc, then again, nothing gained over just making more tags with yes values. What gets lost is that now all the editors have to parse the list of features something has instead of just checking whether a tag exists. So while it's just as expressive, there's no point nor desire from any of the implementors to do it. It's a syntactic complication.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">  No debate though..no comments. Great, so I come to<br>the mailing list instead of the wiki.  Is the policy currently don't worry
<br>about a problem until its killed us?.  I think all these messy tags, and<br>none exsistent or unused tags really need sorting out pronto.  Why not try<br>and stay ahead, and be organised from the start rather than confronting the
<br>large self built barriers at a later date?</blockquote><div><br><br>I think you've made the classic mistake here of assuming the existence of a "policy". This would imply an organisating body setting policy or at least a system of allowing descisions on such things to be made. Unfortunately what you're faced with is a fairly anarchic project with some vaguely emergent tagging consensus propped up with a wiki based voting system which can sometimes be very amusing. The closest you get is some sys admin types who seem to steer relatively clear of tagging issues, and some core dev guys who have far more control than most due to implementing the tagging scheme of their choice. Or in other words... you get to set policy by convincing enough people that you're right, and coming up with plans people implementing editors and renderers want to support.
<br><br>The other thing you have to remember is that most people out there (including me most of the time) either don't care or have something more interesting to worry about. It is therefore absolutely my personal policy to not worry about something until it becomes a problem. Unfortunately rules are there to be broken.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Nobody answered to my preivous email either.<br><a href="http://lists.openstreetmap.org/pipermail/talk/2007-February/010899.html">
http://lists.openstreetmap.org/pipermail/talk/2007-February/010899.html</a>  .<br>Cheers.</blockquote><div><br><br>permissive= seems completely backwards to me. Tags in my head go, property_category=actual_value. permissive is a value not a category -- the category here is access=permissive. Complicating this is that you can have 4 or 5 things with differing restrictions, so we do foot=permissive for pedestrian access, should probably actually be foot_access=permissive, but that's a minor ah who cares issue.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I have one additional question, but I'll skim over it casue I dought there
<br>will be a responce.  Trails.  In a wood or where ever there is nature<br>trails.*  Has anyone done these?  I considered (route_ref=xyz, colour=red)<br>for example.  There is rendering problems with this though, but I won't
<br>bother listing them.  If no responce then I shall custom tag, but this will<br>be a problem at some future point.<br><br>*nature trails not being just footpaths.  But usually suggested circular<br>walks.<br><br></blockquote>
</div><br>I officially have absolutely no interest in this whatsoever ;-)<br><br>