Template talk:Jctbtm

Template:Jctbtm is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.

Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

Untitled

Can we set col= to have a default value of 5 if the user doesn't supply a col value? This is the normal number of columns (2 for location, 1 each for mileage, destination, and notes) and I think if the UK is only using one distance col they have 5 too (mileage, junction, notes, 2 for destinations). —Scott5114 ↗ [EXACT CHANGE ONLY] 13:32, 24 March 2010 (UTC)[reply]

We could. Something that should probably be updated before this template gets much use is to change the current uk= to a country= parameter. That way additional country-specific keys could be added. Imzadi1979 (talk) 17:19, 24 March 2010 (UTC)[reply]

Suggestion - unmatched bracket

This template results in an unmatched bracket. The reason is that it serves as the end of a table. The table starts regularly, with a {| but never closes, since it is this template that closes it. This has the effect that automated tools, such as AWB, get confused as to the end of the table.

I would like to suggest {{RJL begin}}, a template to be added for the head of the table as well, very much like {{col begin}}. It should have no effect on the looks, yet solve this minor problem. What do you think? --Muhandes (talk) 17:25, 23 September 2010 (UTC)[reply]

Tables which use this template often start with {{jcttop}} or {{exittop}}. Combined, this is 1,774 pages which would need the proposed {{RJL begin}}, which I'm guessing would have no content and only serve as a sentinel for AWB. I'm not seeing the value of wasting someone's time editing 1774 pages solely for the benefit of some unspecified feature of AWB. —Scott5114 ↗ [EXACT CHANGE ONLY] 05:22, 24 September 2010 (UTC)[reply]

Of course, tables starting with either {{jcttop}} or {{exittop}} (and there are other, I notice {{MIexittop}}) do not need this as they don't have an unmatched bracket. This is meant to be used only when the table is opened with {|, e.g. the one in M62 motorway. I was not aiming at an empty template, I was thinking it would include a very simple {| class="wikitable" I'm not familiar with the structures used, only with the minor issue they cause, so please try to work with me here (if you wish). Think of it as an opportunity to standardize. Would you say there are other common uses not covered by {{jcttop}} or {{exittop}}? Maybe this is better as {{otherRJLtop}}? And don't worry about "someone's time", this would be either myself or a bot. Still, if there is a general dislike of the idea I'll leave it. --Muhandes (talk) 08:27, 24 September 2010 (UTC)[reply]

I haven't really seen anywhere in the US that plain table code is used to start a table; most of the time people are wanting the standard columns so they will use a template that will generate them as necessary. I suppose such a practice might be more common in the UK, based on your example; you might want to touch base with WP:UKRD to see how they feel on it. —Scott5114 ↗ [EXACT CHANGE ONLY] 00:14, 25 September 2010 (UTC)[reply]

As the one that added the template to the M62 article, I had a simple reason. It's the only UKRD Featured Article, and it had a non-compliant junction list. UKRD is very slow to make updates and changes to their articles, and other European editors were using M62's article as a template, and emulating deprecated practices in contravention of the current MOS standards. As a USRD editor, it's not my job to develop all of the templates they might want, but as a part of WP:HWY, it is partially my responsibility to help ensure that "our best work" actually reflects our best practices. Imzadi 1979 → 00:27, 25 September 2010 (UTC)[reply]

I know most Nevada articles use plain wikitable code. That may change in the future, now that I have a better understanding of what the various 'top' templates do... -- LJ ↗ 01:40, 25 September 2010 (UTC)[reply]

Right, but do they use a template to close the table, like this one? That's the issue, not that NV articles use plain wikitable code. The best solution is for alternative table header row templates to be created where the current templates don't work. Imzadi 1979 → 02:43, 25 September 2010 (UTC)[reply]

I see now that I probably stepped into something which is beyond me here. This seems like something which requires a general standardization approach in WP:HWY, not my kludge proposals. Consider this proposal withdrawn, though I'd be happy to help with any other effort. Best regards. --Muhandes (talk) 17:59, 25 September 2010 (UTC)[reply]

Currently, Jctbtm is used 14,000 times; Jcttop is used only about 9,300 times. That means there's a large number of pages out there (such as Adriatic Sea) which I assume pair {| with this template. That's ugly wikicode, and impossible to parse properly without substituting templates. I don't see the corresponding benefit of pairing a template with a non-template. My suggestion would be to use an extra parameter to prevent the table being closed by this template in those cases, which might also come in handy for adding extra information after the jctbtm text. Eelworm (talk) 09:29, 9 October 2020 (UTC)[reply]

@Eelworm: that assumption would not be correct. There are several country- or state-specific template, like {{MIinttop}}, that could be paired with this template. That one template alone would account for over 200 articles. I'm not saying there aren't articles like Adriatic Sea that pair this template with wikicode, but articles like that one weren't the use case for this template, which is to provide the standard conversion key, optional color code key and close a table that complies with MOS:RJL. Imzadi 1979 → 15:43, 9 October 2020 (UTC)[reply]

Thanks! You're right, intermediate templates account for some of the difference, though some random sampling reveals that the problem isn't limited to just a few articles. And I'm not sure pairing "MIint" with "jctbtm", both entirely opaque terms to the uninitiated, results in readable and reusable wikicode. Maybe it's time to simplify things by using something like {{Junction list|junction1|junction2|junction3}}? Eelworm (talk) 17:59, 9 October 2020 (UTC)[reply]

Perhaps there is a case for looking at the naming conventions of some of the templates--the generic "jcttop" pairing with this "jctbtm" makes sense, but "MIinttop" with "jctbtm" is less intuitive and perhaps something like "MIjcttop" or "jcttopMI" would be better. However, the level of information and formatting detail required in these junction lists is likely unachievable with a single template as you suggest, hence why the jcttop/jctint/jctbtm family of templates and their state/country-specific variants exist. -- LJ ↗ 18:28, 9 October 2020 (UTC)[reply]

There are not many instances (in the US) where specific templates such as {{MIinttop}}, for instance, offer any more functionality than the general {{Jcttop}}. Kansas, for instance, had {{KSinttop}} for some reason (I redirected it to Jcttop earlier this year). What I'm trying to say is that we should be using the general Jcttop whenever possible. –Fredddie ™ 01:28, 10 October 2020 (UTC)[reply]

Extra space at top of RJL tables

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

This template seems to be adding extra whitespace above RJL tables that close with it, rather than with {{Jctbtm}}:

Sample 1 - {{Jctbtm}}

County	Location	mi	km	Destinations	Notes

1.000 mi = 1.609 km; 1.000 km = 0.621 mi

Sample 2 - {{LegendRJL}}

{{Jcttop}}
{{jctint}}
{{LegendRJL}}

~~Could someone with template / Lua coding skills look into fixing this? - Evad37 (talk) 04:30, 16 March 2013 (UTC)~~[reply]

Update: The problem seems to be a linebreak between the </noinclude> and the |- for the new table row. I've removed this in the template sandbox, which fixes the problem:

Sample 3 - {{LegendRJL/sandbox}}

{{Jcttop}}
{{jctint}}
{{LegendRJL/sandbox}}

Can an admin update the main template code to the sandbox code? - Evad37 (talk) 08:21, 16 March 2013 (UTC)[reply]

Done --Rs chen 7754 08:36, 16 March 2013 (UTC)[reply]

Problem with {{jctbtm}} template

The Legend RJL Table doesn't seen to fit together with another template: {{jctbtm}} It should try to be fixed soon. Thanks! QM400032 (talk) 10:52, 15 May 2013 (UTC)

Using both templates together is not intended. {{LegendRJL}} must be used if the RJL uses background colours. If the RJL does not, then {{jctbtm}} can be used instead. - Evad37 (talk) 11:27, 15 May 2013 (UTC)[reply]

Display only relevant color keys

Moved from Wikipedia talk:Manual of Style/Road junction lists

– Discussion only involves changes to this template and its lua module - Evad37 (talk) 08:16, 18 July 2013 (UTC)[reply]

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)[reply]

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)[reply]

