Template talk:Jct/Archive/2017

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Road shield size

I have a question regarding the size of the route shields. Is there a way to change the size? I am asking because for certain shields such as the State road shields in Turkey, they appear unnecessarily large. Any help would be greatly appreciated! Central Data Bank (talk) 15:42, 25 July 2017 (UTC)

@Central Data Bank: Including the parameter |rdt=t will reduce the shield size about 20%; but I agree that there should be a |size= option. Useddenim (talk) 17:51, 25 July 2017 (UTC)
@Central Data Bank and Useddenim: the default size is customizable by country (happy5214 would know where to set a new default specifically for Turkey), but something to remember is that the heights were standardized to keep them similar to the height of adjacent text. That does mean they look rather large for Turkey because of the widths involved, but they need to be a bit large to be somewhat legible. |rdt= is only for use in rail diagram tables, and it shouldn't be used in road/highway articles. Imzadi 1979 → 20:58, 25 July 2017 (UTC)
@Imzadi1979: So does that mean that it can't be changed? Or should I ask happy5215 on how to change it? Central Data Bank (talk) 22:12, 25 July 2017 (UTC)
Anyone with the Templateeditor right and above can change it. Another thing we can do is double check the Turkish MUTCD equivalent and see if the files are sized appropriately. –Fredddie™ 23:03, 25 July 2017 (UTC)
@Central Data Bank: it can be changed. As I said, the size can be customized by country, and happy would know which Lua module or sub template has the coding where we'd set a specific size for Turkey. However, the height of the graphics, as displayed, is designed to complement the height of the adjacent text. Turkey just has very wide signs, in comparison, to those used in other jurisdictions. (The UK is similar, btw), so they do look rather large because of that width. I'd say that what you feel is a bug is really a feature so that the text on the graphics actually appears legibly. Imzadi 1979 → 01:24, 26 July 2017 (UTC)\
@Central Data Bank: is the size used for {{TUR-O}} better? That's x15px (a height of 15 pixels, compared to the 20-pixel default). -happy5214 02:09, 26 July 2017 (UTC)
Added that size to the sandbox. -happy5214 02:17, 26 July 2017 (UTC)
@Happy5214: the size of the Otoyols fit in just fine, due to the fact they are not as wide. But the D.XXX signs are quite wide that it makes the infobox look cluttered. The template size you mentioned might be too small when compared to other road signs on the template, so maybe a size in the middle?. Central Data Bank (talk) 11:21, 26 July 2017 (UTC)

Not working as described

According to the template documentation, {{Jct|state=VA|Sec|600|dab1=Lee County}} should produce a link to [[Virginia State Route 600 (Lee County)|SR 600]]. However, instead it links to [[Virginia State Route 600]], as in this example: SR 600 Can this be fixed? --R'n'B (call me Russ) 18:46, 29 November 2017 (UTC)

@R'n'B:, change the "dab1" parameter to "county1" as such: {{Jct|state=VA|Sec|600|county1=Lee}}. Mind you, it is a redirect to the correct article name. Charlotte Allison (Morriswa) (talk) 19:26, 29 November 2017 (UTC)
Both options should work now, though |county#= as Morriswa explained is the preferred method. –Fredddie™ 22:32, 29 November 2017 (UTC)
SR 600
SR 600
@Fredddie: Is this related to Module:Road data/strings/USA/VA? I haven't looked at how it occurs, but the recent edits at that module have pushed List of Virginia Byways from having an expensive parser function count of 476/500 to 554/500 with the result that the article is in the hidden Category:Pages with script errors. Is that due to Module:Road data/parser? Why does it need to check for the existence of over 500 pages? Johnuniq (talk) 00:00, 30 November 2017 (UTC)
Probably, no, definitely yes. It checks to see if articles exist and then creates the link if it does exist. It was originally a way to deter permastub articles. Though, maybe it's time to retire that logic. –Fredddie™ 00:25, 30 November 2017 (UTC)
I would strongly support retiring that logic. It leads to erroneous links; for example, if State Route 603 (Fairfax County) is a redlink, then the template creates a link to State Route 603 instead, which is an error. --R'n'B (call me Russ) 10:53, 30 November 2017 (UTC)

Appalachian Trail shield?

Moved from Template talk:Jct/doc/type/USA –Fredddie™

Would it make sense to add a type and shield for the Appalachian trail for its junctions with major routes? The Trail's page has a junction list showing the shields of all the roads it crosses, but there's no way to list it on the pages for those roads. --novanglusva 21:54, 15 December 2017 (UTC)

@Novanglusva:: The file that you have been adding File:ANST-Triangle-Logo 1.jpg requires a WP:FUR for each use, so we won't be able to use this file in Jct unless a FUR is added for each page. –Fredddie™ 21:08, 16 December 2017 (UTC)

CSS redo for banners

@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)
Yes:
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.

Changes

  • 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

Issues

  • 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)

Follow-ups

Wow. Incredible. moved my questions below –Fredddie™ 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?

@Imzadi1979:@Fredddie:

  • 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 Toll north

I-376 Toll 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 updates

This is in addition to the previous updates.

Changes

  • 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

Issues

  • 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 planning

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 discussions

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 discussion

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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Jct/Archive/2017&oldid=1129997144"