Proposal:Junction=intersection
| Another Take on Junctions | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | Mwoehlke |
| Tagging: | junction=intersection |
| Applies to: | 
|
| Definition: | Identifies portions of a highway=* which are part of an intersection |
| Statistics: |
|
| Rendered as: | No change |
| Draft started: | 2020-07-08 |
| RFC start: | 2020-07-10 |
Proposal
I propose to add a new value intersection to the existing junction=* key. This would be advised for portions of roads which are part of a logical intersection. For example, in the image below, 'm', 'n', 'p' and 'q' would be so tagged.
Rationale
Currently there exists no accepted way to specify the extent of a junction, although multiple proposals have been put forth (the rationales of prior proposals generally apply here also). In particular, certain uses of OSM data (e.g. routing and traffic simulation) can be confused by the way complex intersections are often modeled. Consider, for example, a typical intersection of dual carriageways controlled by a traffic light:
Each direction of the road consists of a separate way, such that the intersection — logically, a single entity — ends up with four nodes. Worse, if each node is tagged as a traffic signal (which is often done when a signal is present), each way appears to have two signals, when in reality there is only one, which can affect trip planning and estimated duration. Moreover, if signals are specified on the intersection nodes, it is currently impossible to specify their direction in a way that avoids this problem. Some routing engines may also produce spurious directions when faces with these intersections (usually something like "take the second turn", when of course there is logically only one turn). These issues are particularly exacerbated if the road which is modeled using two one-directional ways is not actually physically divided.
Splitting the way so that the portion which is "in" the intersection produces a number of benefits:
- Software can deduce that signals do not apply to a way which is tagged junction=intersection. This immediately fixes the problems with assigning signals to the intersection nodes.
- Routers and traffic simulators can know to collapse nodes into a single logical intersection with many incoming ways. This makes it possible to avoid "wrong" instructions and can allow more intelligent creation of kinematic paths (in applications where that is relevant).
Why not use a relation?
(Proposal)
Relations are much more difficult to enter in existing editors, as well as more difficult for tools to parse. Nor is it clear what entities would be assigned to a relation, and in what manner. The only benefit to using a relation of which I am aware is the ability to assign a name to a specific traversal of a set of ways.
That being said, it is possible that a relation should be used in addition for those cases which truly require it. This proposal is not about naming things, but rather providing the information needed for tools which consume OSM data to model intersection areas in a meaningful and more accurate manner.
Why not use an area?
(Proposal)
Areas are harder to model, and are inconsistent with the use of ways (lines) to represent road surfaces. If we modeled road area, this would be a more sensible solution, but we don't. Also, areas are much harder for tools to deal with, as they require containment testing. Tagging road segments is much easier for tools that consume OSM data.
In my mind, it is a significant advantage that this proposal can be modeled simply by splitting a few ways at nodes 'that already exist and applying a few tags. Creating an area is much more complicated and requires creating many nodes. (Concerns on the discussion page for the area-based proposal should be noted.)
Modeling
One potential concern with this proposal is that it recommends splitting ways at intersections. Although editors should be able to correctly update relations when ways are split, editors may want to be cognizant of existing relations when splitting ways. That being said, in my experience it is often necessary to split ways near intersections in order to correctly supply lane information (n.b. lanes=*, turn:lanes=*), so this proposal is not necessarily making things any worse.
It should be noted that this proposal, in and of itself, is not recommending any change to how signals are annotated. Part of the advantage of this proposal is that users may continue to tag signals on the nodes where ways intersect. The new tag provides sufficient information for tools to accurately deduce the directions (edges) to which a signal applies (which is not currently possible). There are also other ways that signals can be tagged, which should not be affected by this proposal.
175473372 175473372 and 610887949 610887949 show an example of this tag in use. Note that 669392544 669392544 should not be tagged, as the ramp is not logically part of the intersection, but rather a separate turn-off after the intersection.
What is an intersection?
Broadly speaking, an "intersection" is a set of lanes which a human would notionally consider to be a single logical entry. In some cases, this may be difficult to specify exactly, however we can give a couple good rules of thumb:
- If turn lanes which are not separately modeled would cross the area defined by segments that are candidates for being tagged as intersections, then that is an intersection. By this definition, it is clear that the above example is an intersection, since traffic turning from e.g. 'b' to 'f' will cross the gray area.
- Another approach is to look at traffic instructions (stop signs, traffic signals), as these apply at the intersection level. The ways connecting a set of nodes which such directions control as a single logical entity constitute an intersection. Note, however, that the segments approaching such nodes should not be tagged junction=intersection. Normally, these do not need to be tagged specially, although use of junction=approach may be useful in some situations.
(More generally, it is useful to look at when routing would be better served by collapsing adjacent nodes. Note that both of the above rules fit this criteria.)
Rendering
No special rendering for this tag is required. Indeed, many renderers would be *discouraged* from using this tag for rendering purposes. (An exception would be a renderer which tries to approximate intersection shapes, in which case appropriately tagging intersections with this tag is useful.)
Comments
Please comment on the discussion page.