Open main menu

Template talk:Jct

WikiProject Highways (Rated Template-class)
This template is within the scope of WikiProject Highways, a collaborative effort to improve the coverage of highways on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 Template  This template does not require a rating on the project's quality scale.
edit·history·watch·refresh Stock post message.svg To-do list for Template:Jct:

  • Regressions in Lua version
    1. Localized extra icons (airports, hospitals, etc.)
  • Future improvements
    1. Redo banner display mechanism using CSS
    2. Dual shields
  • Figure out what to do for routes with multiple banners
  • Other work
    1. Improve documentation
      • Jct
      • Parser
      • Hooks
      • Strings
    2. Ability to {{subst:jct}}
  • Pass |dir#= through to the parser in order to allow direction-specific shields
  • Parameter category tracking

CSS redo for bannersEdit

@Chinissai: is currently working on updating the banner code to use CSS styling. One thing missing in the current sandbox version is absolute left-right positioning. If we can add that, we can remove the blank image that currently provides left spacing. -happy5214 03:34, 15 April 2016 (UTC)

Looks good so far. Curiously, instances of Jct/sandbox are top-aligned as you can see Template:Jct/testcases/shield1. –Fredddie 03:58, 15 April 2016 (UTC)
@Chinissai: would this new technique allow us to stack multiple banners as needed, say for the Alternate Truck routes in Pennsylvania? Imzadi 1979  04:51, 15 April 2016 (UTC)
PA 23 Alt. Truck. Only two banners for now. Chinissai (talk) 07:13, 15 April 2016 (UTC)
Very cool. Thank you for this. We've needed something like this for a while, and it looks great from everything I've seen. I look forward to seeing this change deployed when it's ready. Imzadi 1979  03:51, 16 April 2016 (UTC)

──────────── No problem. I was getting fed up with asymmetry myself. I think changes are ready for deployment.


  • CSS is now used to place banner shield(s) above the main shield (no more line breaks). Banner shields are centered relative to the main shield, e.g.,  
    US 301 Truck. Rendering might appear to skew to the right. This is the browser's fault; the math is correct. (If you start zooming in, the shield should look more centered.) The CSS I am using is supposed to be standard, so the result should be consistent across operating systems, browsers, and skins.
  • Unlimited stacking of banners is now supported, e.g.,  
    PA 23 Alt. Truck. Multiple banners are specified bottom-to-top in road data's banner field as a Lua table, e.g., {"Truck plate.svg", "Alternate plate.svg"} for the example.
  • More than two shields per route is now supported, in addition to only two shields per route, e.g.,    SR 821. Various banner shields for each of the main shields are supposed to work, but untested. Given that road data's shield field is a Lua table, e.g., {"Toll Florida %route%.svg", "Florida %route%.svg"}, the syntax for banners is supposed to work as follows:
    • If banner is a string, then the banner is applied to each of the main shields.
    • If banner is a Lua table, each element of this table specifies banner shield(s) for the corresponding main shield. If this table has fewer elements than the table for main shields, then later main shields do not have banners. For each element of the banner table:
      • If it is a string, then a single banner is placed over the main shield.
      • If it is a Lua table, then each banner in the table is stacked over the main shield, like in the single-main-shield case.
