Proposal talk:Junctions

Voting

Sounds good. Who starts the voting and when to comclude it?

junction references

How should we annotate junctions that are motorway interchanges with a different junction number on each motorway? eg. ref=M25 J3 / M23 J8 Welshie 17:06, 13 November 2007 (UTC)

I think it would make sense if, in this case (or even all cases), you tag the slip-roads that you use to leave the road in question as thejunction. For example, in the image to the right, the green roads would be M23 J8 and the red would be M25 J3. --Milliams 13:00, 3 January 2008 (UTC)

Agreed. For navigational purposes, it is easier to consider the motorway along which the driver is already travelling. Longwayround 13:22, 3 January 2008 (UTC)

Junction names

I've just proposed a draft for making more use of the junction=* tag (somebody asked for a complete vocabulary on motorway links?). See Proposed_features/Junction. Ivansanchez 04:43, 30 June 2008 (UTC)

Re label 'hint'

Positioning the label is a matter for the renderer, and excellent algorithms exist for the enclosing polygons we're talking about. Strong anti on this particular member role. --achadwick 10:29, 12 August 2008 (UTC)

Complexity: clarify when this should be applied

The main page as it currently stands seems to imply that this could be used for single-point junctions. This seems silly to me; I'd prefer it if the page clarified that this relation is for marking complex junctions, i.e. interlinked roundabouts, cloverleaf and spaghetti intersections, and potentially gyratory systems. Not for single nodes or roundabouts without much deep complexity to them - practice is already well established there, and works fine. --achadwick 10:34, 12 August 2008 (UTC)

• The junction relation can be used for applying a name to simple junction though. If the name were applied to the way instead then that would imply that it's the road name, not the junction name. --Gregoryw 10:26, 13 August 2008 (UTC)

Seems like overkill if the junction is simple enough to be just a single object. For a crossroads, it'd be quite legitimate to tag the shared node as, e.g. junction=crossroads|name=High Cross. Same deal with circular roundabout ways, for which junction=roundabout is already recommended. To my mind, doing this doesn't imply that the name of the road (as an idealised concept rather than its physical details, here) suddenly changes and then changes back again on the other side. Now arguably roads-as-ideals might need a relation of their own, and others have suggested that in the past. But I think we should keep things simple and only use relations where necessary. And they are not necessary for single-object junctions: doing so for the sake of consistency seems overly complex and just plain wrong. --achadwick 11:59, 13 August 2008 (UTC)

Integration with other proposals?

Presumably a Proposed_features/Set_of_Traffic_Signals always happens at a junction, possibly spreading out into neighbouring pedestrian crossings too. Do the two proposals belong together? --achadwick 10:40, 12 August 2008 (UTC)

Reference

A large traffic engine (junction) connecting several major highways might have different references according to which way you are on, how will that be handled on ref=*? Example of this is in areas where the reference of the junction is connected with the mile stone on the road (a junction on mile 16 are junction 16, no matter how many junctions it have been before), and seldom have crossing ways the same distance to the golden mile..... --Skippern 18:22, 25 April 2009 (UTC)

Clean-up and push forward

It looks like this proposal hasn't been touched in a while, but I think it's time to dust it off.

I see two immediate uses for this relation that would improve the quality of the map a lot:

• Sets of traffic signals (on dual-carriageways, for instance)
• Motorway junctions/exits

Both of these would benefit from this relation, because it lets us logically group things together that belong together. The rendering would be improved (one set of traffic lights could be drawn as such, and motorway exits could be placed at the appropriate locations).

I would suggest the following changes:

• Get rid of grade_separated. This should be mapped explicitly, and we can't infer from this tag which road goes on top.
• Keep location_hint (maybe rename it to center) and allow multiple nodes/ways/areas. This is useful for motorway junctions, where you could give the motorway and the cross-street as "centers" and the motorway exit number would be placed centered at their intersection at high zoom levels.
• I suggest junction can take the following values: motorway, traffic_signals, roundabout... are there any others we need? Mostly I think this just tells us what symbol needs to be drawn, if any (e.g., traffic_signals gets a traffic signal icon).

