This is an archive of past discussions on Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Latest comment: 11 years ago23 comments7 people in discussion
I would like to register my view that we should not be using driver location signs (DLS) to show distance on RJL's in the UK. They are not intended for this purpose, they are not always continuous over a single stretch of road and they don't always start from 0. As roads get realigned (so that the route may become shorter or longer) the DLS will become more inaccurate as I highly doubt that they will replace the signs over the entire stretch of what could potentially be a very long road.
Example 1, the M4:
This route used to take a route that was a number miles longer via the original Severn Bridge, however in the 90's it was re-routed via the new Second Severn Crossing. The DLS at Junction 21 states 189.5, then later on at Junction 23A the DLS states 218.5 (or 216.5, can't *quite* make it out).
The distance between J21 and J23A is 11.8 miles (19.0 km), so you'd expect the DLS at J23A to be 208.5, but obviously it isn't.
Example 2, A42:
As part of phase 2 of HS2, part of the A42 will be realigned, shortening the route in the middle by about half a mile. I suspect all that will happen is that the existing DLS's on that section will be moved closer together, leaving the "number" on the sign to just be a reference rather than an precise distance, as as happened in the M4 example above.
Example 3, A1/A1(M):
The location signs on the A1 reset to 0 south of Doncaster and start counting up again.
Example 4, M6
The location signs at it's southern end start at about 130 and count upwards.
How is the distance column calculated in other countries? It would be much more accurate, in my opinion to measure distance on Google Maps (is this acceptable on WP?). We should not be passing off readings from DLS signs as distances to the reader as this is not what they are. Jeni(talk)12:25, 13 March 2013 (UTC)
Examples 1 and 3 sound a lot like California's postmiles. They were defined in 1964 and haven't been updated since and they reset at county lines. So when a route gets moved even just a little bit, you get a jumbled mess.
It is acceptable to use Google Maps. It is used in the US when we can't find any sort of route log published by the state government. –Fredddie™13:18, 13 March 2013 (UTC)
I also agree we shouldn't be using these posts. There's another issue: for instance, on the M11 there are posts both on the main M11 and on routes leading off the M11, e.g. onto the A11...like this which is still technically on the M11 but shows a carriageway called "M"... how is this intended to be represented in this RJLUK schema? I doubt it's been considered. The Rambling Man (talk) 17:34, 13 March 2013 (UTC)
Personally I hate citing signs. There are a few times when there is no way around it (such as when the text of a sign has to be cited), but this isn't a good practice. Frequently the distances on these signs can be quite off. --Rschen775417:36, 13 March 2013 (UTC)
Does anybody have a better idea which they would be willing to implement – ie, whoever opens their mouth must find the reliable references concerned. Please don’t all rush at once – you will be disqualified if you forget to bring actual citations with you.
User:The Rambling Man asked how I intended incorporating the letters such as the letter "M" into the RJLUK scheme with the comment "I doubt it's been considered". I have already thought of that – he might like to look at M602 motorway to see how it has been done. Moreover, if there is an anomaly such as a letter changing, he can add a note using the <code>{{ref group = n}}</code> construction as I have done on Junction 9 of the M9 motorway (Scotland). I woudl also expect him to understand why there is a letrter "M" - after all he made an edit to the article driver location signs.
I think you need to take a step back from all this Martinvl, it's obviously getting to you. Thanks for drawing my attention to the M602 article, another you've edited and introduced these flawed templates without consensus. I cannot see there how you have taken account of these differently named carriageways. Moreover, I still don't understand why an "up arrow" should represent "Westbound", but hey, you've ignored all the responses above, so why should you pay any attention to this. We don't actually need these junction distances, not at all, especially as they're clearly using dubious sources. I'm not sure why you think making "an edit" to a particular article means that an editor has digested and understood the entire article. For instance, your appalling "timeline" on the M4 article is a case in point, total joke, utterly confusing. Anyway, as I said, perhaps take a break Martinvl, so you can take the opportunity to reply to all the threads above which you're studiously ignoring. The Rambling Man (talk) 18:37, 13 March 2013 (UTC)
As Martinvl has noted, I've removed his non-consensusal use of his own bespoke templates on the M602 page, of course please find his version here. Similarly his preferred version of the M9 page which had no consensus is here. Thanks! The Rambling Man (talk) 18:58, 13 March 2013 (UTC)
We should not be using signs as a source, for all the reasons given. I don't like the idea of using Google Maps either. I would rather just not give the distances if there is no real-word reliable source for them. That's what WP:V says, after all. --John (talk) 18:29, 13 March 2013 (UTC)
May I propose that we have a single column marked "MP" with a note stating "MP = Values displayed on marker posts and/or driver location signs". We would not specify any units but we would wikilink to both the article Driver location signs and to the Department for Transport document describing the signs. Such a column would be in full accordance with WP:V. If somebody can find a reliable source showing giving distances from the start of the motorway in miles, that could be incorporated onced it has been verified and the notes amended to explain the two columns to the reader. Martinvl (talk) 20:24, 13 March 2013 (UTC)
What consensus? I have only just made the suggestion and within one minute you took it upon yourself to decide consensus and to proclaim such consensus. Martinvl (talk) 20:29, 13 March 2013 (UTC)
I understand that which is why I posed the question. I also understand that consensus involves everybody, not just Rschen7754 which is why I berated him. Martinvl (talk) 20:40, 13 March 2013 (UTC)
Has anyone attempted to contact the Highways Agency or DfT to see if such sources are available? They can't say no if we don't ask. –Fredddie™20:32, 13 March 2013 (UTC)
I was in contact with the DfT a few years ago. Sometimes somebody will send you a spreadsheet under the counter, but the offical line, as I understand it, is that this information is merchandise for which people like mapping companies must pay. This is standard Britsh Government practice - for example, if you visit the Post Office postcode page you can find fifteen postcodes in a day without charge - great for the private user, but the commerical user has to pay for the privillege. Martinvl (talk) 20:38, 13 March 2013 (UTC)
Perhaps we should try again. If we play the Wikipedia card, we might get that spreadsheet under the counter. –Fredddie™20:43, 13 March 2013 (UTC)
Happily, that example no longer stands; as mentioned here a comprehensive postcode listing is now freely available from the Ordnance Survey here. We now have counter-examples of access to detailed real-time mappable data such as availability of hire bikes in central London. It might be rewarding to make another attempt to find sources. NebY (talk) 10:36, 30 March 2013 (UTC)
User:Fredddie and I have both had a look at this source and it appeared to be too good to be true. It has a number of problems. Fredddie made a snapshot of all the records pertaining to M898 motorway which can be found here. There are three records in referencing sectors of the M898, giving lengths of 2645 m, 1453 m and 254 m respectively. Neither of us was able to decipher the associated OSODR values. I attempted to identify the sectors by measuring sectors on Google Earth - see diagram to the right. We see a fairly good correlation, but not all the sectors that on the diagram map onto database records - I suspect that they are in the database somewhere, but are associated with the M8 rather than the M898.
This raises the next question - how do we measure the length of the M898 (which is really a spur from the M8) - is it length AB, EB, XB, YB or CB, or should we rather not try and calculate its length, but just quote the appropriate marker posts that are associated with the motorway (not easy in Scotland, but in England we have driver location signs while, for a short period the Welsh published the grid coordinates of all their marker posts on the web. I was able to capture them before they were removed.
Latest comment: 11 years ago6 comments4 people in discussion
I think this is one where the UK might be doing it better than elsewhere. Having "blue" = motorway, "green" = primary route, "white" = secondary route helps explain what the colours used in M5, A38 and A379 mean to someone unfamiliar with them (eg an American).
Similar information could be useful in the US: A footer with = "Interstate", = "Interstate business loop / spur", = "US Route", helps to explain what the shields mean to someone unfamiliar with them (eg a Brit). Explanations for the relevant state/county routes would be good too. That would need switches to only display those relevant to the specific RJL.--Nilfanion (talk) 11:59, 6 April 2013 (UTC)
Those legend for those footers were put to explain the meaning of the colored table headers, which some argue are redundant or unnecessary. I don't think putting the icons in the footers would be necessary and would add more visual clutter than is needed. -- LJ↗17:05, 6 April 2013 (UTC)
The real purpose of the footer is to explain the colours used within the table itself (the green for concurrencies, red for limited access etc), as they have no natural meaning, so need an explanatory note.
The shields used within the table on US roads, and any colour patches on UK roads, do have a natural meaning outside WP, but unless you know that meaning they mean nothing to you. Providing minimal explanation - as in "What's that blue shield mean?" or "What's that green colour mean?" could benefit readers.--Nilfanion (talk) 17:25, 6 April 2013 (UTC)
True, and that might be sufficient for US roads. A problem that does affect UK is A roads with primary and non-primary sections. For instance at M5 Junction 21, the A370 to Weston-super-Mare is primary and the A370 to Congresbury is not. So we might have , and the white version of that, in the same point of a RJL and both next to a wikilink to the same article (A370 road)... Without an explanation of why one is green and one is white (to have both as green would be incorrect).--Nilfanion (talk) 17:58, 6 April 2013 (UTC)
The US doesn't have a government-coordinated color coding scheme like the UK does, so this isn't a very good idea. Also, we would have to include dozens of state/county highway shields in {{LegendRJL}} if this came to pass - see U.S. Route 491 for a route that goes through three states. Finally, Scott's right about the shield being explained immediately after it is used. --Rschen775421:56, 6 April 2013 (UTC)
Color question
Latest comment: 11 years ago11 comments4 people in discussion
Is this proper use of the purple color? [1] (i.e. should intersections where a free road interchanges a toll road be colored purple?) As currently worded the guideline is sort of ambiguous. —Scott5114↗[EXACT CHANGE ONLY]21:38, 4 April 2013 (UTC)
I would say yes. However, like any of the other colors, you should say something in the notes column explaining the purple color. Turnpike interchanges are not always tolled, you know. –Fredddie™22:58, 4 April 2013 (UTC)
Too many colours can have a bewildering effect. The tolled areas that I am aware of (all in Europe) are signposted with the words "Toll", "péage" (French) or "Zoll" (German). Examples are here (United Kingdom) and here (France). Also, what do you do if a slip road splits, one part to a trolled sectikon and the other to an untolled section. For example, if you look at the French intersection, you will see two slip roads that are 300 m apart - the road to [[[St Omer]], Arras and Reims is a tolled road while the road to Merck is untolled. Had this interchange been built to UK standards, there would have been been one slip road which would have split, wheras Germany or the Netherlands would have had a service road. In short, as it is the road that is tolled, not the interchange, maybe the colour shoudl be left off. Martinvl (talk) 06:27, 5 April 2013 (UTC)
So yes to the color if you must pay a toll to access the road and no color if you do not have pay a toll even if it's a toll road? I think we should codify that. –Fredddie™22:29, 5 April 2013 (UTC)
And I assume the toll doesn't have to be assessed right at that ramp, correct? (i.e. one could drive down the toll road for a bit and have to pay at a barrier toll.) Another question: what would a good note be here? Just "Toll road"? —Scott5114↗[EXACT CHANGE ONLY]04:35, 6 April 2013 (UTC)
On further reflection, any colour should only reflect sections of this road for which a toll is payable. Even this can cause problems, for example the tolls on many British bridges are payable in one direction only. (The authorities work on the principal that all traffic going one way will return, so collecting a double toll one way and nothing the other way reduces the cost of collecting the toll without affecting the amount commected). Martinvl (talk) 06:32, 6 April 2013 (UTC)
I think the color should be used only at points where somebody traveling on the subject roadway (i.e. the roadway the junction list is created for) would pay a toll if they were to leave highway at that point. Thus, if you're on a free road and you exit to a ramp to a toll road, then that junction is purple. The purple would also be acceptable for a row listing a mainline barrier toll plaza (such as a bridge or tunnel). However, if the subject article is a tolled facility, the purple color should only be used at barrier toll plazas--this helps prevent overuse of the purple color since it should be obvious that a toll will be paid upon entry or exit to the facility otherwise (an explanatory note above the table could clarify if deemed necessary). The use of purple on I-35 in Kansas is excessive, IMHO. -- LJ↗07:05, 4 June 2013 (UTC)
I should point out that I believe this color was initially intended to be used only for interchanges which require use of electronic toll collection like EZPass in order to legally use them (i.e. there is no cash or pay-by-plate option there). —Scott5114↗[EXACT CHANGE ONLY]20:44, 4 June 2013 (UTC)
It was, but there was support for being able to use the purple color for other toll uses as well. I used it for toll barriers, like LJ described above, on Interstate 90 in Illinois. I think some guidelines should be hashed out, though. –Fredddie™22:26, 4 June 2013 (UTC)
OK, so, correct me if I'm wrong here. Purple should be used:
When there is a feature (toll bridge, particular interchange) that requires the payment of a toll on an otherwise free subject road.
When there is an exit from a subject free road to a toll road.
When there is an interchange that requires ETC only on a subject toll road where cash is otherwise accepted.
I fear we may be having the purple color doing too much. I can kinda see how the first two are related, but the ETC one seems like it could be a bit confusing if one is familiar with the first two usages. Furthermore, there is the question of whether the purple should take precedence over incomplete, concurrency termini, etc. —Scott5114↗[EXACT CHANGE ONLY]10:13, 27 June 2013 (UTC)
"Incomplete access"
Latest comment: 11 years ago56 comments9 people in discussion
Okay, so at the footer of a lot of the tables, there's a category for "incomplete access", in pink. Many tables use this key by simply assuming a reader will understand that pink means incomplete access (whatever that really means). Firstly, WP:ACCESS says we shouldn't be using colour alone to convey information. Secondly, "incomplete access" seems a somewhat nebulous definition of a junction. Apparently it means that for some junctions it's only accessible from one particular direction? I'm not clear on it, and I tried to add some text to a US list (here) and was undone in double-quick time twice over. Hence I'd just like to understand what "incomplete access" means (and I'm sincere about this, in the UK, I have no idea what "incomplete access" means to a junction) and how to represent it to our international English-speaking audience (not just our US friends who seem to clearly understand this, along with "concurrency terminus" etc....!!!!) Comments, nice ones, encouraged. The Rambling Man (talk) 22:36, 12 April 2013 (UTC)
Did you even read the existing note in the row? It states "Eastbound exit and westbound entrance". That goes beyond just stating "incomplete access" by saying how the interchange's access is incomplete. Therefore we are not using only the colors to portray the incomplete access, but also stating what kind of access the interchange has. TCN7JM22:39, 12 April 2013 (UTC)
Did you even understand that some motorways around the world don't "expect" to have access all ways round? "Incomplete access" is not easy to understand at all. Many "regular" road junctions in the UK have this so-called "incomplete access", I don't think our international readers should have to be able to interpret the text in the table to then synthesise an understanding of something called "incomplete access". The Rambling Man (talk) 22:43, 12 April 2013 (UTC)
No, because unless noted otherwise, that's taken for granted. However, "incomplete" and "complete" access is something that needs to be discussed, what does this actually mean? Remember this is for the whole of the English-speaking world, not just the US. In the UK, we don't have a concept of "incomplete access".... The Rambling Man (talk) 22:48, 12 April 2013 (UTC)
But apparently it's not in the UK, as you've said elsewhere - when more interchanges have incomplete than complete access, it can't be taken for granted. --Rschen775422:51, 12 April 2013 (UTC)
Ok, let's get to more basic terms. What does "incomplete access" mean? It's not defined in the list, not linked in the key. It doesn't make sense without an explanation. It's been noted above that it means you have to have the "four ramps" or whatever, but in the UK we have no such concept as "incomplete access". The Rambling Man (talk) 22:53, 12 April 2013 (UTC)
Incomplete access means that one or more ramps are missing from the junction, so you are unable to make certain movements at that intersection. The note on the CA-52 list, "no access from SR 52 east to I-5 north", is conveying why the row is pink. It means that if you are on SR 52 east, you can't get on I-5 north, because that ramp is not there. You were probably reverted because "incomplete access" is redundant to that note, and less expressive. —Scott5114↗[EXACT CHANGE ONLY]22:44, 12 April 2013 (UTC)
The key doesn't even explain what "incomplete access" means. It may mean something to the US contributors, but it doesn't mean anything to UK readers. The reason I added the text was that we shouldn't be using colour alone to convey information, especially when we are placing the onus on our international audience to understand what pink means. The Rambling Man (talk) 22:48, 12 April 2013 (UTC)
Ironically, in that same list, one of the junctions states "No access to southbound Cuyamaca Street from westbound exit" but it isn't coloured pink, despite having "incomplete access" as far as I can see.... The Rambling Man (talk) 22:56, 12 April 2013 (UTC)
And while we're there, why is "Eastbound exit and westbound entrance" (18A) in pink but "Eastbound exit and westbound entrance; signed as exits 18B (south) and 18C (north)" (18BC) not in pink? What makes the former "incomplete access" and the latter "complete access" based on the text? I'm sure there's a good reason, but I'd expect to be able to understand it, and would hope our Featured Article would enable our international (i.e. outside the US) readers to understand it. The Rambling Man (talk) 23:02, 12 April 2013 (UTC)
Is movement in all logical directions possible at an interchange, or are there missing ramps that would prevent you from this? --Rschen775423:06, 12 April 2013 (UTC)
I'm not sure what "movement in all logical directions" means. Nor should we assume there are "ramps". I don't want to start a one-size-does-not-fit-all debate here, but my beef is with the legend (which is unlinked, unexplained and incorrectly used per WP:ACCESS, using colour alone and assuming that our readers understand this project's definition of "completeness"). Small steps could fix that, I've already provided three different scenarios in the one article alone that have different outcomes. Plus I have to go to bed. But please continue in my absence. I'll rejoin in a few hours. The Rambling Man (talk) 23:11, 12 April 2013 (UTC)
"All logical directions" is simple. Where two roadways intersect, is it possible to go from northbound to eastbound, northbound to westbound, southbound to eastbound, southbound to westbound, etc. For an intersection/interchange of two crossing roads, there are eight possible traffic movements between the two roadways. If it's a three-way T-intersection, there are only four possible movements between the two roadways. The interchange between M-6 and US 131 and 68th Street would have 16 possible connections between the three roadways, but there is no connection between M-6 westbound and 68th Street. "Incomplete access" means that of the possible movements, one or more are missing. Imzadi 1979→23:51, 12 April 2013 (UTC)
Rather than get into a robust debate about this, how would people feel about changing the words "incomplete access" to a phrase that's still short enough to fit into the legend, but is more specific? --Rschen775423:03, 12 April 2013 (UTC)
See above on the definition. I disagree that a change in terminology is warranted. The notes, when used properly will explain what the situation is that prevents the interchange or intersection from providing complete access between the intersecting roads. Imzadi 1979→23:51, 12 April 2013 (UTC)
In my view "incomplete access", being a generic term, is sufficient. If we look at M25 motorway we see that three such exits have the colouring of "Incomplete access" - Junctions 1b, 19 and 31. In each of these cases the reason for incompletre access is identified as follows:
J1b (Anti-clockwise) "Exit via J2 – Dartford (A225)"
J19 (Anti-clockwise) "No exit"
J31 (Clockwise) "Access via J30"
I think that all of these clarify what is meant by "Incomplete access"
Scott, how about "not connected in all directions (see notes)"? It's a bit shorter and avoids the "access" term, which I'm sorry to say makes me think more of wheelchair ramps than slip-roads or off-ramps. NebY (talk) 12:16, 13 April 2013 (UTC)
It's okay if you know what to look for and are part of the project. Try asking people outside the project. I still can't get to grips with the fact we have, in the route 52 article, notes which say "no access" which aren't pink. Surely people must see this is confusing? And why isn't "Eastbound exit and westbound entrance; signed as exits 18B (south) and 18C (north)" (18BC)" in pink? Why do I have rely on being able to interpret these esoteric notes and work out why some are pink and some aren't? The Rambling Man (talk) 09:13, 13 April 2013 (UTC)
If the intersection of two roads only has three legs (say there's no continuation of the east–west roadway to the east), then there logically would be no need for a way for traffic to enter the east–west highway going east if it ends there. The notes still describe the highway as only having an eastbound exit, as all eastbound traffic must exit, and a westbound entrance, as the only way to access SR 52 westbound is to enter there. That's not incomplete access though, because all logical connections are still provided. Imzadi 1979→09:20, 13 April 2013 (UTC)
Thank you. How does a reader who is not aware of "all logical connections" in this case (where you have only three legs) understand this? It seems a case of "if you know, you know" and if you don't know (like me, or presumably a large volume of our non-road project readers) then it's just confusing. The Rambling Man (talk) 09:30, 13 April 2013 (UTC)
Well, it's assumed that turning off the road into a ditch is not a logical connection, and neither is making a U-turn. --Rschen775409:34, 13 April 2013 (UTC)
At the terminus of a road, it's assumed that you can not turn in the direction the road would have continued in... because the road has ended. --Rschen775409:38, 13 April 2013 (UTC)
Ah, I give up. I'm clearly not getting it, maybe it's the terminology used or maybe I'm just too stupid. It remains unclear to me, I imagine it would be unclear to many others. More importantly, making our readers understand this "logical exit" and to derive it from the notes, so they understand why some are pink and some aren't remains an issue as far as I'm concerned. The Rambling Man (talk) 09:43, 13 April 2013 (UTC)
British road atlases use the word "restricted" (my AA road atlas) or "limited" here rather than "incomplete". The word "incomplete" implies "still under construction". I therefore suggested that the word "incomplate" be replaced with either "limited" or "restricted". Martinvl (talk) 15:20, 13 April 2013 (UTC)
"Limited" and "restricted" make me think of weight/height limits and pinch-points. How about "not completely connected" or "not fully connected"? NebY (talk) 21:42, 13 April 2013 (UTC)
"limited access" seems clear to me. I don't see how that could be confusing. With that said, "incomplete access" is clear to me too, but I'll admit that's a common term on US maps and I'm perhaps just used to it. Above it is mentioned that "incomplete access" implies that access is under construction, which is correct. It's an access that hasn't yet been opened to traffic or doesn't yet exist. Dave (talk) 22:36, 13 April 2013 (UTC)
Checking some maps in my possession, another common term is "partial interchange" (vs. complete interchange). How about those? Dave (talk) 06:40, 14 April 2013 (UTC)
That sounds better for US RJLs, but as per [[[WP:ENGVAR]], the word "junction" should appear on UK RJLs rather than the word "interchange". Martinvl (talk) 06:57, 14 April 2013 (UTC)
And the color is used for at-grade junctions in the US where access is restricted, so one can't assume it would only be used for interchanges. Imzadi 1979→07:15, 14 April 2013 (UTC)
I've made a diagram that might hopefully explain what constitutes "complete" and "incomplete" access. I can point out some real-world examples these are based on if it would help to see satellite photos. —Scott5114↗[EXACT CHANGE ONLY]09:33, 14 April 2013 (UTC)
I think that by now those of us who are taking part in this discussion know what is meant by the term "incomplete interchange" in the context of a RJL. We are debating whether or not this is the appropriate wording taking into account terminology used elsewhere in both the UK and the US. Martinvl (talk) 14:47, 14 April 2013 (UTC)
Don't speak on others' behalf Martin. Certainly "interchange" should not be used in UK articles, we use "junction". I'd still like to gain some outside-of-the-project views as to what Joe Bloggs thinks "incomplete junction" or "incomplete access" means. To me this means unfinished, not that the junction provides limited access to certain directions. So far, all those telling me how obvious this terminology is is either an American or a member of this project, or both. Don't forget we need to appeal to everyone at Wikipedia, not just the project members, or those who already know this stuff. The Rambling Man (talk) 15:51, 14 April 2013 (UTC)
In common UK vernacular, what terms are used to distinguish between an at-grade junction, verses a junction with grade separations and connecting ramps? That may provide some perspective in coming up with a common terminology. Dave (talk) 16:23, 14 April 2013 (UTC)
I checked the Highway Code which is the government-sponsored "rules of the road" for learner drivers (see here). We don't distinguish between at-grade junctions and grade-separated junctions, though we do have roundabouts (in large numbers) and cross-roads. In practice, there is little or no confusion as to whether a junction is grade-separated or not - any intermediate-sized junction is usually a roundabout (or in sme cases a "gyratory system") and we sometimes use teh word "Flyover" where appropriate (for example, the Hammersmith flyover). Martinvl (talk) 16:53, 14 April 2013 (UTC)
Well there you go, I've been driving for twenty years in the UK, Europe, South Africa, New Zealand and Australia and haven't come accross the term "at-grade junction" ever. Nor do we ever talk about "ramps".... not in a normal community (i.e. outside of this project!). Hence my concern we're not particularly accessible to many non-project readers. The Rambling Man (talk) 16:57, 14 April 2013 (UTC)
Accepted, we do have the odd "interchange", a neologism I suppose, another degradation of British English. Yes, certain junctions are formally known as the "XYZ Interchange" but usually, in fact almost always, these are referred to as "junctions". Moreover, I still have no idea what an "at-grade junction" is (nor "grade-separated junction" as you now introduce), nor do we ever use "ramp" in this context, a ramp is something kids launch themselves off on a BMX (or Evel Knievel launched himself over parked cars), unless, as Martin points out below, you mean "slip road"? The Rambling Man (talk) 19:32, 14 April 2013 (UTC)
What about using the term missing movements? I think this would be relatively clear to the average reader, especially when explained with the required note. It avoids needing to distinguish between 'interchange'/'junction' and other regionally specific terminology. It also allows for the using a phrase like "eastbound exit and westbound entrance" at a route terminus without the red background since no logical movements are missing. -- LJ↗18:03, 14 April 2013 (UTC)
No - this would probably confuse all readers, especially those readers whose native language is not English. We need to use the same vocabulary that is used by the readership. Maybe we need to recognise that the Americans and the British have different vocabularies when it comes to road - to the extent that in the United Kingdom, pedestrians are advised to always walk on the pavement, but they are not advised to always do so in the United States.
(ec w/ Scotts post below)If you want to learn what grade separation or At-grade intersection mean, the answers are on this very website. There is no article for ramp, but both the articles on grade separation as well as interchange (road) explain that it is an Americanism with the UK equivalent being slip road. Or you could make a 4th post bemoaning this horrific introduction of new big and complicated words. (OK sorry for the sarcasm I couldn't resist). I doubt this is an example of the degradation of British English, the Guardian article makes it clear that the word is in use in both official contexts as well as familiar contexts, so it's no more of a contamination than anything else really. I didn't have to scour the internet to find those, I spent all of 3 seconds to find those 5 or 6 usages of the term. The larger point being is there's no value in degrading this into an argument over British verses US English. The two are more alike than different and I'm sure working together, mutually understood wording can be found, or as Scott just proposed the use of templates can change the wording as appropriate. Dave (talk) 22:30, 14 April 2013 (UTC)
{{LegendRJL}} already displays different information if you tell it it's on a British article. Rather than perform the impossible task of trying to reconcile British English with American English ("ramp" and "interchange" are common terms here), why don't we just have it display the appropriate terms on British articles? Then we could focus on just making sure that the terms used are common in the country they're displayed on. —Scott5114↗[EXACT CHANGE ONLY]22:13, 14 April 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I propose that that the current situation is untenable. Three sentences and three examples were added some time ago as a compromise, but in the end, I think it has compromised the guidance of this page. To resolve this situation, those permitted deviations should be dropped, and the following text would need to be removed to drop the derogations that were previously added to allow the UK-style format tables.
From the "Standard columns" subsection:
"These columns may be omitted entirely if there is not consensus on what subdivisions to use." would need to be dropped from the discussion of geographic columns.
"This column may be split by carriageway or direction based on local signing practices." would need to be dropped from the discussion of the Destinations column.
"If the Destinations column h been split into two columns by carriageway or direction, omit this column." would need to be dropped from the discussion of the Notes column.
From the "Colors" subsection, the entire second table on UK-specific colors would need to be dropped.
From the "Table footers" section, the third example would need to be dropped.
From the "Examples" section, the current "M5 motorway" example would need to be dropped, or replaced with a compliant example.
No reason why the UK should use an entirely different format from the rest of the world's English Wikipedia articles. Rschen775418:54, 31 March 2013 (UTC)
I think the deviations should be eliminated. I would be willing to keep the provisions for separate carriageways, provided the junction number column was put in the standard place and a two-column span be used where each carriageway's destinations are identical. LJ↗22:15, 31 March 2013 (UTC)
I'm not sure why the British road junction lists need to be so intricate (and based on Google maps images and these posts that Martnvl is so keen on). This isn't a map, this isn't a replacement for a TomTom, this is Wikipedia, we are here to provide an encyclopedic article on everything, including road junction lists. Wikipedia is not here to replace sat-navs. Let's keep it simple, and common. The Rambling Man (talk) 20:05, 3 April 2013 (UTC)
Support: Missing the location out can lead to FAC 1b / FLC 3a (comphrensiveness) failures, as the location of a junction is significant info. Because of the overreliance on advance signs, classified roads at the junction may not be mentioned and that could also cause comphrensiveness fails. Displaying both carriageways is potentially confusing as all destinations are accessible from both directions (unless its limited access), but a reader may not get that impression. The UK specific header can be retained or dropped (I'm neutral), it doesn't need an explanation as to why its blue. Suggest deriving a replacement from my example 2a, as its useful to display a version with coordinates. However, retain the UK-specific "colors" and "table footers" at this time - I think they help with interpretation of the marker icons in the RJL itself. (Note: This is not about complying with the US, but to give best display for UK roads.)--Nilfanion (talk) 11:48, 6 April 2013 (UTC)
Oppose the removal of the only example with coordinates; and the removal of UK-specific colours, which match UK road signs, as set out in UK law (but see note in section below). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits10:49, 1 April 2013 (UTC)
Oppose - Another attempt to steam roll things through with no understanding of the subject in hand. Jeni(talk)09:38, 2 April 2013 (UTC)
Comments on the proposal
The MoS is meant to be descriptive, not proscriptive ("permitted deviations", indeed!). Attempts such as this to change what is done rather than update the MoS to describe what is done, are doomed to fail. They cannot be binding on editors reaching contrary consensus on article talk pages. Further, the proposal as drafted is vague and requires prior knowledge. It should be redrafted making explicitly clear what is being proposed, and its implications (for instance, removal of the only example with coordinates) and what alternatives (status quo or otherwise) are on offer. As many articles may be affected, it should then be advertised as a centralised discussion. Has this proposal, which has specific implications for articles on UK subjects, been mentioned on UK-specific noticeboards? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits10:59, 1 April 2013 (UTC)
Coordinates were not governed by this guideline as Andy keeps trying to point out. The lack of an example showing them should not be considered a reflection on their usage or not. That is a separate debate where we have agreed to disagree. Imzadi 1979→18:20, 3 April 2013 (UTC)
I don't think the proposal is the right approach, as I don't see it as a simple yes/no decision. There are several options, and its possible that some features being used on UK articles may be worth adopting globally. It feels like attempt to steamroll a "you have to change" against a "everything is fine the way it is" opposition, as opposed to both sides actually trying to improve matters.
That said, some UK specific aspects do seem pointless. The colours for instance. Does a table in the article on a motorway really need a blue header that repeats the road number - isn't that a redundancy?--Nilfanion (talk) 12:16, 3 April 2013 (UTC)
There is no attempt to "steamroll" here. This is an attempt to gain consensus to modify some of the MOS, which we've been trying to do for months. TCN7JM12:40, 3 April 2013 (UTC)
This is slightly ridiculous - what features? RJL is a tried and tested format, used in over 40 featured articles. --Rschen775417:14, 3 April 2013 (UTC)
The one feature that the UK tables was supposed to be using was the dual mi/km column set up for distances, a practice that was implemented in the templates used in the US, Canada and elsewhere. Not all articles have been updated to use the templates, but as they are, the dual distance column set up is appearing in a wider assortment of articles.
That said, the table format used in the UK isn't even consistent in application across the articles. Many articles lack a distance column, let alone have both of them. They don't all apply the color key footer consistently. They don't use the formatting mandated by MOS:DTT that this guideline repeats as a requirement for headers and scopes. The templates for the US, Canada, etc, have those accessibility requirements built in now.
The UK format isn't really consistent with the format used by the upper-tier articles from the US, Canada, Croatia and Australia. The format fails to meet the requirements of other sections of the MOS, namely MOS:DTT in terms of accessibility, and as used, fails to use capitalization and italics properly. The standards have moved on over time, and the format should be deprecated in favor of the one that's been tested consistently at our upper-tier review forums. Imzadi 1979→18:20, 3 April 2013 (UTC)
Just a quick note, WP:FLC does require a compliance with MOS, which for technical articles like lists of road junctions means compliance with MOS:DTT, for the benefit of all readers. Of course, a regular (non-featured) article need not have these very simple additions, but it should be encouraged. The Rambling Man (talk) 18:57, 3 April 2013 (UTC)
FLC may "require compliance" with the MoS, but since the MoS doesn't require that we do anything, that's pretty meaningless. And we certainly are not required to comply with FLC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits19:35, 3 April 2013 (UTC)
Yeah, the overuse of italics isn't very helpful at all. I was trying to explain that compliance with MOS is useful. Nothing more. I never said you (or anyone) is required to comply with FLC, or if I did, perhaps you can show me where. Just forget what I said, that's much easier than discussing this further, obviously. The Rambling Man (talk) 19:38, 3 April 2013 (UTC)
Andy, just a quick note, I understand your point, and perhaps I hadn't explained clearly enough, I was only talking from an FLC perspective where we tend to err on the side of the MOS and comply with MOS:DTT. It's a good thing, so screen-reading viewers can benefit from our lists. Frankly I'm surprised the rest of Wikipedia hasn't adopted a similar approach to WP:ACCESS but perhaps it's too difficult or too technical for some. In any case, perhaps I went too far with the italics. Hopefully you get where I'm coming from. If not, feel free to ping me or leave me a message, I'll happily try to explain what I've being trying to explain! The Rambling Man (talk) 20:42, 3 April 2013 (UTC)
In fact, italics are an issue in another sense, as well as ALLCAPS, as many UK road editors have insisted on leaving violations of those MOS guidelines in place in articles, and even revert warring violations of those back in. On another note, we want to set up road articles for success at FAC and FLC. In the US, we have designed our standards so that if an article meets those standards, it will be successful at FAC (we are working on a standard for lists). Surely that must be something that the UK roads project is interested in as well. --Rschen775421:12, 3 April 2013 (UTC)
Rschen, you should have said "it will likely be successful at FAC..." USRD standards have come about because of success at FAC, not the other way around. I know what you meant, but I think we should be clear for those who may not have known what you meant. –Fredddie™21:20, 3 April 2013 (UTC)
No, I meant what I said; if an article meets the USRD standards, as evaluated at ACR, it is virtually guaranteed to pass a FAC, provided that it isn't an article like California State Route 282 which is not long enough. We have repeatedly changed our standards to more closely match the FA criteria over the years. Over the last few years we have had an 85-90% success rate at FAC; the vast majority of the fails are due to lack of reviewers at the FAC stage. --Rschen775421:26, 3 April 2013 (UTC)
Getting back to reality, "Does a table in the article on a motorway really need a blue header that repeats the road number - isn't that a redundancy?", it certainly is true that adding colours or graphics introduces "redundancy" in all articles, but I believe that making an article "attractive" to our readers without transgressing our guidelines and policies provides maximum benefit to the reader. Maybe others disagree. The Rambling Man (talk) 19:54, 3 April 2013 (UTC)
I will agree, it looks nice. The problem is, though, using different colors there means we have to add a color key to the bottom of the table to explain what each color means. Obviously this is no "trouble" at all because we have a template for it, but is it worth having to have a whole second line to the legend just so we can have a decorative table header? —Scott5114↗[EXACT CHANGE ONLY]20:16, 3 April 2013 (UTC)
Fair enough, but we could use a template which has switches for a UK colour scheme. I'm not convinced one way or another, my key thinking is that this encyclopedia isn't here to replicate road signs or anything, it's here to provide encyclopedic information about roads (amongst other things like frogs and space and toffee). A second legend is technically possible of course, but perhaps not required. I would say, though, that the current legend has phrases that I'm not familiar with (like "concurrency terminus") so we'd need to deal with that. The Rambling Man (talk) 20:23, 3 April 2013 (UTC)
The current template does have such a switch; the UK-specific legend is hidden on all non-UK articles. We could clarify "concurrency terminus" with a link, but that's sort of a separate discussion, so perhaps we should wait until things have settled down and we have a stable policy before we get into that. —Scott5114↗[EXACT CHANGE ONLY]20:36, 3 April 2013 (UTC)
I think that the colored header at the top is a bit redundant, but if that was a sticking point, I would be fine with leaving it be as a potential compromise. --Rschen775421:01, 3 April 2013 (UTC)
The header does feel a bit redundant IMO. That said, if its useful on UK roads it should be equally useful for other countries too (eg Interstates having the shield on the relevant green background?)--Nilfanion (talk) 21:15, 3 April 2013 (UTC)
It's not useful in the United States, as there is no government-coordinated color coordination system, and because it borders on violating WP:MOSICON to have the shield there yet again when it already is in the infobox. --Rschen775421:17, 3 April 2013 (UTC)
The colours are not there to "replicate road signs"; but to emphasise encyclopedic information in a manner which is widely understood by a large percentage of the likely audience. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits21:58, 3 April 2013 (UTC)
Examples of UK variants
I've created a few different versions of the M5's RJL and placed them on this page. These illustrate the options discussed in thread. I've put a few comments on that page explaining some design choices I made too.--Nilfanion (talk) 10:22, 4 April 2013 (UTC)
I dropped the coordinates not because I think they should be kept/removed but for simplicity. There is no standard on how to display them, and their inclusion/non-inclusion isn't the reason for this discussion.--Nilfanion (talk) 10:41, 4 April 2013 (UTC)
Might be easier to add more "with coordinates" versions? So existing without/with coords, global without/with, modified global without/with?--Nilfanion (talk) 10:58, 4 April 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Coordinates
Latest comment: 11 years ago32 comments9 people in discussion
I think you reverted more than just that. There appears to have been an agreement to remove UK-specific deviations (see a few items above) and that's what's happened. (I have no dog in this fight, I just saw this slow motion revert war on my watch list). The Rambling Man (talk) 20:36, 26 June 2013 (UTC)
A single change was made. It was bad. I reverted it. Further, the proposal !voted upon (which I said was unclear and should be reworded; but wasn't) included (my emphasis): "the current 'M5 motorway' example would need to be dropped, or replaced with a compliant example". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits20:43, 26 June 2013 (UTC)
Ok, well the removal of UK-specific deviations included the use of geotags, which don't appear to be used in any other form of RJL, was just a single edit, i.e. removal of the UK-specific tables and associated geotags etc. That's all I'm saying. Probably would have been worth arguing the point on the talk page over the past couple of months. Nothing more to add here from me. The Rambling Man (talk) 20:45, 26 June 2013 (UTC)
You appear to have overlooked the comments on this very point which I and others made, in the now-closed section, above. The use if coordinates is not a "UK-specific deviation". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits20:48, 26 June 2013 (UTC)
Sorry, you appear to have overlooked the fact that I have no interest in this really other than to dissuade you from slow-motion revert-warring and to look at the detail of the closure. If I missed the other examples in the MOS where geotags where used then I apologise. Last post here from me. Good luck with your geotags! The Rambling Man (talk) 20:49, 26 June 2013 (UTC)
Feel free to add coordinates to another example with the same caveats that the UK version had, but don't revert the consensus (as judged by an uninvolved editor) to remove the UK deviations. –Fredddie™21:20, 26 June 2013 (UTC)
The existing example needs to be junked for other reasons. Look, Andy, this discussion isn't even ABOUT coordinates, you're just inserting yourself into the discussion for the mere purpose of being obstructionist so you can continue your coordinate-worship. Knock it off, dude. —Scott5114↗[EXACT CHANGE ONLY]22:16, 26 June 2013 (UTC)
To reiterate: we were told that "the current 'M5 motorway' example would need to be dropped, or replaced with a compliant example.". The former option was opposed. If you believe that "the existing example needs to be junked", then feel free to apply the latter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits23:10, 26 June 2013 (UTC)
There is no good reason to retain an example, any example that contains formatting that runs contrary to the text of this section of the Manual of Style. To do so, when the text of the guideline has been altered, is confusing. In fact, until a year or so ago, this section of the overall MOS was neutral to the usage of coordinates. Given the existence of MOS:COORDS, it should not be necessary to include an example here using them. Imzadi 1979→01:22, 27 June 2013 (UTC)
Although I obviously have a known and cemented stance on the topic, I honestly believe you need to step back Andy and see that this is not our attempt to sweep coordinates under the rug. This is an MOS page that should show fellow editors the compliant examples that follow the guidelines set out within. The implementation of coords is not dependent upon these examples, and so the removal of an example does not change the consensus or the guideline. Hell, even if the example is cleaned up, I'm not going to complain... just don't bring them across the pond :P - Floydianτ¢02:21, 27 June 2013 (UTC)
I have reinstated the earlier version of the UK-style RJL. It should not be deleted, but should be replaced by an agreed layout. I had a try a few months ago to bring something in, but I had so little cooperation, that I just gave up. If people can stop getting hot-headed, we might be able to make some progress. It might be worth seeking some mediation on the matter rather than entering into numerous edit wars. Martinvl (talk) 06:20, 27 June 2013 (UTC)
I stole User:Nilfanion's example that has no UK derivations, and reinserted the coordinates, in roughly the same way they were in the old example. Is that acceptable? --Rschen775406:26, 27 June 2013 (UTC)
A number of comments:
I would like to see the banner with the roads name reinstated with the standard UK colours.
The location column is meaningless - it should be removed.
The use of "chopsticks" on the motorway signs is incorrect - "chopsticks" are used to denote a boundary between the Queen's Highway (where everybody has access) and "Special Roads" (ie roads where access is limited to certain classes of traffic)
Work needs to be done to ensure that the icons shown road numbers are the same height.
Other points will come later - can we work on these please. Martinvl (talk)@~
I personally am okay with the colors, but most people weren't, and we have to respect that.
I think that the "locations" column is best decided by the British editors and that editors from outside the UK be asked to respect our view - after all we probably know our own country better that outsiders. Martinvl (talk) 07:09, 27 June 2013 (UTC)
Ummm... I developed that location information, as a Brit, with full knowledge of how UK geography works. Its far from meaningless in my view. Further improvement of how its displayed may be useful, but its not junk info.--Nilfanion (talk) 07:50, 27 June 2013 (UTC)
A question for Nilfanion - why did you choose local authority boundaries as your criteria? Motorways are not maintained by local authorities, but by the Highways Agency (or equivalent bodies in Scotland, Wales and Northern Ireland and from what I have seen, technically lie outside local authority boundaries. Would it not have been more appropriate to choose magisterial districts? After all, if you get fined for a traffic offence, that will be you point of interest - magisterial district and local authority district boundaries do not coincide. Alternatively, would it not have been appropriate to select the local authority who maintains the roads immediately off the junction? After all, if you damage your vehicle as a result of poor road maintenance, they are the people from whom you would claim damages. But their boundaries do not necessarily coincide with local authority or magisterial district boundaries. Remember, Napoleon never conquered Britain, so the hierarchical system of government that he imposed on most of Western Europes and which was adopted by the United States, Australia and elsewhere does not exist here. Martinvl (talk) 09:47, 27 June 2013 (UTC)
The location column is not necessarily meant to provide this sort of legal information. It's simply meant to establish "if I was standing at this junction, where would I be?". Highway maintenance details are not relevant. —Scott5114↗[EXACT CHANGE ONLY]10:24, 27 June 2013 (UTC)
Exactly. Don't over-complicate things and look at irrelevancies. To focus on one example: M5 junction 8, formally the "Strensham Interchange", is located within Strensham civil parish and is an integral part of it. The land it was built on has been part of Strensham parish since its creation 500 years ago, and was not removed from the parish when the motorway came along. In what possible sense is it misleading to say J8 is in Strensham, Worcs?
If you really have an issue with using administrative geography in this manner (to answer the question "If I stood at this site, where am I?", then that is much bigger than just roads, it reflects on every single aspect of UK geography.--Nilfanion (talk) 10:44, 27 June 2013 (UTC)
It was not an RFC, it was a discussion and did not need to be advertised and therefore carries no weight. In view of the acrimony that accompanied some discussions in the previous month, I for one chose not to comment. Martinvl (talk) 13:36, 27 June 2013 (UTC)
1) citation needed 2) Now you're being inconsistent, because that would certainly not lead to "editors from outside the UK be[ing] asked to respect our view" as editors from all over the world would be commenting. --Rschen775415:56, 27 June 2013 (UTC)
Bottom line Who is going to actually do the work behind the conversion? Who is going to write consistent rules regarding the identification of location? Not me - I regard the idea as being non-starter, so lets stop this argument as will somebody do something positive and actually write out the rules as to what constitutes a "location" and why it constitutes a location. I know we have had this discussion a number of times, but people are just not listening. Until we had a coherent set of workable rules, leave the current guidelines as they are. OK, I don't care who writes the rules, but take it from me, unless the person who does so is conversant with all the quirks in the UK, it is going to be a failure. Martinvl (talk) 17:31, 27 June 2013 (UTC)
The UK isn't that bizarre, as there's an underlying geographic hierarchy that can be drilled to relatively local levels. That means the majority of locations can be identified by interpretation of the 1:25,000 scale OS mapping (a basic workable rule). Like any other country there are quirks that affect a minority of localities, and those need more careful thought. UK geographical articles, and RJLs in other nations, deliver "the subject X is in location Y" factoid with no major difficulty, and without getting hung up on technicalities. I see no reason why defining the locality of a UK junction needs further codification.
No one is making you add location info to anything, but if you can point out instances when the wrong location has been identified, and why its wrong, it will be beneficial.--Nilfanion (talk) 18:28, 27 June 2013 (UTC)
Honestly, we're not providing an alternative sat-nav here, we're just providing some useful information to our readers our where the junctions are an approximately how far down each road they are. This pathological dependence on driver location signs is unhelpful (and isn't cited) and the crusade to remove "location" is pointless. Let's make the UK RJLs useful, not an alternative to TomTom. Thanks. The Rambling Man (talk) 18:35, 27 June 2013 (UTC)
@Martinvl: Nobody has to do anything on this site, a volunteer site. Nobody is saying that everything must be converted immediately, though of course converting to a format that is not in the Manual of Style would be problematic. It is also a requirement for FAC. Just like the rest of the MOS. For as much work as we have put in converting the US to RJL, there are still many articles that are not fully compliant. --Rschen775422:17, 27 June 2013 (UTC)
Page protection
Latest comment: 11 years ago30 comments10 people in discussion
Hi, I've fully protected page for three days, as there seems to be reverting in relation to the conclusion of the recent RfC. I can't tell whether that's exactly the material that's being removed and restored, but it seems related.
If editors feel the RfC wasn't properly conducted (e.g. by not being advertised widely enough), the way to proceed is to open another one. If the situation has dragged on for a while, you could announce in advance that this one will be open for only seven or fourteen days (fourteen is probably better). But in the meantime, the result of the recently closed discussion is what the page should reflect. SlimVirgin(talk)19:03, 27 June 2013 (UTC)
I have no problems with you protecting the page, but is it not normal to restore the page to its last stable state before protecting it? For the record the page had 11 edits in the last 25 hours. In the 25 days preceding that, it had only one edit. Martinvl (talk) 19:07, 27 June 2013 (UTC)
Hi Martin, I protected after seeing the latest revert. It's on a version that's neither what was added/removed after the RfC closed, nor the version that was reverted to, so perhaps it's a compromise. There would have to be a problem with it for a particular version to be protected. SlimVirgin(talk)19:19, 27 June 2013 (UTC)
Too true the wrong version was reverted. We do not have an unambiguous set of instructions on how to populate the column marked "locations". Until and unless such a set of instructions are produced and this version can be proven to be workable, it will remain the wrong version. At least the original version worked! Martinvl (talk) 20:13, 27 June 2013 (UTC)
If you disagree with User:Nathan Johnson's previous closure of the discussion, then this is the "right" version. Otherwise there's probably no right version, what with all the slow motion edit warring going on here between certain editors. Shambolic. The Rambling Man (talk) 20:45, 27 June 2013 (UTC)
I would suggest that if there are to be UK-specific guidelines on how to populate that column, that editors interested in working on UK-specific articles should formulate those guidelines at the appropriate UK-specific discussion forum and develop the appropriate standards and guidance to editors on how to comply with the MOS and policy pages. Remember that USRD has WP:USRD/STDS, WP:USRD/STDS/L, WP:USRD/NEW, and such on how to apply the general concepts from several different areas of policy and MOS pages to the specific task of creating, curating and refining the content about US highways and major roadways in articles. The MOS pages are more generalized to have a wider applicability in what is a global project. Imzadi 1979→23:16, 27 June 2013 (UTC)
@TRM: If you agree with the close, then the current version is the "right" version, as that has removed all the UK derivations, while maintaining Andy's beloved coordinates in the same format. --Rschen775405:28, 28 June 2013 (UTC)
I trolled through the archives - On 13 August 2010, User:Rschen7754 proposed the RJL which can be seen here. If I am not mistaken, the RJL layout that he proposed three years ago is the layout that appeared in the version that User:The Rambling Man has identified as the last stable version. Martinvl (talk) 05:22, 28 June 2013 (UTC)
Except that that version relies on text which was removed from MOS:RJL per the discussion closed by a neutral third party. The example Martinvl points to omits a location column scheme; that omission was previously allowed under text now removed but not by the current text. It uses destination columns split by carriageway; formatting scheme was allowed under text now removed but not by the current text. It omits a notes column; that omission was also previously allowed under text now removed but not the current text. It uses a colored header row that was previously allowed under text in the guideline now removed but not the current text. It uses a table footer option previously allowed under text now removed but not the current text. Retaining these five attributes in an example, when the text of the guideline no longer allows those attributes, is just plain confusing an unacceptable. Imzadi 1979→06:11, 28 June 2013 (UTC)
Who has been pontificating about how the British RJLs should be written - lots of people!
Who has actually tried to do something about it. Very few people! I put a lot of effort into this set of templates, I experimented and ironed out a number of bugs before saying anything. I deliberately chose low profile articles to see how things worked out. What thanks did I get from the pontificators - a kick in the crutch. No wonder I am p*ssed off. The way in which the pontificators are trying to get uniformity is totally counter-productive - the workers are just not listening - they are leaving the project. If you look at the current version of the M898 motorway you will see that three years after Rscghen7754's proposals were published, they had not been implemented. If you look this version, you will see that it bears a much closer resemblance to the layout that was proposed in 2010. My work was unceremoniously ditched because there was no consensus. As long as the pontificators continue pontificating rather than cooperating with those who are willing to actually do the work, this project will remain where it is - deadlocked!!!!!!! — Preceding unsigned comment added by Martinvl (talk • contribs) 07:00, June 28, 2013 (UTC)
Martinvl, you have to remember that consensus can change, and in this case, it did. Editors have moved on from a compromise in 2010 to more uniformity and consistency in 2013. While the tables in UK articles have stagnated, the tables in the US, Canada and now Australia are moving forward. I've offered on more that one occasion over the years to help, but that offer has been rejected each time it's made. Imzadi 1979→07:08, 28 June 2013 (UTC)
If your offer is repeatedly rejected, then stand back and let those who want get on with the work do the work their way without you. Don't p*ss them off by insisting that your way is the only way - look at the RJL in this article there is nothing wrong with it, it is just different. Martinvl (talk) 07:19, 28 June 2013 (UTC)
(edit conflict) Ok, so it's the US editors' fault when we make suggestions on how to improve articles, but won't offer to do the grunt work to implement them. It's also our fault for offering to do the grunt work to improve articles to a consistent standard to the benefit of our readers. Gotcha, and now we're comparing an infobox on the Dutch Wikipedia to a more detailed table on the English Wikipedia, that's fairly consistent with a globalized standard. Imzadi 1979→07:28, 28 June 2013 (UTC)
Eventually you seem to be getting the message, to put it bluntly, us Brits don't like Americans (or anybody else)telling us to change our ways to match the their way. We are quite happy improve our way of doing things and to adapt new ideas, but the initiative has got to come from us. We are quite happy to cooperate and meet half-way where everybody gives and takes. I was quite happy to cooperate in merging the articles Freeway and Motorway to produce a more-globally oriented article - the final product is reasonably global. However, the way in which the so-called RJL standards have been handled has been very undiplomatic and consequently counter-productive.
I don't care what the WP:RJL says, if I don't like it, I will not implement it, I will walk away. Are you going to pick up the pieces? Martinvl (talk) 08:07, 28 June 2013 (UTC)
Wikipedia works along no international boundaries. Any user's input is as valid as any others', regardless of where they're from. The sooner you realize that, the sooner you will be able to work with others here. —Scott5114↗[EXACT CHANGE ONLY]08:13, 28 June 2013 (UTC)
As the discussion was opened without being advertised by the RfC bot, [2] the only way forward that I can think of is to open a formal RfC. Are there objections to doing that? The thing to be avoided is for the reverting to start up again when the protection expires. SlimVirgin(talk)16:56, 28 June 2013 (UTC)
I suppose if that is what we have to do, that's what we have to do, though I'd like to avoid it because rehashing this tired discussion over yet again simply because Martin refuses to just let it drop is not exactly my idea of fun. —Scott5114↗[EXACT CHANGE ONLY]17:47, 28 June 2013 (UTC)
I know it's frustrating, but Andy and Martin have a point about the lack of publicity. But if there are other suggestions, please go ahead and consider something else. I'm just concerned that the reverting will continue unless the consensus is really pinned down, or a compromise is found. SlimVirgin(talk)17:52, 28 June 2013 (UTC)
If we must have another RFC, would this be a fair way of phrasing the question—This is a proposal to amend WP:RJL to remove the specific provisions allowing for a special format for UK exit list tables. The goal of this proposal is to harmonize the format of UK exit list tables with the format of those in all other countries. It would remove the colored headers from the top of UK exit list tables, and would remove the legend for the headers from the bottom of the table. It would require two columns specifying the location of the junction to appear at the left side of UK exit list tables, and all other columns to appear in the order prescribed by WP:RJL. If approved, WP:RJL and any examples on that page would be edited to reflect these changes. This proposal does not affect the use of coordinates in articles. Shall the proposal be adopted? —Scott5114↗[EXACT CHANGE ONLY]18:06, 28 June 2013 (UTC)
Couple of questions: (1) Would an affirmative answer to your questions describe the current version of the page? (2) I'm confused about "It would require ... all other columns to appear in the order prescribed by WP:RJL." Given that this is WP:RJL that is being discussed, what does "in the order prescribed by WP:RJL" refer to? SlimVirgin(talk)18:21, 28 June 2013 (UTC)
(edit conflict)(1) Yes, it would. (2) The standard order is, from left to right: geographic columns, then mile, km, junction/exit number (if applicable), destinations, notes. Currently, UK order is, from left to right: mile, km, destinations, junction number, destinations (going the opposite direction from the previous destination column). —Scott5114↗[EXACT CHANGE ONLY]18:39, 28 June 2013 (UTC)
Thanks. What I'm getting at with (2) is that it seems odd to include in the RfC proposal that "it will mean that columns must appear as prescribed by the guideline," without saying which version of the guideline, which is the issue at stake. Or have I misunderstood? SlimVirgin(talk)18:48, 28 June 2013 (UTC)
(edit conflict) And to build on Scott's reply, there is a specific exception where geographic columns are dropped for roads within a single area, but otherwise those columns are required, something the UK format omits. There was previously language that allowed for that omission, but that was removed per the last discussion. The current page now requires geographic columns, except for cases of a road within a single geographic area. The specific order the columns appear in the table is actually unchanged; what did change is that an option to omit the geographic columns, omit the notes column and split the destinations columns was removed. Additionally, the guideline is going to enforce the proper location of the junction or exit number column to fall to the right of the two distance columns and to the left of the single destination column, rather than between the now-disallowed plural destinations columns. Imzadi 1979→18:53, 28 June 2013 (UTC)
Okay, thanks. I think I don't know enough about this issue to ask questions, so I'll just leave the RfC question/proposal up to you, assuming you want to go ahead with one. The thing to watch out for is that the question/proposal is clear enough so that it doesn't confuse the respondents or whoever closes it. SlimVirgin(talk)19:15, 28 June 2013 (UTC)
Regarding the page protection, now that the RfC has begun, will the page protection be extended until the RfC closes? –Fredddie™22:44, 28 June 2013 (UTC)
I've extended the protection by two weeks, which takes it up to July 14. That will cover the period of the RfC and time needed to judge consensus, but it can be extended or reduced as needed, so please let me know if people feel it's too long or not needed. SlimVirgin(talk)17:30, 29 June 2013 (UTC)
RfC: Ratification of recent changes to remove UK-specific formatting provisions
Latest comment: 11 years ago143 comments16 people in discussion
I'm closing this following a request at ANRFC.
There is clear consensus to ratify the previous discussion, which was closed on 26 June with the comment "this discussion is closed with a broad consensus to remove the UK-specific deviations."
This RfC confirms that there is consensus to remove the provisions that allowed a special format for the UK. According to the respondents, those in support came from three countries, including the UK.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This is a proposal to ratify the previous discussions that removed the specific provisions of MOS:RJL allowing for a special format for UK exit list tables. The goal of that proposal was to harmonize the format of UK exit list tables with the format of those in all other countries. To wit:
It removed the colored headers from the top of UK exit list tables, and removed the legend for the headers from the bottom of the table.
It requires columns specifying the geographic location of the junction to appear at the left side of UK exit list tables.
It requires a single destination column and a separate notes column.
It requires that all other columns to appear in the order prescribed by WP:RJL. This order, in general is:
Geographic locations
Distances
Exit or junction number, if applicable
Name of the junction, if applicable
Destinations of, and connecting roads at, the junction
Notes about the junction.
If ratified, MOS:RJL and any examples on that page will be edited to reflect these changes.
This proposal does not affect the use of coordinates in articles. These changes are reflected in the updates to the M5 example between the previous version and the current version of MOS:RJL at the time the RfC was opened.
Shall the changes be ratified?
Note: because of the extended time period from the previous discussion, this RfC will close seven (7) days from the time it opens. A neutral third-party editor will be solicited at WP:AN/RFC at that time to close the RfC. Imzadi 1979→22:42, 28 June 2013 (UTC)
Support ratification of course. There's no good reason why this template should have all these country-specific derivations. TCN7JM22:55, 28 June 2013 (UTC)
Support ratification - there is no reason why roads here in the UK cannot be adequately described using the common format. Indeed the M5 example demonstrates that. The small coloured road symbols will look familiar to UK readers. The articles will become clearer when less burdened with the clumsy, unnecessarily repetitive details they currently carry. The old tables are best consigned to history. Our other kid (talk) 21:59, 29 June 2013 (UTC)
Support, for the reasons that I set out below, with the proviso that I can change my mind if the other side can convince me by providing a really good argument. —SMALLJIM09:30, 30 June 2013 (UTC)
Strong opposeNeutral as pointless bureaucracy that does not help anyone write an encyclopaedia, but helps propogate systematic bias. In my view, the above commenters have a myopic vision of importance, where I prefer to write articles such as M11 link road protest which reached GA status without even having an infobox. I personally think the M5 example looks poor and less user friendly when compared to, say, the entry on CBRD's motorway database here. The examples given do not render well on an iPhone, particularly using the standalone app on a 2G connection, and there is no option to skip, so the user is left waiting in frustration for something to load that they may not have interest in.I think this entire section of the MOS should be removed and editors use good judgement and common sense as to what benefits the reader when evaluating articles at GA and FA. Ritchie333(talk)(cont)10:14, 30 June 2013 (UTC)
Strong Oppose
The promoters of this proposition have not even done the British users the courtesy of removing blanant US terminology such as "shields" instead of "route identifiers" and "North East" when the mean "New England" from their documentation.
The promoters have misused the colour schemes used for road identifiers. The A38. for example, should be green on gold north of J5 on the M5 where it is a primary route, but black on white south of that junction where it is a secondary route.
The non-UK RJL, as it stands does not have a title line. In many style guides for technical subjects, such title lines are mandatory. The UK RJL has gone a step further and used the colours that are standard and are well-understood throughout the UK. Do the promoters want this removed? If they do this, do they realize that these colours are now part of Britain's cultural heritage.
I agree with Richie333 about the use of mobile devices and look forward to this proposition being thrown out and the UK producing a version of the RJL which is suited to use in the UK and to use on I-phones (see Wikipedia:ACCESSIBILITY). I personally am not so arrogant to think that what is suitable for the UK is suitable for other countries in the world, I have lived in South Africa long enough to realize that there are fundamental differences in British and South African motorways/freeways. I have also spent enough time developing software to realize that writing a single-all embracing set of specifications/program suite can have numerous side-effects and requires endless regression tests every time that it is updated to accommodate a new scenario - it is often best to built a second set of specifications/program suite which can build on the lessons learned from the first without having to compromise either. Martinvl (talk) 16:59, 30 June 2013 (UTC)
Comment just worth noting all the initial support came within US daytime, we're now into UK daytime/evening and we're getting opposes. I'd like to hope the closing admin will give this a few days to make sure we get a rounded view, especially since the bright line seems to be between US and UK editors. I would by far prefer a universal solution to this but it has to be said, given some of the discussions about certain esoteric US terminology, it may be that we can't do it. Despite everything I've discussed and suggested, it appears that we may just need to digress from our US-brethren as their odd nomenclature and curious terms really leave the rest of the English-speaking world floundering. Universal is good, as long as it really is universal. I'm still looking for a single non-Wikipedian Brit who knows what an "at-grade junction" is, or an "incomplete junction". Seriously, I've said it all before, but pretty much all of theses discussions take place within the project, and it seems that the project has 80:20 US:non-US contributors. Our audience is not that proportion. We need to consider them first and foremost, not some arbitrary blanket averaging of our approach. The Rambling Man (talk) 17:16, 30 June 2013 (UTC)
Totally true. But those editors seem to believe that the UK public understand what an "at-grade junction" is. That, of course, is completely false. The Rambling Man (talk) 20:56, 30 June 2013 (UTC)
The wording of the legend is something that can be adjusted. There have been some concerns about how colors are being used (especially the recently added purple one - personally, I'm not happy with how it turned out in practice) and I sense that once this is done that there will be a discussion reevaluating their use. --Rschen775420:58, 30 June 2013 (UTC)
Well that would be a start. But I can't help feeling that this pile-driver is now overlooking the fact that UK (or non-US) road folks are being segregated. We don't have "at-grade junction(s)", (or "incomplete junctions") yet we're now being told "ok, ok, you don't have those, but we'll deal with them in the future, shut up for now." I definitely think we should have a standard approach to road junction lists, but we need to get the idea that we don't all speak the same language, and oddly, US English for road junctions is WAY different from British English. The Rambling Man (talk) 21:03, 30 June 2013 (UTC)
Further internationalization is possible, but you do have to realize that the fact that editors forked the guideline from 2010–2013 has been an obstacle to internationalization, which, if the guideline is reunified, we all can work together to fix. --Rschen775421:13, 30 June 2013 (UTC)
See my comment below - the terminology isn't vastly different. eg "at-grade" is the correct (but obscure) term in UK. {{legendRJL}} can easily retain the same core, and allow country variations by switching.--Nilfanion (talk) 21:27, 30 June 2013 (UTC)
Support. However, further development of the colour usage will be worthwhile (see below) which may mean a slight divergence in the legend. I am confident the issues with graphics (like the A38) will be corrected with time.--Nilfanion (talk) 18:31, 30 June 2013 (UTC)
Threaded discussion
A couple procedural points: The removal of the dual columns for destinations should be mentioned above - its one of most visible changes. A few wikiprojects like WP:HWY and WP:UKRD should be notified, and it may be worthwhile to mention at WP:UK too. No need to notify projects focused on other countries like USRD.
More seriously, I'm uncomfortable with a 1 week discussion, its a bit fast. The whole reason for this RFC is to try and get a stronger consensus than that of the previous discussion. That would need greater participation. A longer time-frame maximises the chance of new involvement, and if we only get the same editors as before we are wasting our time. I'd favour a 2 week window, and giving the closing admin discretion to keep it open if productive discussion is underway.--Nilfanion (talk) 23:24, 28 June 2013 (UTC)
I added the destinations column point. As for your other comments, a couple of quick points are in order. Any notifications about other items (updates to the various templates related to Wikidata that require consensus to implement, etc) have been met with open hostility on WT:UKRD lately; we've essentially been told to stop notifying them about anything. Regarding the timeframe, the previous discussion was open for almost two months (March 31 – June 26), and we are dealing with a subsection of specialized topic area of editing. I'm open to discussions on timing, but we need some hard deadline when we know this saga will end. Imzadi 1979→00:38, 29 June 2013 (UTC)
Yes, there have been hostile reactions at UKRD to notifications (on the lines of "wTF does this have to do with us, go away"). However as this change directly relates to UKRD, they really should get a neutral notice, or we still aren't notifying potentially interested parties. Martin has since left a POV notice at UKRD, which is far from ideal.
I'd be inclined up the time to 2 weeks. It may have been open for 2 months, but without a notice its only those that are already here who would have found it. As this is a specialised topic I doubt there is much interest in it, but if there is anyone else who cares we want their views.
Of course this can't go on forever, and needs to end at some point. However what I meant was in the unlikely event that there is productive discussion underway it would be absurd to expect a prompt closure.--Nilfanion (talk) 09:09, 29 June 2013 (UTC)
Yeah, I'll do a few notifications (I'm technically not part of any Wikiproject at present); though I'll ask SlimVirgin for advice regarding the UKRD one. With regards to timeframe - 10 is better - but why the need to rush?--Nilfanion (talk) 09:24, 29 June 2013 (UTC)
Well, it is roughly halfway in between :) but a little more seriously, there's a feeling that this RFC shouldn't have been necessary at all among some people, so it was an effort to compromise. --Rschen775409:25, 29 June 2013 (UTC)
I agree it should be unecessary, which is why we want to try and get more involvement (else it is a pure bureaucratic hoop jumping exercise). What concerns me more, is even if this closes with as strong a consensus as before, I suspect the dispute won't be over.--Nilfanion (talk) 09:33, 29 June 2013 (UTC)
As a UK-based complete newbie to this issue (here thanks to one of Nilfanion's messages), of the two examples given above for the M5 motorway, this one (with the graphics) is clearly better in my view - briefly, the other format has much unnecessary duplication in the northbound and southbound exit columns and lacks county and location details. I think that means I support, but I'm not certain. But why are significant A roads (e.g. A40) in a smaller font size than lesser ones (e.g. A4019)? —SMALLJIM11:38, 29 June 2013 (UTC)
So I can add a "support" above? Speaking generally, if opinions from previously uninvolved people are solicited, it's important to make the options very clear - most people won't wade through reams of previous messages to understand the points at issue (and I haven't done so, on purpose, here). Why doesn't each side provide a short statement explaining to the newcomer why their alternative is better? In some cases the drafting of such statements might show that the two sides aren't all that far apart after all...
It would be good to get those graphics sorted out before considering wide implementation, though. —SMALLJIM12:54, 29 June 2013 (UTC)
Yes, you want would to add a "support" above. I agree with your other comments regarding greater clarity here, there is a heck of a lot of discussion no one should have to wade through. The summary at start provides the advantages of the proposed style, but doesn't really show the contrary position - I'm not really one to do that. As for the graphics, I think those issues should be resolved by the time the RFC is closed.--Nilfanion (talk) 16:50, 29 June 2013 (UTC)
A couple replies to the points above raised by Martinvl and The Rambling Man:
On terminology and documentation—Template documentation is American-based because the templates in use were developed by Americans. U.S. examples were used because they were the ones that were most familiar to the people who wrote the documentation. We are willing to rewrite documentation to be more inclusive if there is an interest in doing so. Because, in each case, the template parameters include the country they are being used it, the terminology issue can easily be resolved by having the templates display alternate terms that more appropriate to the UK ("at-grade junction", specifically, is not specified by RJL, and is simply something that can be, but does not have to be, displayed in the notes column). British English versus American English has been an issue since the project's founding, and there are several tried-and-true ways to work it out, so it's not worth scuttling an entire MOS page over.
Again, the error with regard to A38 was done primarily because an example was needed quickly to replace the old one, so there was not a chance to have someone with a better knowledge of the local situation check it over. Such an error could be corrected by anyone at anytime. Don't worry about a lack of graphics—we are willing to assist in providing a full set of graphics to complete TSRGD standards, which would also eliminate the problems of inconsistently sized graphics.
The function of a title line is served by the second-level header ("exit list" or "junction list") that should be found immediately above the table. Although this is de facto part of the standard (every RJL I've seen has had such a header), we could explicitly require that in this page if it is desired. See also a past discussion where this was discussed and rejected. Most people seem to feel that having a header stating "Exit list" followed by a table title reading "Highway xxxx exit list" is bad form since it subjects the reader to repetition without adding any value.
We currently do a lot of testing before a change is added to the RJL templates to prevent breakage. Nonetheless, usage of the RJL templates is not required by the standard, and is only a tool to assist in creating a compliant table. It is possible to code a table the traditional way and follow RJL. In any event, if you would like to see certain methods of testing done on the templates before changes are done, we are always willing to improve our testing process, and would welcome any feedback along those lines. —Scott5114↗[EXACT CHANGE ONLY]17:43, 30 June 2013 (UTC)
@The Rambling Man: I think your concerns about terminology stem from fact that they are technical terms not generally used by the public, and the roadgeeks here are mostly American. To identify if the technical terms are affected by ENGVAR, look at Highways Agency usage. Grade separation and at-grade are both used here for instance. I am comfortable they are the correct term in the UK. "Incomplete access" feels American, but well-used equivalents in UK "restricted access" and "limited access". For instance, a junction with restricted access is called a "restricted junction" by AA on their mapping.
A switch in {{legendRJL}} might be a good idea to handle the ENGVAR issues and remove things not relevant in Britain: The UK version could keep closed and unopened, tweak "incomplete" to one of "limited" or "restricted", remove mention of ETC and possibly HOV. Both are possible - sourcing is needed to work that out. One that might be worth adding for the UK is managed motorway
Concurrency is more difficult. Its much more relevant in US (as its signposted there), than in UK (as its not). I am not sure what the most common UK English term for it is, or if it would be easier to drop on UK version entirely. For example is the A38 concurrent with the M5 from J27 to J31? Or is there a gap in the A38? A source is needed for that I think!
There is a bit of discussion on my talk page regarding the graphics and handling the primary/secondary issue. The reason the A38, A40 etc look small is because of the white border. I'm not sure if any borders are needed for this use, when coloured patches are used on direction signs they are unbordered.--Nilfanion (talk) 18:22, 30 June 2013 (UTC)
Regarding concurrency: the term "overlap" is used for the same thing by some U.S. DOTs, and it may be more intuitive. We also have an article, concurrency (road), that can be linked to, although it needs some internationalization as all of the photos are of U.S. examples. If it's decided that the entire concept doesn't apply to the UK, we can take it off the UK footer. We can also set the templates up to entirely disallow use of inapplicable colors on British RJLs, if that is desired. (Also, some U.S. editors have some misgivings over the purple/ETC/toll/etc color as it is, so that one may end up being totally deep-sixed at some point.) In any event I am confident that small details like this can be handled with a combined effort . —Scott5114↗[EXACT CHANGE ONLY]18:51, 30 June 2013 (UTC)
It appears to me that the United Kingdom's road identifiers apply to roads, not to routes and a road can have only one name. A road can be split up into multiple sections - for example the M62 motorway has two sections, Junctions 1 to 12 to the west of the M60 motorway and junctions 18 to 38 to the east of the M60. This does not only apply to the M62, but also to a host of smaller roads - here for example, the A361 is not signposted at all between its two junctions with the A36. This picture show a route confirmation marker on the A36, midway between the two junctions - no mention of the A361, just that you will have to leave the A36 at some point if you wish to go to Trowbridge. Merging the US and the UK RJLs will cause this sort of anomaly to arise all the time.
South African route marker This is but one of any number of differences between UK and US road practice and having a product that was built around the needs for the American way of doing things brings with it risks that making corrections could have undesirable side-effects. I am also concerned about the tone of the conversation "We will do this for you" why can't we do it ourselves - who "owns" the RJL templates? In addition to them being American-oriented, they are also very poorly documented - the template jct does not make it clear whether whether the road identifiers are generated internally or whether they provide a wrapper for an image somewhere. This is of immense importance if the code is to be maintained and expanded (or does everybody have to ask the "American owners" to set things up for them? If for example, I wanted to create a RJL about a South African freeway, how would I incorporate the route markers (see right) into the jct template? Could I do it myself or do I need to get somebody to do it for me? Martinvl (talk) 19:42, 30 June 2013 (UTC)
Then why is it not documented? Either you catalogue everything or you tell people how to check for themselves. You have done neither. Martinvl (talk) 20:02, 30 June 2013 (UTC)
I'm reasonably good with templates and could figure it all out with zero help from the Americans if I was so inclined. However, when those who have created the template and routinely use it, are willing to assist with it I am not going to look a gift horse in the mouth and say "no go away, I will do it myself".
The concurrency anomaly isn't a problem with RJLs, its an issue with UK roads as a whole. Concurrency is a concept prevalent in the US, and so has been assumed to apply in UK by British road enthusiasts like SABRE (see this and note the A40 / A449 sign used in their article). I have seen indicators of roads with dual numbering like here, but its not clear when an apparent concurrency is one or when its just a gap in the road. I have found no UK document which uses the word concurrency, or an equivalent, the idea is skirted around. I am trying to find something.--Nilfanion (talk) 20:14, 30 June 2013 (UTC)
@Nilfanion - You missed the point, so could I, but having spent many years in the software industry, I was pointing out that the documentation for the system was shoddy. Moreover, the tone of the discussion has not been one of the package's authors trying to sell their package, but one of trying to force it onto us. What I have pointed out this evening is that it is shoddy and that it is very American-oriented and the techniques being used are those of a bully. User_talk:Scott5114, in his earlier posting tried to justify the "Americanism" of the package rather than apologize for possible shortcomings. Martinvl (talk) 20:25, 30 June 2013 (UTC)
Poor documentation is a problem, but unfortunately its a very common problem throughout Wikimedia. That's to be expected as volunteers want to get their new toy working and aren't obligated to write down what it does (In contrast to professionals who wouldn't get paid without it).
{{Jct}} has good enough documentation for me to figure out with a little trial-and-error. Its written in US English, and it uses "shield" to describe A roads. So what, I get the meaning, why do I care? I wouldn't change a template just to fix a color= call to a colour= call in a template (though I might make colour fall through to color if I expected widespread use).--Nilfanion (talk) 20:46, 30 June 2013 (UTC)
If they are trying to sell their product on the international market, they should internationalize it first and then try to sell it. I don't care if they use "color" instead of "colour" as it must be one or the other. However, the term "Highway shield" (which is an Americanism) could have been replaced by the term" Highway route identifier" which has the same meaning in all variants of English. Likewise, the term "the North-East" (which means different things in every country around the globe) could have been replaced by the term "New England" which is much more specific. These oversights, and more particularly the tone Scott5114's explanations have done nothing to make this product look any better to me, if anything the tone of his reply has put me off the product. Martinvl (talk) 21:05, 30 June 2013 (UTC)
If you really care about this issue, Martinvl, can I suggest that you pull together your arguments into a closely-reasoned statement aimed at the people who really matter – all those undecided wikipedians who can be enticed here – to make it easier for them to make an informed decision. I've seen some potentially good points against ratification scattered around, but to be blunt, your complaints about how the other side has behaved won't sway anyone whose opinion on this question is worth considering. To improve your chance of gaining consensus (which is what this is all about), you need to change your tactics. —SMALLJIM22:56, 30 June 2013 (UTC)
The issue of representation of distance has not yet been raised. In the UK this is a contentious issue. The Department for Transport have seen fit to denote distances in miles but to use kilometres on their marker posts. On English motorways marker posts are clearly visible to motorists. As things stand today, unless both miles and kilometres are displayed, accusations of WP:POV will be made. I personally use the marker posts when I am driving so failing to display kilometres will remove some of the article’s utility from me. I know that many readers do not use kilometres and they will make accusations of WP:POV against me if I insist on kilometres only. I do not believe that this issue can be resolved within Wikipedia, it must be resolved by the British Government. I believe this to be sufficient reason to oppose forcing the UK to use US model. Martinvl (talk) 06:05, 1 July 2013 (UTC)
Both versions of RJL, the old and new one, display both miles and kilometers, regardless of whether the road is in the US, the UK, South Africa, Australia, Canada, or Croatia. Another tangent. --Rschen775406:06, 1 July 2013 (UTC)
Note on length
Unless there are objections to my doing so, after 24 hours from this post I will extend the length of the RFC to 10 days. 14 days remains a possibility (though there is very little support for more than that) but if it's going to be extended at all, it needs to be done soon. --Rschen775405:42, 1 July 2013 (UTC)
Done I will strongly oppose any further extension, however, because it appears that one of the parties is stalling for time. --Rschen775407:04, 2 July 2013 (UTC)
Alternative proposition
Given that
The RJL as currently worded often required that text be folded in order to accommodate a screen of width 1024 pixels (as per WP:ACCESS)
Since WP:ACCESS was written, iPhones with a screen width of 960 pixels have become popular
The current RJL cannot accommodate that certain roads, for example the A38 at Junction 5 of the M5, can change from being a primary route to being a secondary route as it traverses the junction.
The differing requirements of different sectors of the British readership make it desirable to display both miles and kilometres in distance tables.
The RJL as currently worded makes no provision for a table title, even though the current UK layout has a title and many good style guides require that tables (and charts) have a title.
I propose that a UK-specific format for RJLs be developed which
Makes a title a mandatory part of the table
Seeks to minimize the table width
Allows for road types to be changed either side of a junction.
If distances are displayed, both metric and imperial units will be displayed. — Preceding unsigned comment added by Martinvl (talk • contribs)
Oppose this basically attempts to reinvent the wheel, and is a solution to problems that are either nonexistent or have been addressed above. --Rschen775406:51, 1 July 2013 (UTC)
Oppose - The current RJL format can do stuff like this perfectly well, and we do not need a title, nor is the width that much of a problem. TCN7JM06:59, 1 July 2013 (UTC)
Oppose—the points Martinvl seeks to develop in a new format don't actually need a new format.
The table appears in its own section under a heading that serves as the title, so at this time, a specific title isn't particularly necessary, and in fact is quite redundant.
Table width is not the issue he claims it to be. My iPhone, my iPad and my laptop all handle existing RJL tables perfectly fine now.
The content of the appropriate cell of the table can be used to display this by simply displaying two lines. See U.S. Route 45 in Michigan where a single roadway changes designation from M-38 to M-64 as it crosses US 45 from east to west.
Both distances are displayed now in several countries. For the US, miles are first in most cases, and kilometers are second. For Canada and most other countries, kilometers are first and miles are second. Imzadi 1979→07:05, 1 July 2013 (UTC)
None of these are UK-specific things, however there is an issue with regards to the 3rd point in particular:
If a table is not below a section header, the facility for a heading should be there. May make sense to add "Generally road junction lists should be placed in their own section. This means a table heading is unnecessary, as the section heading is sufficient. However, if the table is inline in another section, then a heading should be provided."
Table width is fine. While tables shouldn't be too wide, making them too narrow is also harmful. IMO, none of the columns are particularly redundant.
The facility to handle change in road types is there. However moment there is a minor difficulty with primary and secondary routes. That's being caused by a lack of graphics. I have uploaded a second marker for the A38 and applied it here.
Already is done. Miles should be shown first in UK, because miles are the primary distance measurement in UK. And they are in both RJL versions.--Nilfanion (talk) 08:51, 1 July 2013 (UTC)
Oppose. One standard leads to consistency between articles; consistency is good for our readers. The direction this proposal is developing is not encouraging, as it is specifying overuse of icons that may run afoul of other sections of the MOS. —Scott5114↗[EXACT CHANGE ONLY]20:17, 2 July 2013 (UTC)
Strongly oppose - the one standard, with minor language/terminology tweaks, will adequately serve the needs of the situation in the UK. Our other kid (talk) 21:07, 2 July 2013 (UTC)
A request
I find this whole thing very confusing. Could some kind soul please copy edit A1 in London and fill out the necessary details. I'd like to put in notable points along it like the Angel, Archway, Henleys Corner etc but the documentation isn't obvious and last time I asked someone if they'd do it for me I got a pile of insults back implying I was lazy and wanted to take ownership of the article. Ritchie333(talk)(cont)11:00, 1 July 2013 (UTC)
Not exactly sure you are after? Do you want an RJL-type table added to that article? If so, start a section on its talk page listing which points exactly you want and work can start there. The result of the RFC will decide optimal layout of it.--Nilfanion (talk) 11:15, 1 July 2013 (UTC)
To be honest, I don't know what I want. I want a simple list. Other people upthread want something more. If somebody puts in something that they think is useful to an article I actively helped with, I might start to understand their side of the argument and change my vote to neutral / support. Ritchie333(talk)(cont)11:30, 1 July 2013 (UTC)
Well get that simple list on the talk page (I don't know what those important points are), and I will have a look later. Bear in mind this layout is designed for major highways, not urban roads, so it may not be perfect for your needs.--Nilfanion (talk) 11:57, 1 July 2013 (UTC)
iPhone-friendly example
I have prepared an iPhone-friendly example of the M5 motorway which should go some way towards complying with WP:ACCESS. I took the data from the example proposed in the current RJL project page and made the following changes:
For purposes of illustration of concept I have
Discarded the "Locations" column
Merged the data in the "Notes" column into the "Destinations" column
The effect of this was to reduce the screen width where data wrapped for the first time from 1440px to 1030px (29% reduction) and to reduce the width of the smallest screen needed to display the table without any need for left-right scrolling from 760px to 590px (23% reduction). A few more pixels could be saved by using British Post Office approved abbreviations for counties, eg "Worcs" instead of "Worcestershire" and by tidying up the road identifier icons (or discarding them altogether).
For purposes of illustration of features, I made the following changes:
I assumed that the motorway south of Junction 7 was the A5.
I assumed that the county boundary passed through the middle of the Frankley Services.
I assumed that Junction 5 was a limited access junction.
I added a number of new features:
The distances are the exit distances in both directions.
I have reinstated the table title using UK-specific colours.
I gave greater detail about the continuation of the motorway after its termini.
I reduced the coordinate suffix from "coord" to "c".
I left the footer unchanged - the detail of its contents can be discussed later.
I am happy to accept something based on this layout. Of course, this is only a first draft and many details need to be hammered out. For example, the handling of coordinates is outside the scope of this discussion, though as a thought, they could be in an automatically generated list below the main table with a hide/show option. (Just a thought)
Aside from the changes described above, this example looks no different on my mobile device (which I'm currently using) than the other examples on the MOS page. Keep in mind, though, that my device is brand new. YMMV. –Fredddie™16:27, 1 July 2013 (UTC)
According to iPhone, you mobile device has four times the pixel-count of an iPhone (twice the width and twice the height). Is your device a hand-held device (typically 120 mm x 60 mm) or is it much larger? Martinvl (talk) 17:30, 1 July 2013 (UTC)
My phone has a much higher pixel density than the latest iPhone, thus the obscenely large number. The screen measures 5 inches (130 mm) diagonally. –Fredddie™00:03, 2 July 2013 (UTC)
Oppose why? We're losing the second location column which tells us in what town the junction is in. And "The motorway splits into two with the arms joining the following" makes this sound too much like a travel guide. The title is redundant with the header. Why the two mileages for every exit? What the heck does "(north west)" mean? There's too many design flaws with this one. And for the record, that's an iPhone 4 or higher, which does have that large of a display since it's a Retina display, yet remains handheld. I just loaded Interstate 8 on my very old iPod Touch on both the desktop and mobile versions of the site and it looks fine. So no need for diverging here. --Rschen775419:43, 1 July 2013 (UTC)
In answer to Rschen7754:
In the United Kingdom, the second column added very little, if any, value. All too often, when I am in London and people ask me where I live (a town with a population of 35,000), followed up with the question “Where is that?” My response is that it is just off Junction X of Motorway My – in other words I use the motorway as the reference to the locality, not the other way round. Anyway, the approximate location of the motorway can be established from the destination column. Furthermore, the inclusion of a highly compressed way of displaying coordinates means that the reader who is interested in the location can zoom into the map of his choice and establish the exact information that he wants without us having to second-guess.
What, in your opinion, is the difference between a travel guide and an encyclopaedia?
The two numbers refer to the northbound and southbound exits.
Then convince your fellow UK editors, because most of them seem to disagree with you. And yes, I know what the two numbers refer to, but we don't need to separate the two numbers. In short, I'm not going to support this. --Rschen775421:23, 1 July 2013 (UTC)
Agree with Rschen. The second location column is useful, and dropping it both loses helpful precision and the sense of progression of the road through the county. If someone asked you where you lived, would you really give "near Mx junction y" as your first response? In my experience, the most common initial answers are 1. "in (town)", 2. "in (county)", 3. "near (big city)". Responses to "where's that?" after 1 are often 2 or 3, whilst "where exactly?" to 2 or 3 gets 1. More relevant that that anecdotal stuff, in the context of WP: Consider 2011 M5 motorway crash, Taunton is mentioned in the first sentence, whereas junction 25 gets a much later mention. Other articles, like bridge, junctions or tunnels, invariably give better location info than just the county. If locations don't matter why do we mention them - even in articles about a bit of motorway?
IMO, all these double mileages are too much info, with the clarity of the truly encyclopaedic fact - how far along the road the junction is - getting lost in a jumble of numbers. DLS are about marking an exact point on the road, which that makes them excessively precise for things that cover a broad area (like a junction). It would be better to just round to the nearest km/mile.
As for the key issue you raise and feel so strongly about - width - I don't see the need for dropping the minimum design resolution of Wikipedia, as current generations of smartphones can handle these resolutions easily, and in future they are only going to get better. If you do think there is such a need, then you should take it up at WP:ACCESS itself.--Nilfanion (talk) 22:55, 1 July 2013 (UTC)
Could save some more horizontal space—on both this and tables following RJL—by merging the junction number and description cells on service areas, thus avoiding having the word "services" stretching out the junction number column. —Scott5114↗[EXACT CHANGE ONLY]22:52, 1 July 2013 (UTC)
No objection on the stylistic front, but its not going to save anything as the "Junction" header is the constraining factor and can't be adjusted.
Changing the display of destination roads could save a bit too. Instead of A38 use . The linking and alt text give full accessibility, to an image that is basically text anyway (unlike the rather elaborate shields, the shape has meaning).--Nilfanion (talk) 23:35, 1 July 2013 (UTC)
If you mean using those instead of the word Services, that is a definite violation of MOSICON, and people may not be able to understand what that means (restaurant? services? gas station?) etc. Not to mention that those icons take up bandwidth, so if you're trying to make it more mobile-friendly, that's not the way to do it. --Rschen775406:09, 2 July 2013 (UTC)
Please explain why this is violate MOSICON. The files that I showed above is a German implementation of the Vienna Convention on Road Signs (pg 100). British legislation can be found here - look at images T11, 2308.1, 2310.1. If we want to be more exact in our pictograms, we could use , and as appropriate - their bitmaps are only 256 bytes each.
If we are really serious about saving bandwidth, why not jettison the road icons - returns a 640 byte bitmap image. Martinvl (talk) 06:59, 2 July 2013 (UTC)
Because what that does is represent information with only icons, and is unnecessary decoration. And since different icons are used across the world, nobody will know what they mean outside Europe. --Rschen775407:03, 2 July 2013 (UTC)
Furthermore, while you claim to be improving compliance with WP:ACCESS by making this deviation (which is baseless as a text search on the page for the word "mobile" only brings up two unrelated hits), you actually are straying further from Wikipedia:ACCESS#Images in the process. --Rschen775407:08, 2 July 2013 (UTC)
You are taking an unnecessarily narrow point of view about WP:MOSICON. The icons in use have been defined elsewhere - in the Vienna Convention on Road Signs and in national legislation of a number of European countries - I have already cited UK and German legislation. The Convention has been signed by, amongst others, Brazil and India and is certainly followed by a number of countries including South Africa who have not formally signed the convention. There is no point in arguing this any further. You are taking a typical US point of view and I am taking a typical UK/European point of view. Martinvl (talk) 07:36, 2 July 2013 (UTC)
This is not about how recognizable the images are—it's about promoting accessibility for users that cannot view images (i.e. those with text-only browsers, the blind, et al). —Scott5114↗[EXACT CHANGE ONLY]08:19, 2 July 2013 (UTC)
In that case a template wrapper to enable the text (at the cost of image width) to be displayed for those users who have that facility enabled. Martinvl (talk) 08:47, 2 July 2013 (UTC)
Yes, these may be standard symbols. However, its much clearer for all if the word "Services" is used. As there is no single symbol for a service station, you are going to end up with a whole line of icons with no explanation to their meaning. If I recognise the individual symbols, its still a bit of a leap to combine them to "its a service area".
Contrast that to the situation with airports, where a single unambiguous icon is used (a plane). On road signs it isn't used by itself, but with the airport's name nearby. If space is at a major premium on signs, the text may be dropped, but there will be advance signage saying for "xx airport follow...". Bandwidth is really not an issue here.
There is potential saving with the road markers, as the icon is essentially its own explanatory text. However, contrast in green/yellow and blue/white may be insufficient for users with limited vision (eg colour blindness). Which makes me think that is a dead end too.--Nilfanion (talk) 09:54, 2 July 2013 (UTC)
Do you honestly think that Her Majesty's Government (HMG) would have got this wrong?
Just to make sure, I checked a few references. This document (para 1.4.3 and definitions "Contrast Ratio" and "Relative Luminance") give you all the technical background that you need. For normal text, the contrast ratio must be at least 4.5, for large text (ie 120% of standard text size), the contrast ratio should be at least 3.0. Use the RGB values from HMG, I calculated the motorway blue/white combination to have a contrast ratio of 4.65 and the primary road green/gold combination to have a contrast ratio of 4.27. This means that provided we use 120% text in the header, colour is no problem. If however we use standard size text for the route indicator icons, the green/gold icons are a little below the threshold. Martinvl (talk) 15:00, 2 July 2013 (UTC)
If Services are a separate line like in the example above, the junction, destination, and notes columns would be colspanned together normally. {{Jctplace}} exists for that purpose. I would also drop "Terminus" from the junction column since it should be obvious to the reader that the first and last lines of the list show the endpoints of the road. –Fredddie™11:50, 2 July 2013 (UTC)
Replace the word "Terminus" with one of a number of icons to show how the motorway ends. In this case, the northern end of the M5 forks and joins the M6, while at the southern end, the motorway is downgraded to a primary road (for purposes of this example). This is a real life example of what I mean - a slip road to the left take non-motorway traffic off the road and the motorway starts as one passes under the blue signs on the gantry. Notice the "chopsticks" on the various road signs.
Denote the services offered by the services using icons as shown. For purposes of UK RJLs we will use up to three icons - fuel, food and hotel.
Note - I have removed a few lines to reduce the length of the list.
Interesting ideas and I don't hate them, but I don't think we can do it because of that pesky WP:MOSICON. I would love to replace "Exit" or "Junction" in the header with , but we'd still need text with it.
The split road icon we might be able to do if there is a note in the adjacent column
I actually really like the icon idea for services, but how about "Frankley services (food and fuel)" in the colspanned version? I'm going to make a version of this that would work in the US. –Fredddie™16:24, 2 July 2013 (UTC)
Hi Fredddie,
If you look at the first column of your earlier version, you will see that the note was there. I removed it in my latest version, though it could easily be put back. Similarly, we could introduce the words "Motorway terminates" in the description column. Is there any problem with the description of Frankley Services being "Frankley Services (food and fuel)"?
MOSICON states "This should only be done if the icon has been used previously with an explanation of its purpose." but does not state where it had previously been used or explained. Here is an example of where it has been used. The services in question routinely handle four languages - Dutch, French, English and German. Of course, to really justify using the icons, one can argue that they have been agreed under an international treaty and are written into the laws of many countries including Germany and the United Kingdom. (The actual icons used are taken from German legislation by German Wikipedians, hence the German names "Rast" (Rasthaus) meaning "Road house" or "restaurant" and "Tank" from the German word "Tanken" meaning "to tank" or "to fill up".
I understand. I think the spirit of MOSICON is that the icon is described somewhere on the page, preferably close to the icon. I could be wrong, but I know that's how USRD has interpreted it over the years.
I am envisioning a {{Jctplace}}-like template where you would give the name of the service plaza and then check off the services you can get (e.g. |food=yes or |fuel=yes) and the location-specific icons and description would be inserted automatically. Of course, using the {{Jctint}} family of templates would mean the notes column would be reintroduced. –Fredddie™17:30, 2 July 2013 (UTC)
Maybe the USRD is influenced by the US road sign culture. It might be worth visiting Comparison of European road signs and comparing it to Road signs in the United States. You will notice that the US road signs has a culture of text while Europe has a culture of icons - just note how many of the European signs are free of text!
As regards the icons, I would personally create two images, one of fuel and food and the other of fuel, food and hotel and have the template select one or the other, setting up appropriate alt text. Moving your mouse above the icon will being up the text. In the last few minutes I have amended the last RJL that I posted to enable such text. In practice I would prefer to create a single icon combining the two in the demo RJL. Martinvl (talk) 18:11, 2 July 2013 (UTC)
The pair of icons for Frankley Services (Demo RJL above) has been replaced by a singe icon with a single "Alt text". Martinvl (talk) 19:35, 2 July 2013 (UTC)
The problem with that is when you're on a mobile device like I am again, hover text is of no use :-/ –Fredddie™19:38, 2 July 2013 (UTC)
If you were visually impaired would you be using your mobile device? The icons should be self-explanatory, but I have extended the text so you don't need to hover. Martinvl (talk) 19:41, 2 July 2013 (UTC)
Thanks for understanding what I meant. Hover text is more correctly inputted like a caption than alt text. –Fredddie™19:53, 2 July 2013 (UTC)
I would say that USRD has been influenced by what we've been told from outside MOS editors and editors at FAC, rather. --Rschen775421:29, 2 July 2013 (UTC)
That and the use of icons in Europian road signs at large is hugely influenced by the combined factors of numerous languages in small geographical areas and the lack of travel restrictions at borders by-and-large. The US has one primary language and a land area 96% as large as Europe. That said, I like some of these icons, but methinks they'd be better suited at the beginning of the notes column, followed by text to describe them to comply with our accessibility requirements... which don't include making things iphone friendly. - Floydianτ¢01:42, 3 July 2013 (UTC)
Strongly oppose - it is far too complex looking, misses the vital location column and doesn't need 2 mileages for each junction. If you have hot food and fuel icons for service stations you will also need icons for toilets, hot drinks, accommodation, tourist information, etc. "Services" is fine. And my smartphone can cope with the original table without problems too. Our other kid (talk) 21:25, 2 July 2013 (UTC)
Seriously confused
Okay, there's too much text to read above, but a lot of it revolves around Martinvl's new "iPhone friendly" version of RJL. Correct me if I'm wrong but this is still in the "RfC: Ratification of recent changes to remove UK-specific formatting provisions" section of this talk page? So when did we suddenly feel the need to worry about iPhone users? This appears to have entirely derailed any sensible debate about the actual crux of the matter, i.e. the RfC. If we need to take into account mobile browsing, then we have MUCH more to worry about than just co-ordinates or tables widths. And that's a matter for Big Brother to start discussing, if it hasn't already. The Rambling Man (talk) 21:22, 2 July 2013 (UTC)
I'll try and summarize. Basically above is driven by Martinvl's desire to get a narrower table to fit on a iPhone (960px). Noone else seems to particularly feel that is necessary, but there is exploration of how to make savings. Whether it is necessary is something for broader MOS, not just RJLs. A number of points have been raised and are worth investigating further regardless of the RFC. Note that comments in brackets reflect my reading of situation and may not accurately reflect views of all editors involved:
Addition of header (Only Martin wants it, as it is redundant to section heading)
Removal of 2nd location column (Everyone else wants to keep it)
Removal of the notes column (No-one has really said anything about that, though I doubt it is possible)
No mention of a coordinates column
Adding 2 sets of distances for each junction (reflecting DLS)
Merging the word "services" across several columns (general approval)
Dropping the repetition {{jct}} produces by having "A38" twice, and if the icon alone will do (unclear if MOSICON would allow)
Adding icons for services areas (some interest)
Replacing the word services by icons, with no textual support (general disapproval)
Using other symbols, such as a fork (comment that to comply with MOSICON needs a textual note)
I'm disconcerted that the main reason that Martin last example is much narrower has nothing to do with these points, but simply reflects progressive removal of lengthy destinations. I'd feel happier if he could go back and re-add the largest, J4a, for consistency.
Martin is also working with a layout based essentially on standard RJL, and complies with 2, 3 and 4 of the RFC. eg Martin is showing (some) location info, using the same column ordering, and has taken out the 2nd destination column, which have been big sticking points in the past. I cannot speak for him of course, but that suggests converging viewpoints here. Martin if I am misrepresenting you please say!--Nilfanion (talk) 22:21, 2 July 2013 (UTC)
Removal of the notes column would merge everything into the destinations column; this is not a good idea for unsigned routes (routes only on paper) and makes the table much longer vertically and more confusing - not something I would support. --Rschen775422:28, 2 July 2013 (UTC)
A number of questions:
@Nilfanion - Yes, I think that we are converging - main sticking points being the locations column and the notes column.
Removal of second column - we have had this discussion many times - Can you (or anybody else) come up with a coherent definition
What sort of geographical/admininstrative entities are permissible for the second column.
What sort of geographical/admininstrative entities are not permissible for the second column.
Until this can be done and proven to be realistic, the backers for the second column should, in my opinion, hold fire on this point as it might just not be realistic and could in fact paralyse the entire British RJL program (I for one am not going to spend any time looking for information for a column that I regard as being utterly redundant).
In fairness to the US contributors however they might be subconsciously adopting a US-bias at the expense of a UK-bias: In the US the default is to include the state name after mentioning a town - Elvis Presley was born in Memphis, Tennesse, but in the UK the default is to omit the county - Margaret Thatcher was born in Grantham. I think that this might be part of the thinking behind a "dual location". If that is the case, then
Removal of the notes column - please supply example of what cannot be moved into the destinations column. I have already taken account of end points and limited access.
@Rschen - Please give me an example of an "unsigned route". (preferably from the UK)?
On A30 road, for example, in the A377 line, the first column would be Devon, the second Exeter. Maybe I've been misunderstanding things, but I thought the county column was the controversial one. I've always thought the city would be straight forward. There is no rule anywhere that says the road must enter the city limits to be mentioned as the location. If a city is reasonably close (no more than 2 miles away in rural areas), mention it. I know there's been some contention with where London begins and ends, but that's another discussion :) –Fredddie™04:57, 3 July 2013 (UTC)
@Rschen - I don't see any E-routes having their own RJLs - any route description should be a correlation between the official specification and the actual road that the route follows. The RJLs would be contained in linked articles that describe the actual roads themselves.
@Fredddie - that information is usually present in the destinations column. The word "city" does not mean the same thing in the UK as it means in the US. Historically a UK city had a cathedral (and therefore a bishop). Nowadays towns with a sufficiently large population are granted "city" status by royal charter. Martinvl (talk) 05:09, 3 July 2013 (UTC)
In regards to "could in fact paralyse the entire British RJL program (I for one am not going to spend any time looking for information for a column that I regard as being utterly redundant)." - that is your choice, but there are plenty of people willing to convert British road articles if you don't want to. Personally, I find the "I'm going to take my toys and go home if you don't let me have my way" attitude a bit counterproductive and doesn't really help people discuss the actual issues, making things political.
There is no requirement that the second column be a legally recognized city or town per se - the purpose is to provide in plain English the approximate location of a junction. As other people (including UK editors) have commented here, coming up with this information is certainly possible. --Rschen775405:19, 3 July 2013 (UTC)
Rschen's second point here is what I'm after. It could be a small cluster of houses that has a name and so long as it's verifiable, it'd be OK with me. –Fredddie™05:32, 3 July 2013 (UTC)
Yes, and it can't go in the Destinations column because where the junction is might not be anywhere close to the destination. --Rschen775405:56, 3 July 2013 (UTC)
To summarise then, in order to tick the box, put in anything that appears on an Ordnance Survey map that is remotely near the junction. What a load of bollocks.
Many interchanges do have names – for example, Spaghetti Junction is officially known as the Gravelly Hill Interchange, named after the Gravelly Hill area of Birmingham. If we are to fill in the "Locations" column without resorting to WP:OR, we need to find the names that have been officially given to the interchanges and check whether the name applies to the locality. There are two other alternatives – following a strict set of instructions or indulging in wholesale WP:OR. Lets put this into perspective. Suppose that I was trying to find a location for Spaghetti Junction and I did not know about its original name. I could call up this map .Setting it to the 1:50000 scale, I have a choice of five locations – in clockwise order starting at the north – Stockland Green (1.00 km), Gravelly Hill (1.36 km), Nechells (900 m), Aston (1.66 km)and Whitton (1.56 km). The distances shown are taken from the mid-point of the junction to the midpoint of the text concerned. The grid is a 1 km grid. Which if these five should I choose and why?
Martin, keep things simple and go back to basics. The location of a junction is where reliable sources say the junction is. The county (West Midlands) and city (Birmingham) are easy to very by looking at OS maps. That might well be sufficient information for the M6 RJL. If greater precision than just Birmingham is needed, then the OS maps fail but just look for reliable sources. The relevant council, Highways Agency, BBC to name a few (you will find mentions of Gravelly Hill, but I doubt any of the other places you mentioned)...
If you drop location can easily have ten consecutive junctions in the same county, with the reader having no idea how they relate to one another inside a large geographic area. If you drop the county you have a string of locations, and as it is unlikely that the reader can place them, its fairly meaningless. Which is why giving both is valuable, they complement each other and is why BBC stories relating to Grantham generally establish the county.
I alluded several times to a simple, easily verified, approach. Use the civil parish as a starting point (visible on 1:25,000 scale). That is a direct translation of the location guidance (written in US terms) to UK terminology. A bit of flexibility beyond that is useful, just as I am sure that guidance isn't rigidly stuck to in the US. eg When the junction is on the boundary a major city and a tiny village, just mention the city. Or if the parish is a huge rural one, use common sense (or better, reliable sources) to determine if there is nearby village associated with the junction.
As for the notes column, anything not relating to destinations shouldn't go in the destinations column. eg Details of tolling, opening dates, concurrency details. Limited access doesn't naturally belong in destinations either. Limited exits can be tricky to explain in-line when the two carriageways are asymmetric, while limited access has nothing to do with the destinations at all.--Nilfanion (talk) 10:28, 3 July 2013 (UTC)
If you want a detailed locality, why not use coordinates instead. If I want to know the general location, you can identify that from the destinations served by that or neighbouring junctions. The UK, unlike Germany, does not signpost distant cities at junctions, but signposts distant regions such as "The South West". (In this context, "London" is a region rather than a city). You should also remember that many district councils have large unparished areas. The approach that you are suggesting is a recipe for inconsistency and for edit-warring.
As regards notes, limited access DOES belong in the destinations column - In the example given above, I need to know that Droitwich and Bromsgrove cannot be accessed if I am approaching from the South. The pink background is insufficient. Placing it in the destination column is the appropriate place to put it. Qualifications such as tolls, opening dates can usually be denoted by a single word such as "Second Severn Crossing (tolled)" or "Gloucestershire Gateway services (Opening 2014)". The most complex of cases (which are few and far between), can be described within the RJL as "Complex access" and outside the RJL by means of a note [fictitious example follows]:
Restricted access<ref group = Note> Northbound traffic can only access the A45, southbound traffic can access both the A45 and the A46</ref>.
And why would someone want to use a footnote to access that information, when they could have a notes column running in parallel? Not very good, especially for iPhones. --Rschen775411:49, 3 July 2013 (UTC)
To avoid having a column that is mainly blank apart from one complex statement which, as a result, generates swathes of unnecessary white space across the screen - see Help:Whitespace. Having large amount of whitespace is annoying whatever the viewing device. Look the "before" and "after" resulting from this change which I did this morning. Martinvl (talk) 12:12, 3 July 2013 (UTC)
The location is a significant fact about the junction in its own right. The destinations cannot be relied upon to tell you the location, as there is no guarantee the local town is a destination. That is especially with the most important junctions between major long-distance routes. Coordinates are very precise, but lat/long is utterly meaningless by itself (its value comes from the tools it enables). And yes, many districts have large unparished areas. Those areas are typically major urban areas (this is reverse situation to US unincorporated areas), when its trivial to work out the location (Hint: What is the unparished town/city called?) And limited access to the highway is not destination information, ever.--Nilfanion (talk) 12:46, 3 July 2013 (UTC)
Lat/Long information in Wikipedia can be clicked to give you a choice of whatever map you want. Limited access from the highway (which is what the destination signs show) is, by definition, destination information - what you are writing is only half-correct. Guessing (you used the words "use common sense") location name is a classic case of WP:OR and/or WP:SYN. Martinvl (talk) 13:24, 3 July 2013 (UTC)
More contradictions
There are many differences between motorways/freeways in different countries which I believe should be taken into account when designing a RJL for that country and which could mitigate against a standard system across all of Wikipedia:
Road number or route number: A route number identifies a line between two points. A road number identifies a physical bit of road. The UK uses road numbers – a particular bit of road can only have one number, the US and Germany have route numbers – two routes can occupy the same piece of road.
Exit/Junction numbering: The United States numbers its exits (how are entry points identified?) The United Kingdom numbers its junctions (which may be entry and/or exit points) while Germany numbers its exits (Ausfahrt) but names its interchanges with other autobahns (Kreuz).
May I furthermore repeat that many technical guides require that tables have titles. Why do the proposers of this RFC insist on the UK discarding their titles? Is this the same mentality whereby many Americans do not place a leading zero in front of a decimal number that is less than unity whereas Europeans do add a leading zero? (See picture in the article Gallon which read ".8 Imp Gallons" rather than "0.8 Imp Gallons").
Both of your bullet points are potayto/potahto differences and really aren't relevant to the discussion since they can be easily worked around. I am not discounting your gripe with tables not having titles, but instead of citing vague "technical guides", you should cite specific Wikipedia guidelines. –Fredddie™23:05, 10 July 2013 (UTC)
I am not convinced the UK is any different with regards to numbering - can you give a source to your assertion? The numbers seem to marry up with the routes (eg Traffic Scotland is responsible for the "A1 Edinburgh - Berwick Upon Tweed Trunk Road") and a single section of tarmac may be referred to by two numbers in some cases (eg the A40/A449).
As for the heading, in actual use in articles, a section heading should immediately precede the table, giving the same info as the text heading. What value does the repetition provide? In other situations a heading is much more useful.--Nilfanion (talk) 23:28, 10 July 2013 (UTC)
This picture shows the point where the A449 joins the A40 (travelling southwards). Once one crosses into Wales and get past Monmouth, the A449 resurrects itself, parts company with the A40 and continues to Newport. It is not signposted at all where you suggest that it is part of the A40. Martinvl (talk) 00:35, 11 July 2013 (UTC)
And in the US state of Arkansas, all state highways are officially discontinuous rather than form concurrencies. In the case of Arkansas Highway 1, the highway has six separate segments to avoid creating and signing five concurrencies. (There are formatting updates that I would personally make to that table, but it does indicate the implied concurrencies with US Highways that actually break it into separate segments.) Imzadi 1979→00:43, 11 July 2013 (UTC)
Signs are not a very reliable source by themselves (and anyway note this one). Government orders are a much more reliable source, and notice how this one refers to that section as the A40/A449. If you want to demonstrate that that statutory order uses the numbers incorrectly, a better source is needed.--Nilfanion (talk) 00:50, 11 July 2013 (UTC)
@Nilfanion - Had you read the notice first, you would have seen that it applies to "... the length of eastbound link slip road from a point where it diverges from the A40 southbound link slip road to a point where it merges with the main southbound carriageway of the A449" (ie part of the slip road between the A40 ands the A449). The map is here. Martinvl (talk) 07:59, 11 July 2013 (UTC)
There are a few other orders which describe "the A40/A449" as a single road (example), as opposed to using "the A40 and A449" to describe two distinct roads. Something these orders could easily do in its route description, but isn't.
In any case, this doesn't really affect the layout (your initial concern). Think about what an RJL for the A449 would look like. It would start in Stafford and end in Newport. It would have its junctions with the A40 at Ross and Raglan described as normal. In between lines describing those two junctions would be a line describing the A40. The only difference it makes is what exactly that line says: Either something like "A449 runs concurrently with A40" or like "Gap in A449, connected by A40". Regardless of which applies, that hardly prevents a single uniform layout working globally.
What this situation does suggest is, in general, a potential concurrency should be investigated and not just assumed to exist/not exist based on its location. As Imzadi1979 says, Arkansas practice appears to prefer discontinuities to concurrencies, like the UK, and unlike much of the US. What would be good would be to find three standard phrasings: One for a definite concurrency, one for a definite gap, and one for when its not clear cut. The third is most significant - it shouldn't infer the road has a break, or that it continues, merely that the other road is the one that is marked.--Nilfanion (talk) 09:56, 11 July 2013 (UTC)
In the US, the typical way to handle a discontinuity is to treat the two segments as separate entities, more or less—see Oklahoma State Highway 15, the connecting middle section of which was usurped by US-412. (The discontinuity is a bit more explicit in Oklahoma, with a sign noting the end of the designation present at some of them.) I understand that this approach might not make as much sense in the UK, however. —Scott5114↗[EXACT CHANGE ONLY]10:04, 11 July 2013 (UTC)
I think that the ideal presentation depends on context: How big the gap is relative to the route sections? Is there a single, obvious, road connecting the two sections? As best treatment will depend on the specific circumstances I doubt we can be completely prescriptive..--Nilfanion (talk) 10:29, 11 July 2013 (UTC)
I fully agree that we cannot be fully prescriptive which is why I reject the "one-size-fits-all" notion behind this RFC. Ideally, if we were to create a RJL for the A449, (assuming that it was warranted), then, since the UK does not have the notion of concurrency, it should be in in two parts - one for each section. Martinvl (talk) 11:34, 11 July 2013 (UTC)
I think the problem is side issues getting conflated with the core point. The RFC is about the layout of RJLs: What basic columns to have, in what order. There is no prima facie reason why any country needs a fundamentally different layout (though there may be such a need), which is what the RFC seeks to confirm.
The concurrency thing above is a prime example of a side issue. Regardless of how they should be handled, or your views on them, their existence, or not, does not affect the layout of an RJL - the purpose of the RFC - in any way shape or form.
If these side issues could be disentangled, there has been discussion about them, which could have been somewhat productive. However, as its all been conflated it just looks confrontational.--Nilfanion (talk) 12:45, 11 July 2013 (UTC)
Concurrency is not a side-issue, it is fundamental. If a road has a break, such as the M62, then IMO we should have two RJLs, each with its own header, for example "M62 Junction list: J5 to J12" and "M62 Junction list: J18 to J38" with appropriate pieces of text to link the two headers. If there were concurrency (as is the case in the United States), then we should have a single table. In such cases the table header is clearly not redundant. This in itself is a good enough reason to ditch the "one-size-fits-all" approach.
In many academic disciplines, new theories are subjected to stress tests - are there any scenarios in which the theory no longer holds? If such a case is found, then the theory must be withdrawn and re-examined. In the case of RJLs, the handling of concurrency cases the RFC to fail the stress-test. In view of this, I again ask the proposers to withdraw their proposal.
I feel like taking a really hard line with this to be honest. I think a list of junctions should only exist if it is encyclopedic and helps the user understand the topic, and only then if the junctions themselves are notable. If a junction does not have significant coverage in multiple, independent, reliable sources (and I'm going to count an OS map as not significant nor independent) it should not be in the list. If a road has no junctions with significant coverage in reliable sources, it should not have a list. I appreciate I did discuss this with Nilfanion recently, and he suggested otherwise because something like Henlys Corner was not notable, but ought to appear in a list. I dug around and found in fact it was notable after all, and created an article for it.
If I asked Mrs 333 what she found interesting about roads, junction numbers and their layouts would probably not pique her interests compared to, say, that the first bulldozer to attack the M6 Preston Bypass ground to halt after about three seconds because the Ministry of Transport didn't have enough money for petrol.[1] Or, last week we were travelling on the M20 towards London where a VMS sign displayed "M25 congestion J5-J6". I happened to know that didn't affect us since we were going via the Dartford Crossing, but she had no idea. Conclusion = M25 J5 and J6 are non-notable. We must write for the opponent, which may explain why two road related articles I took to GA are specifically about people who hate roads. Ritchie333(talk)(cont)15:10, 11 July 2013 (UTC)
^Moran, Joe (2010). On Roads : A Hidden History. Profile Books. p. 19. ISBN9781846680601.
Wikipedia is an encyclopeadia and has different readers, each of whom has different interests. The article should cater for as many interests as possible. User:Ritchie333 has recently completed a good article about as particular road to which I have given him feedback. He broke the route description into five sections, but one of the shortcomings of the article was that he failed to indicate the length of each section or to relate the sections to the map that accompanied the article.
On occasions I have printed out a RJL for use when I am driving, so I probably have a totally different need from Wikipedia to to Mrs 333's need. Martinvl (talk) 15:44, 11 July 2013 (UTC)
That's a little disingenuous. What I failed to find, if anything, was a reliable source that documented those lengths, and split the article for simple readability and accessibility purposes. You might have a different need, but if it's a minority need not shared by most people, it may not be significant enough to go in an article. Sorry, but that's the way the world works. Ritchie333(talk)(cont)15:55, 11 July 2013 (UTC)
I cannot speak for the admin that chooses to close this discussion, but 12 supporters from three different countries with only 2 editors in opposition seems like a clear-cut consensus to me (that's 86% support, which would even be a pass at RFA). Were I tasked with closing this discussion, I'd close it with consensus for the changes. If it is closed with the changes having consensus, and you choose to bring this to dispute resolution, I cannot stop you (nor can anyone else), but I will note that you will face a rather large uphill battle going against an RFC that has gone opposite you in such a decisive fashion. I implore you to put thoughts of pursuing dispute resolution aside, and focus on implementing the changes—there are many minor, less contentious details to be worked out yet, and we will need help determining how those are to be decided. —Scott5114↗[EXACT CHANGE ONLY]23:52, 11 July 2013 (UTC)
I've struck my oppose, as reading through things I'm not actually opposing what's being put on the table here, and find myself agreeing with Our other kid (talk·contribs)'s sentiments. What I think my argument basically boils down to is this - there is a perception (it's fairly well hidden but if you search on a website notable for criticizing Wikipedia that starts with the letter "w", you'll find it) that road articles are sad, boring and geeky affairs with no general interest. What I want to do is alter that perception as much as possible. Improving articles helps, arguments like this don't. Ritchie333(talk)(cont)08:18, 12 July 2013 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Page protection
Latest comment: 11 years ago3 comments2 people in discussion
Just noting here that I fully protected the page after the flurry of reverts, and recently extended it to 21 July to allow time for the RfC to close. I've just closed it, so I'm assuming it's okay to lift the protection now. Please let me know soon if there's a reason to leave it in place. SlimVirgin(talk)22:37, 15 July 2013 (UTC)
Addition of "allocation terminus" to an Australian specific RJL footer.
Latest comment: 11 years ago38 comments10 people in discussion
The sandbox version of this module has been updated to include a new colour for an "allocation terminus" (where a shield allocation (or route) starts/stops or joins/leaves) a roadway. This is not required in most other places where the road articles are covered by using entire routes (or shield allocations). The changes to jctint/type required to support this are already live. To use the new colour, all that would be required is to use the switch: {{LegendRJL|country=AUS}}. (in the mean time, for temporary testing/demonstrations, use: {{User:Nbound/sandbox/templatetester|country=AUS}})
The updates have been checked for errors by a few USRD users, and they have also removed the UK-specific colouration, per the above RfC.
A partial RJL example below (this is a WIP pertial RJL, so i realise the rest of the RJL isnt necessarily upto scratch!):{{ACTinttop}}
Eastern Terminus -Signal controlled crossroads; Southbound access from north only, no westbound acces from north. Western Terminus - 3-way Roundabout, one eastbound lane of Morshead Drive bypasses roundabout.
Highway terminus - continues north as Morshead Drive
(B23 crosses over an un-numbered section, before coming back at the next interchange to be the highway's route number from that point onwards).
The colour chosen is the former colour used by USRD to denote concurrencies, and was chosen as it is not too bright/strong, and there was no blue-based colour in use. To set this colour, use: |type=alloc on any jctint based template. (This is already live)
I am notifying HWY, AURD, and USRD. Though am happy to take suggestions for further interested parties.
Ummm... is this really needed? Is there any situation in which the green colour, with an appropriate note in the notes column, wouldn't cover it? See for example Great Eastern Highway#Major_intersections, where there are a number of routes along various parts of the road. - Evad37 (talk) 00:14, 17 July 2013 (UTC)
It should also be noted that there is an actual concurrency further down this highway (B23/B72). Another road likely to benefit significantly is the Oxley Highway, where the main shielding (B56) doesnt cover the entire length, there is a duplex with A15, and then after the end of B56, there is also a section of A39 (including a very short duplex of that route with B55) [noting this here, because those articles arent up-to-date] -- Nbound (talk) 00:42, 17 July 2013 (UTC)
So are you suggesting that blue should only be used when there is a transition between a section with a route number and a section without any route numbers, and green be used when there is other transitions? - Evad37 (talk) 00:48, 17 July 2013 (UTC)
Basically blue should be used when there is a transition between a section with a route number and a section without any route numbers, and also if there is a transition to a non-concurrent number (eg. the Federal Highway changes from M23 to A23 at a random interchange, and any other example where highway <Wxx> turns into <Yzz> (even outside of the same series)). Concurrency colouration should only be used if there is an actual route number concurrency/diplex/multiplex. In WA if State Route X terminated, and turned into State Route Y (or National Highway Z), you would use blue. -- Nbound (talk) 01:26, 17 July 2013 (UTC)
Okay, this makes more sense. But maybe there is a better term than Allocation terminus. Two issues with it are the it can't be easily globalised, as the allocation concept doesn't really exist elsewhere, and it is a bit counter-intuitive to have an allocation terminus, with the route then continuing on in another direction. I don't have anything better at the moment, but its something to think about. - Evad37 (talk) 01:51, 17 July 2013 (UTC)
I'll also note that this could be used for the named highways in Alaska, such as Richardson Highway, so it would good to come up with an acceptable term for there, even in we keep Allocation terminus (or similar) as a localised version for Australia. - Evad37 (talk) 02:03, 17 July 2013 (UTC)
(edit conflict) I agree, a better name could be found- "allocation transition"? "allocation change"? we could use the route terminolgy if need be, but I was using the AU terminology in line with IAusR, IBR (AUS subtemplate), and ENGVAR. Presumably, if the US wants to use this colour too (it has been hinted at by another editor, as it could be useful on a small number of US roads) they can have their own wording. At this stage it only appears if the country is set to AUS.Of course, if a global term can be found that works, there is no reason we cant use it. -- Nbound (talk) 02:06, 17 July 2013 (UTC)
On the subject of terminology, is "allocation" anything more than a roadgeek term that's been in use on Wikipedia for ages? I haven't actually seen it in any reliable sources. Perhaps we really should be using "route number" or "road route" in infoboxes. - Evad37 (talk) 02:36, 17 July 2013 (UTC)
This is better, except maybe for the situation when a route terminates but the road continues on... does "Route transition: Route X ends" (or "Route transition: northern Route X terminus") sound right to you? - Evad37 (talk) 00:30, 18 July 2013 (UTC)
It could just be "Route Transition" in the Legend, in the notes itself you could write either "route transition or "route terminus" depending on the case. Technically the end of a route is still a transition (to nothing), but I agree it wouldn't sound right when worded that way in the notes. Some examples below of proposed usage (in the notes).
Route terminus - Route X to the south. No allocation to the north.
Route transition - Route X to the south. No allocation to the north. Route X continues east on Foobar Highway.
Route transition - Route X to the south. Route Y to the north
I suppose this is okay (and I can't think of anything better), so I'm opening a formal proposal below - Evad37 (talk) 07:28, 18 July 2013 (UTC)
As far as tourist routes go (in your example linked), I think we should ignore them in any colouration scheme (no blue or green), they add unnecessary complexity, and are really just routes that someone has designated as pretty/interesting. They arent actual highways in the standard sense (they often run on locally controlled roads). Still we could use the shielding and note any concurrencies if applicable (just not colour them), either that or just ignore them for the purposes of the RJL. -- Nbound (talk) 01:36, 17 July 2013 (UTC)
Many state routes aren't highways in the technical sense either, and also run on locally controlled roads - Evad37 (talk) 01:51, 17 July 2013 (UTC)
Well, all colours are optional, but it seems a bit strange to me to have some rows which note concurrencies coloured, and others plain. - Evad37 (talk) 02:36, 17 July 2013 (UTC)
I guess I dont really consider them notable enough to colour. Not that it matters, this strand is a little offtopic anyway -- Nbound (talk) 02:43, 17 July 2013 (UTC)
When this is sorted out, I'll imagine we will add one, either showing the use of the blue colour if this proposal is successful, or else just one that is compliant. (Also the color section would need to have this added) - Evad37 (talk) 01:18, 17 July 2013 (UTC)
We have just gone through pages and pages of discussion about variations that are UK-specific. Now we are looking at Australian-specific variations. For a start, the UK does not have HOV lanes, so having them in the footer clutters things up. Can we get rid of them in respect of UK roads? Martinvl (talk) 06:01, 17 July 2013 (UTC)
Maybe a better question is can {{legendrjl}} be modified so that we can make is show the particular colors in use on any particular article (could it detect automatically)? -- LJ↗10:49, 17 July 2013 (UTC)
Having the legend only show colors relevant to the table it sits below sounds like a good idea, even if if it's just by using parameters to turn keys on or off. Probably a question for the Lua programmers of the Module:LegendRJL, @Scott5114: and @Happy5214: - Evad37 (talk) 00:30, 18 July 2013 (UTC)
Indicates a transition from one route number to either another route number, or a section without a route number, along a named road
Support as proposer (of this table row, full credit to Nbound for the initial proposal above ), though I am more than willing to consider alternate phrasing - Evad37 (talk) 07:28, 18 July 2013 (UTC)
Support as proposer (of the initial proposal, full credit to Evad37 for the current proposal ), though I am more than willing to consider alternate phrasing -- Nbound (talk) 07:54, 18 July 2013 (UTC)
By the looks of the straw poll, most people arent interested either way, but I will ask, is there anyone that would have concerns if this was merged? -- Nbound (talk) 08:03, 24 July 2013 (UTC)
Latest comment: 11 years ago10 comments9 people in discussion
Some editors have voiced disapproval with the recent change in the ordering for the {{jctbtm}} key. To the best of my knowledge, there has not been an established consensus for the key ordering; the de facto has been an alphabetical ordering based on the {{jctint}} type keys. To resolve this issue, I would like to solicit comment from my fellow road editors in this matter. I pledge to implement whatever consensus is reached here in Module:Jctbtm, to whatever extent the Scribunto platform and my programming abilities allow me. The floor is yours. -happy521410:50, 2 August 2013 (UTC)
Route transition first, rest as previous (ie. as per example in proposal thread above) - listing the simpler/more basic case first makes more sense (route transition before concurency) - (a route transition deals with a road gaining/losing/changing a singular route marker, a concurrency deals with a road gaining/losing/changing an additional marker or markers). I will happily abide by the will of the mob -- Nbound (talk) 11:17, 2 August 2013 (UTC)
Weak support for alphabetical. I don't think it really matters that much, so would be fine with any order. @Nbound: simplicity is a subjective term: is HOV-only simpler than tolled or incomplete? - Probably depends on personal bias. - Evad37 (talk) 12:31, 2 August 2013 (UTC)
@Evad37: there is a numerical relationship between route transition and concurrency that doesnt exist between the other legend items (ie. number of simultaneous shields). Its similar to a map legend - You would never list the legend ordered as: street, freeway, railway, arterial road, etc. -- Nbound (talk) 12:44, 2 August 2013 (UTC)
Latest comment: 11 years ago1 comment1 person in discussion
This is just throwing an idea out there, but would it be possible/feasbile/a good idea to automate adding keys to {{Jctbtm}} through the use of tracking categories? To accomplish this, we would need separate tracking categories for each {{Jctint}} type and for each Jctbtm key. The idea is that the number of articles should be the same in each type's tracking category and a bot could check for this and add the keys automatically. This could then go on in perpetuity, so all we'd have to do is add Jctbtm. –Fredddie™17:25, 3 August 2013 (UTC)
Missing lines under last interchange row
Latest comment: 11 years ago4 comments3 people in discussion
Every example on this Project page has some lines missing between the last interchange row and the footer row. Can someone be found to fix this problem and show editors how to do likewise in other similar tables.Downsize43 (talk) 07:18, 5 October 2013 (UTC)
Maybe its just an IE problem. What is missing is the line between the last interchange row and the footer row for all columns except the first. Downsize43 (talk) 12:33, 5 October 2013 (UTC)
Latest comment: 11 years ago4 comments4 people in discussion
Since there is are a large variety of lanes used on different roads around the wolrd, do you think it is appropriate to indicate the lanes in a column like that (the examples are from Trakia motorway, Bulgaria and Motorway 25, Greece):
Generally, this is handled in the route description, since there would be a lot of repetition in the column, and we already have several columns in the table as it is. The other issue is that the above examples violate accessibility guidelines; using solely an image to represent the information means that those who are visually impaired have difficulty understanding it. --Rschen775406:49, 7 October 2013 (UTC)
Rschen read my mind with his reply. Additionally, the graphics used don't intuitively denote which is the northbound direction and which is the southbound direction (or the east and west directions) of the roadway. There are other issues related to transitions, unsymmetrical configurations where one side has a different number of lanes, etc. Plus, lane counts aren't aren't something that need to be detailed at this level. Imzadi 1979→07:01, 7 October 2013 (UTC)
Generally most if not all the RD is reiterated in a different context within the RJL (the RD has a more experiential slant, as opposed to the absolute physical data expressed in the RJL), I dont think this is a basis for non-inclusion itself. I do agree that an image is a poor way to portray the information though. On most roads lane counts are unlikely to be too interesting, but I do note that some very major roads already include this information in a separate table. I dont think this information should be in RJLs, which are already relatively complicated even on short roads. I do think that a seperate table may be warranted where a road has a high number of lanes in locations by local standards. Of course an in-prose description is par for the course for most roads (Usually in general terms, but may sometimes mention specifics depending on the complexity of changes along the alignment). -- Nbound (talk) 07:43, 7 October 2013 (UTC)
Time zones on the interstate routes in the USA
Latest comment: 10 years ago16 comments11 people in discussion
It would be a great idea if the time boundaries were indicated on all the interstate routes in the United States, e.g. Entering _______ Time Zone. That would be useful for motorists and others. Jay (talk) 20:23, 21 December 2013 (UTC)
Oppose—a mention of the time zone boundaries should be in the route description, if necessary. (I swear we've had this exact same discussion before at some point, but I'm not locating it at the moment.) Wikipedia is not a travel guide, and while our topic area does tread close to travel guide territory, we are cognizant of the fact that we have to keep on the encyclopedia side of that line.
Time zone boundaries do not serve the overarching purpose of a junction list: to detail the various junctions/exits and occasion special items like major bridges/tunnels along the roadway with their relative distances (mileposts) and locations. On interstate highways (any highway that crosses a state line) where there is a single junction list, like U.S. Route 8, the state lines are indicated so that the total length of each state segment is displayed. That repeats the length information from the lead that US 8 is 280 miles long: 22.129 miles in MN, 255.55 in WI and 2.322 in MI. Inserting a time zone boundary does not further either purpose. Imzadi 1979→20:50, 21 December 2013 (UTC)
To follow up on my comments, the proposed format is faulty in one respect. Our tables can be read top-to-bottom for the south-to-north or west-to-east directions, but they can also be read bottom-to-top for the opposite. It's a minor quibble, but we need to be better at writing for the bidirectional nature of the roadways by recognizing this fact. IFF time zone boundaries were added, they should be written in the form of "Central–Eastern time zone boundary" similar to how the well-written articles list state lines. Imzadi 1979→21:50, 21 December 2013 (UTC)
Oppose. I can see why someone would want to include the time zone boundaries, but I don't think it's necessarily a good idea. And yes, we did have this discussion a year or two ago. There was an editor in Oregon insisting on adding the time zone boundaries to junction lists. In that instance, the boundary was listed on the state route log, but not all states do that. If all the states listed the boundaries consistently and accurately, my answer might have been different. –Fredddie™21:43, 21 December 2013 (UTC)
Modern time zone boundaries always match county lines, right? If so, the information's already all there. Perhaps on a route that crosses into multiple time zones, the zone can be placed under the county name? --NE202:33, 22 December 2013 (UTC)
Not quite. The southern part of Malheur County, Oregon, is on Pacific Time while the northern 3/4 of the county is on Mountain Time. Arizona has a bunch of weirdness where the Hopi Tribe's reservation does not observe DST, the Navajo Tribe does, and the remainder of Arizona does not. The reservation boundaries do not correspond to county lines either. Imzadi 1979→02:41, 22 December 2013 (UTC)
The boundary in southwestern North Dakota is inexplicably random as well, and seems to move farther west every decade or so. By the time I die, the whole state will probably be observing Central Time. TCN7JM05:33, 24 December 2013 (UTC)
Oppose per the reasons above. Plus note that this is a worldwide standard for junction lists, and the US isn't the only country with multiple timezones. - Evad37[talk]04:13, 22 December 2013 (UTC)
On the fence: While I totally understand the desire to include time zone information, I think the junction list may not be the best location. A brief mention in the route description is good, but a mention in the junction list could be good. Allen (Morriswa) (talk) 02:34, 23 December 2013 (UTC)
Weak support. If the information on where the timezone boundary lies is verifiable, I think we should include it, same as we do geographical features like rivers and manmade features like bridges, toll plazas, and tunnels. I am sure there is a shapefile or KML on the internet somewhere that we could use for this purpose. —Scott5114↗[EXACT CHANGE ONLY]02:50, 23 December 2013 (UTC)
Question: How would this work with timezone boundaries that only exist during summer months, when one side switches to daylight saving time and the other side doesn't? - Evad37[talk]03:07, 23 December 2013 (UTC)
I have to agree with Scott here. I don't see the major difference between including the route's crossing over a river and including the route's crossing of a time zone boundary. TCN7JM05:33, 24 December 2013 (UTC)
A20 motorway example
Latest comment: 10 years ago7 comments4 people in discussion
The naming conventions for highways in many countries aren't fully formulated. Feel free to fix things that need fixing. Imzadi 1979→20:52, 1 March 2014 (UTC)
(edit conflict) This discussion is better suited for {{Jct}} than here, but I'll reply here anyway. When I created the Jct subtemplates, I was not sure about the N roads, so I copied the style from NLWP, where an N road would be Provinicale weg 223. However, changing the link to Provincial road N223 is a simple fix. –Fredddie™20:54, 1 March 2014 (UTC)
Done. (Although the change is apparently trivial, it could possibly have changed the intended meaning of the sentence, so I was reluctant to make any change without explicit approval because of my outstanding change proposal #Inclusion of major water bodies.) Mitch Ames (talk) 13:39, 11 June 2014 (UTC)
Latest comment: 10 years ago4 comments2 people in discussion
Hello,
I made an exit list on this article, but 'N' roads in the Netherlands don't have numbered junctions/exits so I put images in. Is that allowed according to this Manual of Style? Thewombatguru (talk) 15:35, 3 March 2014 (UTC)
The images would not be acceptable as presented. The biggest problem is that the meaning behind the icons is not apparent. Additionally, even if some sort of key to their meaning was added, not all readers will have graphics enabled. In the US, we've typically added a "All exits are unnumbered." note above the table for freeways with unnumbered exits, like M-5 (Michigan highway) and its freeway segment. You could drop the column completely and indicate intersection vs. interchange status in the notes column. (I assume the X icons are at-grade intersections, the circular ones are roundabouts and the others are types of grade-separated interchanges.) Imzadi 1979→19:13, 3 March 2014 (UTC)
I just think of it this way: all graphics are either purely decorative and could be removed without losing meaning, or they have some sort of caption (and possibly alternative text) to impart the meaning. Some readers have graphics disabled in their browsers, some browsers can't display graphics, and some readers use adaptive technologies like screen readers to access our articles. Imzadi 1979→19:22, 3 March 2014 (UTC)
Pictures of Roads
Latest comment: 10 years ago4 comments2 people in discussion
What is the best practice for editing in taking pictures of roads? I have been focusing on the terminals of most roads as well as any major intersection. Should I take the picture of the junction looking down the road I am editing? Should I focus on the signage of the road marking the beginning and end of the road? I just would like to get this squared away before I start editing pages and people say..."no that isn't how we do it here." Swithich (talk) 22:20, 31 October 2014 (UTC)
Personally, I would not focus on the endpoints. The roadgeek websites do that and I think it looks silly. I would be more concerned with finding a scenic view that has a road in it and take that shot. Here's a compilation of pictures that I like User:Fredddie/Portal pics. –Fredddie™22:57, 31 October 2014 (UTC)
Okay, the issue with the roads out here is that they lie on a flat plain and many of those pictures are taken from elevation (or they have relief in the background). About the only way to get that out here is to climb a communication tower or water tower...and that isn't exactly legal. If I get a chance...I'll take some cool pictures...but otherwise most of them will be a straight shot of the highway for about a 1/2 mile. I'll just write the pages for now and let you guys decide what looks best.Swithich (talk) 20:29, 1 November 2014 (UTC)
If you drive, or know someone with a pickup, you could always pull off on the side of the road and climb in the bed. It's not much height, but it would work. If you think it'd be a good picture, that's good enough for me. –Fredddie™03:24, 4 November 2014 (UTC)
Mile or km
Latest comment: 9 years ago13 comments7 people in discussion
The Mile and/or km columns seem to be a bit inconsistent:
Mile is not an abbreviation, but km is.
Mile is sentence/title case but km is lower case. It is possible that lower case "k" is mandated by the SI standard, per WP:UNITS#Specific units, but see item 1.
Mile is singular, but in most cases (any other than the value "1") the plural would be more appropriate (including values less than 1, per MOS:DECIMAL).
Changing the headings to Miles and Kilometres would resolve all of these inconsistencies, but Kilometres might make for excessively wide tables.
Changing to Miles to mi (abbreviated per WP:UNITS#Specific units) would mostly resolve the inconsistencies - albeit leaving those column headings not capitalised, as all the others are, but I think it's the best compromise.
Yes, the k of kilometres should be lower-case. But if it was up to me and it didn't make columns too wide, I'd have mile (or even miles or mile(s))and km. I don't think we have to be completely consistent in making both abbreviations or both full, and while the mi abbreviation is now the norm in the US, that's not so world-wide (and I think hasn't been in the past in the US). UK motorway signs, for example, use m or mile.[4]NebY (talk) 12:25, 8 June 2014 (UTC)
MOS:UNIT does say that "Where space is limited, such as in tables, infoboxes, parenthetical notes, and mathematical formulas, unit symbols are preferable." Since "mi" is given as a standard symbol for mile in MOS:UNIT, and is used all over Wikipedia in {{convert}}, I don't see the problem in using it in the table headings – in the context of "km | mi" or "mi | km", what else is "mi" going to be? - Evad37[talk]01:55, 10 June 2014 (UTC)
@Mitch Ames, NebY, Evad37, and Rschen7754: I know this thread is almost 8 months old, but do we have any resolution? For a large number of articles, if we change the appropriate templates, the headings will change as the server processes the change through the job queue. I have no objection to switching to "mi", but any of the other options present other issues. Imzadi 1979→15:34, 17 February 2015 (UTC)
To pop in and offer my opinion I see nothing wrong with changing "mile" to "mi" as it keeps consistent use of abbreviations along with "km", however, the status quo is also fine. I'm indifferent as long as we don't change "km" to "kilometer" as that is too clunky for the header. Dough487217:37, 17 February 2015 (UTC)
I wouldn't object. I'm still not fond of "mi" and I'm not convinced that we need this sort of consistency, but "mi" is more common than I thought. NebY (talk) 18:15, 17 February 2015 (UTC)
Latest comment: 10 years ago18 comments9 people in discussion
MOS:RJL#What to include says to include "major water bodies", which seems to be a bit strange. If a road passes over a river - on a bridge, with no off-ramp leading to the water's edge - there is no "junction" with the river, and the road does not "join" the river. If a highway passed over another highway "where no interchange between the highways exists", RJL says that crossing should be excluded, so why would we include a body of water (over which a road passed) "where no interchange between the road and the body of water exists"?
Favor. There are a lot of rivers in the Southeast and some editors get too existed naming every one of them along a route when there is really nothing particular about the river and/or bridge. I would prefer removing them altogether; but if that's not going to happen, then at least tighten the rules were justification can be made beyond just crossing a body of water (i.e. historic or unique bridge used). --WashuOtaku (talk) 19:35, 10 June 2014 (UTC)
Oppose—only "major water bodies" are supposed to be listed for the reasons Fredddie says. In the cases WashuOtaku mentions, it's called "editorial judgement". The reason the word "major" was chosen was to avoid every single stream from being listed. Even a body of water being called a "river" may not be enough to make it major, and that's a judgement for editors to make concerning the specific article. If people are getting too excited over smaller water bodies, {{trout}} them. Imzadi 1979→20:06, 10 June 2014 (UTC)
I understand that major water bodies are useful points of reference / landmarks, but they are not "junctions". If the intent is to list landmarks then perhaps MOS:RJL needs updating (possibly renaming) to include landmarks that are not junctions with the road. One could argue that where road A passes over or under major road B, that over/underpass is a useful landmark also, even when there is no interchange between the two roads - but RJL currently explicitly excludes such a landmark.
Fredddie's example of I-275 going over Tampa Bay on the Sunshine Skyway Bridge is interesting, because the I-275 does connect to the Bridge. So there is a junction with the bridge, whose location happens to be the Bay. The specific instance that triggered this discussion is Forrest Highway#Major intersections. The road very definitely does not intersect or join the river - it passes over it. Possibly:
Pinjarra Rd should be listed as one row in that table
Murray River Bridge (assuming that the bridge has that name) should be listed as a second row in that table
Whether the Murray River Bridge is an "intersection" or a "junction" is debatable - in normal Australian English usage I would say not. Would US or UK people use "intersection" or "junction" (in contexts other than Wikipedia and MOS:RJL) to describe a named bridge carrying a road goes over a river, when there are no exits from the road at the bridge (eg leading to the water)? Would anyone call the Mount Henry Bridge an intersection or junction on the Kwinana Freeway? Yes, it's definitely a landmark and useful point of reference, but I don't think it is a junction or intersection, or interchange (as implied by being listed under Kwinana Freeway#Interchanges).
As I said, I see the merit in listing landmarks (such as a body of water), but in that case I think RJL needs rewording - including, but not limited to, the lead paragraph - to state explicitly that the list should include junctions/intersections and landmarks that are not junctions/intersections with the road in question.— Preceding unsigned comment added by Mitch Ames (talk • contribs) 11:37, 12 June 2014 (UTC)
@Mitch Ames: "Murray River & Pinjarra Road" is the actual name of the bridge, according to Main Roads WA; and Pinjarra Road is already included in the first row of the junction list. - Evad37[talk]12:45, 12 June 2014 (UTC)
If the bridge is officialy called "Murray River & Pinjarra Road Bridge", a reference would probably be a good idea. However a Google search for that term did not turn up anything. What I did find were references to Windich Bridge and this Main Roads document (April 2009, according to PDF properties, so it may not be current) which refers to "Pinjarra Road Interchange" and "Murray River Bridge". (We might want to take that specific issue back to Talk:Forrest Highway.)
In any case, having a name for the bridge and treating the bridge and the Pinjarra Rd interchange as a single entity might solve the issue for that article, but it does not resolve the general problem here, that RJL purports to be about road junctions, but allows inclusion of a major body of water that does not form a junction or interchange with the road (while explicitly excluding "Crossings with other highways where no interchange between the highways exists", even though such a crossing could just as easily be a landmark).
If the intent of RJL is to include landmarks other than junctions, then the lead paragraph (and possibly other sections) should say so explicitly. If the intent is to only include things that actually form a junction (road) with the road then bodies of water ought not be included. Limiting RJL to junctions might not be what we want, because not all bridges "allow vehicular traffic to change from one road to another", so some quite notable bridges (eg Mount Henry Bridge) would be excluded.
If landmarks (that are not junctions) are to be included, it might be appropriate to explicitly include the name of the body of water a bridge goes over, eg instead of Toll barriers, major water bodies, major bridges and tunnels, it should be Toll barriers, major bridges and tunnels, the names of major water bodies over/under which bridges and tunnels pass.
This whole thing is splitting hairs. If a major water body is mentioned, the context of it being mentioned in a junction list implies that the highway crosses over/under the major water body. VC 02:22, 15 June 2014 (UTC)
If a major water body is mentioned, the context of it being mentioned in a junction list implies that the highway crosses over/under the major water body It might be being mentioned because it is a landmark that the road passes next to, rather than associated with a bridge carrying the road over the water. See below. Mitch Ames (talk) 07:30, 15 June 2014 (UTC)
Perhaps we should temporarily put aside the issue of "bodies of water" and go back to a more fundamental question. Is a "road junction list" intended to include:
Junctions as defined in junction (road), ie "a location where multiple roads intersect, allowing vehicular traffic to change from one road to another"? (Presumably yes, but this is included for completeness, and for contrast with other items.)
Bridges that are not junctions as defined in junction (road) (criteria yet to be defined, but possibly "named" or "over major bodies of water", but presumably not "other highways where no interchange between the highways exists", what about "over railway lines")? (Examples: Mount Henry Bridge, Redcliffe Bridge)
Notable landmarks that are not junctions (item 1) or bridges that meet the yet-to-be-defined criteria for 2?
Other things, such as toll barriers and service areas, that may or may not be junctions as defined above.
"Junctions" where that word is defined to mean something other than what junction (road) defines it as? In that case I suggest that RJL should define what it means by "junction". If the meaning varies from one country to another, it's probably worth saying so explicitly.
At the moment the guide's name, and the lead section says "junction" - which in this context, and in the absence of any other definition, implies junction (road) - but "what to include" explicitly lists things that are not necessarily junctions (and includes "bodies of water" which are unlikely to ever be junctions). It includes bridges over water, but excludes bridges over other roads (where there is no interchange) - but it's not obvious why a bridge over water is more of a junction than a bridge over another road. It's not clear from the guide, whether the intent is to strictly limit the list to "junctions", or to always include bridges over major bodies of water even when they are not technically junctions, or to leave it to the editor's discretion. If it's strictly junctions, Mt Henry Bridge should be removed from MOS:RJL#Kwinana Freeway.
Oppose, but please note that "major" is open to interpretation. Mitch Ames, is there a specific case that you are concerned about? --Rschen775405:46, 20 June 2014 (UTC)
Oppose, simply because a feature is not a junction doesn't mean it shouldn't be listed in the list as a reference item. It is certainly useful to our readers to include things like counties traversed with no junctions, toll plazas, important bridges, and other non-junction features, so throwing them out just because they are not junctions would be obtusely anal and bureaucratic. —Scott5114↗[EXACT CHANGE ONLY]06:18, 20 June 2014 (UTC)
I'm not fundamentally opposed to excluding features that are not junctions from the lists - what I am suggesting is that the text of the guidelines match what we want the lists to include, which currently is not the case. Mitch Ames (talk) 12:25, 20 June 2014 (UTC) :Mixed feelings, I understand the point. I'm also very much aware of the futility of keeping these major landmarks off of highway articles. I dare you to sign up to keep Golden Gate Bridge off of the junctions list for U.S. Route 101 in California, even though you're right there is no junction there (unless you count the shipping channel as a junction) but if you do it you'll be blocked for 3RR in the first 6 hours. =-) Dave (talk) 06:25, 20 June 2014 (UTC)
Just so that's its clear what we think should go in "road junctions lists", could some editors please give their opinions on which of items 1 - 5 above they think we should include in RJLs, and what they mean by "junction". Mitch Ames (talk) 12:25, 20 June 2014 (UTC)
Whether a bridge is technically a junction or not seems to be beside the point. Going back all the way to 2007 [7], the consensus recorded on this page has been that certain features other than road junctions (as in junction (road)) should be included, such as bridges over significant water bodies. Judging by the responses above, this consensus is unlikely to change any time soon. While "road junctions and other significant features list" would be more accurate, surely we can stay with "road junction list" for brevity, on the understanding that these lists/table do predominately feature road junctions. Perhaps such a definition would be useful to have in the lead, something like
Road junction lists, whilst predominately listing road junctions, may also include some other significant features as points of reference.
as already indicated in the 'What to include' subsection. The wording could be adjusted/improved, but that shows the general thought. - Evad37[talk]13:26, 20 June 2014 (UTC)
I think that works, or something that more-or-less says the same thing. We should remember that guidelines should be crafted to represent the current generally-consistent state of good/featured articles, rather than crafted to change existing practise. - Floydianτ¢23:09, 20 June 2014 (UTC)
What to include: at-grade highway intersections
Latest comment: 8 years ago8 comments5 people in discussion
The what to include list of inclusions and exclusions is biased toward highways with grade separated interchanges only. What about highways with no interchanges, just at-grade intersections? What about highways with a combination of both? Through some mentoring from Imzadi and Rschen a few years ago, I believe the consensus approach reported to me for highways was to only include at-grade intersections with other highways in the absence of interchanges. If this is correct, given the majority of highways do not have interchanges, I think the what to include list should be revised to provide explicit direction on how to approach highways with only at-grade intersections. Hwy43 (talk) 19:00, 12 June 2016 (UTC)
I think what you're concerned with ends up falling under local consensus. What you've described is certainly the standard operating procedure for U.S. Roads, and is mentioned on the project's standards page. Other regions might not follow this approach though, hence one explanation why such language may be absent from this page. -- LJ↗22:53, 12 June 2016 (UTC)
I would have to agree. From what I know (looking at the Ontario GAs/FAs) I think this is what is followed. --Rschen775423:12, 12 June 2016 (UTC)
The better, and more generic statement might be phrased: "list all junctions with other roadways at the same classification level as the subject of the article, or a higher classification" as one bullet point and retain the other bullet points as written. (Even then, the US would concatenate Interstate, US and state highways as a single level because in many ways they're considered as types of state highway generally.) We should probably also make it explicit to always include the termini, even though that should be a given. Imzadi 1979→00:41, 13 June 2016 (UTC)
Maybe, but it's a starting point. I've often included county-level roadways in state highway articles' RJLs because they're indicated on the official state map. We're setting a minimum floor, not a maximum ceiling, and only good editorial judgment applying the guidelines will determine that ceiling. Imzadi 1979→00:51, 13 June 2016 (UTC)
Latest comment: 8 years ago3 comments3 people in discussion
Should railway crossings be included? They are an important reference point, and can be very important places on many roads.Beejsterb (talk) 01:06, 13 July 2016 (UTC) Beejsterb (talk) 01:06, 13 July 2016 (UTC)
Latest comment: 7 years ago11 comments6 people in discussion
Recently, WMF updated its palette of colors (view here) in order to improve readability for people who don't see colors well. I'd like to propose using some of those same colors in order to unify our project with the rest of the encyclopedia.
Color key
Current Color
Proposed color
Use
Notes
#ddffdd
#f5fdf4 (GREEN90)
Concurrency terminus
#d3d3d3
#c8ccd1 (BASE70)
Closed
Previously complete and open, but now closed (temp. or perm.)
#ffff99
#fef6e7 (YELLOW90)
HOV only
Interchange/intersection only accessible to high-occupancy vehicles (HOV)
#ffdddd
#fee7e6 (RED90)
Incomplete access
Some ramps/movements missing
#dcdcfe
ETC/Tolled
Interchange or bridge requires the use of electronic toll collection or is otherwise tolled as an exception to the rest of the roadway
#ffdead
Unopened
Interchange/intersection being constructed, not yet open to traffic
#dff9f9
#eaf3ff (ACCENT90)
Route transition
Indicates a transition from one route number to either another route number, or a section without a route number, along a named road
#dcdcfe
stripes
ETC test
Don't take this too seriously, it's only a test
Two of the colors are not listed on the palette, so I am not suggesting any changes to those colors at this time. –Fredddie™03:12, 22 December 2016 (UTC)
I'm fine with RED90, YELLOW90, and BASE70, and to a lesser extent ACCENT90. GREEN90 looks more like light blue than it does light green to my eyes. -happy521403:28, 22 December 2016 (UTC)
Agree with the merits of the proposal. I agree with Happy5214 about the green color, and I also think Yellow90 and Red90 are kind of close in color (depending on the angle I view it from on my screen). -- LJ↗03:31, 22 December 2016 (UTC)
Random thought: I wonder if we shouldn't split the ETC and toll colors so that they aren't the same. They're not really supposed to be used at the same time in the same article, but it happens. If so, I'd propose retaining a purple shade for ETC. Then I'm tempted to use green for toll, changing the concurrency terminus color to something else. The other option would be to use a yellow for toll and reassign the HOV use a different color. I'm not pleased with the YELLOW90 at all, and I'd suggest a replacement option. Imzadi 1979→04:53, 22 December 2016 (UTC)
See Pennsylvania Turnpike for an RJL that uses both meanings for the ETC/toll color. I agree that using the same color is confusing and that we should find a second color for one of them. VC 03:38, 23 December 2016 (UTC)
I just did a proof of concept that striping the cell could work. Not that we want to do that, but it seems to be an option. –Fredddie™03:47, 23 December 2016 (UTC)
The GREEN90 shade is actually closer to our existing route transition color on my screen, so I'm thinking that it should be reassigned there. Maybe the toll color could be the existing #ddffdd color, and we either use the ACCENT90 shade for concurrency termini, or find another color from the palette? Imzadi 1979→03:48, 23 December 2016 (UTC)
Replying after the edit conflict, but I like the stripes; they would allow use to keep a linkage between ETC and toll (both involve money) without requiring us to use two different colors. Imzadi 1979→03:51, 23 December 2016 (UTC)
And I'm pretty darn sure they're terrible for accessibility. I have no personal problem with the stripes, but I think having them defeats the purpose of redoing the colors more than a bit. -happy521400:28, 24 December 2016 (UTC)
Insertion of a rail-only right of way
Latest comment: 7 years ago7 comments7 people in discussion
Someone recently attempted to insert a rail-only right of way into a junction list, listing only {{rint}} into the destination column instead, as WP:RJL#Tables basically says, {{jct}}, a road name or destination name presented on guide signs.[8] Is there any consensus for this? Zzyzx11 (talk) 08:22, 5 July 2016 (UTC)
I can't say that I personally approve of that change. One of the concepts we've slowly been integrating into articles is that whenever a graphic appears, there's a caption of some sort for it. At the top of the infobox, where the primary marker for the highway appears, the name appears below it. Good articles have captions for the maps in the infobox. In a RJL table, the names of the highways referenced appears after the markers in each row of the table. So at least on that score, the edit was deficient because the template only added an icon without any extra text.
As for the rail-only line in the table, I don't quite see that as useful information in keeping with the overall purpose of the table. We've used {{jctplace}} to insert where highways transition from freeways or expressways and back to surface highways or where express–local configurations begin and end, and that's similar to the rail-only situation, but I'm not convinced that it is a status that really affects vehicular traffic. For that reason, I wouldn't include it. Imzadi 1979→17:15, 5 July 2016 (UTC)
At the bottom of the slippery slope, we'd have to come up with inclusion criteria for level crossings because there'd be so many to add. This seems more like a job for prose anyway, so I'm !voting no. –Fredddie™23:42, 5 July 2016 (UTC)
We already have a "sliding scale" for things like bridges, bodies of water, rest areas, and tunnels as "not interchange features" being listed in the junctions list. So I agree with Fredddie's point that it's a slippery slope. However, we're already on a slippery slope. There are already cases where we've had edit wars with people adding bridges that don't even have wikipedia articles about them to exit lists, because "hey this bridge is listed there so what about bridge B". An extreme example, most most Wikipedia articles Tunnels are allowed on the exit list and every tunnel is listed. However, on Interstate 70 in Colorado, some tunnels are missing from the exit list. This was done by consensus (after some minor edit warring) as some of the tunnels on I-70 are short and non-notable. I view rail crossings as "yet another" instance of non-intersection features being included in the exit list.
On a highway as long and as complex as California State Route 1, I would say no way should we add rail crossings. The infobox is complicated enough as it is, without opening the door for rail crossings (of which there are undoubtedly dozens on this route). On a highway that has 10 entries in the exit list, I would consider allowing railroad crossings. On a highway that has 100 entries in the exit list, no; same as we do with things like bridges, tunnels and view areas.
If we do allow railroad crossings, there is a tougher issue to manage. Roads are mostly publicly owned and their official name and owner is a matter of public record. However, that's not the same for railroads, where the owners, and operators situation is much more complicated, and sometimes not even documented. For example, in the edit to CA-1 that started this thread, the lines were listed by their MUNI route numbers. However, that says nothing as to who owns the track or it's official name, and may not be correct. It may be MUNI owned track, it may be owned by a private company and the public agency is either granted trackage rights, or outright leased the track. For a well sourced exit list, it creates a more complicated web to untangle. Dave (talk) 00:27, 6 July 2016 (UTC)
I am completely against adding railroad crossings to junction lists since railroads and roads are different modes of transportation and its not really noteworthy to mention the crossings whether at-grade or grade-separated. However, it is acceptable to include an interchange that serves a train station, such as the one serving Cornwells Heights station along Interstate 95 in Pennsylvania. Dough487201:24, 13 July 2016 (UTC)
Leave it to the route descriptions, and some linear maps. And yes interchanges and intersections that serve railroad station are not just acceptable, they're a good idea. ---------User:DanTD (talk) 01:30, 24 December 2016 (UTC)
LGA should be removed from Australian example
Latest comment: 7 years ago5 comments4 people in discussion
I've tried raising this at Template talk:AUSinttop but no one's answering, so I'll try here: the Australian template shouldn't include the LGA (Local Government Area). Presumably someone thought it was the Australian equivalent to a county in the UK or USA, but it's not. They're purely an administrative thing and never used when referring to geographical locations. They're not used in postal addresses. And, on the point of this article, they're not referred to in travel destinations. To take the example in the article, no one travelling from the 4th entrance to the last would say, "I'm travelling from South Perth council area to Murray Council area"; they'd say "I'm travelling from Como to Ravenswood". The LGA adds unnecessary information, and clutters the table. It should be removed, both from the template and from this style page. Adpete (talk) 04:16, 29 December 2016 (UTC)
There was some discussion about four or five years ago when junction lists first started to be converted to follow this MOS page (but I can't seem to find it at the moment). Also of note is the WP:AURD/RJL project standard/advice page from WikiProject Australian Roads (which includes LGA). Anyway, the LGA column isn't pointless – it provides some context between somewhere in the state and this very particular location for the "State subdivision" column mentioned at MOS:RJL#Standard_columns. Plus for roads which aren't controlled by the States, the LGA would in almost every case be the auhority in charge of the road. State-based regions could possibly be an alternative with more 'geographic', but the boundaries can be confusing as different regional systems can have regions with the same or similar names, but different boundaries (e.g. Regions of Western Australia). LGAs at least have a single specific boundary. And when driving along major roads that cross LGA boundaries, it is quite common to see "Welcome to..." and/or "Thanks for visiting..." signs for LGAs. You can might get more comments and more Australian editors' opinions at Wikipedia talk:WikiProject Australian Roads. - Evad37[talk]00:21, 3 January 2017 (UTC)
Hi all, I'm a member of WP:WikiProject Australian Roads and an avid editor to highways and motorways, especially in NSW and ACT. This debate could go back and forth forever. In order to bring the matter to conclusion in a timely manner, I suggest that Adpete succinctly propose the arguments in favour of removing the LGA from MOS/Rjl in a format similar to {{Template:Merge to}}. Then each person may respond in the format of either Support or Oppose and state the reasons for their case. After say, ten days (given the time of year when many people are on breaks), there should be a count of the for and against votes and then a decision made on whether we include LGAs or remove them. Finally, the best place for this vote to occur is at Template talk:AUSinttop
– and not here or at Talk:WP Australian Roads, where there is extensive discussion on the subject. That's my comments for the time being. Rangasyd (talk) 09:22, 4 January 2017 (UTC)
Junction list colors for toll and ETC
Latest comment: 7 years ago7 comments4 people in discussion
I have concerns with the junction list colors that need to be addressed. The colors for ETC and toll are an identical shade of purple, which can be confusing if a road has both ETC only tolls and traditional toll facilities. Is there a way we could differentiate between the two and use two different shades of purple? Dough487200:20, 26 September 2017 (UTC)
For those who aren't aware, "ETC" is Electronic Toll Collection, a relatively new phenomena pioneered in the late 1990s where cameras scan a licence plate to charge the vehicle owner based on distance travelled. My only comment is: why do they need separate colo(u)rs? - Floydianτ¢02:39, 26 September 2017 (UTC)
The reason is that they're supposed to be mutually exclusive within the same article, but apparently people don't get that concept. For a toll road, an interchange that is restricted to usage by drivers paying via ETC (electronic toll collection, whether by plate or transponder) is the exception to the general rule that warrants the highlight. For a non-toll road, a bridge or interchange involving a toll is the exception to the general rule that warrants the highlight. If we're going to allow both situations to be highlighted in the same article, we'd need two separate colors, not separate shades. So far, we have in use red, orange, yellow, green, blue (cyan), purple and gray for incomplete, under construction, HOV-only, concurrency termini, route transitions, toll/ETC and closed/former. If I were to reconfigure the color mappings and separate the toll and ETC cases, I'd use green for toll (as the color of money) and leave purple for ETC (the color used for ETC signage), which would mean we'd need a new color for concurrency termini. The only basic color not in use that would not require the usage of white text is a lighter shade of brown unless we could pick a shade of blue that worked and was still distinct enough from the cyan. Imzadi 1979→02:48, 26 September 2017 (UTC)
Is it really that confusing, given that colour isn't (or shouldn't be) the only way the information is imparted? – i.e. the notes column should also specify the tolling. Do you have particular examples to illustrate your point? - Evad37[talk]03:30, 26 September 2017 (UTC)
I think we can use green for toll and purple for ETC while using a different shade of blue for concurrency termini. The Pennsylvania Turnpike article has both the toll color for the toll booths that mark the end of the ticket system and the ETC color for the E-ZPass only exits, so we need differentiation there. Also, Interstate 95 in Maryland has both traditional toll plazas and ETC express lanes. Dough487203:52, 26 September 2017 (UTC)
At least in the turnpike case, the toll booths should not be colorized because it's a toll road. The ETC-only exits should, because they're the exception to the general rule. Imzadi 1979→04:18, 26 September 2017 (UTC)
But the I-95 MD case is a good example why we need two colors, the two toll booths along with the ETC express lanes are exceptions to what is otherwise a free highway. Dough487204:28, 26 September 2017 (UTC)
Jctbridge template not showing dual locations for crossings
Latest comment: 6 years ago4 comments2 people in discussion
I just added two river crossings to Interstate 480 (Ohio) but couldn't show both of the municipalities at each in the location column – a city line runs down each river – because Template:Jctbridge doesn't recognize "location1" and "location2" like Template:Jctint does. For now the respective westernmost cities are shown, with the easternmost commented out right below in the code. (As an aside, I also left the mi/km columns blank since I don't know what reference point is used for bridges). Mapsax (talk) 15:51, 6 December 2017 (UTC)
In those cases, the location for the bridge is usually the river, and not necessarily the cities. As for the one, since the bridge doesn't have a name, or if it does, it doesn't have an article, I removed that crossing completely. The primary purpose of these tables is to list the junctions/exits, and as it's been noted before, a bridge isn't a junction. We do include major bridges and tunnels, which usually means those structures are independently notable and have a separate article. That, or the body of water is especially significant. Otherwise we run the risk of cluttering the tables with every little creek or stream. Imzadi 1979→19:14, 6 December 2017 (UTC)
Per your first sentence: I see this implied in the examples on the MOS/RJL main page, but I was using the Usage notes at the Jctbridge template as my guide, and there is no mention of that there. Whoever oversees those notes probably should add it. I will defer rather than be BOLD at this point. As for the omitted crossing: I'll admit that that one was a toss-up, but what decided it for me was that while the crossing has no article, the river does, in addition to the crossing being a high-level bridge and a local landmark. I was poking around a little bit before the edit to see if it had a name, and if it had, I might have added a red link, that's how notable I saw it. I won't lose sleep with it not being there, but, again, maybe a mention of notability parameters should also be added to the template's usage notes. And while I'm on that kick, the "mile" entry there should also address my parenthetical above, since I still don't know which figure to use in the respective remaining entry; I have three from which to choose per the ODOT straight-line diagram: the west end, the city boundary, and the east end.
It's true that none of this is crucial to the article, but it the template's there, we might as well use it, and use it correctly. Mapsax (talk) 13:55, 7 December 2017 (UTC)
@Mapsax: usually, for mile posts, I use a single point if it's an intersection, but a range if it's something like a bridge. When it comes to interchanges, if the cross road is divided, I use a range again for the two points where each carriage way crosses/is crossed. Imzadi 1979→14:22, 7 December 2017 (UTC)
Services in exit lists
Latest comment: 6 years ago7 comments5 people in discussion
I was thinking of an idea of something we can do to enhance our exit lists. Maybe we should look into including services that are available at each exit along each limited-access road (food, gas, lodging, camping, phone) as suggested by blue service signs along the road. If we did this, we would just keep it general by mentioning just the type of service (for example, "food", not "McDonald's and KFC"). Also, we should only do this for exits along limited-access roads and not at-grade intersections along surface roads. If we did this, we could either mention the services in the notes or maybe create a services column in the exit list. I thought this would be a good enhancement for our exit lists as to give readers an idea what services are available at each exit, which could be a good idea if they're planning a trip along an Interstate through rural areas and should have an idea what to expect at the exits. I just wanted to get input from project members on whether we should do this or not. If so, we should make changes to MOS:RJL to provide guidance on how they should be handled. Dough487219:22, 30 January 2018 (UTC)
Oppose. I think this would make us a tour guide, which we are NOT. Plus, I think it would creep into every article, which is not idea. If you recall back in the early days of USRD (loooong before RJL became part of the MoS), junction lists were only for Interstate Highway articles and they crept into nearly every article. –Fredddie™21:08, 30 January 2018 (UTC)
Oppose—I sympathize with the proposal, but the creep issue makes it an non-starter. I could see this as an addition to the service area listings on toll roads, but I'm not sure how to handle it appropriately to avoid information overload. Imzadi 1979→22:48, 30 January 2018 (UTC)
Okay, I'm starting to get an idea that including services in exit lists for road articles on Wikipedia is a bad idea. But I'm thinking an idea is to do exit lists with services on Wikivoyage as that is a travel guide more suited for that information. We could create Wikivoyage pages for every Interstate (using the same rule for state-detail pages as we do here), and on those pages have an exit list generated using the same templates here that could include much of the same information here such as counties, locations, mileposts, exit numbers, and destinations, but with additional columns for services (food, gas, lodging, camping, phone, attractions). If this is done on Wikivoyage, then we could more specific with the services at each exit, as in what specific restaurants, gas stations, and hotels are at each exit. How we would this on Wikivoyage can be discussed, but any further discussion should probably be done there. Dough487201:14, 31 January 2018 (UTC)
Latest comment: 6 years ago1 comment1 person in discussion
I brought up some issues on the talk page quite some time ago but never got any reply. The main thing being that several of the listed “major intersections” aren’t really major and the one at the terminus may not exist at all. Beeblebrox (talk) 20:44, 14 June 2018 (UTC)
Temporary closures
Latest comment: 6 years ago3 comments3 people in discussion
Exits that are temporarily closed should in Template:Jctbtm not have the same color as those that are closed permanently. They could be given an orange tint, as that color has not been used yet. OhioRoadSigns (talk) 12:09, 26 July 2018 (UTC)
@OhioRoadSigns: do you have a specific article about which you mean? In any case, the orange color is reserved for intersections that unopened/under construction, and the gray color is used for closed/former intersections. Imzadi 1979→13:21, 26 July 2018 (UTC)
We really shouldn't be covering temporary closures with any specificity, especially not in junction lists. If you must, speaking in generalities in prose is best. –Fredddie™05:06, 7 August 2018 (UTC)
Latest comment: 6 years ago8 comments7 people in discussion
Gonnym and I are having a discussion and the idea came up to use tooltips in the RJL mile and kilometer abbreviations. So I'm here to ask if that's something we could/should do. –Fredddie™06:31, 15 October 2018 (UTC)
I like it. Just curious, is this for the "cool factor" or has someone actually complained that mi and km are not obvious abbreviations? Dave (talk) 13:09, 15 October 2018 (UTC)
I think the tooltips are a great idea for readers who don't understand what the abbreviations "mi" and "km" mean. Dough487221:58, 15 October 2018 (UTC)
Exit terminology when an exit is only on one direction
Latest comment: 5 years ago13 comments6 people in discussion
The Interstate 75 in Georgia article (I'm using this as an example) is inconsistent on how it describes exits that are on only one direction. It sometimes says "Northbound exit only"; sometimes it says "Northbound exit and southbound entrance"; sometimes it says "No northbound exit". (For clarification, these phrases also have the variants where the words ending in "bound" are replaced by their opposite meaning; both variants apply.) This is ridiculous because exit lists are supposed to be about exits, not entrances. Any thoughts?? (Please apply whatever changes there are to all Wikipedia articles with highway exit lists.) Georgia guy (talk) 15:18, 14 December 2018 (UTC)
The three examples have different meanings. To wit:
"Northbound exit only" means at that interchange, only northbound traffic may exit. Northbound traffic may not enter, and southbound traffic may not enter nor exit.
"Northbound exit and southbound entrance" means at that interchange, only northbound traffic may exit, and only southbound traffic may enter. Southbound traffic may not exit, and northbound traffic may not enter.
"No northbound exit" means at that interchange, of the four possible options, only one is missing. Northbound traffic may not exit, but it can enter the freeway. Southbound traffic is not restricted; it can enter and exit.
In short, the notes exist in these formats because the succinctly state the access restrictions. As for meaning, exit lists cover the interchanges. That means covering entrance restrictions as well as exit restrictions. Imzadi 1979→02:42, 15 December 2018 (UTC)
They are all examples of incomplete interchanges (thus highlighted in pink), the notes provide additional information why it is incomplete. --WashuOtaku (talk) 11:32, 15 December 2018 (UTC)
It's incredibly pedantic. This has been part of the MoS for over 10 years and I cannot recall any time when an article goes through FAC that it was tripped up because the section was titled "exit list" and not "exit and entrance list". –Fredddie™14:49, 15 December 2018 (UTC)
That's because everyone perceived it as a list of exits only, and nobody bothered to notice that it was in fact a list of exits and entrances. Georgia guy (talk) 14:54, 15 December 2018 (UTC)
I think in all this time, most users/readers have not bothered to dwell on the section header other than distinguishing between a junction list (on non-freeways) or exit list (on freeways). You're being really pedantic here, as I think the intent is understood by most readers. If you insist on pushing this point, at least advocate for something more palatable like "Interchange list". LJ↗18:19, 15 December 2018 (UTC)
@User:Imzadi1979 has twice reverted my edits showing interchange type for each grade-separated junction in the "major intersections" table. They argue that such information is "not needed for a generalist audience". We've had a similar discussion earlier, where they seemed OK with a bare reference to "interchange", just not the type. In fact, as this highway has different characteristics along its length, I also included "intersection" for each row that qualifies. They seemingly inconsistently were not bothered by this, as they did not remove those facts. I return to my earlier arguments: 1) The information is correct, 2) A generalist reader can see the words "SomeTypeOf interchange" and ignore it, 3) An interested reader might follow the link, or hover over it, if supported by browser and 4) WP:IDONTLIKEIT is not a valid, policy-based reason not to include non-trivial information about an article. --Chaswmsday (talk) 22:02, 14 July 2018 (UTC)
I don't like them either, but I'm not going to remove them; nor do I like the "intersection" notes. All too often, our notes columns get bogged down by people (generally speaking, I'm not calling you out Chaswmsday) feeling the need to add every single nugget of information they can find. When that happens, the destinations column, which IMHO is the most important column in the table, gets squeezed to about 10% of the table while the notes column takes up 40%. So let me be clear; I don't hate these "notes", but they would be better off as prose in the all-but absent RD. –Fredddie™03:46, 16 July 2018 (UTC)
Freddie, thanks for having a civil discussion with me instead of just reverting. I consider intersection type an important fact about a junction, not a random "nugget". In fact, MOS:RJLspecifically calls for the "design of an interchange" to be included as part of an interchange row's Notes. I'm not sure what you mean by 10% vs 40%. Visually on a mobile device? Visually on all devices? Amount of markup code devoted to a note vs to destinations?
Nonetheless, I have no issue covering such info under the Route description only. However, @Imzadi1979:does. Under Interstate 675 (Ohio), during a recent string of edits of this very type I was making to the RD, they added this snidely-worded comment: "note to editors: don't write this section as a regurgitation of the exit list. That style of writing is quite yawn-inducing for general readers. Instead, give them a sense of where the highway goes and what a driver would see along the way." I personally don't care for this type of prose, finding it often overly WP:FLOWERY, but I wouldn't remove it unless it's inaccurate or blatantly crosses the line into boosterism. Imzadi1979's comment was added just below a 2013 "expand the section" comment urging moving prose from Notes to the RD.
Imzadi1979, in this (US 24 in Ohio) article, seems to have no problem leaving standing a recently-added (as of this date) image with the caption "Part of the new 'Fort to Port' US 24 freeway in Ohio". The word "new" violates the MOS section "Relative time references"; while "Fort to Port" is a term undefined within the article. Yet not a peep.
So, between the catch-22 of following MOS guidelines or face being selectively reverted, then trolled by un-WP:CIVIL comments on Imzadi1979's part, I cannotassume good faith. Again, not directed specifically at you Freddie, mostly to Imzadi1979. --Chaswmsday (talk) 21:01, 20 July 2018 (UTC)
@Chaswmsday: three quick points are in order here. MOS:RJL doesn't require the notes to include the interchange type. It offers some suggestions for additional information in list in the notes, but nowhere does it use a "shall" signal to require any of them.
The second is that the RD section needs to describe the route of a highway. There is a lot more to the route of a highway than its interchanges. In fact, I'd say most of a freeway's length is not contained within the interchanges. Where the road goes, what it passes, and the directions it takes to get there are all integral to the route.
Following the second point, keep the description objective, and you won't have to worry about WP:FLOWERY. That guideline has to do with biased writing and using Wikipedia's voice to make claims. It would be against the guideline to call a highway segment "scenic", but it isn't puffery to say it has a scenic highway designation. Imzadi 1979→05:27, 21 July 2018 (UTC)
End Copy.
Despite this earlier discussion, Imzadi1979 is once again reverting interchange types, shown in these diffs: Interstate 196 & U.S. Route 131, now calling the information an "esoteric detail".
A plain reading of this MOS shows it strongly encourages including "the design of an interchange" in the Notes column. It even holds up Kwinana Freeway, which is replete with such table prose, as an exemplar of a table written to standards.
And now, these diffs: Interstate 196 & U.S. Route 131 by Imzadi1979, "other interchange types are not indicated, so yes, it's an esoteric and unneeded detail".
So, I'm trying to capture that this very rare (and IMHO notable), not formally named, interchange type exists on these roads AND to create a reciprocal link back to Interchange (road), where these very roads are specifically mentioned, but that's all supposedly "esoteric"? And now it's incumbent on me to cure any and all deficiencies in the affected pages?? OK, I'll play your game.--Chaswmsday (talk) 12:49, 30 July 2019 (UTC)
It looks like you're trying to include links to "hybrid interchange". Reading the section on interchange (road)#hybrid interchanges, it is not a specific interchange type but rather noting that blends of different interchange types may be used. To me, that isn't inherently notable such that you'd link to hybrid interchange in the notes column of the junction list. I can understand mentioning if the interchange is of a specific design, such as a diverging diamond or turbine—but there isn't a specific design associated with "hybrid interchange", so I think including it can be misleading or confusing to the reader. (Disclosure: I don't necessarily like listing interchange types myself, but don't necessarily actively remove them from articles either.) LJ↗14:22, 31 July 2019 (UTC)
I've had issues with "hybrid interchange" as well, as it doesn't reflect a type recognized by other sources. It all feels so much like original research to me.
As for the continued insertion of interchange types into exit list tables, a reply I typed out last week that apparently didn't save here, noted that the guideline text itself says of the notes column that it includes "[a]ny additional notes about the interchange or terminus, such as the design of an interchange, special circumstances such as missing ramps, concurrency termini, opening date, or additional locations that do not merit inclusion in 'Destinations'." Furthermore, of the seven examples tables, only one lists interchange types. That hardly seems to be that MOS:RJL "strongly encourages" anything of the sort, just that it offers it as possible content to be included. If it were mandated, the guideline would use stronger language, such as "the notes shall include the design of an interchange", and if it were encouraged, but optional, "the notes should include the design of an interchange". Imzadi 1979→20:54, 5 August 2019 (UTC)
(edit conflict) I find that saying "interchange" can be useful if it's a road that alternates between intersections and interchanges (for instance, U.S. Route 24 in Michigan has a couple cloverleaf exits with crossroads but is largely a divided highway otherwise). The verbiage to me suggests that interchange descriptors are encouraged if the exit follows a nonstandard design that requires clarification as to what ramp goes where, such as US-31/I-96/Hile Road/Airline Road or I-96/I-275/M-5; or if the exit does not provide access in all directions or only provides indirect access. If it's just a basic diamond on a rural freeway, then that doesn't need to be clarified. Ten Pound Hammer • (What did I screw up now?)21:05, 5 August 2019 (UTC)
Starting a new sub-thread for this: but what is the consensus on exit numbers for intersecting highways in the RJL? There's several IPs who keep re-adding them to Washington articles when they are wholly unnecessary (especially in the case of an exit 0 at a highway terminus). It's not exactly easy to cite and only saves a fraction of time compared to pointing users towards the appropriate article (already linked in the destination column). SounderBruce21:28, 5 August 2019 (UTC)
Note that MOS:RJL *is* a guideline, not a policy; "shall" and "should" are thus scarce within it. If one were to give this guideline *that* strict a reading, the "standard columns" verbiage doesn't *explicitly* state that mileage/kilometerage "should" be included; however *not* to do so would not be reasonable.
Also note, that among the example tables included in this guideline, the "only one" (quoted from Imzadi1979) that lists interchange types is in fact a Featured article, not some average, run-of-the-mill WP road article.--Chaswmsday (talk) 23:39, 8 August 2019 (UTC)
Procedural points: (Summoned by bot) It truly was pretty inappropriate to have moved this discussion here without the assent of the author(s). Basically said editors availed themselves of the appropriate community process for deciding a WP:LOCALCONSENSUS issue on a particular article, and then that proposal was moved here (awakwardly and with with !votes already lodged), where the proposal has an entirely different scope and context than that which was intended in the initial instance. This is doubly problematic in this case, as we are talking about MoS advice: while the style guide has some precedential power, it absolutely can be overridden by local consensus, if the editors of a given article decide there is good reason to do so. That means not only has the move A) changed the character of the proposal, widening it to all articles and therefore changing the outcome of the eventual !vote, it would still not resolve the issue definitively for any given article, meaning the RfC could be restarted there and nothing would have been accomplished except a waste of time for numerous editors.
Instead, this move should be reversed, and the RfC can run out as originally intended on the local talk page. Then, in parallel to that discussion, Chaswmsday can, if they so choose, open the issue here on this page with a separate and general RfC--which is what they should have done from the start. Note that this does not constitute forum shopping because it's entirely possible for both discussions to reach different conclusions as to what the appropriate outcome is, and in that case the more particular localconsensus at the article talk page would control if there was significant consensus, while a new more general standard for most articles generally will also have been established. It's also possible that the discussion here will result in an !vote that any general rule represents unnecesary WP:CREEP and that this issue should generally be left to local consensus without any strong default advice here. Lastly, both discussions could agree as to the appropriate course of action, in which case there would obviously be a clear path forward at the Route 131 article. But the point is, it is disruption of the consensus building process to move an ongoing RfC from its place of origin without some degree of assent by those who opened it and those who have commented thus far already. More than that, the move here confuses two different scopes and two different community discussions that need to take place in different spaces, instead conflating and smashing them together here. This is just not how our process is meant to work. Snowlet's rap10:09, 10 August 2019 (UTC)
M5, 
A38 and 
A379 mean to someone unfamiliar with them (eg an American).
= "Interstate", 
= "Interstate business loop / spur", 
= "US Route", helps to explain what the shields mean to someone unfamiliar with them (eg a Brit). Explanations for the relevant state/county routes would be good too. That would need switches to only display those relevant to the specific RJL.--Nilfanion (talk) 11:59, 6 April 2013 (UTC)
appears it's got a link to some sort of Interstate 35 related page after it, e.g. 
I-35. —Scott5114↗ [EXACT CHANGE ONLY] 17:40, 6 April 2013 (UTC)
, and the white version of that, in the same point of a RJL and both next to a wikilink to the same article (A370 road)... Without an explanation of why one is green and one is white (to have both as green would be incorrect).--Nilfanion (talk) 17:58, 6 April 2013 (UTC)
N1. I'm pretty sure South Africa was set up a while ago and has been used by a South African editor. –Fredddie™ 19:52, 30 June 2013 (UTC)
Done I will strongly oppose any further extension, however, because it appears that one of the parties is stalling for time. --Rschen7754 07:04, 2 July 2013 (UTC)
A41 - West Bromwich, Birmingham (north west)
A4123 - Dudley, Wolverhampton, Birmingham (west)
A456 - Birmingham (south west), Kidderminster
A491 Stourbridge
M42 - Birmingham (south & east), NEC, Birmingham Airport, London, the North East, Redditch
A449 - Worcester (north), Kidderminster;
A4538 - Evesham
A44 - Worcester (south), Evesham
A38 use 
. The linking and alt text give full accessibility, to an image that is basically text anyway (unlike the rather elaborate shields, the shape has meaning).--Nilfanion (talk) 23:35, 1 July 2013 (UTC)
, 
, 
or 
? Martinvl (talk) 05:59, 2 July 2013 (UTC)
and 
as appropriate - their bitmaps are only 256 bytes each.
returns a 640 byte bitmap image. Martinvl (talk) 06:59, 2 July 2013 (UTC)
M6 - The North West, Wolverhampton, Walsall
, but we'd still need text with it.
Frankley services (food and fuel)" in the colspanned version? I'm going to make a version of this that would work in the US. –Fredddie™ 16:24, 2 July 2013 (UTC)
Morshead Drive (north/west) / Pialligo Road (east) Canberra Airport
Canberra Avenue [B23]
Moved to Template talk:LegendRJL#Display_only_relevant_color_keys|Template talk:LegendRJL
), though I am more than willing to consider alternate phrasing - Evad37 (talk) 07:28, 18 July 2013 (UTC)
), though I am more than willing to consider alternate phrasing -- Nbound (talk) 07:54, 18 July 2013 (UTC)
Added after 1 week with no opposes - Evad37 (talk) 07:35, 25 July 2013 (UTC)
-- Nbound (talk) 11:17, 2 August 2013 (UTC)
N 223 –Fredddie™ 21:17, 1 March 2014 (UTC)
Done
Partly done [5], [6] - Evad37 [talk] 08:44, 11 March 2015 (UTC)
You are invited to join the discussion at Talk:Highway 2 (Israel)#RFC: Which table should be used . The RFC concerns the implementation of MOS:RJL Gonnym (talk) 19:44, 6 August 2018 (UTC)