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.

[slhh]

@kepta The lane icons on the map are awesome, but there is still some improvement possible:

• Use a pointing shape instead of the circular shape in order to indicate the lane direction. The current method is sufficiently clear in the example, but would become much less clear in case there aren't turn indications.
• Use a resizeable shape to allow placing multiple lane properties like turn and maxspeed.
• In case there are any hidden lane properties defined, which can't be visualized on the map, the style of the lane icon should indicate this.
• Highlight the lane icon of the selected lane.
• Make the lane selectable by clicking the lane icon on the map.

Example of pointing, resizeable lane icon shapes:

The arrows in the select lane field look like it were left-hand traffic, but the turn icons on the map are correct for right-hand traffic. The select lane field should have a "X" button to unselect all lanes and hide lane properties. Lane buttons of the select lane field should have a different styling in case any lane property has been set for the respective lane.

[tordans]

@kepta this looks awesome.

Comment 1: Visualization: I wonder why you went for the "icon on lane" approach instead of adding lanes like described on OSM Lane Visualizer. I guess its a lot harder to create those lines on the fly?

Comment 2: Editor Usability: I think the UI you proposed at https://github.com/openstreetmap/iD/issues/387#issuecomment-277539927 could be improved. Especially when considering the interface design patterns that the iD Editor uses.

The design pattern – the way I understand it – creates a group ("Lanes") and in this group allows for key-value-editing. The editing itself is based on dropdowns most of the time.

Sitenote: It also uses radio button lists only in very few cases and in your wireframe 1 it should be at least a radio button list – but the dropdown approach reduces the overall visual complexity, so its even better from a usability point of few.

Based on this, the UI could be (URL):

Your design is based on indenting the panels but they are still separate panels that have an interaction between each other. This is not what I would expect them to behave like and I think it is quite komplex and therefore hard to understand and use. This might be a good place for some quick user testing with 5 mappers ("new" and "old" once).

My wireframe 2 follows the existing patterns more closely. It has however a disadvantage for power users that want to edit with as few clicks as possible (editing speed). However, this is an advantage in my opinion since the iD editor targets new users over power user (who have tools like JOSM).

Possible extentions:

• The (i) icon should preview and explain the edit with an example image just like it does in other cases
• Since the order of tags from top to bottom has a meaning it might be a good idea make this more explicit by adding a number "1. Lane", "2. Lane" as a prefix to the row.

Comment 3: Bike lanes: Did you look at https://wiki.openstreetmap.org/wiki/Key:cycleway for this project and do you have plans to add a proper bike lane editing to the Editor? For example, there is the whole left/right vs. forward/backward complexity to handle.

[1ec5]

I wonder why you went for the "icon on lane" approach instead of adding lanes like described on OSM Lane Visualizer. I guess its a lot harder to create those lines on the fly?

I agree, these lane indicator overlays can be pretty distracting when selecting a feature without the intent of editing lanes. Even when editing lanes, they extend too far to either side, so they don’t seem visually related to the selected way. It calls to mind some of the usability problems of the old pie menu, but multiplied by the number of lanes. Having the indicators appear only at the highest zoom levels could mitigate that somewhat, but it would make lane editing functionality less useful for all but one-off edits, since I suspect editors tend to stick to a single zoom level while editing.

Some time ago, I was brainstorming with @bhousel and @kepta about a design for the lane editor that’s unobtrusive yet can accommodate multiple facets besides turn:lane tags (access:lane, change:lanes, destination:lanes, hov:lanes, etc.).

Instead of overlays on the map, put all the lane visualization and controls in a mini-editor. The OSM Lane Visualizer is a step in the right direction; @bhousel mocked up something along these lines in SVG. But take a look at Streetmix or StreetPlan: an interface like this can be really intuitive, even for people who aren’t well-versed in urban planning tools. It can visualize multiple facets compactly, and I think it’s pretty easy to see how it would fit into a mini-editor, either in the sidebar or in a bottom bar (to accommodate more lanes).

The main problem with a cross-section is confusion about directionality when a north-south way is selected: the user will assume the left side of the diagram corresponds to the left side of the way on the map (but not left per the tag). It gets even worse when selecting a curved way. I don’t have any confidence that newer users would pay attention to the little direction arrows on two-way streets to know which way the way is progressing. To mitigate this problem:

