Proposal talk:Transit

Crossing lanes

The proposal seems to assume that lanes are not crossing each other between the "from way" and the "to way". This assumption is not true in reality. Examples:

• changing to right turn lane might need to cross a bicycle or bus lane
• left turn bicycle lanes between motor vehicle lanes might be entered by explicit crossing of motor vehicle lines.
• bus lanes might change side

--Slhh (talk) 18:16, 7 March 2015 (UTC)

Could you please provide a photo of such situation? --Imagic (talk) 07:50, 17 March 2015 (UTC)

Here an example of a cycleway crossing.--Jojo4u (talk) 20:28, 25 July 2015 (UTC)

Lane numbering

You have introduced lane numbering in the placement proposal. Why not simply use these numbers as destination lane for key transit? This would also solve the crossing lanes issue.--Slhh (talk) 18:21, 7 March 2015 (UTC)

Readability, ease of use, analogy to the key turn. --Imagic (talk) 07:50, 17 March 2015 (UTC)

Starting lanes

Examples #1 and #3: The starting lane in the "to way" seems to be a pure feature of this way. Therefore it should be tagged on the "to way". One method to do this would be to set the starting width of the lane to 0:

Example #1: width:lanes:start=||0

Example #3: width:lanes:start=0||

The ability to change to the starting lane can be specified using change:lanes. --Slhh (talk) 19:18, 7 March 2015 (UTC)

The key width:lanes:start could be used to provide the width and this then could be used for guessing the right lane connections. The key/relation transit is about the exact specification of the lane connections. --Imagic (talk) 07:52, 17 March 2015 (UTC)

Transit to Transition

The word transit is confusing, can we use the term transition which better represents what is proposed. Maning (talk) 13:48, 8 September 2017 (UTC)

My thoughts exactly & perhaps the slightly wordier highway_transition. Transit may well be mistaken for an alternative to public_transport. Avoid. SK53 (talk) 15:35, 8 September 2017 (UTC)

would lane_transition be better? Maning (talk) 11:28, 12 September 2017 (UTC)

I would also say that lanes:transition would be a better name for this. --Polyglot (talk) 07:30, 11 June 2018 (UTC)

Tagging the way

In the relation-less scheme, the fact that the "from way" is tagged, but the tagging actually applies to the end node of that way creates some new challenges for editing and processing, I expect. Splitting a way with a transit tag now results into something that means something different: now both the original end node and the node where the split was applied have a transition. Similarly, it is no longer possible to merge two continuing ways that have the same tags. (I don't know if this also applies to other tags, but I can't think of any.) Of course you can often recover from this when processing the data (as you can tell that the tag is the same and the number of lanes will almost always no longer match), but I do wonder if it wouldn't be possible to avoid this. Maybe only have an option to tag the node itself (if the number of incoming and outgoing ways are both 1), and the option to use a relation if multiple incoming or outgoing ways are involved? --Xnyhps (talk) 08:14, 14 October 2017 (UTC)

I had missed link to ticket 11054 for JOSM which addresses the same problem. --Xnyhps (talk) 18:37, 15 October 2017 (UTC)

https://josm.openstreetmap.de/ticket/11054 is a working link Mateusz Konieczny (talk) 06:06, 11 June 2018 (UTC)

Fundamental issues ("I can't support transit:lanes")

https://lists.openstreetmap.org/pipermail/tagging/2018-June/037082.html - "I notice that `transit:lanes` has already been tagged on around 4000 or so ways, so I thought it would be worth pointing out that the proposal is Dead on Arrival in it’s current state. We should rework it before people tag too many more of these and end up disappointed." Mateusz Konieczny (talk) 06:05, 11 June 2018 (UTC)

In https://lists.openstreetmap.org/pipermail/tagging/2018-June/037105.html this tagging scheme was described as horrible by a Vespucci developer Mateusz Konieczny (talk) 16:33, 11 June 2018 (UTC)

https://josm.openstreetmap.de/ticket/11054 has discussion about supporting it in JOSM Mateusz Konieczny (talk) 16:35, 11 June 2018 (UTC)

https://github.com/osmandapp/Osmand/issues/5221 is about OSMand support Mateusz Konieczny (talk) 16:37, 11 June 2018 (UTC)

Lane extensions through intersections