In short, different banners for each main shield should be nested in a Lua table accordingly.
  • In Module:Road data/parser/sandbox, more robust handling of tables other than parser hooks and switch tables. Tables that do not contain hook, arg, and default fields are processed elementwise. This enables "more than two" things above. This change might affect other modules that I am not aware of, so more testing might be necessary. (Is there a way to figure out which modules use a given module?)
  • Fixed a spec mismatch in Module:Road data/parser/sandbox: Given a switch table containing ifexists, only the default is supposed to be check for existence. The previous implementation checks for existence of other switch values as well.
  • Name-to-route junctions, e.g.,  
    Buffalo Street to NY 79, are now supported. If the route type is left blank, the route "number" is used plaintext. This should help with interchanges that connect directly with an unnumbered route leading to a numbered route, and help eliminate some uses of {{roadlink}}. Even without a numbered route, this should still help with automatically wikilinking control cities, e.g., Ballard Road – Wilton, Corinth, Gansevoort.
  • The prefix before control cities can now include "in" and "near" be different from –, as in    I-90 / New York Thruway near – Syracuse. One of the new template flag parameters incity and nearcity Template parameter citiesprefix can be used as appropriate. This is useful for the major junction list in the infobox, but might result in overlinking, and I am not sure if using the template is actually shorter than hardcoding the location. At least, it prevents some potential typos from hardcoding.
  • Substitution is now supported, though not thoroughly tested. Example: {{subst:jct/sandbox|state=NY|NY|79}} gives   NY 79.
  • Various code refactoring.

Pages that need deployment


  • Some undeployed rdt changes remain in Module:Jct/sandbox. I have refactored these changes so that two places need corrections if not to be deployed (conditionals involving route.rdt in sizeshieldSpec and routeText functions).

  • The more stacking banner shields, the taller the line. However, the text will align with the rest of the line if used in a paragraph, and the text will remain in the middle of a table cell, where this template is supposed to be used most. Alternatives include
    • Shift the template output text up or down the current line, but this will make the text unaligned with the rest of the line if used in a paragraph.
    • Shift each route marker up or down the current line, but this will make route markers not lined up at the baseline.
Vertically shifting the entire line in which this template is used is probably not possible. (Imagine resizing your browser window, and imagine how much work your browser has to do to update the positioning of the new content of the line containing a use of this template.)

Future work (anyone can do)

  • Refactor remaining data, e.g., shield and banner sizes, out of Module:Jct/sandbox. The module should contain only the rendering logic. These sizes should be part of road data.
  • Better handling of ifexists when default is a value table.

Comments welcome. Chinissai (talk) 23:58, 16 April 2016 (UTC)


Wow. Incredible. moved my questions belowFredddie 00:09, 17 April 2016 (UTC)
Another quick question, would the stacked banners eventually allow us to use the appropriate "TO" plate? Years ago, we decided not to use them because of the complexities involved, which basically meant we had to resort to manually inserting those graphics. Imzadi 1979  00:27, 17 April 2016 (UTC)

This is seriously great, but I do have some questions: –Fredddie 00:33, 17 April 2016 (UTC)

  • Does this mean |road= can be retired eventually?
  • It looks like aliasing doesn't work. There are unknown type errors showing up in the Jct error category.
  • Missing shield errors. How will we know which shields are missing? |debug=yes?
  • Direction banners?


  • Small bug with aliasing. Fixed.
  • To and directional banner plates can be inserted, though this will have to be incorporated into the rendering logic itself, and not part of road data. If these banners are always at the top of other banner plates, then it will be done more easily. I imagine "to" plate at the top, above the directional plate, above other banner plate(s). Should I try this now? Do we have these plates readily available?
  • {{jct/sandbox|state=MA|I|90|MATP||dir2=west||Albany Street}} gives   I‑90 / Mass Pike west / Albany Street. So, yes, |road= can be deprecated.
  • Error reporting for missing shields: That will depend on where you would like to see the error. I think right now the module adds the article under "1" heading in Category:Jct template errors. I don't think using |debug=yes to enable more detailed error reporting will be globally helpful, because you will need to know which use of the template has the trouble in the first place before adding this parameter. Would it help to add a "3" heading in Category:Jct template errors that lists referenced missing shields? (Can redlinks be added to a category?) Then, "what links here" can be used. (Again, does it work with redlinks?)

Chinissai (talk) 01:09, 17 April 2016 (UTC)

