Proposal talk:Alternate oneway

Status

status should be changed to rfc --Skratz 13:59, 11 January 2009 (UTC)

I can't see rfc among Proposed features#Proposal_Status_Process. --Vincivis 14:23, 29 January 2009 (UTC)

Directionality

I'm all for it. The direction of the way would have to go in the direction of the traffic that has preference (the white arrow). and the renderers could draw a white and red arrow on the way in the corresponding directions. --Skratz(?)

I don't like the key choice, but agree that the direction of the way should determine which direction has priority. --achadwick 13:21, 28 January 2009 (UTC)

How much is oneway=-1 used? We may find that other-way priority sections are required (one example would be long bridges where the rule is "give way to traffic already on the bridge" (several examples in the UK); having to reverse part of the way may affect route relations). My preference is for priority=yes/-1 so that it doesn't affect routing using oneway=* (though routers should be encouraged to use it as a speed hint).--Tms13 12:27, 3 March 2009 (UTC)

Would this tag automatically imply lanes=1?--Tms13 12:27, 3 March 2009 (UTC)

key choice "oneway"

"oneway" is an access restriction (it makes the way totally unavailable some traffic). This "alternate oneway" (is this a "real" term, btw?) is only priority regulation (some traffic might be slowed down by having to wait for a while). I oppose to use the oneway-Key for both types of information and suggest to create a new key instead. You might try to find a solution that also works for right of way at junctions, but simply switching to something like alternate_oneway=yes is probably fine, too. --Tordanik 13:37, 25 January 2009 (UTC)

I agree with Tordanik above. I've never heard the term "alternate oneway" before. In the UK the physical road layout would normally be covered by traffic_calming=choker (I think, from reading the Map Features description, although possibly traffic_calming=chicane). This proposed tag would be trying to add the priority information to the narrowed section of the way, in much the same way as you might want to tag "Give Way" or "Stop" signs (highway=stop applies to nodes to mark the signs for the latter of those two). Perhaps tagging the signs either side of the restriction rather than the way itself might be more consistent? EdLoach 09:11, 26 January 2009 (UTC)

I'd be happy-ish with it becoming part of the traffic calming traffic_calming=* somehow, because the intent is to slow down traffic. I'd prefer it if the restriction itself were tagged: the fact that there are two traffic signs is neither here nor there really. highway=stop has some pretty serious deficiencies regarding direction, it'd be good to not use it as a model. --achadwick 13:21, 28 January 2009 (UTC)

The intent is to regulate traffic, not to calm it. There is a permanent obstacle (like an old building, a tight tunnel) that cannot be removed. --Vincivis 14:23, 29 January 2009 (UTC)

But I'm happier with it being represented as an access restriction. It certainly isn't a oneway: it's about traffic in two directions, albeit not at once. --achadwick 13:21, 28 January 2009 (UTC)

I admit it's a traslation from italian (senso unico alternato). I'm obviously available to review tag's name and category. --Vincivis 14:23, 29 January 2009 (UTC)

what's about car=oneway and car=alternate_oneway and so on? its like a restriction, isn't it? --Josias 12:45, 26 January 2009 (UTC)

this is a priority sign, not a restiction sign. --Vincivis 14:23, 29 January 2009 (UTC)

While the oneway= tag could be extended as proposed, I agree with Tordanik that it would be wiser to treat oneway= as an absolute access restriction. car= is not good as the sign applies to all traffic, including bicycles. traffic_calming=choker works, what does the proposer think? It is certainly something good to capture for routing calculations. MikeCollinson 17:02, 27 January 2009 (UTC)

ITYbothM motorcar=* there. But if we make it an access restriction, vehicle=* could be used to mean "all vehicles". So what about speccing it as <mode>=priority_over_oncoming , as the Vienna Convention on Road Signs and Signals calls it? With reference to the direction of the way the tagged is a part of. And we should suggest the use of vehicle for <mode> in most jurisdictions (here, cyclists like me are delayed/get proriity at these things as much as motor cars). --achadwick 13:21, 28 January 2009 (UTC)

My +1, FWIW, is on making it an access 'restriction'. Because you'd never be combining it with anything actually restrictive for the mode in question there would be no tag clash. Also suggest the use of traffic_calming=* on the same so that the physical layout is captured. --achadwick 13:21, 28 January 2009 (UTC)

This is a priority sign (like a stop), so could it be placed among Intersection features. It could be renamed highway=alternate_oneway or alternating priority, etc. --Vincivis 14:23, 29 January 2009 (UTC)

As a native English speaker, I found the term "alternate oneway" a bit puzzling too, "traffic direction priority" is clearer. http://en.wikipedia.org/wiki/Comparison_of_European_traffic_signs calls the sign: Traffic has priority over oncoming vehicles / Diritto di precedenza nei sensi unici alternati / Prioridad respecto al sentido contrario / Pierwszeństwo na zwężonym odcinku drogi MikeCollinson 17:02, 27 January 2009 (UTC)

The meaning is "alternating priority", I think based on the traffic sign graphic. We do need to refer to the way's directionality here. --achadwick 13:21, 28 January 2009 (UTC)

What do you think about a new tag priority/give_way=right(default for all countries?)/yes(both)/alternating ??

There are TWO separate features being mapped here. The first is the physical layout. This could be tagged as 'barrier=chicane', or by 'lanes=1'. The second is the legal traffic priority. This could simply be tagged as 'priority=yes' with the priority in the direction of the way, which will enable the correct traffic sign to be rendered at each side of the restriction if wanted. It would HAVE to be tagged on a way, and not a node, as a node isn't be able to designate a direction. WessexMario 13:07, 04 June 2009 (UTC)

I partly support WessexMario's suggestion. Another reason why we should separate the physical condition (road to narrow for simultanous trafic in both directions) and the legal condition (one direction has the right of way) is, that there might be situations where there simply is no priority bound to a specific direction.

However, it might be worth thinking about generalizing the whole priority idea to apply to junctions as well. At the end, such a situation would be a junction of two roads, but instead of a junction node, there is a junction way which is the portion where there is only one lane. --DLichti (talk) 16:10, 15 December 2013 (UTC)