As far as I know it would have to be done with parameters; I don't think there's any way to share data between different template instances. —Scott5114 ↗ [EXACT CHANGE ONLY] 01:56, 18 July 2013 (UTC)[reply]

That is correct. I could whip up a parameter-based one if needed. -happy 5214 06:08, 18 July 2013 (UTC)[reply]

Okay, but should the parameters turn the color keys on or off? (I'm assuming that the parameters will be something like |hov=on or |hov=off) - Evad37 (talk) 08:16, 18 July 2013 (UTC)[reply]

Or just |hov=. If it is to be implemented, then I suggest that a new template be created so that the old and new can co-exit. The current template is used in over 3000 articles.

I suggest, turn parameters on so that additional parameters can be added as time passes without disturbing existing articles.

May I suggest that the name of the new template is RJLlegend and that all new templates be prefixed "RJL", makingit easier to find them in a list. Martinvl (talk) 08:19, 18 July 2013 (UTC)[reply]

Actually, there was the idea of merging the functions of this template with {{jctbtm}} at the other name. The idea behind sticking with the jctbtm name is the connection to the existing {{jcttop}} template used to generate the top of the table. Over time, the uses of this template could be migrated to the other template, and this one would be deleted. Imzadi 1979 → 08:45, 18 July 2013 (UTC)[reply]

Sounds like a good idea – I'm sure the section above wasn't the first time someone has been confused regarding the two templates - Evad37 (talk) 08:54, 18 July 2013 (UTC)[reply]

I would agree with turning parameters on. Would there be a way to code it so that the default is all color keys displayed, but then specifying particular key(s) would only make those specific ones appear? This way, we cover bases of color usage in case someone forgets to add the parameters into the template--and has the benefit of not disturbing existing articles.

I also think merging the two templates would be a good idea. -- LJ ↗ 17:47, 19 July 2013 (UTC)[reply]

This could be done, but {{jctbtm}} is currently used for cases where no color key is displayed (i.e. tables that don't use colors), so if this were done, we'd have to do some sort of AWB run to add "displaykey=false" (or whatever) to the existing uses of jctbtm. Either way something is going to get disrupted if we merge the templates. —Scott5114 ↗ [EXACT CHANGE ONLY] 21:51, 19 July 2013 (UTC)[reply]

That being said, the best way to program it, in my opinion, would be to leave everything off by default, and turn them on one by one as needed, since the vast majority of roads will use only one or two colors. For consistency/discoverability, the template should use as parameter names the same keywords used by jctint (concur, incomplete, etc). —Scott5114 ↗ [EXACT CHANGE ONLY] 23:50, 19 July 2013 (UTC)[reply]

Template:NYintbtm could then be done away with. --Rs chen 7754 23:52, 19 July 2013 (UTC)[reply]

Another possible implementation would be to have a single parameter that takes a comma separated list of keys, ie |keys=concur,incomplete,closed, and then use Lua code (such as Module:String#find or similar) to search for partial string matches, and output the relevant keys for the legend. And use something like |keys=off or |keys=none to turn everything off, per the current {{Jctbtm}} usage. This may be simpler than typing |<keyword>=on for each one (or adding multiple parameters in VisualEditor), and avoids intefering with the unnamed parameters, as 1 is currently used to turn on extra columns if exit/old exit numbers are used. - Evad37 (talk) 09:19, 20 July 2013 (UTC)[reply]

In the hopes of restarting the discussion, here are the two main issues:

Should the default case (ie, no parameters entered) for a merged {{Jctbtm}} / {{LegendRJL}} template be show all color keys, or show no color keys?
What parameter style should be used – <parameter>=on, keys=<comma separated list>, or unnamed parameters?

I have also prepared a summary of each of the six options, see User:Evad37/Sandbox 7

Default case discussion

I think it makes more sense for everything to be turned off by default, and only turned on when required (with whatever parameter style is decided). This would mean conversion from LegendRJL to the proposed new Jctbtm would be slower and have to be done manually, but would result in more logical code in the new template. And there is WP:NODEADLINE - Evad37 (talk) 10:21, 26 July 2013 (UTC)[reply]

It should be possible to do both simultaneously, based on which template is called. -happy 5214 09:14, 28 July 2013 (UTC)[reply]

Not merging the templates during the upgrade is probably sensible, they can be proposed for merging afterwards - Evad37 (talk) 00:41, 30 July 2013 (UTC)[reply]

Parameter style discussion

I would be opposed to using unnamed parameters (as in {{Jctbtm|closed|incomplete}}), because this would conflict with the use of unnamed parameter 1, which is used to turn on extra columns if exit/old exit numbers are used. Either of the other options would be okay - separate parameters for each key is probably easier to code, a single parameter taking a comma separated list may be easier to use. - Evad37 (talk) 10:21, 26 July 2013 (UTC)[reply]

I've implemented all three at Module:Jctbtm. It appears to me that the comma-separated version is actually the easiest to code. -happy 5214 09:14, 28 July 2013 (UTC)[reply]

Thank you for making the module. If comma-separated list is actually the easiest to code, then I propose we go with that. Any endorsements, objections, or other ideas? (Pinging all users who contributed to the above discussion: @Ljthefro:, @Scott5114:, @Martinvl:, @Imzadi1979:, @Rschen7754:) - Evad37 (talk) 00:42, 30 July 2013 (UTC)[reply]

I like the idea of the comma-separated list. Full steam ahead? Imzadi 1979 → 00:57, 30 July 2013 (UTC)[reply]

Sounds good. --Rs chen 7754 00:58, 30 July 2013 (UTC)[reply]

Just a quick thought, but can we phase out "mplex" as a type coding by not implementing it here? Any AWB or other conversion in the articles should drop the type coding as well. Imzadi 1979 → 01:01, 30 July 2013 (UTC)[reply]

Seems reasonable, given that multiplex is just a roadgeek term. We probably also don't need to have "alloc" as an alias for "trans" (Route transition) - Evad37 (talk) 01:31, 30 July 2013 (UTC)[reply]

All sounds fine to me. -- LJ ↗ 06:40, 30 July 2013 (UTC)[reply]

Sure. —Scott5114 ↗ [EXACT CHANGE ONLY] 16:52, 30 July 2013 (UTC)[reply]

Breakage

M-120 (Michigan highway)#Major intersections should have its extra |key= present that would look like the one at M-82 (Michigan highway)#Major intersections. Can we get that fixed ASAP in {{jctbtm}}. Also, before we go any further, we should add a method to turn the conversion key back on in cases where it may still be needed. Imzadi 1979 → 20:46, 31 July 2013 (UTC)[reply]

I don't see why we couldn't have a key=all that displays the full key. —Scott5114 ↗ [EXACT CHANGE ONLY] 23:50, 31 July 2013 (UTC)[reply]

|key= sets up the custom key, like the one used on M-82 or M-120. Now, we have |keys= that is used for the various color keys (and because of the similarity, the newer parameter should have received a different name, say |legends=. Imzadi 1979 → 00:02, 1 August 2013 (UTC)[reply]

I take it the custom legend is simply appended to the end of the key? Are there any other known examples of something like this in use? As for M-82 and M-120, it may be better to use {{cref}} and {{cnote}} instead of placing this information in the table footer. —Scott5114 ↗ [EXACT CHANGE ONLY] 00:26, 1 August 2013 (UTC)[reply]

Interstate 70 in Colorado uses it as well. Functionality shouldn't be removed from a template though without either a) a replacement or b) a discussion to deprecate it. Imzadi 1979 → 01:03, 1 August 2013 (UTC)[reply]

My apologies. There was no intention of removing the |key= parameter. It was just buggy code. Specifically, |key= was not checked if nothing was passed to |keys=. It should be fixed now. -happy 5214 04:07, 1 August 2013 (UTC)[reply]

Any chance at getting rid of the extra space that appears on M-82 or M-120 when using |key=? I think we also need a way to force the conversion line since MOS:RJL still requires that if the table doesn't have two columns. Going forward, tables should be converted to have both mi and km columns, but until then, the key should still be available as an option. Imzadi 1979 → 04:50, 1 August 2013 (UTC)[reply]

Route transition needed in legend

Per the consensus at WT:RJL#"Route transition" Proposal, I have added Route transition (#dff9f9) to MOS:RJL. We now need to include it in this template – preferably not by specifying |country=AUS (as in the module sandbox), because this isn't limited to Australia (eg could be used for the named highways in Alaska). It might be better to just rewrite the template/module per the above section, and included the new colour in the rewrite. (Pinging @Scott5114: and @Happy5214:) - Evad37 (talk) 07:58, 25 July 2013 (UTC)[reply]

When you say "per the above section," what exactly do you mean? I don't see a clear consensus as to the parameter style. -happy 5214 09:18, 25 July 2013 (UTC)[reply]

I meant doing both changes at the same time, seeing as there does seem to be support for the general idea of a more flexible system for the legend (unless I'm reading too much into the comments made above), whatever the consensus for the parameters turns out to be. Thinking about it now, maybe it's not such a good idea, as it may take awhile to form consensus on the parameter style, and to complete a AWB run for all instances of {{jctbtm}}. In any case, I just think it would be silly to have to use |country=AUS on an Alaskan Highway article to force Route transition to show up in the legend, and coding it in for every instance of LegendRJL doesn't seem sensible either, given it will have limited usage – though HOV and Tolled/ETC were done that way, so there is a precedent. - Evad37 (talk) 10:03, 25 July 2013 (UTC)[reply]

This edit request to Module:LegendRJL has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please add the line

*<span style="border:1px solid #000; background-color:#dff9f9; color:#dff9f9;">&nbsp;&nbsp;&nbsp;&nbsp;</span>&nbsp; [[Route number|Route]] transition

to the standard legend in Module:LegendRJL. This will be a short term solution to allow the new route transition color to start to be used, anywhere in the world that it is applicable, per the recent update to MOS:RJL. Since the proposal at Wikipedia talk:RJL#"Route transition" Proposal gained consensus, adding the colour here is a natural consequence. (The longer term solution is to modify the templates/module so that only relevant color keys are shown, being discussed above) - Evad37 (talk) 01:04, 27 July 2013 (UTC)[reply]

Done --Rs chen 7754 01:08, 27 July 2013 (UTC)[reply]

Note

All discussion above this section occurred at Template talk:LegendRJL, prior to that template's deletion. It has been retained here following a suggestion at that TfD. --BDD (talk) 23:24, 27 August 2013 (UTC)[reply]

Correction needed urgently

I guess it is a case of oops, but the part "1.000 km = 0.621 mi" is seriously wrong. The real values are "1000 km = 621.4 mi". Please correct this ASAP. The Banner talk 19:15, 27 January 2014 (UTC)[reply]

How is it "seriously wrong"? --Rs chen 7754 19:18, 27 January 2014 (UTC)[reply]

Divide your stated conversion by a factor of 1,000 (one thousand, English uses the comma to separate thousands and the period as a decimal point) and then truncate the result to three decimal places, and you'd see that they are the same. Imzadi 1979 → 21:10, 27 January 2014 (UTC)[reply]

In that case I suggest to simplify the notation to "1 km = 0.621 mi". The Banner talk 23:08, 27 January 2014 (UTC)[reply]

No, because the two sides should have the same precision, and it should match the "1.000 mi = 1.609 km" reciprocal conversion which also uses three decimal places of precision on both sides of the equals sign.

Also, it should be noted that at some point, the default behavior of this template will be reversed. In the future, the default will not be to display the conversion key; rather |conv=on will be necessary to force it to appear. Imzadi 1979 → 02:04, 28 January 2014 (UTC)[reply]

And so the reader will be the loser. Sorry to hear that numbers are more important than our readers. The Banner talk 02:19, 28 January 2014 (UTC)[reply]

I don't see the issue. We have four numbers in the conversion key, all set to the same level of precision. Removing the trailing zeroes in an exact defined conversion like this isn't proper, nor would it read any better as "1 mi = 1.609 km; 1 km = 0.621 mi". Imzadi 1979 → 02:26, 28 January 2014 (UTC)[reply]

Perhaps it prevents mistakes with people who are not familiar to the American/English notation system. The Banner talk 02:57, 28 January 2014 (UTC)[reply]

Can you please explain how equalizing the precision for each unit causes any mistakes at all? I would think it does the opposite. T C N7JM 02:59, 28 January 2014 (UTC)[reply]

This is the English Wikipedia though. As far as I know, our MOS requires us to use a period as the decimal point and either a space or a comma as the thousands separator. We're also supposed to convert «» to quotation marks, for example. If I were reading an article on the French Wikipedia, I would expect to see commas and periods reversed and «» instead of quotation marks. If I weren't familiar with the notation and punctuation system there, I would be expected to become familiar with it, and the reverse holds true here. Imzadi 1979 → 03:05, 28 January 2014 (UTC)[reply]

So you don't care about the customers. Okay, clear. The Banner talk 03:13, 28 January 2014 (UTC)[reply]

No, I do, but we do expect a reasonable level of proficiency in dealing with the English language. Imzadi 1979 → 03:19, 28 January 2014 (UTC)[reply]

The MOS guideline Imzadi refers to is MOS:DECIMAL: "A decimal point is used between the integer and the fractional parts of a decimal; a comma is never used in this role" and "The number of decimal places should be consistent within a list or context ... except if the quantities were measured with different precisions." As this is a straight conversion, the precision is the same, and so the number of decimal places should be the same. - Evad37 [talk] 03:34, 28 January 2014 (UTC)[reply]

I am also of the opinion that the conversion should read "1 mi =1.609 km" (and similar for 1 km=...) rather than "1.000 mi = ...". The guideline "The number of decimal places should be consistent within a .. context" does not apply here because the numbers on each side of the equal sign are not the same context. The number of the left is exact, whereas the number on the right is an approximation, to an arbitrary degree of precision. We are not measuring something, whereby we want to indicate the degree of precision in both units (eg the distance from A to B is 1.000 mi or 1.609 km, both measurements implicitly ± .001), we are "defining" one mile (exactly) to be 1.609 km (approximately, ie ± .001). Ie the quantities are "measured" with different precisions - the one on the left of the equals sign is exact, the one on the right is not.

The values (of distances between junctions) in a highway article's junction list table should have the same number of decimal places, but the conversion key at the bottom (ie the contents of Jctbtm) should not. Mitch Ames (talk) 10:07, 8 June 2014 (UTC)[reply]

While "1.000 [unit] = " isn't exactly wrong, i.e. 1.000 mi is equivalent to 1.609 km, using the exact value "1" probably would be better given that it is a definition, not a measurement. - Evad37 [talk] 01:40, 10 June 2014 (UTC)[reply]

At this time, we can probably turn the conversion off by default unless specifically invoked with |conv=on. At the moment, |conv=off suppresses it, which if the table has a mile and a km column, it's superfluous. Imzadi 1979 → 01:42, 10 June 2014 (UTC)[reply]

Template-protected edit request on 7 January 2019

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

In the context of displaying the color key for Electronic toll collection, I propose spelling out the words "Electronic toll collection" rather than the current display of "ETC" . I don't think "ETC" is a common-knowledge abbreviation and there doesn't seem to be an issue regarding space. — C16SH (speak up) 19:09, 7 January 2019 (UTC)[reply]

Not done: According to the page's protection level you should be able to edit the documentation page yourself. If you seem to be unable to, please reopen the request with further details. – Jonesey95 (talk) 20:38, 7 January 2019 (UTC)[reply]

Reopened. I think User:C16sh was referring to the usage of "ETC" in the template itself (which is template-protected), not in the documentation. Space probably isn't an issue, but the abbreviation is linked to the article on the topic. -happy 5214 02:35, 8 January 2019 (UTC)[reply]

I went ahead and made the edit [1]. Seemed straight forward after Happy5214 mentioned it. –Fredddie ™ 02:44, 8 January 2019 (UTC)[reply]

Edit request on 21 Nov 2022

This edit request to Module:Road data/RJL types has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I would like to propose a few changes to the jctbtm parameters in Module:Road data/RJL types:

incomplete – remove link entirely (currently links to a nonexistent section in Interchange (road))
hov – change piped link to: [[High-occupancy vehicle lane|HOV only]]
toll – create piped link: [[Toll road|Tolled]]

–Dream out loud (talk) 11:39, 21 November 2022 (UTC)[reply]

I'd be in favor of removing all the links in the key.

That said, incomplete should be linked to the definition in that article through the use of an anchor, if we're linking things. Imzadi 1979 → 13:58, 21 November 2022 (UTC)[reply]

On a second thought, I implemented these two links because they make sense. I also added an anchor so that the link for incomplete access works again. Imzadi 1979 → 06:28, 23 November 2022 (UTC)[reply]

Template-protected edit request on 12 September 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I think future should have a separate color from unopened. Is this acceptable? 2601:C6:D281:6710:557D:E686:E006:25E (talk) 19:35, 12 September 2023 (UTC)[reply]

By definition, a future intersection/interchange is unopened. The distinction is slight by not meaningful because per MOS:RJL, only confirmed and in process intersections/interchanges should be listed. Additional. Imzadi 1979 → 20:32, 12 September 2023 (UTC)[reply]