As far as I can tell, the fundamental issues raised by developers relate to the use of transit:lanes=* on ways. This proposal also included a provision for type=transit relations, which would enable us to map lane change restrictions through (four-way) intersections. [1] With the rejection of this proposal, perhaps we should develop something based on change:lanes=* for that purpose. – Minh Nguyễn ^💬 18:59, 30 December 2018 (UTC)

A relation based approach needs excelent graphical editor support, but than it might be the better solution.

The proposal Relations/Proposed/turn lanes describes an existing approach, and there is also a nice JOSM plugin "turnlanes" to edit the relations graphically.

Proposal and plugin aren't compatible to the current ":lanes" scheme, but can be used in a compatible way: do not use extra lanes and the resulting relations of type=turnlanes:length. --Slhh (talk) 04:14, 31 December 2018 (UTC)

If I understand correctly, that proposal can express which lanes can go in which direction, which is similar to what we can express using the more widely accepted turn:lanes=* tag. But it doesn’t seem to be able to express, for instance, that the leftmost left turn lane may turn onto the left two lanes of the cross street, whereas the second-to-left left turn lane may only turn onto the right lane of the cross street. That’s what I’m hoping to be able to accomplish with a relation. –Minh Nguyễn ^💬 07:06, 6 January 2019 (UTC)

Your intention was clear to me, and I thought it were covered by the proposal, but I was wrong. Nevertheless, the JOSM plugin could be a good base to start with.

The GUI can be easily modified to generate a target per outgoing lane instead of a common one for all outgoing lanes of a way.

The proposal can also be easily extended to cover your intention, but it might be better to start a new one from scratch.--Slhh (talk) 16:51, 6 January 2019 (UTC)

We should keep the number of generated relations low. The graphical connectivity editor should calculate and show the default connectivity and generate relations to specify deviations from the default only. How to calculate the default needs to be well defined.--Slhh (talk) 00:13, 7 January 2019 (UTC)

I like the idea of only adding connectivity relations where they differ from default expectations. Proposed features/transit#When to use and when not proposed some default connectivity rules that I think are a reasonable starting point. Basically, if an intersection differs from these norms, it would get connectivity relations instead of transit:lanes=* tags on ways. (I think this proposal failed in part because it was too overzealous in avoiding relations, complex as they can be.) – Minh Nguyễn ^💬 03:24, 8 January 2019 (UTC)

Avoiding relations was quite mandatory at the time of the proposal. iD has a very bad history of destroying relations, and nearly all requests to improve relation editing in iD were ignored at that time, graphical transit editor in iD was unimageable. Therefore, the proposal was focussing on manual editing, but this results in being less suitable for graphical editing. Another issue of the proposal is focusing on nicely looking tags for standard situations, at the cost of making the rules much more complex than required, but functionally more restricted than necessary. Btw, I don't agree on the "fundamental issue", it's a bit nasty, but much less work than a graphical editor. Nevertheless, a graphical editor is desirable.--Slhh (talk) 01:34, 9 January 2019 (UTC)

Calculating defaults is a little complex for intersection nodes. We need to match geometry and turn:lanes values in the first stage, and calculate the default based on the numbers of incoming and outgoing lanes for a specific turn. We need to limit using defaults to the common consent of major applications. The complexity to decide whether a relation is required or a default can be used, needs to be hidden from the user.--Slhh (talk) 02:00, 9 January 2019 (UTC)

Lanes can also be bicycle lanes, which might be connected to cycleways instead of lanes. The cycleway might be tagged on the highway. We need to support cycleway to lane, lane to cycleway, and cycleway to cycleway connectivity. UI could show the cycleway as small lane using a different color. The cycleway might also be mapped as a separate way. The connectivity editor needs to be available where a cycleway connects to the road.--Slhh (talk) 00:13, 7 January 2019 (UTC)

LeifRasmussen has proposed a new connectivity relation type. – Minh Nguyễn ^💬 17:20, 18 April 2019 (UTC)

Lane connectivity of consecutive ways

Mapping lane connectivity through intersection doesn't make sense as long as we ignore to specify lane connectivity in the simple case of two consecutive ways. The same graphical UI should be available in this simple case, but we need to keep the number of generated relations really low, to avoid their negative impact on highway editing. This means, we need a very good default connectivity. Placement tags are a good base to calculate the default connectivity in case of oneways (e.g. highway=motorway). Unfortunately, placement tags do hardly help in case of bidirectional streets.--Slhh (talk) 01:17, 7 January 2019 (UTC)