<p>If you're using member roles to distinguish the oneway halves of a route, practice in the US is to use the roles "east" and "west" or "north" and "south" as appropriate (consistent with signage if possible).  (I understand some countries don't sign directions this way, so you might have to choose arbitrarily.)  This is still "wrong" according to the way the wiki defines route relations the last time I read it, but it's supported by wide usage and doesn't ambiguate the "forward" and "backward" roles, which are meant to say you're only on the route if you're going this direction on a way. That still leaves the unusual case of how to tag a unidirectional route membership on a two-way street using one relation for the whole route.  For example, if you're going northeast on Chillicothe St then you're going north on Route 3, but if you're going southwest on the same street then you aren't on Route 3 at all; I would personally apply a role like "forward:north" which isn't well supported by tools like Relation Analyzer.  The more laborious but less ambiguous solution is to have a separate relation for each direction (with appropriate "direction" tags) which use "forward" and "backward" as originally intended, and ideally a superrelation to collect the whole route.</p>

<p>So basically it's a choice between more work or nonstandard route relations.  In the US, nonstandard route relations seems to win, at least for now.</p>
<div class="gmail_quote">On Aug 6, 2012 12:40 PM, "Paweł Paprota" <<a href="mailto:ppawel@fastmail.fm">ppawel@fastmail.fm</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
We (as in Polish OSM community) have been remapping for a while now and<br>
also repairing our road network. As a starting point for this effort we<br>
wanted to create relations for major roads.<br>
<br>
It's all good but some "issues" have been coming to light during this<br>
work. One of them I posted last week to this list - data redundancy with<br>
"ref" tag (on relation vs on ways).<br>
<br>
Now there is another one which does not seem to be addressed in OSM, at<br>
least not in a consistent manner...<br>
<br>
OK, so let's take the following road - it's a Polish motorway (A4):<br>
<br>
<a href="http://www.openstreetmap.org/browse/relation/114014" target="_blank">http://www.openstreetmap.org/browse/relation/114014</a><br>
<br>
It is interesting because it has two (one way) parts which don't connect<br>
at any point. Therefore, tools like Relation Analyzer report it is not<br>
in one piece:<br>
<br>
<a href="http://ra.osmsurround.org/analyzeRelation?relationId=114014" target="_blank">http://ra.osmsurround.org/analyzeRelation?relationId=114014</a><br>
<br>
Plus it miscalculates length of this road because it counts each part<br>
separately.<br>
<br>
We have discussed this and decided that it would be good to be able to<br>
easily recognize each "part" of a road in such cases. That's why we<br>
started using backward/forward relation member roles. And our tool<br>
calculates everything properly:<br>
<br>
<a href="https://wiki.openstreetmap.org/wiki/OSMonitor/Poland_Major_Roads" target="_blank">https://wiki.openstreetmap.org/wiki/OSMonitor/Poland_Major_Roads</a><br>
<br>
You can see that A4 is green and length is correct (444 km).<br>
<br>
However, one person from our community suggested today that We're Doing<br>
It Wrong (tm) because backward/forward roles have different meaning for<br>
route relation members. I am inclined to agree with him<br>
<br>
Basically, backward/forward is used to define in which direction given<br>
way is navigable in given relation - in the context of direction of that<br>
way. So not really a good idea to use those roles for recognizing<br>
different parts of a road.<br>
<br>
So the questions are as follows:<br>
<br>
1. Is it even needed to be able to recognize (technically) that A4 has<br>
two parts (east-west and west-east - separate)?<br>
<br>
2. If "yes" in (1) then how to do it?<br>
<br>
Ad. 1 - I think it adds more information and allows to easily calculate<br>
(and more importantly - verify!) length and traverse the road properly.<br>
<br>
Ad. 2 - I think relations with proper member roles could work here but<br>
currently it is not specified how to use them in this way.<br>
<br>
I have found a previous discussion about exactly this topic:<br>
<br>
<a href="http://lists.openstreetmap.org/pipermail/dev/2010-October/020925.html" target="_blank">http://lists.openstreetmap.org/pipermail/dev/2010-October/020925.html</a><br>
<br>
I guess it is called "super relations" and some people thought it is the<br>
way to go but tools are not handling them well (funnily enough, Relation<br>
Analyzer has been mentioned there too).<br>
<br>
Do you think it makes sense to discuss this again? I am willing to do<br>
some work around the topic, without that functionality, reporting on<br>
*roads* (not ways or relations) gets a lot harder.<br>
<br>
Please let me know what you think (but constructive stuff only... I'm<br>
not willing to discuss with "OSM is not a computer project" arguments<br>
again... - I am willing to do the computer work so what's wrong with<br>
that if it improves the project?).<br>
<br>
Paweł<br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/tagging" target="_blank">http://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>