I was thinking debug mode would add a red square or some other visual cue to tell us where the missing shield is. Go ahead and try the directional banners. –Fredddie 01:12, 17 April 2016 (UTC)
I just realized that the "to" plate will have to be customized based on the main shield, e.g., interstates use a different "to" plate. Same for directional banners. I will try not customizing these first and go from there. Chinissai (talk) 01:17, 17 April 2016 (UTC)
Would it work to define the to plates in the road data modules? –Fredddie 01:20, 17 April 2016 (UTC)
That will definitely work, though I don't think we should need to add this for every route type. Again, same for directional banners. I don't have a better idea yet. Chinissai (talk) 01:26, 17 April 2016 (UTC)
I would say define them for any that aren't black-on-white (Interstates, South Dakota state highway, etc.) –Fredddie 01:30, 17 April 2016 (UTC)
All of the banners use a similar nomenclature, so we could just define the variable. See commons:Commons:WikiProject U.S. Roads/Auxiliary plates. –Fredddie 01:47, 17 April 2016 (UTC)
We could probably just define a banner type and a color and have the client modules generate the banner from that. -happy5214 02:00, 17 April 2016 (UTC)
Maybe a designated base type with some form of inheritance within the parser and the modules? -happy5214 02:00, 17 April 2016 (UTC)

As the full-time maintainer of this family of templates, I feel owed the professional courtesy of inspecting the changes and giving the go-ahead before deploying this stuff. Remember, I'll be the one to fix any bugs, so I'd like to know the code I'm inheriting. -happy5214 02:00, 17 April 2016 (UTC)

Well aware. Chinissai (talk) 02:06, 17 April 2016 (UTC)

I should note some of the banners need to be corrected for toll roads.

There are others for sure that need to be checked. Dough4872 01:07, 18 April 2016 (UTC)

I should also note I-Toll is coming up with white banners instead of blue in different states  
I-95 north  
I-376 west. Dough4872 02:14, 18 April 2016 (UTC)
I wasn't sure from reading. Should these have blue banners instead of white? Chinissai (talk) 03:04, 18 April 2016 (UTC)
Yes, tolled Interstates use blue banners for direction and TO while the toll banner is yellow. Dough4872 03:47, 18 April 2016 (UTC)
Added I-Toll to Module:Road data/banners/USA. I don't think there are many I-Toll routes, but the type is generic enough that adding its entry in the main module is justified. Chinissai (talk) 03:59, 18 April 2016 (UTC)

Also New York has parkways which use different shields but the same template:

I don't know what the best way to handle this would be. Dough4872 04:05, 18 April 2016 (UTC)