Let me know what you think. I'd like to see this put into wide-spread use. BigPeteB 18:38, 10 July 2010 (UTC)

I agree with this, we should keep the proposal simple and as generic as possible --Computerfreaked 08:52, 19 April 2011 (BST)

I'd call it "label position". --Lulu-Ann 13:19, 13 July 2010 (UTC)

My only concern is that, assuming complex motorway junctions won't have an obvious node at their center (since they are dual-carriageways), I think we should avoid creating a node which serves no purpose other than to mark the center of a junction for the renderer. It would be cleaner and easier [for the user] to just submit several nodes or ways and ask the renderer to figure out the logical center of them. Calling it "label position" doesn't really make that clear, I think. (I could be convinced otherwise, though.) --BigPeteB 02:17, 16 July 2010 (UTC)

I think one more node is pretty cheap to finally have a good rendering! Lulu-Ann

The role "label" is used by a number of other proposed tagging schemes to suggest where renderers should place the label/icon. I'm not so concerned that we use "label" specifically, but it would make sense for all relation types to use the same name to be consistent. Also, i'd say 95% of the time there shouldn't be a label role, it's only needed if an automatically calculated location (like a centroid) doesn't make sense in that particular case. -- Joshdoe 03:47, 10 April 2011 (BST)

I do agree with Joshdoe --Computerfreaked 08:52, 19 April 2011 (BST)

Are there any existing tagging schemes which use a label node, and is there any running code which uses it? --achadwick 18:36, 3 May 2011 (BST)

As discussed I removed grade_separated and changed location_hint to lable --Computerfreaked 09:54, 1 May 2011 (BST)

Typo'd "label", assume that's part of the plan :) I still think it's unnecessary. Please can you clarify what it means too? For example, should a renderer centre the label text on it, or use it as a start mark for the string (at the baseline, presumably)? --achadwick 18:36, 3 May 2011 (BST)

Ah I didn't notice the dutch spelling when I cleaned it up ;) The idea of the lable tag is that it's not mandatory and may be used when a render can't know or has a difficult time to figure out where to draw an icon. In the case of a traffic light controlled junction the centre of the junction(in whatever way the centre is determined) might not always be a logical place to put the icon. --Computerfreaked 17:44, 9 May 2011 (BST)

Page maintenance

I have attempted to merge the Relations/Proposed/Junctions page with this page. I hope I've done it correctly if not please let me know --Computerfreaked

Just areas?

Do we actually need to use relations? Serious question, since this can at least partly be expressed with areas. Relations are difficult for new mappers, and OSM should always be about making things easy for map makers.

At the moment I'm just making schematics for traffic flow, then drawing an area around the junction pieces and tagging with junction=*, examples:

• 110341980 110341980 (named)
• 31957935 31957935 (relates traffic lights, space, and some moderately complicated permissible traffic movements)

Related traffic lights and crossings go on the edge of the area or inside it ☺ The rendering of junction names leaves something to be desired, but it's fast to create and surprisingly expressive for something so simple. It maps negative space well, and allows one to determine pretty simply which points and ways are inside the junction and which are outside.

Concrete examples of where this approach fails would be appreciated. I want to see at what level of complexity my simple model breaks, if it does. Let's consider simpler options and reject them if necessary.

--achadwick 19:06, 3 May 2011 (BST)

What you are refering to is this Set of traffic signals. One objection to your proposal is the one from Eimai (see discussion page set of traffic signals):

One more problem with your area is that I've seen numerous junctions with extra traffic signals in the middle of the junction in addition to those at the end of each road. There's no way to make areas out of that, you could link them with a closed way of course, but then you need to have a way that goes criss-cross over the junction. --Eimai 11:01, 30 June 2008 (UTC)

--Computerfreaked 17:55, 9 May 2011 (BST)