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."

[slhh]

In the case of two driving directions using the pure :lanes extension might not be intended by the proposal, but the reality of the database seems to be different. In fact using the pure :lanes extension seems to be convenient for some base keys, and the meaning of the data is well defined.

[slhh]

@kepta
Are you aware that the number of lanes defined by the lanes* keys doesn't need to equal to the number of lanes used in the values of keys with the :lanes suffix? Your proposal seem to assume that these quantities are equal.
The lanes* keys are counting full width lanes for motorized traffic only, but the :lanes suffix is counting all lanes without such a restriction.
Therefore, a common graphical representation of both lanes* and *:lanes doesn't seem to be possible.
I think the lane editor should focus on *:lanes and the lanes* keys should be supported by normal fields.
In case of missing *:lanes keys the quantities from lanes* keys can be used as a default for the graphical representation, but the user needs to be able to add lanes without changing the values of the lanes* keys.

[kepta]

Hey @slhh, yes I am aware of that.
My mentor @bhousel did point that anomaly while I was writing the proposal

23:43 bhousel: also.. in some places, there is a special lane for a tram or something
23:44 bhousel: so it's not clear whether to tag that as a lane.. it's not a lane cars can drive in, but it's important to know about
23:44 kepta_: hmm, I guess thats what the osm-talk discussion would be
23:44 bhousel: yeah that's what they are discussing now
23:44 bhousel: but anyway, the weird thing is that the number in lanes= sometimes does not equal the sum of all the lanes
23:45 kepta_: :O
23:45 bhousel: yep, that's osm ¯_(ツ)/¯
23:45 kepta: and why?
23:47 bhousel: because osm can't decide whether lanes means "lanes" or whether it means "lanes for motorized traffic"

I am really sorry I forgot to mention it in my proposal.

[slhh]

@kepta, how do you intend to address that issue?

What bhousel did point out seems to be only a part of the problem.
It is not only the sum in lanes=* which might not equal to the sum of lanes:forward=*, lanes:backward=*, and lanes:both_ways=*, but also the value in for example lanes:forward=* doesn't need to match the count of lanes in *:lanes:forward=*
Example:
bicycle:lanes:forward=no|designated|no|designated usually requires lanes:forward=2.

23:45 kepta: and why?
23:47 bhousel: because osm can't decide whether lanes means "lanes" or whether it means "lanes for motorized traffic"

lanes=* is the older key, which seems to be mainly intended for capacity estimation, and its definition has been kept unchanged for compatibility reasons.
If the newer key suffix :lanes were restricted to full-width lanes for motorized traffic, describing some real situations like bicycle lanes between motorized traffic lanes would be prevented.

Personally, I would prefer to deprecate lanes=*, and replace it with something based on :lanes, for example something like direction:lanes=forward|forward|both_ways|backward, which would also prevent any issues with driving_side (it is impossible to render lanes without determining driving_side) or even support any unusual sequence of driving directions.

[slhh]

@kepta, @bhousel
The intention of a lane editor can't be to let users spend time tagging useless data, but it should be to improve OSM data in order to enable applications. Therefore, the design should be driven by application requirements and not just by tag statistics.
Currently all the *:lanes=* tags are quite useless because existing applications using these tags are very rare.

I see the following main applications for the lane specific data, but these potential applications are prevented by missing data in most regions currently:

• Rendering of lanes at high zoom levels
  This needs the following keys for a harmonic position and shape:
  placement, placement:start, placement:end, width:lanes, width:lanes:start, and width:lanes:end
  The last two keys mainly support a more realistic shape of starting, ending, forking, or merging lanes.
  In addition this application needs the following keys for road markings with second priority:
  turn, turn:lanes, change, and change:lanes
• Navigation system lane support
  This mainly needs information about lane connectivity. Connectivity of the lanes within a single way is defined by the change and change:lanes keys. Connectivity to the lanes of the following way can be defined by something like the transit key. I think the transit-proposal should be improved, but we definitely need a lanes connectivity editor, which is working on interconnection nodes like the turn restriction editor, in order to define such connectivity. The lane connectivity editor might even be an extension of the restriction editor.
  In simple cases such a connectivity specification is unnessesary or might be replaced by tagging width:lanes:start, and width:lanes:end, which allow to determine connectivity automatically in case of ending, starting, merging, or forking lanes. I think it is easier for the user to define the geometry of the single way than to define some kind of relation to the lanes of the next way.
  Other lane properties seem to have second priority behind connectivity for this application.

