WikiProject Highways | (Rated Template-class) | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
|
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)
- Yes:
- @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)
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'sbanner
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 thebanner
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.
- If
- 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
, anddefault
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 thedefault
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 parametersTemplate parameterincity
andnearcity
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
- Template:Jct/sandbox
- Module:Jct/sandbox
- Module:Road data/parser/sandbox
- Module:Jct/city/sandbox
- Module:Jct/statename/sandbox
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
insize
shieldSpec
androuteText
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
whendefault
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?- Yes. We should probably add a this to Category:Jct template errors. It's not technically an error, but it serves as a tracking category. –Fredddie™ 01:02, 17 April 2016 (UTC)
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)
- 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)
- Would it work to define the to plates in the road data modules? –Fredddie™ 01:20, 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)
- 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)
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)
I should note some of the banners need to be corrected for toll roads.
- PA Turnpike 43 south / Penna Turnpike east - The Pennsylvania Turnpike and numbered toll roads operated by the Pennsylvania Turnpike Commission (like Pennsylvania Route 43) should use green banners.
- N.J. Turnpike north - The New Jersey Turnpike should use green banners as well.
- Palisades Parkway north - The Palisades Interstate Parkway should use brown banners.
- G.S. Parkway north - The Garden State Parkway uses light green banners with yellow letters and border (as seen here). We will need to make new NORTH, SOUTH, and TO banners.
- A.C. Expressway east / A.C.–Brigantine Connector north - The Atlantic City Expressway and Atlantic City–Brigantine Connector should use blue banners.
- New York Thruway north - The New York State Thruway should use blue banners.
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)
- Yes, tolled Interstates use blue banners for direction and TO while the toll banner is yellow. Dough4872 03:47, 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)
Also New York has parkways which use different shields but the same template:
- Saw Mill River Parkway north - Standard, should use green banner.
- Palisades Parkway north - Palisades Interstate Park Commission roads, should use brown banner.
- Garden State Parkway south - Garden State Parkway, should use special banners as I mentioned above (though we might be able to replace the usage of this with the New Jersey template).
- Grand Central Parkway east - Grand Central Parkway, should use white banner as it currently has.
- Northern State Parkway east - Long Island, should use white banner as it currently has.
I don't know what the best way to handle this would be. Dough4872 04:05, 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)
- Empty string
- 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)
- 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)
- 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)
- This is more or less what I was thinking of, so this is great. –Fredddie™ 05:02, 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 like22*(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)
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
anddirshield
(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)
- Turned off context banners for US 1926. PA 1926 should be handled in Module:Road data/strings/USA/PA using entries
- 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)
- 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)
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 inModule: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 hasNJ.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)
- Is it possible to reinstate separate categories like Category:Jct template transclusions with missing shields? (Why was this decommissioned in the first place?) Are subpages of a category allowed? Chinissai (talk) 22:07, 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)
- 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
- 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)
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)
Side discussions
Unrelated: @Rschen7754: do you think we can finally delete the Infobox road subtemplates? –Fredddie™ 03:59, 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)
Inheritance and overriding in road data modules
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.link = 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 = {}
NER.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 RI.US.name
, then any place that uses USA.US.name
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")
print(util.arrayToString(p))
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:
MI.I.link = {
["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"
AR.US.name = "U.S. Highway %route%"
AR.US.link = 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 = AR.US.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)
Shield height for |rdt=
Changes made to Module:Jct over the last four months have disrupted the |rdt=
function. Shields should be no taller than 17px (rather than the default height) so as to not break Route Diagram Templates. Would someone please fix this? Useddenim (talk) 00:40, 28 July 2022 (UTC)
- I am concerned about this change and think that it could be controversial, and also there is no draft copy in a sandbox, so I would suggest that this request be declined. --Rschen7754 06:35, 28 July 2022 (UTC)
- @Rschen7754: When the
{{{rdt}}}
option was added in 2014 the icon height was set to x17px; however, earlier this year Freddie unilaterally decided to impose WP:RJL standards onto Route Diagram Templates even though it disrupts the line spacing. And there is no draft copy in the sandbox because I don't code Lua. Useddenim (talk) 09:52, 28 July 2022 (UTC)
- @Rschen7754: When the
- To Useddenim: is there an example that can be studied that depicts the problem you want to be solved? P.I. Ellsworth , ed. put'r there 18:36, 28 July 2022 (UTC)
- @Paine Ellsworth: Take a look at the lines with the National Highways on Template:Railways around Delhi. Useddenim (talk) 18:41, 28 July 2022 (UTC)
- Not sure what is wrong. All four Jct templates have
|rdt=y
and all four shields are 17px in my Chrome browser. What am I missing? P.I. Ellsworth , ed. put'r there 18:56, 28 July 2022 (UTC)
- Not sure what is wrong. All four Jct templates have
- @Paine Ellsworth: Take a look at the lines with the National Highways on Template:Railways around Delhi. Useddenim (talk) 18:41, 28 July 2022 (UTC)
- @Paine Ellsworth: Well, I've looked at it in four different browsers on three different computers (in Chrome, Edge, Firefox, & Safari running under Windows, OS-X and iOS) and it's not displaying correctly. Useddenim (talk) 21:56, 28 July 2022 (UTC)
- @Useddenim: You have to explain to us what is not displaying correctly. Everything looks fine to the untrained eye. –Fredddie™ 23:23, 28 July 2022 (UTC)
- For the nth time, "tall" marker signs are not being shortened to x17px causing gaps to appear between rows of Route Diagrams (particularly noticeable between the two NH44 signs). Fredddie, this was already explained to you. Useddenim (talk) 00:22, 29 July 2022 (UTC)
- The module edits back to 23 July 2021 have been removed in the sandbox, after which they were compared in the {{Railways around Delhi}} template in preview. There are no discernible differences in the gaps, which makes me think that if the gaps are larger, made so by shields that are taller than 17px, then they have been that way for quite awhile – much longer than just the "last four months". Is it possible that you are just now noticing a difference? that the edits which changed the shield aspect ratio were done much longer ago? P.I. Ellsworth , ed. put'r there 09:12, 29 July 2022 (UTC)
- The {{Railways around Delhi/sandbox}} page has been created to use {{Jct/sandbox}}, which invokes Module:Jct/sandbox. Compare that with {{Railways around Delhi}}. There don't seem to be very noticable differences in gaps nor any differences in shield dimensions – 17px by 23px in both cases. P.I. Ellsworth , ed. put'r there 09:27, 29 July 2022 (UTC)
- That's because Module:Jct doesn't control the sizes of shields. Module:Road data does. I've reverted back to a July 2021 version of Module:Road data/sandbox and things work as Useddenim wants them to. I will have significantly more time in a couple weeks to work on this than I do right now. –Fredddie™ 14:19, 29 July 2022 (UTC)
- @Fredddie: Thank you; that's precisely what I wanted. (Was it really that difficult to make the change?) Useddenim (talk) 20:28, 29 July 2022 (UTC)
- Does this mean that the Road data sandbox can go live? or do you want to wait? In any case going to shut this one down for now, since you have a handle on it. And thank you very much! P.I. Ellsworth , ed. put'r there 16:49, 29 July 2022 (UTC)
- That's because Module:Jct doesn't control the sizes of shields. Module:Road data does. I've reverted back to a July 2021 version of Module:Road data/sandbox and things work as Useddenim wants them to. I will have significantly more time in a couple weeks to work on this than I do right now. –Fredddie™ 14:19, 29 July 2022 (UTC)
- @Useddenim: You have to explain to us what is not displaying correctly. Everything looks fine to the untrained eye. –Fredddie™ 23:23, 28 July 2022 (UTC)
- @Paine Ellsworth: Well, I've looked at it in four different browsers on three different computers (in Chrome, Edge, Firefox, & Safari running under Windows, OS-X and iOS) and it's not displaying correctly. Useddenim (talk) 21:56, 28 July 2022 (UTC)
Update
Use {{Jctrdt}}
going forward. I am going to remove rdt functionality from Jct soon, so switch over any and all instances of {{Jct}}
in RDTs. –Fredddie™
- So you expect me to update almost 1,000 RDTs because you're too lazy to code something properly? WRONG ANSWER. Useddenim (talk) 16:24, 30 July 2022 (UTC)
- Works well in the {{Railways around Delhi/sandbox}}. Even 1,000 pages wouldn't take too long with AWB? Thinking down the road, though, it might still be better to update the Jct template with what's been done to the Jctrdt template. Maybe {{Jct}} should invoke the better module, Jctrdt? P.I. Ellsworth , ed. put'r there 20:32, 30 July 2022 (UTC)
- Just working with templates using the Indian road signs, there are 123 templates to review. -- WOSlinker (talk) 20:43, 30 July 2022 (UTC)
- The problem is that you're basically trying to make one template that serves purpose A serve purpose B. It would be better to move these functions to a different template. --Rschen7754 21:10, 30 July 2022 (UTC)
- @Rschen7754: When the
|rdt=
parameter was added to {{Jct}} a fixed height of x17px was pretty-much accepted as the way to go. While editing the module earlier this year Fredddie made an undiscussed change to the height display, and was then unwilling to restore the function [1] [2][3][4]. Useddenim (talk) 22:09, 30 July 2022 (UTC)
- @Rschen7754: When the
I am done commenting on this so long as Useddenim keeps accusing me of bad faith. –Fredddie™ 20:58, 30 July 2022 (UTC)
- As someone who's been casually observing this conversation, I think {{jctrdt}} would work. If it's too hard to manually update {{jct}} to {{jctrdt}} in RDTs, then there's always the option of replacing them using AWB or sending in a bot request. – Epicgenius (talk) 21:16, 30 July 2022 (UTC)
- @Fredddie: You make WP:AGF difficult given your comment of 01:20, 29 July 2022. Useddenim (talk) 21:18, 30 July 2022 (UTC)
- Seems like more than just 2px as my software brings the shields in at width=17px, height=23px. Just sayin'. P.I. Ellsworth , ed. put'r there 22:38, 30 July 2022 (UTC)