<div dir="ltr"><div dir="ltr"><div>This is an interesting proposal, but it needs a lot of thinking before we can consider it a working proposal.</div><div><br></div><div>Here is my lost of <i>additional points</i> that need clarification.</div><div><br></div><div>1) The problem exists in the same way also for other routes like:</div><div>route=road|foot|hiking|bus|trolleybus|tram|mtb|</div><div>So the wording has to be reviewed under this aspect</div><div><br></div><div>2) There is an unresolved issue with bicycle routes, i.e. that, variants apart, in most cases a cycle route between A and B uses a different chain of ways different in the direction A > B form the route B > A (due to things, like roundabouts, one-way streets, one-way cycle paths that are mapped as separate ways in OSM, and possible others). The only logically clean solution is to have two separate relations for the two directions under a super-relation. But none of the (many) cycle route relations I know follow this model. The usual approach is to include all ways in the same relation and use the forward|backward roles on the ways that differ. The consequences for the hierarchy model need to be looked at. <br></div><div><br></div><div>3) There is a tendency to include signposts in the relations. This has a number of open issues of its own. <br></div><div>3a) with the one-relation-per-direction scheme the signposts that have information for both directions, do they belong to the super-relation or do they have to be included in both child relations?</div><div>3b) In case of more routes sharing the same string of ways, many signs (referring to different routes) share the same physical support, i.e. they should be tagged on the same node. <br></div></div><br><div class="gmail_quote">Volker</div><div class="gmail_quote">Padova, Italy<br></div></div>