The lanes editor should encourage users to provide the required information to enable these applications. In addition to all keys mentioned above, their :forward and :backward variants need to be supported too.

[slhh]

@kepta, @bhousel
In addition to application requirements the priority of tag support of the lanes editor should be driven by programming efficiency and usability:

1. In order to avoid the requirement of major graphical redesigns the keys which need a special graphical representation and not just a an added icon should have first priority:
   width:lanes, width:lanes:start, width:lanes:end, placement, placement:start, placement:end, change, change:lanes
2. Keys which would be error-prone to use if there were not a graphical representation should have second priority. The following keys do fall into this category if they are not already handled with first priority:
   • Due to potentially changing right/left with backward direction: turn, turn:lanes, change, change:lanes
   • Due to a potential confusion when combining :start or :end with backward direction:
     width:lanes, width:lanes:start, width:lanes:end, placement, placement:start, placement:end
3. For the remaining tags with :lanes suffix a graphical representation is nice to have, but handling these tags with lane based fields seems to be sufficient for some time.

[HolgerJeromin]

Just for your information: OsmAnd uses turn:lane tagging for its navigation.

[kepta]

Here is an demo of what I have been working on.
Would love to hear some suggestions.

[HolgerJeromin]

Nice!
A graphical view of resulting arrows (most used combination are sufficient) above the lane number would be cool.
So you could quick check (without clicking all tabs) if all lanes are matching the reality.

Example of ways with both forward and backwards would be interesting, too.

[kepta]

@HolgerJeromin
How about this

[HolgerJeromin]

I thought about adding it to the table in the sidebar. But in the map is perfect.
Eventually they could be rendered even if the way is not selected (at a high zoom). This way checking a highway crossing would be extreme fast.

[BjornRasmussen]

When I first started editing osm with iD, the bike lane editor had the right and left side editor, which was confusing at first. I glanced at the selected way, saw the small arrows, and mapped according to which side was left and right. I don't think that this should be the number one concern

[BjornRasmussen]

One simple solution would be rendering the cardinal directions in the editor as subtle letters on the sides. This would let people know that there is a directionality to the editor.
A compass icon could do the same.

[BjornRasmussen]

I have a simple UI suggestion: make the editor have two sections, a visualizer that can let you select lanes and lane dividers, and an editor for specifying lane information for the selected lane/divider.
Basically just a more beautiful version of this:

What I mean by "divider" is that you could click on a divider and specify change:lanes for nearby lanes, and therefore the type of divider (dashed vs solid).

Lane width would also be useful, especially since bike lanes are usually much narrower than drive lanes.

Also, the bottom area could be used for editing the number of lanes when no lane is selected. This way, no space is wasted.

[BjornRasmussen]

Another idea I have is render the lane display based on a .json rendering file that can be different depending on which country the lanes are being edited in. Most of Europe does not have a double yellow stripe in the center of the road, but rather a double white stripe.

[BjornRasmussen]

Of course, a popover with the same information as my sketch would likely be better, since even less space is used.

[slhh]

@BjornRasmussen
Cardinal directions wouldn't work for U-shaped or circular ways.

When the sidebar is open, using a popover requires even more space. In addition, a popover needs a control to be opened.
Users need to be made aware of any existing lane tagging, major geometric changes like merging or appending a way are otherwise prone to generate wrong data. Therefore, we must not hide lane tagging in a rarely opened popover.

[slhh]

@quincylvania

Here's an update on my previous design.

You need to differentiate pure forward/backward indications and "through" turn indications.

[tordans]

Hi! I am very happy to see new energy in this thread.

However, I don't know if I still know what the goal of this thread is.

I write this, because I see a real issue with trying to solve all lane related tagging in one place. Which will IMO become a huge mess of complexity (like this thread show already, IMO). And I am really not sure if its even possible to build a UI for all this.

In case we try to find a UI that "consolidate(s) all of the "stuff tagged on a street" into a single place" (like bhousel put it and quincylvania visualized it), I see two mayor issues:

1. Separate lanes vs. "everything on one lane".

