Proposal talk:Highway=junction

Please add to the discussion using the Add Topic button above. Keep discussions succinct, try to stay on topic, and mark finished conversations with {{Resolved}} and related templates.

Common nodes of areas and ways

In the example, highway=* ways have no common node with the junction area where they enter it. Since the way sections within the junction area will have to be handled differently from those outside it (e.g. just rendering lines and not the road surface itself, as the latter is already covered by the junction surface), this makes processing this mapping style more challenging for certain renderers (such as my own). Would it be a problem to connect the ways to the junction areas? --Tordanik 21:46, 22 April 2012 (BST)

Not for me. But I fear, that many people will forget/ignore this, as it makes editing more complicated, especially if one has to move ways. And if it then is not considered by applications (because the common nodes are missing), people will not use this feature and we haven't gained anything. But I'm completely open for a discussion about this. --Imagic 08:44, 23 April 2012 (BST)

I know this is old, but I think it's a good idea, so I'll reply. If the mapping software can detect crossing ways even without an intersection node, it can detect where ways enter the junction area (and warn the mapper). You may notice that in the example image, there is a traffic_signal node on *each* way that enters the junction area. If the junction itself is tagged with, say, junction=traffic_signals, this makes tagging simpler. Actually, it could make mapping *much* simpler if the software just considered any pair of entry/exit nodes to be a valid routing through the junction (unless a restriction relation exists - see below). It would no longer be necessary to examine ways and nodes to find possible perverse routing and create a restriction at that specific node, at the same time splitting those two ways at the node. This is a big plus in my opinion!

It strikes me that there are three possible ways to tag - simple, advanced, and classic:

Simple: No intersection nodes or turns whatsoever are mapped within the junction (but all entry and exit points are marked with nodes). Ways are only mapped in the junction to avoid splitting them unnecessarily. The routing software treats any pair of entry/exit nodes as a valid route. This presents a very "clean" intersection. Downside: most software will not currently be able to route any turns through the junction. (Unless we somehow treat the junction perimeter as a valid way)

Advanced: No intersection nodes are mapped within the junction, but all legal routes are mapped, as in the given example. To be technical, an intersection node (or conflict point) is one where at least two ways enter and at least two ways leave the node. (otherwise it is a merge or a split, with no traffic conflict). This "advanced" mapping scheme would allow the routing software to show a more exact path through the intersection.

But wait - There are two intersection nodes in the given example, with turn restrictions! If you take a closer look, those are not actually necessary. They could be replaced with link ways for the desired turns, one at the north side and one at the south side of the bridge (sorry for not providing a diagram).

Classic: Intersection nodes at conflict points are all mapped, as they currently are. Restrictions can be entered as they currently are, or as described below. In the absence of restrictions on specific nodes, the software should make the assumption that no turns are made from one way to another at an intersection node, unless this is necessary to route to the desired exit way. Also, once the user is actually within the junction, the routing software should not change his routing through the junction (to avoid silly turns). This approach has the added benefit of clearly marking the conflict points in a junction.

This leave the question: Which ways are valid routes through the junction? Well, we already have restrictions. Just one tweak: the junction itself is the "via" member. As before, the roads are "from" and "to" members. It would even theoretically be possible to tag a turn restriction without splitting both ways in two at the junction. Since each way enters and exits the junction only once, the routing software would know that if the junction is entered via the "from" way, it cannot exit via the "to" way.

To reiterate: a junction implies that all entry ways may be routed to all exit ways, even if there is no apparent connection. If there is a connection, it is used by the routing software, and this helps the end user see his path through the junction. If there is a restriction, this (of course) disallows certain entry/exit pairs.

I sure hope this proposal is revived - it has a lot of potential! --Eliyak (talk) 05:59, 16 May 2014 (UTC)

Common nodes of ways with each other

I think there are just too many reasons to keep all the ways connected. You might want to know how many points of conflict there are at an intersection. You might be able to cross on foot at some of the crossings and not others. And those turning restrictions are unnecessary - a router will never have you e.g. go straight and then turn right when there's a sweeping curve to the right unless it's broken. --NE2 11:25, 23 April 2012 (BST)

Just for clarity, I've created a separate section for your comment. My comment above is about connecting the ways with the area outline, not with each other. --Tordanik 18:25, 25 April 2012 (BST)

If the ways are in this area, they are all connected. The only exception would be if a highway has a different layer tag. So there is no problem with connectivity. It's all a big area of asphalt (or whatever). Conflicts are possible on the whole area, so this is more accurate at that too. I think this is a great proposal. --Janko 13:43, 25 May 2012 (BST)

One more reason for connecting ways are emergency services which are allowed to ingore turn restrictions.--Jojo4u (talk) 19:35, 17 April 2016 (UTC)

Relation use

I believe that using a relation of type collection would be an appropriate solution. The notion that relations don't render as well as other content types is not one I would support as it is close to the notion of mapping-for-the-renderer ... I'm not trying to start an argument, just expressing my impression. I also disagree with the notion that relations are more difficult to keep up-to-date than other types of content; I think this might be true of the Potlatch editor, but I don't find this to be true when using the most current JOSM editor. Regards --Ceyockey 15:18, 11 August 2012 (BST)

My arguments against relations are "Because it is much harder to keep updated and much less visible in editors.". Lets elaborate on this a little bit:

• Limited visibility: when you draw a closed way, it is obviously visible in any editor. No matter if and how the editor supports relations. The relation is completely invisible even in your (and btw my) preferred editor JOSM. To make it visible you first have to know it's there, then select it and then tell your editor to select all objects. That's a lot to do just to make something visible.
• Fragility of relations: assume a junction that is mapped with either a closed way or a relation. Now John Mapper comes along and adds the newly installed traffic light. He has no idea about neither the relation nor the closed way. He just wants to add the traffic light so he adds a node and puts highway=traffic_signals on it - end of story. Now what happened to our relation or the closed way? The relation just broke - it no longer contains all the nodes and ways of the junction. The closed way on the other hand still covers the whole extent of the junction and the newly traffic light are within this extent. So the traffic light are now part of the junction (in OSM). One of course could argue that this would not be true if the traffic light would not be within the (drawn) extent of the junction. But this should only happen if either the extent was drawn too small or the junction had changed lately. As soon as this is fixed the traffic light is part of the OSM-junction. This also shows a great strength of the closed way against the relation: if we have two mappers and one knows only about the relation/way and the other only about the feature (in this example the traffic light) then the relation will never be correct, because either mapper only has limited information. The way would be correct because this limited information is sufficient. So the knowledge needed to keep the data correct is lower which is always good (I hope we agree at least on this).

Furthermore you state yourself that "(it) might be true of the Potlatch editor ... that relations are more difficult to keep up-to-date". So you risk that a large number of mappers continuously destroy the relation. When using a closed way we would not have this problem.

And beside the mentioned problems with a relation we would also lose one information compared to a closed way: the physical extent of the junction which might be of interest for (at least) renderers. --Imagic 08:41, 16 August 2012 (BST)

Using star topology as an option, if junction 'internals' are hidden by an outline area anyway

• Identical approach suggested earlier

If the proposal is serious about hiding the internals of the junction by mapping/showing its outline, there seems to be little reason to not use simplified star topology inside it - see the last two variants in the section suggested way back. --Cmuelle8 (talk) 10:34, 14 March 2013 (UTC)

Actually, building on Lanes and combining it with

• a mapped junction outline (see area:highway=* also) and
• an extension of turn restrictions

you could

• reduce the number of turn restrictions needed
• hide away a simplified star topology inside the junction for ease of mapping

while preserving as much information detail as if lanes were mapped individually.

For this, Relation:restriction would need to be extended to permit specifying per-lane turn restrictions. You'd use the fat, :lanes-tagged osm-way leading up to the junction in question as a from member, but specify restrictions lane-wise. Having done this, one could spare out mapping individual lanes as a single osm-way and proceed in a similar manner of mapping the star topology for the fat, :lanes-tagged osm-ways, instead of the thin, single-laned ones. --Cmuelle8 (talk) 11:05, 14 March 2013 (UTC)

One of the big advantages of highway=junction is to reduce the number of needed restriction relations greatly.

This is not true, the reduction you're advertising stems from the fact that you're breaking with common mapping practice, namely to not have crossing ways without a connecting node. Encapsulating this with an area is a weak justification to break with this established practice. It increases the complexity of mapping rules, processing and rendering rules alike, so it's hard to see why this approach should be superior to others. Also, this is error prone - imagine a mapper accidentaly connecting the crossing ways (like he is used to for other ways). This should not be to uncommon. As there are alternatives it probably does not make sense to loosen this rule within a special area.

You want to combine this with a topology that greatly increases the number of restriction relations. I don't see any advantage there.

No, I see you did not get my point made above. The star topology only increases the number of restriction relations, if lanes are mapped individually. Using Lanes they are not mapped individually, hence the number of restriction relations needed is (in theory) the same as in classical mapping, i.e. w/o a star topology and w/o Lanes.

BUT, to account for the Lanes-tags of way-members, the restriction relations become more complex:

• they need to allow restrictions for each lane of a way, not for the way as a whole

• e.g. if you have one Lanes-tagged way as a from-member, and another as a to member, the tagging of the restriction relation should define how the lanes relate, and not how the ways relate
• most probably you will have to allow for multiple to-members as well, since not all lanes of the lanes-tagged from-member have to relate exclusively to all the lanes of a single, lanes-tagged to-member

For the case of restriction relations I consider it optional, whether

• the center node of a Lanes-based star topology drawn within a junction area is used as via-member or
• the whole junction area itself is used in that role.

Theoretically the latter makes it unecessary to draw any way within the junction area. A style would regenerate the junction layout based on all Lanes-tagged ways connected to the junction area. This would further visualize mistakes, as the generated junction layout will be faulty, until the mapper has correctly tagged these ways.

Furthermore, relation restrictions will be fully redundant if an algorithm is found that properly deducts restrictions itself - I presume this is possible for both of the mentioned options, i.e.

• prolonging the (Lanes-tagged) ways from the junction areas outline to a center node OR
• leaving the junction area empty.

The algorithm would walk around the outline and collect all connected highways, then evaluate the Lanes-tags for each and find matches. As long as lanes are not closed on the junction, each incoming lane will be connectable to exactly one outgoing lane, that is, if "turn:lanes" is tagged correctly. Together with "access:lanes" this will make restriction relations redundant, imho.

You would also lose the information how the lanes run within the junction. --Imagic (talk) 09:19, 26 March 2013 (UTC)

This is true, but it can be calculated from the information contained within the Lanes-tagged ways leading up to the junction, just like you calculate the layout of the way with Lanes currently. I.e. it is consistent with your approach to abstract away visual information into tags. Secondly, the assumption is made that junction lanes connect gracefully, again, just as you assume that there are no quirks in individual lanes when regenerating their layout from a Lanes-tagged way. --Cmuelle8 (talk) 13:33, 26 March 2013 (UTC)