2008/12/1 Matt White <span dir="ltr"><<a href="mailto:mattwhite@iinet.net.au">mattwhite@iinet.net.au</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Douglas Furlong wrote:<br>
><br>
> This makes is pretty straightforward to tag for all vehicle types<br>
> easily<br>
> - a tertiary road that has a fair few potholes could be<br>
> smoothness=bumpy (given that car is the primary vehicle for the<br>
> tertiary<br>
> highway type)<br>
> smoothness:mtb=bumpy<br>
> smoothness:racing_bicycle=rough (or unsuitable)<br>
> smoothness:tank=normal (or even "glass like" :-)<br>
> smoothness:rollerblade=unsuitable<br>
><br>
><br>
> I really honestly can't see how the above differs from, for example.<br>
><br>
> bicycle:mtb=bumpy<br>
> bicylce:racing_bicyle=rough<br>
> tank=normal<br>
> skate:inline=unsuitable,<br>
><br>
> Other than, we drop smoothness and replace it with the mode of<br>
> transport in question.<br>
><br>
> I would strongly suggest Richards suggestion is ultimately clearer,<br>
> than the arbitrary smoothness tag.<br>
><br>
</div>I wasn't suggesting it was any better, although I kind of like the core<br>
key name first (smoothness:vehicletype=*) as it doesn't waste the<br>
primary tag (and something like skate:inline=unsuitable doesn't actually<br>
indicate what the why it is unsuitable (too steep, bad surface, high<br>
traffic volume, idiot weekend cyclistd abound etc.)</blockquote><div><br>the bumpy/rough/unsuitable are just examples, and of course would need further clarification.<br><br>But more importantly, they could be dependant on the leading values.<br>
<br>I.E. skate:inline, could have totally different values to bicycle:mtb, which could be specified by the enthusiasts that use that form of transport.<br><br>I'm not certain why you want smoothness first, ultimately the end user should never REALLY have to know about the order these values per tag, we should be relying on the editors, to have reasonable graphical interfaces to allow for an easy way of ticking boxing and selecting drop downs of relevant values.<br>
<br><br>and renders to render the maps depending on these values.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d">><br>
> I don't personally like the term "smoothness" either, but I've yet to<br>
> find a decent alternative ("surface" would be nice, but 'tis taken).<br>
><br>
> The 4WD proposal (plug:<br>
> <a href="http://wiki.openstreetmap.org/wiki/Proposed_features/4WD_Only" target="_blank">http://wiki.openstreetmap.org/wiki/Proposed_features/4WD_Only</a>) is a<br>
> little bit separate. It could be taken into account using some sort of<br>
> smoothness, track type, surface, take your pick, but I am specifically<br>
> looking at tracks that are actually signed as 4WD only, to be rendered<br>
> with a nice bit of text at the end of the road name to make it obvious<br>
> what is 4WD only (most decent AU maps of hte country side have<br>
> explicit<br>
> 4WD tags of those roads that require it). Good for routing and the<br>
> like<br>
> (where the relative smoothness can be a bit subjective)<br>
><br>
><br>
> Where you have the sign post for 4WD only, is that an access<br>
> restriction or a suggestion?<br>
><br>
> I.E. If you go on that road with a motorbike, or a 2wd vehicle, could<br>
> you face prosecution? Or would you just be considered a bit foolish?<br>
><br>
> If it is the latter as opposed to the former, then I'd rather see some<br>
> thing along the lines of vehicle:4WD, as opposed to an access tag,<br>
> which to date I believe is being used to indicate permissibility, as<br>
> opposed to suitability, which are not the same thing at all.<br>
</div>It is the latter (it is a recommendation) rather than a legal<br>
restriction. The point of such an explict tag is so that when I'm out<br>
driving, the map actually shows the 4WD state as text (given that I dont<br>
think the Garmin I have really has any other way of visually<br>
distinguishing the road state/vehicle requirement)<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>This sounds a bit like tagging for the render, which I believe is frowned upon.<br><br>Having vehicle:4wd=suitable (or what ever), could just as easily be rendered, as a 4wd access tag, however it would fall in to the whole suitableness kinda argument that is going on.<br>
<br>We need to separate visual representation of features, from how that feature is tagged, as they are not the same thing.<br><br>I'd be curious to know from a maintainer of one of the visualisation projects, which they would find easier to work with.<br>
</div></div>