<div class="gmail_quote">
<div>Before we all get too depressed, I think I agree with both of you (Dave / Mike) that any changes to tagging should be backwardly-compatible, as far as practical (or at least minimise the "wrongness" if the old tagging is unchanged).</div>

<div> </div>
<div>But we also need a scheme that is simple, effective and shows what's on the ground, not just what's on the sign.</div>
<div> </div>
<div>I think the nub of it is the tagging of path/bridleway/cycleway. I think "path" serves a useful function for ways that are more than just footways, but where usage/access for horses/mtb/bicycles is uncertain. I think "bridleway" serves a useful function in those countries where access for horses is well-established (and thereby is becomes a useful shorthand for highway=path+designation=public_bridleway), but in practice there may be little to distinguish a bridleway from a path (and there might be sense in rendering them quite similarly). </div>

<div> </div>
<div>Whereas, highway=cycleway is an explicit assertion that the surface is somewhat better than you might expect on a bridleway/path, without going into the minefield of the multiple values that might be tagged for tracktype/surface/smoothness.</div>

<div> </div>
<div>I think I'm concluding that highway=cycle&footway is unnecessary; perhaps highway=cycleway+cycleway=shared would be a better bet (and leave it to the renderers whether they do anything with that). But if highway=cycleway is to be used for shared cycleways, then the wiki definition will need to be more inclusive than currently.</div>

<div> </div>
<div>Richard (West Oxford)</div></div><br>