Support for lane and turn lane tagging

[simonpoole]

The road style should reflect the number and type of lanes added.

Further a smplified method of tagging lanes should be available.

See http://wiki.openstreetmap.org/wiki/Key:lanes and http://wiki.openstreetmap.org/wiki/Key:turn

[tmcw]

Do any existing map styles or editors do this?

[simonpoole]

The approved lane tagging is rather new so support is limited. There is a map style for JOSM in two versions that supports the tagging see http://wiki.openstreetmap.org/wiki/Josm/styles/lane_features

Currently there is some support in OsmAnd for navigation and I suspect others will follow now that there is an established method of tagging, It is likely for lane tagging to be very popular down the road once it actually has an effect, so while I would classify supporting it for a first release as not necessary it is something that will probably have to be done down the road.

[kepta]

Here is a link to the proposal I submitted for my google summer of code application.

[slhh]

@kepta Thanks for sharing your proposal, I will comment later.
Do you know the awesome OSM Lane Visualizer?
Example: http://osm.mueschelsoft.de/cgi-bin/render.pl?relref=B%2075&start=1&placement&adjacent&lanewidth&usenodes
Supported Tags:https://github.com/mueschel/OsmLaneVisualizer#interpreted-tags
Maybe you can reuse some ideas, code or icons.

[slhh]

@kepta
I don't think it is a good idea to make turn lanes unavailable somewhere for the following reasons:

• Turn lanes can have the length of multiple OSM-ways.If the user wants to tag the first section of such a turn lane first, his workflow will likely be prohibited by any rule for turn lane availability..
• Merge values can end without a junction.
• Special cases where other turn markings don't end at a junction do probably exist somewhere.

I don't see how splitting whithin the lane editor could work, because it needs to be made at the correct geoposition. I think the radial menu split operation is sufficient anyway.

What could be implemented in the lane editor is a longitudinal split due to a physical separation between lanes. It is a useful operation, but handling affected relations doesn't seem to be easy. Therefore, this has a low priority.

Instead of drawing allways rectangles the lanes should be drawn like following example:

The lane width should be drawn according to width:lanes, but at the bottom this should be overridden by width:lanes:start , and at the top be overridden by width:lanes:start.

The information defined using the keys
placement, placement:start, placement:end altogether can be represented using a 4 vertix line like the red, dotted line in the example. Instead of these keys their :forward or :backward variants can be used alternatively. In oder to modify the placement keys I would like to just have the red, dotted line dragable.
In this case showing any of these placement keys as a field can be avoided.

It is important to support the witdth:lanes and placement keys including their :start and :end variants because they are not only required for lane rendering but also are very useful to define connectivity.
A well defined lane connectivity is absolutely necessary for lane support of navigation systems.

[slhh]

Users should not be required to use the lanes tagging syntax, therefore a lanes editor should not support a subset only of applicable keys. Therefore, I suggest a more generalized approch:
For each lane use a temporary object, both way lanes need one per direction. Decompose each *:lanes*=* tag of the highway into tags which are added to the lane objects, where :lanes, :lanes:forward and :lanes:backward is removed from the key and the value is reduced to the part corresponding to the respective lane.
The graphical UI of the lanes editor should allow the user to select a lane. When a lane is selected the "all fields" section and the "all tags" section should show and edit the tags of the temporary object of the selected lane instead of the highway object. This way the existing fields can be reused in order to edit the lane values. "All fields" and "all tags" should be temporarily named "lane fields" and "lane tags" respectively while the lane is selected.
When all lanes get unselected, the *:lanes*=* tag needs to be reassembled in order to be shown in the all tags section. There seems to be a preferred method to use :lanes for oneways and :lanes:forward/:lanes:backward otherwise, but in case this was tagged differently and the lane values haven't been changed, the original tag should be used.

[slhh]

The lane editor should not only cover keys with :lanes, :lanes:forward, and :lanes:backward, but also keys with pure :forward or :backward modifiers. Therefore, the previously mentioned approch should be extended:
Line the temporary lane objects use a temporary object for forward and backward direction each.
Tags of the highway object with :forward but not :lanes:forward key modifier go to the forward object with the modifier being cut out of the key. A thick forward arrow at the right side of the lanes drawing should enable selecting the forward direction. When selected the temporary forward object should be edited by all fields and all tags like a lane is edited according to my previous post.

The same applies with forward replaced by backward direction and the arrow at the left side of the lanes drawing.

[slhh]

The lane editor needs to care about right-hand or left-hand traffic, based on tagging of the highway and also the country-specific default. This is not only relevant for the graphics, but also for matching the value parts of *:lanes tags to value parts of *:lanes:forward or *:lanes:backward.

[pnorman]

but also for matching the value parts of *:lanes tags to value parts of *:lanes:forward or *:lanes:backward.

These are in the direction of the OSM way and I'm having a hard time coming up with a situation where this matters except for display. Could you explain?

Unfortunately, the wiki page is very short on examples of lane tagging for non-oneway roads.

[slhh]

Example with two forward and two backward lanes:
maxspeed:lanes=10|20|30|40 equals to

• maxspeed:lanes:backward=20|10 and maxspeed:lanes:forward=30|40 in case of right-hand traffic
• maxspeed:lanes:backward=40|30 and maxspeed:lanes:forward=10|20 in case of left-hand traffic

[HolgerJeromin]

Are you sure? The proposal says
"In the common case of two driving directions we need to use the already existing :forward/:backward extension."