Proposal talk:Junction=intersection

Value name

Would something like junction=traffic_signals fit more? There are signalized "junctions" (eg complicated merges and weaving sections) that may not be considered "intersections", and some meaning of "intersection" considers it as any at-grade junction thus including roundabouts in some sense. This goes with your aim to highlight conflict points signalized as one junction more. -- Kovposch (talk) 11:51, 11 July 2020 (UTC)

No, because an intersection might not have signals. It has been [noted on the mailing list] that traffic signals can be solved in other ways, and that's somewhat irrelevant. That junction=intersection can sort out traffic signals is a bonus, but is not the only, or even primary, purpose of the proposal. Those other reasons apply to all intersections, not just those with traffic signals. (On a related note, I'm tempted to propose junction=interchange for larger, more complex "intersections"... maybe later. Put differently, note the area proposal; an intersection should get junction=intersection if and only if a) it consists of more than one node, b) it would get a highway=junction area per that proposal, and c) it isn't already covered by a e.g. junction=roundabout. Note also that a roundabout is actually technically not 'an intersection; it is a junction, but it is actually multiple intersections (one per road entering the roundabout). Mwoehlke (talk) 13:29, 13 July 2020 (UTC)

Ok I'm going to think about that, but here's another question I forgot to ask because of the implication. Take your example. Do you disagree with tagging 610887949 610887949 and 669392544 669392544 with your proposed tag as well? I'm not sure if "should not be used on segments which border a non-road surface such as a traffic island" is necccesary as this is also an integral part of the junction. -- Kovposch (talk) 18:36, 13 July 2020 (UTC)

Yes, at least for 669392544 669392544; the I-87 on-ramp is logically after the Fire Road intersection. (FYI, I say this as someone that used that ramp five days a week pre-COVID and hopefully will again at some point. Similarly, the southbound I-87 exit is not part of the intersection of 146 and the northbound exit / southbound entrance... even though the exit lane 'touches' said intersection, because you are not supposed to enter or exit that lane until 1389615365 1389615365, which is after the intersection.) Now that you mention it, though, 610887949 610887949 should have junction=interchange; since that's part of the intersection I'd previously tagged (and, again, the road is already split there), I added it. I'm not sure if "should not be used on segments which border a non-road surface such as a traffic island" is actually correct, but I was thinking about very large, complicated intersections such as the example here. And, bleh, the more I think about it, the more I think you're right; I'm going to go strike that sentence... Mwoehlke (talk) 19:11, 13 July 2020 (UTC)

Junction Names

In several countries around the world, junctions and intersections have names. This proposal would be more useful for us, if there is an option to use the junction=intersection tag on a relation and the ability to add a name tag to the relation. --Zstadler (talk) 13:34, 19 July 2020 (UTC)

Yes, it's not a perfect replacement for some cases where a relation would still be useful. That's okay, as noted in the proposal itself, we can use both where needed. Mwoehlke (talk) 17:19, 20 July 2020 (UTC)

Would the tag traffic_signals:direction=* make it?

I've encountered the described issues in OsmAnd and raised them along with other users in the OsmAnd Ru Telegram channel. The developers have recently incorporated direction* tags in their navigation algorithm, thus, the described problems should be avoided. So, I suggest that instead of introducing new tags, we just map intersections in more details (place traffic lights on points were the traffic is supposed to stop and add direction* tags). Besides, direction* is very useful for signs like "Stop", as these signs usually affect particular, not all directions on intersections. Yury Yatsynovich (talk) 15:20, 19 July 2020 (UTC)

This is already being done, and as pointed out not mutually exclusive. This is meant to describe an intersection, not the traffic control methods. However, what I tried to ask above is using a tag like this to show what sets of traffic lights are formed/"synchronized" as one signalized junction. -- Kovposch (talk) 15:41, 19 July 2020 (UTC)

Ok, but then it means that out of two outlined benefits -- avoiding double-counting of traffic-lights and collapsing four intersection points into one -- only the second one is left (the first one is already achieved by proper usage of traffic_signals:directions*). I can probably see some benefits of the second -- e.g., if you need to turn around, the navigator says "turn around" rather than "turn left, turn left again" -- but even this may not be obvious (if the intersection is large and you really need to turn left, drive 10-20 meters and turn left again then the instruction "turn around" might be pretty confusing). Yury Yatsynovich