I feel like all of these would be better declared from the state road data modules. –Fredddie 02:29, 18 April 2016 (UTC)
Unfortunately, these routes share too many common properties to define suffixes collectively. So, I had to add 16 entries in Module:Road data/strings/USA/NY, which is not too bad. Note that the GSP plates are coming up, so as of this writing, a missing-shield error is reported. Chinissai (talk) 04:56, 18 April 2016 (UTC)
This is more or less what I was thinking of, so this is great. –Fredddie 05:02, 18 April 2016 (UTC)
Along these lines, we should probably remove CR from Module:Road data/banners/USA. There are too many locations that don't use the pentagons that should prevent us from declaring all CR banners to be 'county' all the time. –Fredddie 05:06, 18 April 2016 (UTC)
If the pentagon shield is the biggest shareholder for CR route type (even if less than 50%), I would say keep this entry and override for others. Otherwise, the entry should be removed. We'll need to consult the statistics department, which I obviously am not in. Chinissai (talk) 05:22, 18 April 2016 (UTC)
Pentagon is the largest shareholder, followed by black-on-white squares. How would we override to the blank suffix option? –Fredddie 05:26, 18 April 2016 (UTC)
Empty string "" (documented below; it actually didn't work originally). It is easy to fall into a trap for "white". I already did when doing the NY Pkwy. Chinissai (talk) 05:30, 18 April 2016 (UTC)
There might be a better way to handle this. We probably could determine whether the CR shield is a pentagon shield. If so, use County; otherwise, use black-on-white (default). The remaining CR routes can be overridden. Chinissai (talk) 06:05, 18 April 2016 (UTC)
  • @Chinissai: would it be worth trying a 2px gap above the top banner, if that's possible? My thinking is that I won't notice that {{Jct}} is glued to the top border of a table cell with a small gap. –Fredddie 02:29, 18 April 2016 (UTC)

:Actually, I don't really know how much gap in px is above the top banner, as I was trying an arbitrary number that seems to result in what appears to you. This gap probably also varies across different skins. Would you like more or less gap (and how much)? As mentioned above, more gap will lead to taller line. Chinissai (talk) 03:04, 18 April 2016 (UTC)

Actually, you can try this yourself. In Module:Jct/sandbox, function render, look for a formula that looks like 22*(bannerCount-1) + 12. Change 12 to a different number (more means more gap) and try previewing Template:Jct/testcases or any page that uses Template:Jct/sandbox. Chinissai (talk) 03:44, 18 April 2016 (UTC)

Note that gap size may also vary between different OS / browser combinations, per Template_talk:Jct/Archive/2013#Bannered_routes - Evad37 [talk] 03:34, 18 April 2016 (UTC)
I found a better way to place these banners, so they now occupy exactly the amount of space they are supposed to. No more gap problems. Chinissai (talk) 16:47, 19 April 2016 (UTC)

In addition to the special banners for the Garden State Parkway, we are going to need special banners for the Harris County Toll Road Authority toll roads, such as the Hardy Toll Road. The banners are purple with yellow letters and border in the same color scheme as the shields (See here for a picture). Dough4872 02:43, 20 April 2016 (UTC)

Also I think we should create block font banners for the shields that use them (such as the 1926 US shields). I know we have File:Business plate old.svg but we should make a complete set for other bannered routes and directions. Dough4872 00:38, 22 April 2016 (UTC)
I'm leery of this simply because banners weren't a thing until the 1935 MUTCD. And even then, there were only Detour, Alternate, Bypass, Business, and Temporary banners – no directions. Then there's the issue of the banners being 20x8 inches while the shields were 16.5x16 inches. –Fredddie 00:51, 22 April 2016 (UTC)
Then we should only create the Alternate, Bypass, and Temporary banners in the block font. Also, how would we handle directional banners for those older routes, such as   
US 611 north / PA 73 west? Should we perhaps turn off directional banners for the old routes because displaying the current banner would not be right? Dough4872 00:59, 22 April 2016 (UTC)
Turned off context banners for US 1926. PA 1926 should be handled in Module:Road data/strings/USA/PA using entries toshield and dirshield (set to empty string). An alternative would be to detect "1926" in the route type and turn off context banners (might be expensive). Chinissai (talk) 01:42, 22 April 2016 (UTC)
When were directional banners first used? That way we can establish a cutoff and turn off banners for route types around before then. Dough4872 03:16, 22 April 2016 (UTC)

─────────────────────────We are also going to need banners for the Inner Loop (Rochester), they are orange with white letters and border (See here). Dough4872 01:34, 28 April 2016 (UTC)

Second-round updatesEdit

This is in addition to the previous updates.


  • Missing shield errors are reported in the HTML source code. These errors always begin with Module:Jct error: Missing route marker graphics:, so this can be used for searching in the source code. Example of error message: Module:Jct error: Missing route marker graphics: CR 25A jct (OH).svg. More detailed error message can be provided upon request.
  • Context banners, i.e., "to" plate and directional plates, are automatically stacked at the top of the shield if |to#= or |dir= is specified accordingly. (Is there an actual name for "context banners"?) Module:Road data/banners/USA defines these plates. Since certain route types use different banner appearances than black-on-white, entry .suffix in this module lists the different appearances. While this module handles most route types, it can never handle all possible route types that may have special appearances. As such, these values can be overridden in Module:Road data/strings/* as follows. As a guideline, add an entry in the above module if it can be applied to many route types; otherwise, override in individual modules when an entry applies to only one route type.
    • .to.shield: overridden by .toshield.
    • .to.shieldsize: overridden by .toshieldsize.
    • .dir.shield: overridden by .dirshield.
    • .dir.shieldsize: overridden by .dirshieldsize.
    • .suffix.shield: overridden by .bannersuffix. (If no suffix, specify the empty string.)
I have made some changes to individual modules for the examples above. Example:  
To Palisades Parkway north has NJ.PIP.bannersuffix defined in Module:Road data/strings/USA/NJ. This is the best form of overriding I can think of at the moment. Lua might permit better overriding via redefining certain keys in a table. My Lua knowledge is not there yet.
  • |to#= now has a different semantics. Each instance of the template permits at most one use of |to#=. All routes that follow this flag will have a "to" banner displayed. I don't think it makes a lot of sense to have an "immediate" route follow a "to" route in the junction list. For example, seeing    To NY 79 / NY 34, I would read that NY 34 is also a "to" route. The new semantics give  
    To NY 79 / NY 34. Duplicate uses of |to#= in a template instance will result in a category-3 error in Category:Jct template errors.
  • A new parser hook in Module:Road data/parser/hooks/sandbox: beginswith. If the given arguments begins with something in a list of patterns, then a corresponding result is returned. Used in Module:Road data/banners/USA.
  • Various code refactoring.

Pages that need deployment


  • A page can only appear once in Category:Jct template errors. So, multiple error categories cannot be displayed all at once. Perhaps detailed messages in HTML source code will help. Chinissai (talk) 03:37, 18 April 2016 (UTC)
  • Banner sizing does not work with |rdt= yet. I don't believe it worked in the old banner mechanism either. Chinissai (talk) 22:07, 18 April 2016 (UTC)

Future work (anyone can do)

  • Better handling of module aliases for these context banners. For example, if the alias changes the route type, then the initial route type should probably change too. Example test cases needed before changes should be made.
  • Automatically determine banner shields, given a route type. For example, one can infer from "US-Truck" and "PA-Truck" types that each of them should have a "Truck plate" banner. Then, the suffix table will determine the correct appearance. However, since the banners for most of these route types have already been hardcoded in individual modules, I feel that implementing this now will not give a lot of utility and will generate unnecessary work, where such route types that actually should not have a banner will have to be modified accordingly. Still, this can be on a to-do list if a major overhaul of these modules is in order in the future.

Comments welcome, as usual. Chinissai (talk) 03:04, 18 April 2016 (UTC)

Deployment planningEdit

This inspection will keep me busy for a while. I see a multi-staged approach to deployment, with as many independent steps inspected and deployed separately. I think the location-related code can be deployed on its own, but I'm not sure about the rest. Ideas? -happy5214 04:02, 22 April 2016 (UTC)

Not exactly sure what you meant by "location-related" code. One thing we could do is to release modules that are prerequisites of others first. There are Module:Road data/parser/hooks/sandbox and Module:Road data/parser/sandbox. The parser hooks should be easy for you to review. The parser itself is pretty much a major rewrite, so it might be more convenient not to compare with the live version. I can add comments to ease your reading. Question: Is the parser being used in some other module I am not aware of? In other words, what other templates than jct reference the parser? There is an off-chance that those modules could break; I just want to make sure.
Template:Jct/sandbox can also be deployed separately. The only change was to make substitutions available. That correctness doesn't depend on any module.
The remaining modules have mutual dependencies. Some data were moved from Module:Jct/city/sandbox to Module:Jct/sandbox (specifically, the en-dash preceding control cities). If you are okay with having no dashes displayed in the live version, then Module:Jct/city/sandbox can be deployed first along with Module:Jct/statename/sandbox. The data movements between the last two modules are so dependent that they must be deployed at the same time. Chinissai (talk) 04:30, 22 April 2016 (UTC)

I think the order of feature release for Module:Jct/sandbox should be something like this (judging from whether they are ready for the whole system):

  • Name-to-route junctions. [Functions involved: jct]
  • CSS for banners (and stacking). (I think the code is now stable, since I found a placement method that I know will work correctly.) [Functions involved: bannerSize, bannerSpec (without addContextBanner), shieldExists, render, shield]
  • Centralized error reporting. [Functions involved: _jct (bottom block), routeText]
  • Prefix before control cities. [Functions involved: _jct (middle if)]
  • Revised "to" semantics. [Functions involved: parseArgs]

I think context banners should wait, as discussions remain active. Chinissai (talk) 04:48, 22 April 2016 (UTC)

I'm starting to have second thoughts on the context banners. The sandboxes have proved that we can do it, and they are indeed pretty, but is it something we actually want to do? I think the end result will be a mad dash to make articles pretty instead of making them Featured Articles. –Fredddie 05:04, 22 April 2016 (UTC)
I think we should do them it gives the reader a visual aid about the direction of the route and what routes a junction leads to, rather than a mess of shields with no context. It's not really gonna be a "mad dash" to make articles pretty as once the switch takes place, the work is automatically done. We came this far to add them I don't think we should turn back. Dough4872 05:13, 22 April 2016 (UTC)
So what you're saying is junction lists need to be pretty. I don't want to take away from what Happy5214 and Chinissai have done, because they have done an amazing job maintaining and improving {{Jct}} and I would buy them each a beer or whatever in appreciation for their work. But, the context banners are getting out of hand before we even implement them. We apparently now need an entire set of banners for the Garden State Parkway and Harris County toll roads. Really? Where does it end? –Fredddie 05:55, 22 April 2016 (UTC)
From an implementor's point of view, I don't mind going either way. The logic for context banners takes only about 30 lines of code, though it required a bit of design and planning to make that so small. Even if we decide not to do this now, the code is there in the history we can fetch anytime in the future. One concern I have for context banners is the extra work generated for creating a main shield: If the main shield has a different appearance (colors mainly), then the shield comes with "baggage" that corresponding context banners need be created as well. I don't believe we should create a full set of banners given a new shield appearance (e.g., why do we ever need a west plate for GSP? Scenic GSP??). An alternative would be to turn off context banners for such "specialized" shields, but then we would see the inconsistency in the display. If we were to take this approach, though, I think we should have a full set of "To" plates, as I see they are visually more important for consistency than directional plates. In other words, supporting "To" as the only kind of context banners seems to require least extra work, i.e., the baggage of creating a specialized shield is one additional "To" shield, not more. Chinissai (talk) 11:39, 22 April 2016 (UTC)

─────────────────────────Here's my quick 2¢: in short, I'm in favor of deploying all of the banner plates, however, if we only deployed the to plates for now, that's fine. I do have a question of how international this is at the present, but I'm in favor of moving forward. Imzadi 1979  13:10, 22 April 2016 (UTC)

Right now, context banner spec is specified only for USA (Module:Road data/banners/USA), so they aren't showing up in routes in other countries. Chinissai (talk) 13:56, 22 April 2016 (UTC)
Regarding new banners, we only need to make a total of 8 new banners between the Garden State Parkway and the HCTRA roads: North, South, and To for GSP and North, South, East, West, and To for the HCTRA roads. That's not much work at all and I don't see why it's a problem to implement context banners for both directions and to when there's not much more work that needs to be done. Dough4872 16:26, 22 April 2016 (UTC)
What is the progress of the deployment of the CSS redo? Dough4872 01:17, 28 April 2016 (UTC)
It's been a month and this discussion has been quiet. Any updates? Dough4872 02:26, 31 May 2016 (UTC)

Side discussionsEdit

Unrelated: @Rschen7754: do you think we can finally delete the Infobox road subtemplates? –Fredddie 03:59, 15 April 2016 (UTC)

Which ones? --Rschen7754 04:39, 15 April 2016 (UTC)
Look at the testcases page I linked above and the other pages linked from there. All the blue links in the left column can probably go away. –Fredddie 04:45, 15 April 2016 (UTC)
  Done --Rschen7754 05:09, 15 April 2016 (UTC)

────────── Anything in Category:United States highway infobox templates that can also go away? Chinissai (talk) 23:58, 16 April 2016 (UTC)

Reviving this discussionEdit

It's been about a year since anything has been posted in this dicussion, so I'd like to revive it with the fact that I've made the banners for the Garden State Parkway (North, South, To) and the banners for the HCTRA roads (North, South, East, West, To). I'd also like to propose a major change to the Texas subpage of the road data module. Right now, the "toll" type in the page includes both normal toll roads and toll roads maintained by the HCTRA. I would like to move the HCTRA roads to a seperate type so a different banner suffix can be used for those roads. Also, what's the progress of the deployment of the CSS redo? PhilrocMy contribs 18:58, 17 April 2017 (UTC)

It's not a good idea to deploy new code without having someone with the knowledge to maintain it. Chinissai wrote virtually all of the sandbox code, but it seems he has not worked on it this year. Generally, I handle Lua maintenance for HWY and USRD, but I have not had the time to learn the new code and would be of no help if it were to break. Of the remaining USRD members, only User:Scott5114 really has experience writing Lua modules, and he is not particularly active anymore. I have finals the first week of May, and if my other priorities are under control after that, I will sit down and digest the new code. Until then, I oppose any attempt to push this code into production. -happy5214 22:25, 17 April 2017 (UTC)
I would like us to get back to deploying the code to implement context banners, but we need to make sure we have someone who knows how to do it properly. Unfortunately I am not the person who could do that as I have no experience with writing Lua codes. If Chinissai or happy5214 or someone else good with the codes could get around to it someday then we will implement the context banners, but right now it seems there is no firm schedule as to when it will happen. Remember WP:DEADLINE. Dough487210th 23:42, 17 April 2017 (UTC)

Inheritance and overriding in road data modulesEdit

There are no existing module talk pages to host this discussion, so I am posting it here. Feel free to move this to a new, appropriate talk page.

I am trying out inheritance for road data modules. This means entries to be shared across multiple modules should be defined in one place. Inheriting modules have an opportunity to override values as appropriate. The rest of this post gives a tutorial of how this is done.

I have updated Module:Road data/strings/USA to act as a shared module. There is not much difference from a previous version except for additional entries that can be shared in state modules. Modules to be inherited like this one won't look that interesting.

The interesting part comes in the inheriting modules. I have updated Module:Road data/strings/USA/RI to use this pattern. I chose this module because it is small yet large enough to illustrate features. The updated module is backward compatible, except for the missing "width" key that will not be needed for the new banner display mechanism. The implication is that banner placement will be a little off in the old display mechanism; otherwise, no harm done.

The first difference is the declaration of the table to be returned. Formerly, we started with the empty table:

local RI = {}

Instead, we import the inherited module:

local RI = require("Module:Road data/strings/USA")

Having done this, all entries defined in the inherited module become available immediately. We need only override entries that differ from the inherited module. For example, the link for an interstate in Rhode Island should point to the state-specific article instead of the national article. Formerly, we had to define the whole entry:

RI.I = {shield = "I-%route%.svg",
        link = "Interstate %route% (Rhode Island)",
        abbr = "I‑%route%"}

Instead, we can simply override the link field: = RI.I.base .. " (Rhode Island)" -- Use the inherited RI.I.base.

Note that we cannot write RI.I = {link = ...}, or we would be overriding the entire I table and not inheriting entries therein. Of course, if the entire table is not to be inherited, this method is appropriate.

Certain route types are shared regionally and should not be defined in the main inherited module. Still, we can "mixin" these route types. For example, New England routes are to be shared among New England states, and not others. First, we create a separate module Module:Road data/strings/USA/regional/NER that looks like one to be inherited:

-- New England
local NER = {}

	shield = "New England %route%.svg",
	name = "New England Route %route%",
	link = "Route %route% (New England)",
	abbr = "Route %route%"

return NER

Then, to mixin route types defined in such modules, we simply append the existing entries:

local util = require("Module:Road data/util")
-- Add entries in second table to first.  require here returns NER table above.
util.addAll(RI, require("Module:Road data/strings/USA/regional/NER"))

(Note that this is currently disabled in the actual module, because USA defines NER. This can be resolved after we figure out what to do within New England Interstate Route 26, perhaps by changing {{jct|country=USA|NER}} to {{jct|state=XX|NER}}.)

An obvious advantage of this approach is that we write less. The Rhode Island module is about 400 bytes (33%) less. Another advantage is that changes in the shared module propagate automatically to inheriting modules, unless they override the fields that change.

This approach comes with an issue. Unwanted route types might show up in the inheriting module. For instance, a state might not have US-Spur, but this type will be available because USA defines it. I don't believe this is undesirable. Truly unwanted route types should be defined in a mixin module, so we have a way around this.

Another issue is that overridden fields are not propagated to the inherited entries that use those fields. For example, if the inheriting module overrides, then any place that uses will remain as is unless overridden. I think redundant overriding is the only option, but it does not seem too much a burden in the modules I have converted so far.

Also, it is now more obscure of what are defined, and what their actual values are. To help with this, I created a few scripts to dump the content of a table. To inspect the value of a road data module, use Special:ExpandTemplates with the following input text:

{{#invoke:Road data/dump|dump|module=Module:Road data/strings/USA/RI}}

Replace |module= with the module in question.

When editing a road data module, simply paste the following script into the debug console:

local util = require("Module:Road data/util")

I have most of the US-state modules ready to go (without width fields), but I don't want to pollute Wikipedia with them yet. Let me know if you are interested to see the new modules for other states.

Thoughts welcome. Chinissai (talk) 15:23, 30 April 2016 (UTC)

I don't know if I like this. It seems to me that this unnecessarily complicates the road data modules, which I suppose is the exact opposite of your intentions. I know some states' modules have been edited such that an Interstate or U.S. Highway will never link to a redirect, so those states will never use this setup. And if I understand it right (I might not) states like Arkansas that use suffixes instead of banners wouldn't be able to use this? –Fredddie 22:05, 30 April 2016 (UTC)
I can say with confidence that modules will be more compact with inheritance, as you need not redefine the same thing over and over again. It is easier to maintain. To address your concern, let's look at the override for Michigan interstates: = {
	["96"] = "Interstate 96",
	["196"] = "Interstate 196",
	["296"] = "Interstate 296",
	["496"] = "Interstate 496",
	["696"] = "Interstate 696",
	["94N"] = "Interstate 94N",
	default = {
		hook = "split",
		split = 100,
		above = MI.I.base .. " (Michigan)",
		below = MI.I.base .. " in Michigan"

It looks pretty much the same as before, but you don't need to redefine abbreviation and shield, which are already defined in USA.

For Arkansas, the entire US-Bus type is redefined like you mentioned, so we can simply fall back to the current method:

local suffix = " ([dab||%dab%, |]Arkansas)"

-- override some entries for inherited AR.US
AR.US.shield = "US %route% (AR).svg" = "U.S. Highway %route%" = AR.US.base .. " [dab||(%dab%, Arkansas)|in Arkansas]"

-- override US-Bus entirely and forget what's inherited
AR["US-Bus"] = {
	shield = "US %route%B.svg",
	name = .. "B",
	link = AR.US.base .. "B" .. suffix,
	abbr = AR.US.abbr .. "B"

Still, inheritance takes advantage of AR.US.base and AR.US.abbr, which are already defined in USA.

One thing to keep in mind is that a child module can always elect not to inherit at all, which simply results in what we have now. The best use comes with overriding, like with MI interstate links above. Chinissai (talk) 01:06, 1 May 2016 (UTC)

Return to "Jct" page.