Most mockups above assume IMO, that there is one way which holds all the tags. Eg #387 (comment) and #387 (comment).

The advantage is, that the UI looks very good and easy to use.
The disadvantage is, that it's only one way of tagging and it does not really work if lanes are split in multiple ways or other means of transport (bike, foot) are split in separate ways.

I also feel like the community is slowly pushing towards tagging separate was for separate traffic sources. Like https://www.youtube.com/watch?v=DHecYP_b3os (a good talk!). This development is IMO accelerated by the need for more descriptive tagging (like bike-lane-width and -smoothness, …) on ways, which would otherwise cause the main-way to be segmented into a hundred peaces, making it impossible to maintain (think: parking tagging on a street + turn lanes + bike-lane-width on one way).

2. Not just lane tags, but all the sub-tags as well

The other issue is, that having a UI that handles the lanes is one thing. But the same UI should also allow to add all the descriptive sub-tags as well. I see #387 (comment) started adding a few of those. But there a quite a few more. And they are different per "lane" (eg. parking-sub-tags vs. driving-sub-tags). This will make the UI very complex. We could just leave this part out, but then the new UI will be a lot of work and break later once we try to add "tagging-depth" to it.

Two approaches

One UI for all

Lets assume we find a UI that can deal with the separate lane-issue (1) above and also handle "sub-tags" (2). Which might be possible given enough dev-power! I feel like the discussion here is not really clear about what we want to add to this UI. What are the features we need to add to this UI? IMO https://streetmix.net/-/773938 is a good start:

• sidewalks
• parking (car, bike, …)
• car driving
• bike driving
• bus driving
• tram (train) on street
• tram (train) as separate lane (eg. in the middle, between car lanes)
• and between all of those separation elements like …
  • barrier=kerb
  • trees
  • bollards

If this thread continues this road, I suggest we first collect the cases we want to handle with the UI. The list above could be a starting point.

Separate UIs

On the other hand, we could just start by adding a great UI per use-case.

• for cars / turn lanes there is a lot of good stuff above, that will make the IMO very hard to understand tagging schema of (turn) lanes really easy to use. This is a huge win, IMO. Just like the turn-restriction-UI made a very complex tagging super easy; by focusing on this one problem.
• for parking, I started Parking alongside streets (parking:lane) #6178 to collect ideas
• for bike lanes – I fear there is a lot to do on the tagging definition front, first
• bus, tram, … – I personally know to little about, yet

Maybe we could even think about how to push the mapping forward in the direction of "separate lanes per means of transport". Eg by adding a "split the sidewalk (or cycle lane) tags from this way into a separate way"-feature.

[quincylvania]

@BjornRasmussen said:

I have a simple UI suggestion: make the editor have two sections, a visualizer that can let you select lanes and lane dividers, and an editor for specifying lane information for the selected lane/divider.

Yep, I was thinking something like this as well. Either below the lanes, or as I said in my one comment, "You would click on a lane to open an editing popover." This could also apply to dividers if the OSM tagging is that far developed.

@tordans said:

I also feel like the community is slowly pushing towards tagging separate was for separate traffic sources.

I'm all for this! I vastly prefer separate sidewalks and even bike lanes, but if people keep tagging this stuff on roads then I do think it makes sense to show them in the lane layout.

The other issue is, that having a UI that handles the lanes is one thing. But the same UI should also allow to add all the descriptive sub-tags as well.

We can start with the basic lane info (access, turns) and see what makes sense after that. The point is to make lane-tagging possible and easy, not to do everything 😅

[tordans]

The point is to make lane-tagging possible and easy, not to do everything 😅

I am glad to hear that.

That would mean, we can now find the best solution to handle the following tags, right?

• lanes=3…
• turn:lanes=none|none|none|merge_to_left|…

and

• lanes:forward=1…
• turn:lanes:forward=left|through;right…
• lanes:backward=1…
• turn:lanes:backward=through|through;right…

Source: https://wiki.openstreetmap.org/wiki/Key:turn#Example_for_a_road_with_both_directions

But also destination tags? - https://wiki.openstreetmap.org/wiki/Key:destination
Anything else?

So we need to be able to …

• add a lane
• remove a lane
• reorder lanes
• specify the lane type
• change the direction of a lane
• respect the oneway-key
• understand where north is / which way the street shows / what direction I am editing
• anything else?