For 1, I assume he may mean double-counting in a pair of "intersections" signalized as one junction (defined as one single controller?), as in (especially Tight ones) a Diamond Interchange (as if it's a wide median, with an extra wait line between); not when highway=traffic_signals is tagged on the intersecting points in OSM.

Example signal plans:

https://ops.fhwa.dot.gov/publications/fhwahop06006/images/fig3_31.jpg, https://ops.fhwa.dot.gov/publications/fhwahop06006/images/fig3_32.jpg (FHWA Traffic Control Systems Handbook https://ops.fhwa.dot.gov/publications/fhwahop06006/chapter_3p2.htm)

-- Kovposch (talk) 10:47, 20 July 2020 (UTC)

traffic_signals=direction is not adequate to describe direction, at least if the signals are on the nodes where the ways intersect. Consider, for example the top left node of an intersection of two dual carriageways; the signal applies (in right-hand drive countries; in LHD the same will happen, just on different ways/nodes) to the way entering from the top, but not the way entering from the right. There is no way AFAIK to express this currently. That said, yes, there are other ways to address this, but it isn't the only (or even main issue that the proposal is attempting to solve. Mwoehlke (talk) 17:19, 20 July 2020 (UTC)

Actually, in the above mentioned illustration, all fours roads are one-way, so, there is even no need for traffic_signals:directions to avoid double-counting of traffic lights -- just remove the traffic lights from intersection points and put them on corresponding roads before the intersections, like here: https://drive.google.com/file/d/1FDgGhFNbwTpj6jUryBxSfL8UoSV8gb1G/view?usp=sharing Yury Yatsynovich (talk) 00:05, 21 July 2020 (EST)

That would be the "other ways that signals can be tagged" that I mentioned in the proposal and in my previous reply ("there are other ways to address this"). Also, the signals are no longer on the intersection nodes; as I noted previously, this is an issue "if the signals are on the nodes where the ways intersect" (emphasis added). Again, this is not the only problem, or even the main problem, I'm trying to solve. Some uses of OSM data need to understand when 'stuff' constitutes a single logical intersection for a number of reasons, including to be able to give sensible directions (not just time-wise)Mwoehlke (talk) 15:38, 25 July 2020 (UTC)

CycleStreets proposal at State of the Map 2019

Have you see this video which essentially proposes the addition of an area polygon around a junction? I realise that your proposal says that an additional field requires containment testing, but this seems entirely doable for the kinds of advanced software that need it. The key benefit is that it enables the real geometry of the space required for a junction to be specified. Also, am not sure if it is enough just to note that Ways are part of a junction - why not Nodes also?

https://media.ccc.de/v/sotm2019-1038-is-the-osm-data-model-creaking-#t=1400

Ugh, not going to try to get video working there; I assume https://www.youtube.com/watch?v=pMCnEFzjPD8 is the same video? AFAICT, that is just this proposal, which I already referenced? My proposal also fixes most or all of the messes in that video. (Don't model intersections as stars! with this proposal, you don't need to.) Yes, containment testing is "doable", but it is vastly harder than this proposal, especially for tools that don't even otherwise process areas! As for nodes, they don't need to be marked separately; the idea is that the nodes of junction=intersection ways are logically collapsed into a single junction node. (Admittedly this means there is a "gotcha" that tagging two ways that share a node but are part of different intersections is bad; don't do that. I'm not aware of instances where that would be necessary, however.) Mwoehlke (talk) 17:19, 20 July 2020 (UTC)

Specific cases where it would be useful

A/B Street - https://abstreet.slack.com/archives/CQJ2U8BJ4/p1597158883010000?thread_ts=1597122451.009900&cid=CQJ2U8BJ4 Mateusz Konieczny (talk) 17:29, 11 August 2020 (UTC)

A solution for ambiguous road-related routing tags!

When there is an intersection between two dual carriageways, as in the example diagram, there is a problem identifying the correct street related tags (such as name=* or lanes=*) for the ways within the intersection. Identifying which ways are internal to the intersection with junction=intersection provides a solution, by allowing such tags to be optional within the intersection. (Physical tags, such as surface=* are still useful.)

Is way p a part of B-Road or C-Road? There is no "on the ground" obvious answer, and no answer that is correct for routing through it: Routing from North to East (e -> p -> n -> d) it appears p should be "B-Road", but routing East to South (c -> m -> p -> g) it appears p should be C-Road. This same problem exist for turn:lanes=* whenever the incoming roads have different turn lanes, which is very common.

junction=intersection provides a trivial way for routers to produce the correct turn and lane instruction (even if they could guess that it is an intersection) and provides a way to disambiguate more complex situations, like this monstrosity (iD) in Melbourne. It also reduces the burden on mappers trying to figure out how to model turn lanes and the like. It even affords them a flexibility to use these ambiguous street-related tags to solve some other problem without harming the routers. --BudgieInWA (talk) 14:13, 7 June 2021 (UTC)