• Overlay a colored view cone atop the selected way on the map, just like in a street level imagery overlay.
• Emphasize a front-facing perspective by putting vehicles atop the “pavement” without any overlap. @bhousel suggested tilting the diagram, but I think this risks reintroducing the north-south confusion. The front-facing perspective is like the street-level imagery pane: you don’t get confused by a street-level photo looking southbound.
• @bhousel also suggested adding the names of cross streets above and below the diagram to orient the user:

  The cross street names could help in urban areas, though it won’t be much help in suburbs or rural areas where cross streets tend to be farther apart.

The cross-sectional lane editor could probably replace some existing fields like the cycleway editor.

[quincylvania]

I felt inspired today and mocked-up the basics of a potential lane editor. It has icons for the turning and traffic type of each lane. You would click the icons to cycle through the options if there are only a couple, or open a picker if there are lots. You would drag-and-drop the lanes or dividers to change the arrangement. I'm not quite sure how adding/deleting lanes would work yet.

I hadn't read this thread beforehand so there are probably tips here I could incorporate. Good idea to show the cross-streets!

[bhousel]

Looks awesome @quincylvania 👍

[slhh]

@quincylvania Looks nice, but we do also need an identification of lane position and direction on the map. When hovering a lane in the sidebar the rendering of the selected highway on the main map can change to rendering separate lines per lane including direction arrows per lane, and highlighting of the hovered lane.

To add or delete lanes the lane representation in the sidebar can have a right click context menu with delete, add on right, and add on left operations.

Showing cross-streets looks nice at a glace, but I think it would be less useful or even confusing in practice: It does likely work for small roads, but these rarely need lane tagging. Larger roads with multiple lanes do unlikely have constant properties between two cross streets. This results in splitted OSM ways between cross streets. Another issue is the naming of highways within large junctions, e.g. with separate ways per direction.

[1ec5]

Showing cross-streets looks nice at a glace, but I think it would be less useful or even confusing in practice: It does likely work for small roads, but these rarely need lane tagging. Larger roads with multiple lanes do unlikely have constant properties between two cross streets. This results in splitted OSM ways between cross streets.

The cross streets would be shown for navigational purposes only, but you’re right that we’d have to take care not to imply that the entire stretch of roadway between the two cross streets have uniform properties. One way would be to label the cross streets without visually connecting them to the lane diagram. It’s enough for the labels to be above and below the lane diagram.

[1ec5]

Though it doesn’t support lane tagging, the Waze editor takes a router-influenced approach to orienting the mapper when tagging, regardless of the road’s directionality. When a way is selected, the endpoints are marked A⃝ and B⃝ on the map, and the tag editor’s one-way and per-direction speed limit fields are labeled A→B and B←A.

Compared to the cross-street naming idea above, it’s probably faster to match A⃝ and B⃝ on the map, and long street names aren’t a problem. The A→B label also forces the mapper to consider directionality when interpreting the diagram, unlike my view cone idea.

Waze’s treatment works because the mapper only selects a single segment between intersections in the Waze editor, as opposed to a whole street that might go off screen. But I think iD could dynamically clip the A⃝ and B⃝ markers to the viewport, just as it centers the little directional/vertex-adding triangle within the viewport today.

[slhh]

@1ec5 I like the A-B approach , but the A and B labels should be shown only when the sidebar is hovered or focussed. Otherwise they would interfere with editing like the former radial menu.

Maybe A and B can be replaced by cardinal directions, where the way is suffiently straight to make the usage of cardinal directions non confusing.

[bhousel]

tbh, the more I think about this, the more I'd prefer to just render the lanes directly on the actual map at high zooms.

[1ec5]

Rendering the lanes onto the map would address the issue of orienting the user, at least when they aren’t copying from street-level imagery. Would we have the user edit the lanes directly on the map, or would there still be lane-specific controls in the sidebar? As soon as we put anything in the sidebar, we have to address the issue of associating the map overlays with sidebar controls, which is challenging when the way runs south to north or non-linearly.

Perhaps the user could select a lane on the map, and the sidebar would show only the controls for the selected lane, as though it were a first-class object like a node or way. Not sure where the user would go to add a lane.

