Proposal talk:Left-right things

The "side=left" proposal is about finding the "centre" and "outside" of multi-carriageway roads.

This is about discovering which side of "M25 northbound" contains the hard shoulder (in this case, it would be the left side, because we drive on the left. But the hard shoulder, verge, and fence of "Route National 1" would be on the right of each carriageway)

left/right is dangerous

I'm not a big fan of direction-related tagging. First of all I see possible conflicts; we have them today already with things like "incline=steep" and "oneway=true" (both assume that the tag refers to the direction of the way), and this is "solved" by allowing "oneway=-1" (ugly ugly ugly!). Secondly I view the way direction as something rather volatile; users almost routinely change a way's direction to merge with something else or so. Editors would have to have knowledge of all tags that rely on the way's direction to be able to warn the user that he should not reverse this way unless he knows what he's doing.

I would very much prefer an explicit solution that does NOT depend on the direction of the way. For oneway, inclines and so on I would suggest using a relation (this way is oneway between node X and node Y - if you reverse the way the info is still valid). For dual carriageways etc., what we really want to map is the fact that "this way forms one road together with that way", the renderer can then find out which side is the outside - no need to ask for trouble with "left" and "right" stuff. As for the bridges which are mentioned here as well, this has been one of the first proposed uses of relations (mapping the fact that multiple ways share one bridge).

I know relations aren't "there" yet, we need to do a lot in the editors and renderers to make them work, but we *have* the tool to do it right, and I think the left/right stuff is an ugly workaround that we don't really need. --Frederik Ramm 17:51, 28 March 2008 (UTC)

Arguments pro left/right and against relations

In my opinion a consistent left/right-notation ist much better than a solution based on relations. Advantages are:

• much easier to render
• less paths and nodes
• GPS-coordinate acquisition needed only once, not for every way/path

First of all, you need a consistent notation, e. g.

 [left|right].[footway|cycleway|parkinglane|tram|...].[<property>]="value"

Without left/right at the beginning, the property will apply on both sides. By turning a way in JOSM/Potlatch etc., the left and right properties should be exchanged by default. This seems very easy to implement and nearly nothing will be destroyed by accident. There might be an extra option to turn paths without exchanging these values.

When using seperate paths and relations it seems also very difficult to be rendered, because the rendering software has to process the positions of each way, e. g. to get their order. Additionally no way will be overlaped by a second way because the rendering can easily be optimized for every zoom level without recalculating or modifying the coordinates.

The order of the ways/paths beginning from the middle of the road might be specified with a notation similar to this one (r=roadway, c=cycleway, p=parkinglane, f=footpath):

 wayorder = "r,c,p,f"
  - or -
 left.wayorder = "r,c,f"
 right.wayorder = "r,c"

See also: Talk:Proposed_features/Footway, --Plasmon 16:35, 9 July 2008 (UTC)

Added features

When adding features to a road, such as emergency phones, bus stops and such, it can be a good indicator which side of the road they appear. Many places a bus stop appears only in one direction even though traffic flows in both directions on the road. Emergency phones is also often located with altering positions (left -> right -> left -> right) where these exists. --Skippern 01:09, 8 September 2008 (UTC)

Also for roads with a physical deviding barriere and crossover/return routes, it can be handy (at least for planning software) to know which lane to follow when approaching such features. I know that this also can be achieved by proper mapping and correctly tag number of lanes, direction of flow etc. --Skippern 01:09, 8 September 2008 (UTC)