If so, the first question for the UI is IMO:

• should it display the lanes on the road (in the map view) (Support for lane and turn lane tagging #387 (comment) and maybe Support for lane and turn lane tagging #387 (comment))

• or: should it handle the details in the sidebar (Support for lane and turn lane tagging #387 (comment) and similar)

• or: both, but the map to show it, the sidebar to edit it?

[BjornRasmussen]

should it display the lanes on the road (in the map view) (#387 (comment) and maybe #387 (comment)).

or: should it handle the details in the sidebar (#387 (comment) and similar).

or: both, but the map to show it, the sidebar to edit it?

I would prefer both, with the option to turn rendering of lanes situated next to the wireframe option in map data.

[BjornRasmussen]

But also destination tags? - https://wiki.openstreetmap.org/wiki/Key:destination

I think that it would be too difficult to work this into the interface, but maybe would fit somewhere in the pop-up.

[EmpireFall]

Edit - after reading all the comments regarding this issue, it has occurred to me that a lot of commenters are arriving at the same sort of concerns regarding the challenges behind creating an interface for solving this issue, what I typed-up below is essentially a rephrasing of ideas that commenters have already come up with (I had yet to actually read all of the previous comments regarding this issue at the time when I wrote it, it looks like we are all more or less on the same page)

I was designating 'turn:lane' tags for 'ways' using the current iD editor, it requires a certain amount of focus to get right, otherwise the user may confuse the direction of the 'way' with the intended direction of the 'tag' in conjunction with the road markings seen in the background layer (as the forward heading direction of a 'way' is defined by the direction in which it is drawn, there have been times that I have mistakenly assumed that the forward heading direction of the way is the same as the side of the road in which traffic flows, which has led me to designate tags accordingly only to realize later that the heading of the way is in reverse, that coupled with a background layer that is always facing upright can make designating turn:lane tags a rather focus intensive process)

in this regard, a function in the iD editor that came to mind, that I thought was rather intuitive is the 'turn restriction' box

would it not be possible to present the 'turn:lane', 'parking:lane', 'road markings, etc' tags for each respective lane with similar presentation and functionality of the 'turn restriction' box?

if the angle for each symbol of each respective lane tag were facing the same orientation as the 'way' itself (as seen in the turn restriction box), that would make it much easier for the user to orient themselves with the respective tags of each lane in conjunction to the orientation of the 'background layer'

https://i.imgur.com/PJxpPip.jpg
https://i.imgur.com/96k12Rj.jpg

as the orientation in which a 'way' can be either 'forward' or 'backward' and angled toward any direction, having a box with all the lane details presented facing upwards (as shown in the image below), the user may end up feeling as disoriented as with the current setup available in the iD editor

https://i.imgur.com/vhNHga0.png

imagine designating 'turn restrictions' if the orientation of the 'way' in the turn restriction box were facing upright rather than at the orientation of the way itself, things could get rather confusing without a certain amount of focus

just a thought

[hungerburg]

Removing the WIP label usually means, the feature is complete. Can I get my hands on a working testbed?

[kymckay]

@hungerburg Removal of WIP just signifies work is no longer actively in progress. There'd be a lot more buzz on this issue if the feature was complete 😄

[hungerburg]

Is the abandoned work of Quincy's open source? Recently someone did some lane tagging in the area of my local_knowledge with iD and I think, they mostly did that manually, at least not all the stuff passes validation, so I think that it be worthwhile to continue that work, the screenshots looking very nice indeed.

[reticivis-net]

bumping this issue because there's multiple designs and working prototypes and I really want to see this integrated into iD. JOSM's turn lane plugin sucks

[Zaczero]

@HexCodeFFF, I think that's a trend with iD development in general. I wouldn't get my hopes up. I completely gave up on any iD contributions a few weeks after posting this thread: #9500

[reticivis-net]

Damn. Sucks cause iD is, imo, much cleaner and easier to use than JOSM but there's no plugins and slow development.

[dabreegster]

Putting in a plug for a-b-street/osm2streets#216 -- we have a web app for visual lane tagging started. Could use help with getting OAuth to work, and with design/implementation for a nicer UI to edit (rather than raw tags). Happy to adapt/use one of the designs from earlier in this thread -- better to get something going and iterate quickly.