Lane overlays like the ones shown in https://github.com/openstreetmap/iD/issues/387#issuecomment-277539927 make plenty of sense for turn:lanes, but if we ever want to support placement or change:lanes, rendering those details as overlays would be tricky. JOSM takes the approach of completely obscuring the road with a lane diagram that can depict all those details, but while that approach great for understanding what’s already tagged, I think obscuring any amount of aerial imagery would be inconvenient for anyone mapping turn lanes from scratch. Also, I wonder if people would try to drag these overlays around, since they wouldn’t look like a contextual menu.

I tend to edit at zoom level 18 or 19, because I have the luxury of crisp aerial imagery at those zoom levels where I map. I’d probably find it annoying to have to zoom in further to map turn lanes, since I’d have to zoom back out to easily pan to the next intersection. For reference, this is what a wide, two-way road with lots of turn lanes looks like at z19 around 39°N:

This is a more common scenario, where I would typically enable wireframe mode to see what’s under the rendered way:

It sounds like you’d only show lanes at a higher zoom level where there’s more screen real estate, to avoid overlapping adjacent features like sidewalks. But a higher zoom level could still get uncomfortable if the user happens to be using an imagery layer that gets unreadably pixelated above z19.

[jguthrie100]

It could always be an option to orientate the lane editor in the same direction as the map and have it rotate around as the map is rotated..

[ignaciolep]

Please, bear in mind the need to input different maxspeed values for each lane. This is important in two-way roads, where each direction have different maxspeed values. Wiki: https://wiki.openstreetmap.org/wiki/Key:maxspeed#Lanes

[BjornRasmussen]

tbh, the more I think about this, the more I'd prefer to just render the lanes directly on the actual map at high zooms.

That could be setting that is automatically activated when editing lanes.

[BjornRasmussen]

Lanes would only be rendered when they were needed.

[quincylvania]

Here's an update on my previous design. You would click on a lane to open an editing popover.

As noted elsewhere, special lanes like sidewalks, bike lanes, and parking lanes should all be incorporated into the lane editor.

It'd be great to show the lane editor directly on the map in some cases, but I think it's necessary to always have it in the sidebar too.

[1ec5]

I don’t think we can completely rely on cross street names to disambiguate directions. For example, this way doesn’t have any named cross streets, its endpoints are continuations of the current street, and the nearest named cross streets at each end are the same street. If I were to add street parking along one side but not the other, I’m not sure which side in the diagram I’d edit. The cross street name can be an aid, but there probably needs to be something else too.

In this latest design, the diagram wouldn’t be directly editable, so I wonder if we could get away with rotating it according to the main map, just as with the turn restriction mini-editor.

[quincylvania]

I don’t think we can completely rely on cross street names to disambiguate directions.

Agreed. We would only show the crossroad like that if it was a clear circumstance.

In this latest design, the diagram wouldn’t be directly editable, so I wonder if we could get away with rotating it according to the main map, just as with the turn restriction mini-editor.

Possibly. I'm not sure how this would work in practice. I'd prefer to just rotate the map to align with the editor, but this wouldn't necessarily work especially well with long and twisty roads. We could try larger way direction markers when editing roads, or even an animation on the road showing the flow.

[slhh]

@quincylvania When a lane is hovered or selected in the sidebar , dots moving along the lane could be animated on the main map to indicate lane direction. Preferably, the lane position is calculated based on the driving_side, placement, and width:lanes tags where present. The slight side ofset to the OSM way would be visible on high zoom levels only, but the lane direction on all editing zoom levels.

[slhh]

@quincylvania

I'd prefer to just rotate the map to align with the editor,

The rotation might not be identifyable for the user dependent on the structure of the data and thebackground structure in the viewport. The user might loose orientation.

We would only show the crossroad like that if it was a clear circumstance.

What seems to be a clear circumstance for Id might be different what the user thinks to be clear. iD might show the crossroad on the other side of the way than expected by the user. This could result in inverse tagging of the lanes.

Showing crossroads could be quite confusing within large junctions with separate carriageways for each directing and/or separate carriageways for turning. Especially the later ones rarely have well defined names.

[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 https://github.com/openstreetmap/iD/issues/387#issuecomment-483702193 and https://github.com/openstreetmap/iD/issues/387#issuecomment-483289342.

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 https://github.com/openstreetmap/iD/issues/387#issuecomment-483702193 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 https://github.com/openstreetmap/iD/issues/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.