Template talk:Infobox road/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

Two parameters for NZL

I'll toss the initial request here, and I might actually write the coding for an edit request. Over at WT:NZ, there is a discussion about the potential switch to IR, but they'll want two parameters added. The first is a location type for "Primary destinations". The second is for "tourist routes". The latter should go with the Route information section and the former in the locations. Imzadi 1979 → 22:23, 4 July 2010 (UTC)

{{editprotected}} Please add the following two items to the template in the appropriate locations. (The first goes on a new line after |data 17 = and the second after |data69 =. These two additions will enable two parameters per the discussion at WT:NZ#Highway infoboxes. Additionally, two subtemplates will need protection per WP:HRT: {{Infobox road/hide/tourist}} and {{Infobox road/hide/destinations}}. These two subtemplates control which countries' articles can display the output of the two parameters, just like the other location types. Imzadi 1979 → 23:02, 4 July 2010 (UTC)

|label18= Tourist<br>routes:
|data18 = {{#if:{{{tourist|}}}|{{#ifeq:{{Infobox road/hide/tourist|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{tourist|}}}|}}|}}

and

|label70 = {{#ifeq:{{{country|}}}|UK|[[Primary status|Primary<br>destinations]]:|Primary<br>destinations:}}
|data70  = {{#if:{{{destinations|}}}|{{#ifeq:{{Infobox road/hide/destinations|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{destinations|}}}|}}|}}

All done. --Rschen7754 06:24, 5 July 2010 (UTC)

The New Zealand conversions have been using the map parameter to show an image (see Auckland Northern Motorway for an example). Would it be better to add photo & photo_notes parameters to use instead for photos? -- 21:03, 5 July 2010 (UTC)

I'm of the opinion that photos shouldn't be placed within the infobox. – TMF 21:08, 5 July 2010 (UTC)

I second that. Yes, people have used photos instead of maps, but I don't want to encourage it. Imzadi 1979 → 21:12, 5 July 2010 (UTC)

Destinations

Can MYS be added to {{Infobox road/hide/destinations}}. Thanks -- WOSlinker (talk) 22:29, 9 July 2010 (UTC)

 Done by TMF. Imzadi 1979 → 22:45, 9 July 2010 (UTC)

Australian State Codes

Moving from my talk page: Imzadi 1979 → 00:04, 10 July 2010 (UTC)

Does it really matter if both USA & AUS both have state WA in Infobox road, as when using the Australian version, the country will always be set to AUS. I set up the state codes with the commonly used postal code abbreviations, see Postcodes in Australia#Allocation. -- WOSlinker (talk) 22:48, 9 July 2010 (UTC)

Yes, it does. TMF said on IRC just now that it would cause problems with the way things work. state and country are really designed to be mutually exclusive. Imzadi 1979 → 22:54, 9 July 2010 (UTC)

Do the two places that WA refers to (Christmas Island and some other island group) have notable roads? If not, we could ignore the WA in Australia and not have an issue. --Rschen7754 23:48, 9 July 2010 (UTC)

List of highways in Western Australia Imzadi 1979 → 23:55, 9 July 2010 (UTC)

Never mind, I missed the list at the top :| --Rschen7754 23:58, 9 July 2010 (UTC)

All that needs changing is {{Infobox road/meta/mask/country}} from

{{#switch:{{{1|}}}
|CA|TX|NY|FL|IL|PA|OH|MI|GA|NC|NJ|VA|WA|AL|AK|AZ|AR|CO|CT|DE|HI|ID|IN|IA|KS|KY|LA|ME|MD|MA|MN|MS|MO|MT|NE|NV|NH|NM|ND|OK|OR|RI|SC|SD|TN|UT|VT|WV|WI|WY|DC|AS|GU|MP|PR|UM|VI=USA
|AB|BC|MB|NB|NL|NS|NT|NU|ON|PE|QC|SK|YT=CAN
|AGU|BCN|BCS|CAM|CHP|CHH|COA|COL|DIF|DUR|GUA|GRO|HID|JAL|MEX|MIC|MOR|NAY|NLE|OAX|PUE|QUE|ROO|SLP|SIN|SON|TAB|TAM|TLA|VER|YUC|ZAC=MEX
|#default={{uc:{{{2}}}}}
}}

to

{{#if:{{{2|}}}|{{uc:{{{2}}}}}|{{#switch:{{{1|}}}
|CA|TX|NY|FL|IL|PA|OH|MI|GA|NC|NJ|VA|WA|AL|AK|AZ|AR|CO|CT|DE|HI|ID|IN|IA|KS|KY|LA|ME|MD|MA|MN|MS|MO|MT|NE|NV|NH|NM|ND|OK|OR|RI|SC|SD|TN|UT|VT|WV|WI|WY|DC|AS|GU|MP|PR|UM|VI=USA
|AB|BC|MB|NB|NL|NS|NT|NU|ON|PE|QC|SK|YT=CAN
|AGU|BCN|BCS|CAM|CHP|CHH|COA|COL|DIF|DUR|GUA|GRO|HID|JAL|MEX|MIC|MOR|NAY|NLE|OAX|PUE|QUE|ROO|SLP|SIN|SON|TAB|TAM|TLA|VER|YUC|ZAC=MEX
|#default={{uc:{{{2}}}}}
}}}}

WOSlinker (talk) 00:00, 10 July 2010 (UTC)

From what I can tell, this code won't make an ounce of difference for this situation. If {{{2}}} - the country - is specified, it's still going to ignore whatever's passed into {{{1}}} - the state or province. – TMF 02:02, 10 July 2010 (UTC)

Would it not then select the correct country if |country=AUS |state=WA was set and we could then use state=WA in {{Infobox road/browselinks/AUS}} to show the appopriate browse info? -- WOSlinker (talk) 02:19, 10 July 2010 (UTC)

If it were set up that way, |country=USA would need to be set on every US article. Imzadi 1979 → 02:21, 10 July 2010 (UTC)

(ec) @ WOSlinker: From that approach, it seems like it would work. If this is used, the last line of the switch becomes pretty redundant, though.

@ Imzadi: As far as I can tell, it wouldn't require that country be used for any US, Mexican, or Canadian state or province except for maybe WA, but since WA is still in the switch above, even they wouldn't need it...for now. – TMF 02:28, 10 July 2010 (UTC)

No it wouldn't because if country was blank, it would still use the switch statement on the state value. -- WOSlinker (talk) 02:27, 10 July 2010 (UTC)

no country set
Location
Country	United States
State	Washington
Highway system
State highways in Washington Interstate US State Scenic Pre-1964 1964 renumbering Former

country set to AUS
Location
Country	Australia
State	Western Australia
Highway system
Highways in Australia National Highway Freeways in Australia Highways in Western Australia

Could you make the change and see if it makes a different to the two infoboxes? -- WOSlinker (talk) 02:26, 10 July 2010 (UTC)

Just did. Also replaced the last line of the switch with an error tracker. – TMF 02:35, 10 July 2010 (UTC)

Here's an example of live & sandbox versions:

setting	live	sandbox
country not set, state=WA	USA	USA
country=AUS, state=WA	AUS	AUS
country=USA, state=WA	USA	USA

See. -- WOSlinker (talk) 02:33, 10 July 2010 (UTC)

Question about "maint" parameter

With the infobox road overhaul, the former "maint=" parameter is now automatically filled in if certain parameters are present. One can also manually enter another entity should the default value be incorrect. But is there a way to prevent the parameter from being displayed? Nevada State Route 8A was a state highway decommissioned in the 1970s; as far as I can tell, the unimproved part of the route in northwest Nevada isn't maintained by NDOT or any local entity...thus the "Maintained by" line probably shouldn't appear in the infobox. So is there a way to prevent this from showing? -- LJ ↗ 08:33, 9 July 2010 (UTC)

At the moment, no. A shutoff (like "maint=none" or such) could easily be added, though. – TMF 08:53, 9 July 2010 (UTC)

Added as described. "maint=none" will shut off the maintenance line for countries that have a /maint template (currently only the US); for other countries, the maint param still won't display unless maint is manually specified. – TMF 09:05, 9 July 2010 (UTC)

Wow, that was fast! Thanks. -- LJ ↗ 09:42, 9 July 2010 (UTC)

Massachusetts

I just changed the default for MA to the generic "Commonwealth of Massachusetts" because recent legal changes have changed the specific agency which maintains some state roads. It's not at all safe to assume that it's MassDOT, as some roads belong to DCR and MassPort, and some roads are still in flux. I'm requesting that individual roads be checked against a referenced source before specifying an agency. Is there some easy way to get a list of all MA roads that use this template? I don't see any obvious categories that roads using this infobox get sorted into by state. -- Beland (talk) 18:33, 10 July 2010 (UTC)

All highway articles in MA should be using the infobox. Additionally, if the default is not correct, just set |maint= to something else, and it will override the default on that article alone. Imzadi 1979 → 18:45, 10 July 2010 (UTC)

Removed MA from the maint template. I'd imagine most roads are owned by one agency, but if there's going to be a stink about this, there may as well not be any default. – TMF 22:12, 10 July 2010 (UTC)

browse country templates

Just wondering about the Infobox road/browse/countrycode set of templates. Are they really needed, since all the ones that currently exist just seem to contain a html table wrapper around {{Infobox road/meta/browse}}. What I mean is that there doesn't seem to be any need for a country specific version of this and that the table wrapper could be added to Infobox road/meta/browse and it could be called directly. -- WOSlinker (talk) 08:41, 10 July 2010 (UTC)

Doing so would mess up the extra browse rows (entered in by "browse="). The meta/browse is what generates the rows; the browse/<country> is what presents them. – TMF 14:43, 10 July 2010 (UTC)

I should add that I'm not saying the code can't be cleaned up a bit with some changes; I'm just saying the suggested change isn't one of them. – TMF 22:13, 10 July 2010 (UTC)

Couldn't the browse param also be moved into Infobox road/meta/browse and then called directly rather than via Infobox road/browse/countrycode? -- WOSlinker (talk) 23:31, 10 July 2010 (UTC)

If the browse parameter was moved into meta/browse, meta/browse would be calling itself through the use of the extra browse row templates. Like I said above, there is a way to streamline the code - I thought of one such way today - but it doesn't involve changing meta/browse at all. – TMF 03:40, 11 July 2010 (UTC)

And this was said way. With this change, both the IBR/browse/<country> series of templates and IBR/country are no longer needed. – TMF 05:15, 11 July 2010 (UTC)

That's great. IBR/country is still used in Template:Infobox road/meta/spur of though. -- WOSlinker (talk) 08:57, 11 July 2010 (UTC)

Browse question

Do you always need to specify both previous_route and next_route when using the browse functionality or could the templates be improved so that it would work if only one of previous_route or next_route was specified? -- WOSlinker (talk) 21:47, 15 July 2010 (UTC)

You always need to specify both - I'm not sure of a scenario when only one would be specified. (You loop around at the ends). --Rschen7754 22:38, 15 July 2010 (UTC)

The only time that I could see not having the previous_route is a Highway 1, but in that case Highway 9999 (or whatever the highest number in the series) is used, so the chain loops around. Imzadi 1979 → 23:44, 15 July 2010 (UTC)

One other thing I was wondering about is wether the previous_type and next_type parameters should default to the type value if they are not set, so that browsing could be setup by just setting the previous_route and next_route values. -- 12:05, 16 July 2010 (UTC)

That was set up previously, and in the revamps was removed. Any time a *_route value is specified, the *_type value is required. Previously the main type would default to the state's value, but that was removed as well. Imzadi 1979 → 17:14, 16 July 2010 (UTC)

I'm personally not in favor of restoring that "feature". I can think of a very plausible scenario where an editor just provides the prev_route and thinks everything is OK...except that the previous route is an Interstate or U.S. Highway. Sure, the wrong type would likely generate redlinks for the link and the shield, but if anything's been proven over the years, it's that a lot of editors are oblivious to the fact that redlinks usually mean they messed something up. – TMF 17:19, 16 July 2010 (UTC)

Or in the case of a state like Michigan, where we do duplicate numbers between the three systems, forgets the the type and gets M-94 instead of I-94, skipping the I-94 entry in the browser order. There wouldn't be a redlink to alert of an error in states that don't have a prohibition on duplicate numbers. Imzadi 1979 → 17:34, 16 July 2010 (UTC)

Image parameter

Per discussion at Template talk:Indian expressways, I'd like to propose the addition of a parameter for adding images. The way I'd like to have it implemented is that the image would require a caption for the map, if present, and for the image, but not require it for the map if the image is not present (as it is currently). It could be coded as such: —Fredddie™ 22:50, 16 July 2010 (UTC)

|image={{#ifeq:{{{map_custom|}}}|yes|<span style="white-space:nowrap;">{{{map|}}}</span>|{{#if:{{{map|}}}|[[File:{{{map}}}|290x172px|alt={{{map_alt|}}}]]|}}}}
|caption={{#if:{{{image|}}}|{{#if:{{{map|}}}{{{map_custom|}}}|{{{map_notes}}}|}}|{{{map_notes|}}}}}
|image2={{#ifeq:{{{image_custom|}}}|yes|<span style="white-space:nowrap;">{{{image|}}}</span>|{{#if:{{{image|}}}|[[File:{{{image}}}|290x172px|alt={{{image_alt|}}}]]|}}}}
|caption2={{#if:{{{image|}}}|{{{caption}}}|}}

As I've stated before, I think having pictures in the infobox is a horrible idea. Other infoboxes, like those for buildings and bridges, have photos because that's the best way to visually show that object. For a linear object like a road, a map is that best way, and as such the map param functionally replaces a photo param in the infobox. That said, I really don't see the point of having a photo param in addition to a map parameter. The argument I've heard in favor of it is that it provides a "lead" image for the article. In all likelihood, an image would make the infobox so big that it wouldn't be the first image people see, defeating its purpose. The extra space the param and the subsequently expanded infobox would use is better utilized by adding the image right to an appropriate spot in the article.

I understand we're trying to consolidate all of the road infoboxes in the world into one, but I don't think we should absorb horrible practices to meet that end. – TMF 03:01, 17 July 2010 (UTC)

I have to agree. Just because {{infobox}} supports two images, doesn't mean we should. The times where a second image would be handy, IMHO, are the infoboxes have have the university's academic logo and the athletics logo/mascot both shown. Or a government agency's seal and logo when the agency has both. Maybe a country's flag and a map. We already have two graphics, the highway marker and the map, or photo for those that use the map parameter that way. The best representation of a linear object is a map, not a photo that shows only one point or perspective of the road. If you look at Ontario Highway 401 in this revision, that infobox is just too long. Essentially it doesn't matter what order the elements in the box appear, they'd still produce an infobox of that length. The box even follows USRD's project convention to use a maximum of 10 junctions.

To sum it up, I understand the desire to add the parameter as "leverage" in the potential mergers, but honestly, the goal is not to just write and design highway articles, but the best highway articles possible. Trying to cram the infobox full of everything and the kitchen sink does not do that. Imzadi 1979 → 03:23, 17 July 2010 (UTC)

Well how about at least adding an image parameter that only works when the map parameter is not in use as that would be better than people putting photos in the map parameter. -- WOSlinker (talk) 08:19, 17 July 2010 (UTC)

I'll let others comment, but I'll restate my opinion again, the best graphic that summarizes the entirety of a roadway, excluding the marker sign, is a map. As linear features, only a map can demonstrate the whole roadway, while a photo would be of a single location. Photos are fine for bridges, buildings or even city skylines as a photo can capture the whole subject. Only the most extremely short roadway could be completely captured in a photo. If others feel the need for photo parameters, make them alternate names to the map/map_notes/map_alt/map_custom parameters. Imzadi 1979 → 09:08, 17 July 2010 (UTC)

Anyone can currently put two images into the infobox by using map_custom=yes and then adding two images into the map parameter. I've had to use the map_custom option myself (although not for adding two images) as the default map size is sometimes too small for certain maps. If there was a map_size parameter, then there would be less need for a map_custom option though. -- WOSlinker (talk) 09:47, 17 July 2010 (UTC)

There are some Albertan usages of the template that use map_custom because the map is a template, not a simple graphics file. Imzadi 1979 → 21:51, 17 July 2010 (UTC)

I would caution against a map_size parameter just because of the potential for abuse, as in 1000px wide maps. —Fredddie™ 22:39, 17 July 2010 (UTC)

If we decide to change the map's size, I would suggest handling it in the same way that we handle the size of the shields in the browse row: via a template that sets specific sizes for each country or region. For U.S. roads, the preferred size is 290x172px; however, other countries may want another size. I definitely wouldn't support allowing the size to be controlled by a parameter. – TMF 23:10, 17 July 2010 (UTC)

German Infoboxes

With the German infoboxes ({{Infobox Bundesautobahn}} and {{Infobox Bundesstrasse}}), they include Federal States. Just wondering if an existing parameter such as regions could be used or if there is a need for another location parameter called states? WOSlinker (talk) 22:24, 13 July 2010 (UTC)

There is a parameter in development called |states= that will be set to work for the US, Indian and Germany. The trick is the coding to allow it to work for |country=USA but not simultaneously for articles that are specific to one state. (It would be redundant to display a state name for a single state, when the article is on a state highway specific to that state. Such potential redundancies have been abused in the past by editors, which is why the different location types are whitelisted for certain countries.) Imzadi 1979 → 22:33, 13 July 2010 (UTC)

There is one other issue with the German road articles, which is that some of the junction lists are huge. For exmaple Bundesstraße 3. One option for that could be to use {{Collapsible list}} to house the junction list. see User:WOSlinker/Sandbox4 for an example. -- WOSlinker (talk) 22:50, 13 July 2010 (UTC)

The problem with that though is that it encourages leaving the junction list in the infobox alone. That might be the practice on dewp, from which the templates were translated, but on ewp, MOS:RJL is set up to provide a basic format for road junction lists. The infobox should only be a summary of what's in the article, and not a source of unique content. Imzadi 1979 → 22:53, 13 July 2010 (UTC)

Moving it to a juction section in the article instead of being in the infobox is also an option for the longer lists. -- WOSlinker (talk) 22:58, 13 July 2010 (UTC)

Regardless of what happens, it definitely needs fixing. I checked out Bundesstraße 3 on Lynx and the junction list section was a trainwreck. —Fredddie™ 01:45, 14 July 2010 (UTC)

Is the states parameter ready yet? -- 193.122.158.250 (talk) 13:09, 22 July 2010 (UTC)

It has been for a bit, it was just sitting in the sandbox.  Done – TMF 15:22, 22 July 2010 (UTC)

Infobox road/meta/mask/country

In {{Infobox road/meta/mask/country}}, is the line with just |= needed? As it looks as though the #default option will not not get called if the country cannot be identified. -- WOSlinker (talk) 18:17, 24 July 2010 (UTC)

Without that line, the mask and all templates calling it would be placed in the transclusion error category by default. IMO, having the line is a more efficient way to avoid that than wrapping everything in includeonly tags. – TMF 18:25, 24 July 2010 (UTC)

Also: I just tested removing the line, and it categorized the template in the error cat as expected. The code enters the switch if country isn't specified, and it reaches the "blank" line and the default if state/province is 1) not specified or 2) not valid. – TMF 18:28, 24 July 2010 (UTC)

Nevermind, I've found another way to find infoboxes without a country set. Special:WhatLinksHere/Template:Infobox_road/maint/ -- WOSlinker (talk) 18:32, 24 July 2010 (UTC)

I see a lot of streets there, and they should be using {{infobox street}} instead. – TMF 18:34, 24 July 2010 (UTC)

How should the New England Interstate Routes be classified? -- WOSlinker (talk) 18:49, 24 July 2010 (UTC)

I'd say |country=US |type=NER (for "New England route", and to distinguish it from the default type for Nebraska highways). It doesn't work at the moment, but I'll add it in in a bit. As for the /maint what links here...that's a flaw in the template's code that I'm about to commit a fix for. I suggest grabbing the what links here right now and saving it to a text file or a sandbox. – TMF 18:59, 24 July 2010 (UTC)

Why not put a bit of namespace detection around the category so that it only works on articles

|#default={{#ifeq:{{NAMESPACE}}|{{ns:0}}|[[Category:Infobox road transclusion errors]]}}

as it is useful to find articles where the country is not set. -- WOSlinker (talk) 20:03, 24 July 2010 (UTC)

Well, the Canadian, Mexican, and US articles that use state or province shouldn't have country set since it's redundant. The whole point of the mask is to eliminate the need to pass through the extra country parameter. As for this suggestion...it wouldn't pickup on infoboxes with errors that are in sandboxes or on talk pages. Historically, we've fixed those as well when we see them so if they come into the namespace, they're good to go as soon as they do. On a final note, I'm trying to think of a situation where adding a jurisdiction - country, state, province - wouldn't be appropriate. The only ones I can think of are city streets, but they shouldn't be using this template in the first place. – TMF 20:11, 24 July 2010 (UTC)

It wouldn't pickup the Canadian, Mexican, and US articles as long as the state or province was valid. It could be done the other way, to only ignore those in the template namespace. -- WOSlinker (talk) 20:26, 24 July 2010 (UTC)

|#default={{#ifeq:{{NAMESPACE}}|{{ns:10}}||[[Category:Infobox road transclusion errors]]}}

I'm really not convinced {{{country}}} (or {{{state}}} or {{{province}}}) should become a mandatory parameter. This is an example where adding it made no difference since the name and shield are hardcoded in, the headers are already controlled by the header_type, and no system is specified. In fact, adding country broke the infobox by making the "Highway system" header appear. – TMF 21:00, 24 July 2010 (UTC)

In other cases, we should be working with WP:USST and the city projects to convert their street articles away from {{infobox road}} to {{infobox street}}. Where possible, I've already switched articles to {{infobox road junction}}, {{infobox bridge}} or {{infobox tunnel}} as appropriate. Imzadi 1979 → 21:45, 24 July 2010 (UTC)

Banner

{{editprotected}} Could US-old or whatever formatting is required be added to the no banner section of {{Infobox road/banner}}? Thanks. –Fredddie™ 05:12, 26 July 2010 (UTC)

I'm not seeing why it's necessary to add it as US-old alone doesn't generate a banner anyway. – TMF 05:54, 26 July 2010 (UTC)

Ontario infobox

Feel free to convert any remaining uses of {{Infobox Ontario road}} over to Infobox road. I reverted most of the changes I made, but am strapped for time and unable to do the rest at the moment. I'll get around to it if nobody else does. - ʄɭoʏɗiaɲ ^τ _¢ 14:54, 27 July 2010 (UTC)

 Done a while ago, check any of the arterial articles for tweaking. Imzadi 1979 → 04:30, 28 July 2010 (UTC)

Tagged for CSD. The end. - ʄɭoʏɗiaɲ ^τ _¢ 04:51, 28 July 2010 (UTC)

Where did I go wrong?

I need help!

I changed the template to add an argument to display Connecticut US 202 shields like the New Hampshire shields and now the entire template is messed up. What did I do wrong?

HighwayMaster (talk) 20:56, 28 July 2010 (UTC)

I think I got it. A little more context would be helpful to know what you're talking about. We aren't mind readers and your editing history only tells us so much. –Fredddie™ 21:22, 28 July 2010 (UTC)

Code to fix citation errors

{{editprotected}} As it is, if you put a citation in the established, formed or history parameter, it gets numbered 1, even though it shows up below the length ref. This should fix that:

Replace:

|header1= {{#if:{{{section|}}}{{#ifeq:{{{maint|}}}|none||{{{maint|}}}}}{{#ifeq:{{{maint|}}}|none||{{#ifexist:Template:Infobox road/maint/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|{{#ifeq:{{Infobox road/maint/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|state={{{state|¬}}}|province={{{province|¬}}}}}|||show}}|}}}}{{{time_period|}}}{{{length_mi|}}}{{{length_km|}}}{{{established|}}}{{{formed|}}}{{{history|}}}{{{spur_of|}}}{{#ifeq:{{Infobox road/hide/tourist|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{tourist|}}}|}}|Route information}}

With:

|header1= {{#if:{{{section|}}}{{#ifeq:{{{maint|}}}|none||{{{maint|}}}}}{{#ifeq:{{{maint|}}}|none||{{#ifexist:Template:Infobox road/maint/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|{{#ifeq:{{Infobox road/maint/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|state={{{state|¬}}}|province={{{province|¬}}}}}|||show}}|}}}}{{{time_period|}}}{{{length_mi|}}}{{{length_km|}}}{{{length_ref|}}}{{{established|}}}{{{formed|}}}{{{history|}}}{{{spur_of|}}}{{#ifeq:{{Infobox road/hide/tourist|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{tourist|}}}|}}|Route information}}

This changes the if that checks if any parameters are entered to also check for length_ref before it checks history, formed and established. - ʄɭoʏɗiaɲ ^τ _¢ 15:05, 29 July 2010 (UTC)

That will make the header appear if length_ref is used. If that parameter is used and no other parameters in the group are, it's going to result in the route information line displaying for an empty section (since length_ref doesn't do jack unless a length is specified). The reference number issue has been discussed before (if not here, then on IRC), and I don't personally think it's a big deal. – TMF 18:01, 29 July 2010 (UTC)

For the sake of discussion, I have two solutions: invert the order of the dates and length or a variation on Floydian's suggestion. If the order were inverted, the dates would appear and be checked by the if statement first, resulting in lower numbered citations. The second is more along the lines of using parser functions. Is there a way to craft the if statement to look for the length_ref only if length_mi or length_km are defined? If that can be done, and done in the right order, wouldn't that solve the inconsistency of a lower ref number appearing after a higher one in the template display, but not display the header if the length isn't given but the ref is. TMF's point is valid because there are ON usages that have the reference filled in, but no length given. Imzadi 1979 → 18:08, 29 July 2010 (UTC)

I'd rather flip the length and date lines than make the "Route information" display switch any more convoluted than it already is. – TMF 18:12, 29 July 2010 (UTC)

Instead of adding just {{{length_ref|}}}, you could add {{#if:{{{length_mi|}}}{{{length_km|}}}|{{{length_ref|}}}}} -- WOSlinker (talk) 19:39, 29 July 2010 (UTC)

That kinda was my second idea above. Imzadi 1979 → 19:46, 29 July 2010 (UTC)

I'm against adding length_ref in any capacity to the header switch because it's not necessary for the header to work correctly. That header switch already has five ifeqs and one ifexist - plus the if that wraps all of them together - and adding something for little more than cosmetic purposes just clutters it up even more. Like I said above, I'm far more open to moving the formed/deleted and history lines above the length than I am to adding some extraneous and unnecessary code to an already convoluted line. – TMF 20:22, 29 July 2010 (UTC)

I'm all for the simpler fix of moving up the dates. –Fredddie™ 20:53, 29 July 2010 (UTC)

Would that fix M-107 (Michigan highway). The citations there appear in the order: 1) formation date, 2) length 3) decommissioning date. If we're going to do this, we need to do it right the first fix. Imzadi 1979 → 21:26, 29 July 2010 (UTC)

That brings up a thought I had regarding some of the params that work off of "time_period". Since none of those are in the header switch, any refs in them will be presented after refs in parameters that are in the switch. Same goes for the "deleted"/"decommissioned" parameter. I said this initially, and I'll say it again: I really don't think what order the references appear in is a big deal. Not like it breaks the reference link or anything. The only surefire way to "fix" this is to add every parameter to the header switch, and by that point the header code would be so bloated and so full of redundant, unnecessary code that I'd be in favor of scrapping it entirely. – TMF 22:18, 29 July 2010 (UTC)

Not done for now: disabled request as discussion seems to be ongoing, and TMF can make the edit when you've made up your minds. — Martin (MSGJ · talk) 22:37, 29 July 2010 (UTC)

Unless there's objection, I'm declaring the fix as unneeded. If anyone complains at FAC or another forum, tell them there's a technical restriction in how the template is written and move on. Until then, this is officially a non-problem, that even if "fixable" doesn't need changing. Imzadi 1979 → 22:41, 29 July 2010 (UTC)

Personally I'm more concerned about fixing it than worrying about somebody only entering length_ref and having a weird blank section. Thats a screwed up template transclusion, as opposed to a wrongfully coded template. FAC is happy to raise objections to templates, and "I can't edit it, it's protected" just doesn't cut it anymore. You just put the length_ref check within another if that doesn't evaluate anything, but just hides it.

|header1= {{#if:{{{section|}}}{{#ifeq:{{{maint|}}}|none||{{{maint|}}}}}{{#ifeq:{{{maint|}}}|none||{{#ifexist:Template:Infobox road/maint/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|{{#ifeq:{{Infobox road/maint/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|state={{{state|¬}}}|province={{{province|¬}}}}}|||show}}|}}}}{{{time_period|}}}{{{length_mi|}}}{{{length_km|}}}{{#if:{{{length_ref|}}}|}}{{{established|}}}{{{formed|}}}{{{history|}}}{{{spur_of|}}}{{#ifeq:{{Infobox road/hide/tourist|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{tourist|}}}|}}|Route information}}

OR

|header1= {{#if:{{{section|}}}{{#ifeq:{{{maint|}}}|none||{{{maint|}}}}}{{#ifeq:{{{maint|}}}|none||{{#ifexist:Template:Infobox road/maint/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|{{#ifeq:{{Infobox road/maint/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|state={{{state|¬}}}|province={{{province|¬}}}}}|||show}}|}}}}{{{time_period|}}}{{#if:{{{length_mi|}}}{{{length_km|}}}|{{{length_mi|}}}{{{length_km|}}}{{{length_ref|}}}}}{{{established|}}}{{{formed|}}}{{{history|}}}{{{spur_of|}}}{{#ifeq:{{Infobox road/hide/tourist|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{tourist|}}}|}}|Route information}}

C'mon, you coded this massive template, we can find a fix to this minor issue. Convoluted code is no excuse, nor a reason to do nothing. We're not here to worry about performance, and one extra parser function won't break the bank. - ʄɭoʏɗiaɲ ^τ _¢ 14:10, 30 July 2010 (UTC)

Has FAC complained yet? If not, this is a non-issue. – TMF 17:00, 30 July 2010 (UTC)

As an addendum, that's not going to "fix" setups like State Route 74 (New York – Vermont), where the lengths and references are in length_notes. This goes to my point above: the only way to "fix" this is to add every parameter to the header switch, even if said parameters don't require the header to appear. I'm totally against that as I'd rather have only the most essential code for the header to work right than for the template to look "right". (Also, note the quotation marks; to me, there's no problem with the status quo. Reference numbering has been broken with IBR for years, just in a different manner pre-revamp, and because of a parser function.) – TMF 17:11, 30 July 2010 (UTC)

Infobox road/meta/length

Resolved

 – Multiplier added to meta/length; /km and /mi deleted. – TMF 17:23, 30 July 2010 (UTC)

Just wondering if there's really a need to keep the length conversion factors in separate templates (km & mi) as they could be incorporated directly into Template:Infobox road/meta/length with a parser function: {{#ifeq:{{{1}}}|mi|1.609344|0.621371192}} -- WOSlinker (talk) 19:56, 29 July 2010 (UTC)

Those are holdovers from an era in Wiki history when parser functions either 1) didn't exist or 2) weren't widely used yet. Most of IBR's original length conversion process was built during that time, resulting in somewhere around a half-dozen to a dozen templates to perform the conversion. A lot of it was cleaned up in the revamp, bringing it down to the three used today. As for the point above, they probably should be combined - not sure why I passed over it during the revamp. – TMF 20:31, 29 July 2010 (UTC)

 Done Seems to be working. – TMF 22:38, 29 July 2010 (UTC)

time_period param

Could someone point me towards an article using the time_period parameter as I just want to see how it's used. Thanks -- WOSlinker (talk) 12:55, 30 July 2010 (UTC)

It was added as a result of Template talk:Infobox road/Archive 5#Infobox extension, but I don't think it's actively being used. – TMF 16:57, 30 July 2010 (UTC)

TX colors

The "Park" and "RE" types for Texas should be switched to default to brown, per WT:TXSH. I'm checking on other types, but it looks like that's all that needs to be switched for now. Imzadi 1979 → 19:42, 7 August 2010 (UTC)

That's all the types for TX that need switching. Imzadi 1979 → 20:37, 7 August 2010 (UTC)

"RE"/"Rec" already defaulted to brown; "Park" added as requested. – TMF 02:29, 8 August 2010 (UTC)

Australian colors

I'm working on the details for supporting the potential conversion of the rest of Australia over. The following types and colors are in use at the moment in {{infobox Australian road}}, which I've added here for reference. A full proposal on what types/colors to add to the template is coming. Imzadi 1979 → 21:09, 3 August 2010 (UTC)

Added in a sample column with the colors because I couldn't visualize it. –Fredddie™ 22:51, 3 August 2010 (UTC)

I've been going through articles, looking for how the system is signed, and it looks like we can do something similar to Canada here. There would need to be a header_type override for the freeways or roads. I can't find the street "red" in use at all. Otherwise most of the types that would be needed for Australia would call either the green or the grey. Imzadi 1979 → 23:14, 3 August 2010 (UTC)

Type	Color	Sample
freeway	#D2E2F9
highway	#E9F9D2
city highway	#E9F9D2
road	#FFFFE0
rural road	#FFFFE0
street	#F9E2D2
default	#ccc

Seems like there are no objections - this ready to implement? (The Australians have been notified of this, right?) --Rschen7754 06:01, 13 August 2010 (UTC)

No, nothing was proposed to them yet. I've been a little busy with other things for a bit, and I was waiting for the QLDroad template to be CSD T3 deleted, which it has now. Imzadi 1979 → 06:06, 13 August 2010 (UTC)

India Destinations

Can IND be added to Template:Infobox road/hide/destinations. Thanks -- WOSlinker (talk) 23:18, 20 August 2010 (UTC)

Is this to list primary destinations? --Rschen7754 23:19, 20 August 2010 (UTC)

Yes, there are 10 I've just converted listed at Category:Infobox road transclusion errors if you want to see some examples. -- WOSlinker (talk) 23:41, 20 August 2010 (UTC)

 Done --Rschen7754 23:42, 20 August 2010 (UTC)

Municipalities

{{editprotected}} Old:

|label66 = {{#if:{{{counties|}}}{{{parishes|}}}|{{#if:{{{parishes|}}}|Parishes|Counties}}:}}
|data66  = {{{counties|}}}{{{parishes|}}}

New:

|label66 = {{#if:{{{counties|}}}{{{parishes|}}}{{{municipalities|}}}|{{#if:{{{parishes|}}}|Parishes|{{#if:{{{municipalities|}}}|Municipalities|Counties}}}}:}}
|data66  = {{{counties|}}}{{{parishes|}}}{{{municipalities|}}}

This will allow support for Puerto Rico, where the correct second-level region is called a Municipality. –Fredddie™ 23:34, 26 August 2010 (UTC)

Done Dabomb87 (talk) 01:56, 27 August 2010 (UTC)

Australian colors

{{editrequest}} Add the following code to {{Infobox road/meta/colors}} to enable colors for Australian roads in preparation for a proposed conversion of that template.

 |AUS={{#switch:{{{type|}}}
  |Metroad|M|freeway=background-color:#D2E2F9;
  |A|B|highway=background-color:#E9F9D2;
  |C|road=background-color:#FFFFE0;
  |street=background-color:#F9E2D2;
  |#default=background-color:#ccc;
  }}

Thank you. Imzadi 1979 → 19:23, 27 August 2010 (UTC)

 Done --Rschen7754 19:39, 27 August 2010 (UTC)

Photo parameter

A photo parameter has been added to the infobox; however, it has been blacklisted for the US per this discussion. – TMF 22:31, 27 August 2010 (UTC)

Can we get an alternate set of parameter names for it? image, caption/image_notes, image_alt and image_custom? There has been a request to that effect made at WT:UKRD. Imzadi 1979 → 00:43, 30 August 2010 (UTC)

I'm not a fan of any of the parameters. "caption" is way too open; is it a caption for the map or for the photo? "image" is equally as vague; both maps and photos are images. I believe having "caption" would confuse way too many people, but "image" might work, if for no other reason than the articles using it wouldn't be in my backyard. "caption"  Not done; "image" et al  Done. – TMF 01:01, 30 August 2010 (UTC)

length_round

The length_round parameter currently defaults to 0. Just wondering if it would be better to calculate the default using a template such as {{getprecision}}. -- WOSlinker (talk) 21:13, 25 August 2010 (UTC)

Just so I understand correctly, it would automatically figure out the precision similar to how {{Convert}} handles precision? If so, I'm all for that. –Fredddie™ 22:04, 25 August 2010 (UTC)

Yeah, it sounds good. I mean, I would test it in a sandbox to double check and make sure it works before deploying it, but I support it. --Rschen7754 22:06, 25 August 2010 (UTC)

The principle is sound, and would simplify things. Granted, sometimes we'd want to override it or what not, but defaulting like that would be great. Imzadi 1979 → 22:08, 25 August 2010 (UTC)

Here's a few samples with the change in the sandbox. -- WOSlinker (talk) 22:18, 25 August 2010 (UTC)

Number	Round	Live	Sandbox
10	not specified	10 km (6.2 mi)	10 km (10 mi)
10	0	10 km (6.2 mi)	10 km (6 mi)
10	1	10 km (6.2 mi)	10 km (6.2 mi)
10.0	not specified	10.0 km (6.2 mi)	10.0 km (6.2 mi)
10.0	0	10.0 km (6.2 mi)	10.0 km (6 mi)
5.8	not specified	5.8 km (3.6 mi)	5.8 km (3.6 mi)
5.8	0	5.8 km (3.6 mi)	5.8 km (4 mi)
5.8	1	5.8 km (3.6 mi)	5.8 km (3.6 mi)
5.83	not specified	5.83 km (3.62 mi)	5.83 km (3.62 mi)
5.83	0	5.83 km (3.62 mi)	5.83 km (4 mi)
5.83	1	5.83 km (3.62 mi)	5.83 km (3.6 mi)
5.83	2	5.83 km (3.62 mi)	5.83 km (3.62 mi)
0.09	not specified	0.090 km (0.056 mi)	0.09 km (0.06 mi)
0.88	not specified	0.88 km (0.55 mi)	0.88 km (0.55 mi)

I've applied it now. -- WOSlinker (talk) 07:11, 26 August 2010 (UTC)

How foolproof is the template? If it's as foolproof as it sounds and seems, we could probably deprecate "length_round". – TMF 20:02, 27 August 2010 (UTC)

I think it would only be on very odd occasions where it might still be needed. Can't think of any examples now though. Massachusetts Route 128 seems to have a rather high precision for the length though, is there really a need to specify it to 4 decimal places? -- WOSlinker (talk) 21:09, 27 August 2010 (UTC)

WT:USRD is probably a better venue for that question. As for the odd cases, we could always shut the parameter off now and restore it if something messes up. – TMF 21:48, 27 August 2010 (UTC)

Well, the suggestion in the MOS is that small distances should actually have an extra decimal place of precision. That way "1 mi (1.6 km)" instead of "1 mi (2 km)". If the template in place now handles that sort of thing, then I don't see any need to override the level of precision. Imzadi 1979 → 22:18, 27 August 2010 (UTC)

It doesn't, but meta/length could be modified to do that (If precision is 0 and value is less than 2 - or whatever - round to 1 place). But yeah, that's another case for doing all of the rounding template-side as I bet many if not all infoboxes with length_mi=1 have length_round=0. – TMF 22:28, 27 August 2010 (UTC)

I found what I consider a couple of glitches with the template: 0.090 mi (0.14 km), 0.88 mi (1.42 km). Having a bit of extra precision to make the conversion more meaningful is one thing, but I think this is excessive. – TMF 16:07, 31 August 2010 (UTC)

The issue was only affecting lengths between 0 and 1 so I've done a workaround of adding 1 to the length before calling getprecision. See here. And I've also asked Wikid77 about the getprecision template issue. -- WOSlinker (talk) 17:57, 31 August 2010 (UTC)

New signs for Slovak roads

There are new signs for Slovak roads uploaded on Commons, using the official "Universal Grotesk" font.

• Highways: [1] (only the .svg files - Diaľnica Dx.svg)
• Expressways: [2] (Rýchlostná cesta Rx.svg)
• 1st-class roads: [3] (only the .svg files - Cesta I. triedy číslo xx.svg)

Current signs are using images from here, but they are incorrect (this font isn't used on Slovak road signs).

Can be this corrected in template? Thanks. --Chiak (talk) 18:13, 31 August 2010 (UTC)

 Done. The 1st-class roads have been assigned |type=C. If you wish to change these in the future, {{Infobox road/shield/SVK}} sets the graphics for the browser at the bottom of the infobox, and {{Infobox road/shieldmain/SVK}} sets the graphics for the top of the infobox. The full list and instructions is at Template:Infobox road/doc/country. Imzadi 1979 → 18:31, 31 August 2010 (UTC)

specific browselinks for different .hr roads

Someone was kind enough to make Template:Infobox road/browselinks/HRV. However, that makes the whatlinkshere output for Highways in Croatia really messy. There are specific incoming redirects for two (well, three) different types of roads - motorways, state roads, expressways. What's the best way to make each of those link to a specific redirect? --Joy [shallot] (talk) 10:45, 2 September 2010 (UTC)

 Done Motorways and state roads now link to Motorways in Croatia and State roads in Croatia, respectively, while all Croatian roads that aren't motorways or state roads will still link to Highways in Croatia. As far as I can tell, there isn't a type for expressways, so it's not possible to add that link. Hope that helps. – TMF 16:32, 2 September 2010 (UTC)

orbital parameter

{{editrequest}}

Insert:

|data22  = {{#if:{{{orbital|}}}|[[Orbital road|Orbital]] around {{{orbital}}}|}}

and update:

|header19= {{#if:{{{terminus_a|}}}{{{beltway_city|}}}{{{orbital|}}}{{{junction|}}}|Major junctions}}

To add a new |orbital= parameter for ENGVAR support for BrEng. Imzadi 1979 → 23:14, 8 September 2010 (UTC)

 Done --Rschen7754 23:17, 8 September 2010 (UTC)

ENGVAR/UK updates

{{editrequest}} Per Wikipedia talk:WikiProject UK Roads#Infobox conversion proposal, a few small semantic changes should be made.

|header72= {{#if:{{{state|}}}{{{province|}}}{{{country|}}}{{{type|}}}{{{system|}}}|Highway system}}

Should be changed to:

|header72= {{#if:{{{state|}}}{{{province|}}}{{{country|}}}{{{type|}}}{{{system|}}}|{{#switch {{{country|}}}
 |GBR|IRL= Road network
 |#default=Highway system}}
}}

This will switch the output of the last header to "Road network" for the UK and Ireland. All other countries will remain unaffected. Future capability is preserved to customize based on WP:ENGVAR.

|header19= {{#if:{{{terminus_a|}}}{{{beltway_city|}}}{{{junction|}}}|Major intersections}}

and

|label25 = Major<br>junctions:

Should be changed to:

|header19= {{#if:{{{terminus_a|}}}{{{beltway_city|}}}{{{junction|}}}|Major junctions}}

and

|label25 =  

This will move the ENGVAR-neutral "junctions" to the section heading, and blank the label for the junction list. Imzadi 1979 → 22:10, 8 September 2010 (UTC)

 Done --Rschen7754 22:44, 8 September 2010 (UTC)

I think having no label for the major junctions looks weird. Sure, the header's supposed to imply that they're all major junctions, but to me, having labels for the termini and nothing for the intermediate junctions is a bit jarring. – TMF 19:26, 10 September 2010 (UTC)

I can't think of a better solution, though. Having 'Major junctions:' showing twice in the same section is terribly redundant. I think that's why the header was changed to 'Major intersections' in the first place. –Fredddie™ 22:21, 10 September 2010 (UTC)

Remove colons

I think labels of infoboxes shouldn't end with colons, because the tabular layout is enough to differentiate the label from the data, so I changed the sandbox version. If there are no objections, I think the main template should be changed. Svick (talk) 13:54, 12 September 2010 (UTC)

It's just fine as it is now. I would leave it alone. Imzadi 1979 → 18:48, 12 September 2010 (UTC)

"Prefectures" and "municipalities" as locations

Hello. I wonder if someone could add "prefectures" and "municipalities" as options for locations. The Greek equivalent of these terms is used in Greece. --Dead3y3 (talk) 08:13, 19 October 2010 (UTC)

County Roads

The problem with the "state" field in the infobox is that if the field is filled, it automatically assumes that the state's DOT maintains the road. However, this is not true in some cases -- for example, Central Avenue (St. Petersburg, Florida), also known as Pinellas County Road 150, requires "FL" in the "state" field for the county shield to be displayed; however, by doing so, the infobox says that the road is maintained by the FDOT, when in fact it is maintained only be the Pinellas County Highway Department. Is there any way for the mainenance of roads to be changed in the infobox? -- azumanga (talk) 21:01, 13 November 2010 (UTC)

Yes, adding |maint=none will remove the Maintained by section. -- WOSlinker (talk) 21:06, 13 November 2010 (UTC)

Or add |maint= Pinellas County Highway Department to change from the default. This is similar to what I did with County Road 492 (Marquette County, Michigan). Imzadi 1979 → 21:11, 13 November 2010 (UTC)

As the originator of the idea to fill in the |maint= field automatically, I think we should review whether it's really needed. There are a number of sub-templates which could be eliminated as a result. –Fredddie™ 01:40, 14 November 2010 (UTC)

I take that back, there's only one sub-template. Perhaps we can add a switch which would prevent the |maint= field from being filled when it's a CR or equivalent. –Fredddie™ 01:42, 14 November 2010 (UTC)

Honestly, I've had mixed feelings about automatically setting any parameter values like this for reasons like this. Imzadi 1979 → 03:13, 14 November 2010 (UTC)

I'd rather implement something like that than throw the proverbial baby out with the bathwater. I'd take it one step further, though; what I would do is restrict the automatic generation of the maint line to Interstate Highways, U.S. Highways, and state highways. I think there is value to the feature, and this change would eliminate the sole complaint we've seen regarding it. – TMF 08:55, 14 November 2010 (UTC)

Switch added as described above. – TMF 23:02, 15 November 2010 (UTC)

Paramter for Districts

{{editprotected}} Old:

|label66 = {{#if:{{{counties|}}}{{{parishes|}}}{{{municipalities|}}}|{{#if:{{{parishes|}}}|Parishes|{{#if:{{{municipalities|}}}|Municipalities|Counties}}}}:}}
|data66  = {{{counties|}}}{{{parishes|}}}{{{municipalities|}}}

New:

|label66 = {{#if:{{{counties|}}}{{{parishes|}}}{{{municipalities|}}}{{{districts|}}}|{{#if:{{{parishes|}}}|Parishes|{{#if:{{{municipalities|}}}|Municipalities|{{#if:{{{districts|}}}|Districts|Counties}}}}}}:}}
|data66  = {{{counties|}}}{{{parishes|}}}{{{municipalities|}}}{{{districts|}}}

This is to support the state highways of India. The subdivision of a state in India is a district. Thanks ! --Nayvik (talk) 15:15, 30 November 2010 (UTC)

I'm bumping this back out of the archives. The edit request was only made in the last day or so, but the bot is working off the date in the signature. Imzadi 1979 → 09:14, 12 December 2010 (UTC)

 Not done I inserted the code and it broke the template. --Rschen7754 09:54, 12 Decemb</nowiki>er 2010 (UTC)

There was a missing set of double closing curly brackets. That didn't close the last if function in the label coding, breaking the template. It has been corrected and tested in the sandbox. Imzadi 1979 → 10:12, 12 December 2010 (UTC)

 Done --Rschen7754 10:13, 12 December 2010 (UTC)

Banner fix

{{editprotected}}

Template:Infobox road/banner needs an addition to support older route types

Currently: |US-Alt={{#switch:{{{state}}}

Should be replaced with: |US-Alt|US 1961-Alt|US 1948-Alt={{#switch:{{{state}}}

Actually, any instance of a US type should be amended to add support for US 1948 and for US 1961. The 1961 markers should be finished soon. –Fredddie™ 03:55, 12 December 2010 (UTC)

 Done --Rschen7754 05:04, 12 December 2010 (UTC)

Could the same be done for US, US-Bus, US-Byp, US-Conn, US-Opt, US-Scenic, US-Spur, US-Temp, and US-Truck? US-Toll is newer option, so that one is not necessary. –Fredddie™ 12:56, 12 December 2010 (UTC)

 Done for all but US since type=US doesn't generate a banner if subtype isn't passed through. – TMF 15:23, 12 December 2010 (UTC)

Duh, thanks. –Fredddie™ 22:42, 12 December 2010 (UTC)

I wouldn't say that US-Toll is new. The Tri-State Tollway was TOLL US 41 before it was I-294. Imzadi 1979 → 22:53, 12 December 2010 (UTC)

Keep in mind the older toll roads used the white banner while toll roads now use the yellow banner. Dough4872 19:41, 13 December 2010 (UTC)

So, do we need a {{{toll}}} and {{{oldtoll}}}? –Fredddie™ 21:29, 18 December 2010 (UTC)

Chinese localization

Just need to add "Administrative areas" (|adminareas=) for China (CHN). The heading should be linked to Administrative divisions of China. Imzadi 1979 → 21:25, 25 December 2010 (UTC)

While I'm not against this, I think we should start looking into making subdivisions into a subtemplate or three. –Fredddie™ 23:05, 25 December 2010 (UTC)

Requests for parameter changes

I'd like to make some revisions to Location parameters, but am apprehensive to attempt editing this template as it is fairly sophisticated. I feel it might be more efficient to request someone to process these revisions on my behalf. These revisions are summarized below:

• 1. There are parameters for cities, towns, and villages. Within the published template, the cities parameter appears as Major cities, while the other two appear per their parameter names (Towns and Villages). If we are providing an opportunity to list all towns and villages in the template, which are usually smaller than cities, why only allow major cities and not minor cities in the published template? Differentiating between major and minor is POV-based. Can this template be changed such that the cities parameter appears simply as Cities instead of Major cities?
• 2. Like for Manitoba and Saskatchewan, can we allow the rural_municipalities parameter for use in Alberta? In Alberta, its Ministry of Municipal Affairs characterizes three different municipal status types as rural municipalities. Allowing this parameter to be used in Alberta would enable us to list all municipal districts (also branded as counties), special areas, and improvement districts that a particular highway could pass through under one parameter. The current counties parameter is insufficient for Alberta as technically there is no such municipal status of county in Alberta anymore, and it isn't inclusive of special areas and improvement districts.
• 3. May we have parameters established for other municipal status types in Alberta such as specialized municipalities and summer villages? How about blank location parameters as well so that they can meet the needs of other provinces, states, and countries with unique municipal status types?

Cheers, Hwy43 (talk) 06:26, 9 January 2011 (UTC)

Some replies:

1. I think that the intent is to use the highest applicable level (cities, towns or villages). The idea isn't to be comprehensive and list all because the prose of the article should contain all of the communities, regardless of type. The infobox, like the lead, is meant to be a summary only, not a substitute for the article itself. The US has recently moved away from listing cities/towns/villages completely for the reasons you mention: there's no objective way to determine what to list and what not to list, making it subjective and POV/OR. (P.S. The "municipalities" for the template are what Puerto Rico uses instead of counties. Counties/parishes/municipalities are mutually exclusive.)
2. We can whitelist Albert for rural municipalities. If municipal districts is a better, all-encompassing term though, we can add that. (Really, truly, you shouldn't have mixes of them, but use one heading that incorporates the rest.)
3. Are these subtypes of rural municipalities? If so, they can/should be listed using that parameter.

I hope this helps. Imzadi 1979 → 06:40, 9 January 2011 (UTC)

I too agree, the major should be dropped from 'major cities', and a municipal district parameter would be nice. 117Avenue (talk) 08:21, 9 January 2011 (UTC)

To respond to 3...

3. There are three general types of municipal statuses in Alberta:

• urban municipalities (cities, towns, villages, and summer villages);
• rural municipalities (municipal districts, special areas, and improvement districts); and
• specialized municipalities, which often allow urban and rural communities to coexist under a single municipal government.

Therefore, specialized municipalities and summer villages are not sub-types of rural municipalities. The former is its own type, while the latter is a sub-type of urban municipalities.

Ideally, it would be nice to have parameters to reflect all different municipal status types and sub-types in Alberta. However, whitelisting the rural_municipalities parameter for Alberta to allow entry of all three of its sub-types instead of creating new parameters for all three sub-types would be acceptable. Hwy43 (talk) 20:39, 9 January 2011 (UTC)

Would it bet a good idea to drop the rural from {{{rural_municipalities}}}? –Fredddie™ 21:46, 9 January 2011 (UTC)

A {{{municipalities}}} already exists. Hwy43 (talk) 22:49, 9 January 2011 (UTC)

Is there one term that encompasses the top level of the subdivisions for Alberta? If so, that's the term that should be in use/added to the infobox. The Locations subsection of the infobox should not attempt to be overly comprehensive. List all of the specifics in the article, leave the infobox as a summary of the highlights. If a single list of top-level divisions is possible, then you can skip the cities/villages/towns completely and still give the reader an overview of the location(s) served by the road. Imzadi 1979 → 23:24, 9 January 2011 (UTC)

To respond to 1 and 2...

• 1. Cities, towns, and villages represent the highest applicable levels of urban communities in Alberta. Below them are summer villages (incorporated), hamlets (unincorporated), and then other unincorporated communities. (Note: numerous hamlets in Alberta meet the population and density requirements to incorporate as a city, town, or village).

I recently swept all Alberta provincial highway articles to remove all hamlets and unincorporated communities from the infobox, and assign those incorporated communities that were missed. (My past efforts on Alberta highway articles have been well-received and no controversy has ensued from my recent edits.) I did this sweep for numerous reasons:

• the parameters they were assigned to were incorrect in terms of incorporated municipal status, potentially misleading some readers as a result while perpetuating common myths to others about certain communities holding certain statuses when they do not;
• to ensure no controversy over undue weight in including one city/town/village over another city/town/village or personal POV of significance of one over another; and
• to limit the balance of communities to the prose of the article as, I agree, the infobox should not list absolutely every community.

Also, what has happened in US highway articles is noted. However, Canadian provinces are outside the realm of WP:USRD/STDS.

• 2. As you've suggested, please whitelist Alberta for rural_municipalities as it is an all-encompassing term for its three sub-types (municipal districts, improvement districts, and special areas). Removing Alberta's usage of the counties parameter in exchange for rural_municipalities would be satisfactory (although may be subject to controversy by those who are unaware of this). Hwy43 (talk) 06:26, 14 January 2011 (UTC)

1. There is a persuasive reason though why WP:USRD/STDS was crafted to specifically exclude all cities/towns/villages (hereafter being called "second-tier subdivisions") but allowing all counties/parishes/boroughs/municipalities (Puerto Rico) and equivalents (hereafter being called "first-tier subdivisions") in the location section of the infobox that would be applicable to note regarding Canada and other countries. It's easy to list all first-tier subdivisions in a state/territory as the list can be exhaustive without normally being too long. To keep infobox size down, as has been requested at several of the USRD-nominated FACs over the years, it was desirable to limit how many second-tier subdivisions were listed, i.e. keep the list to the most major of cities for a particular highway. The problem is that there is no objective criteria that's can be used satisfactorily to determine what's "major". In other words, why would one city be included but another excluded? A well-crafted Route description should list all second-tier subdivisions in the text as a natural part of the writing. (Adding all first-tier subdivisions may not always be possible, but they should be listed as a part of the junction list anyway.) So to prevent issues where editors could be "accused" of WP:OR over attempting to decide which cities/towns/villages to include and which to exclude, all were excluded in the US, leaving only the first-tier subdivisions. (Some articles in the US will also list which states, but only if multi-state articles.)
   It is my suggestion though that other areas avoid listing cities/towns/villages, especially multiple types. The reason is that if cities, towns and villages are all listed, you lose the geographic continuity. (The first-tier subdivision, be it counties or rural municipalities should be listed south-to-north or west-to-east to follow the written direction of the roadway.) The cities would be in one list in order, the towns in a second and villages in a third, with no idea where the roadway runs. It could run first city, second city, first village, third city, first town, second village... and no reader would have a clue from the separated lists.
2. As for whitelisting, Alberta, I can ping an admin to update the specific subtemplate to add AB. I will caution, I don't think there's a way to black list the counties parameter for Alberta, so you may find that things are added or re-added to infoboxes that way in the future. Imzadi 1979 → 00:10, 15 January 2011 (UTC)

AB added to the whitelist for the parameter. Imzadi 1979 → 01:15, 15 January 2011 (UTC)

1. Alberta does not distinguish municipalities into hierarchal tiers. It simply groups them into similar types by predominant density/built form – urban, rural, and specialized (usually an urban/rural mix, but having geographic sizes similar to rurals). You've provided a good summary for what is implemented in the US, and the issues that led to it. However I have not witnessed the same issues arising for Canada or Alberta in particular (as far as I know). I don't see the need to implement something, which resolved issues that arose in one country/state, on another country/province where these same issues have not been raised.
   Personally, I find a complete list of incorporated municipalities in the infobox to be very helpful. I get what I want to know right away, saving time from reviewing the detailed route descriptions on Alberta highway articles to gather a complete list of what I am looking for... a process which can be prone to human error when reviewing reams of information. I have yet to scrutinize each Alberta highway article's route descriptions, but I recall from past visits that a significant amount do not have them at all, and those that do use a variety of different methods – various templates, simple tables, bullet points, and paragraph forms.
   Your concern about the principle of geographic continuity is something I very much agree with. I have followed this principle among the various Alberta municipal types and sub-types thus far. You raise a very good point about true geographic continuity though – I had yet to think about it from a first city, second city, first village, third city, first town, second village perspective for Alberta's urban municipalities (although this was the principle behind why I requested rural_municipalities be whitelisted for Alberta).
   Perhaps a new catch-all urban_municipalities parameter for Alberta would ensure true geographic continuity among these municipal sub-types.
2. Thanks for arranging to whitelist rural_municipalities and for advising about the counties parameter.
3. As mentioned under 1. above, there are no hierarchical levels among Alberta's three municipal status types (urban, rural, and specialized). An unofficial hierarchy among the urban municipality sub-types can be derived based on the minimum population thresholds associated with each, but that would be POV-based. The only term that could encompass all municipal status types is simply municipalities. However, using that would compromise true geographic continuity as nearly all urban municipalities are islands surrounded by rural or specialized municipalities.
   

Based on all of this above, I see there being one ideal option for the Alberta template... two new parameters – rural_specialized_municipalities (published label being Rural/specialized municipalities) and urban_municipalities (published label being Urban municipalities), where rural and specialized are grouped together based on having similar geographic sizes. If implemented, the rural_municipalities could then be unwhitelisted. Also if implemented, it would be nice to embed wikilinks in the published labels of the two parameters (i.e., Rural/specialized municipalities and Urban municipalities) to assist readers in understanding what each means and which municipal status sub-types are included in each. Hwy43 (talk) 21:11, 23 January 2011 (UTC)

Some replies in brief because what's above is TL;DR. The articles should not be relying on tables for Route descriptions. The table should be compliant with MOS:RJL and located in a separate section called "Major intersections", "exit list" or even "Junction list" or "Junctions". The RD section should be written prose (yes, paragraphs). That plus a history is the basic three sections required to be rated as either C- or B-Class depending on the quality of writing, the comprehensiveness of the content and the level of referencing/quality.

Now, I think that the rural_municipalities (as a single top-level division) is appropriate and I would not like to see the infobox split any further. In the US, we list independent cities in the county list, even though it's a single-tier municipality. (The City of Balitmore is considered as if a county, and separate from the County of Balitmore. Both would be listed in a county list for a Maryland highway.) Imzadi 1979 → 22:08, 23 January 2011 (UTC)

Again, there is no hierarchy of subdivisions in Alberta, unlike there are in states and some provinces. In Michigan, according to the I-5 article, counties appear to be subdivided further into townships and urban municipalities. Alberta does not subdivide its rural and specialized munis into lower level munis such as townships. Further, these munis have no jurisdiction over the urban munis that they surround. Therefore, all three types of subdivisions in Alberta (urban, rural and specialized) are at a same, singular level.

Alberta is unique from the majority of states/provinces in that respect; hence the request for an urban_municipalities parameter to achieve geographic continuity among all cities, towns, and villages in the infobox like we now have for all rural municipalities in the infobox (MDs aka counties, IDs, and SAs). Hwy43 (talk) 22:05, 26 February 2011 (UTC)

Additional header color for your consideration

Former routes

Former routes

I'd like to propose adding |header_type=former which would be used to represent former routes, some of which are currently being misrepresented by |header_type=historic. It would use the color #6a6a6a. –Fredddie™ 01:15, 16 March 2011 (UTC)

Ok, we'll need to research my answer, but I think that once upon a time, guide signage was white on black (I know in Michigan's MUTCD from 1939 it was). I've added that as a potential option without the drop shadows. Personally, I don't know that we need to retain the drop shadows anymore though. I've seen odd results with the headers when I've printed out articles, or saved them as PDFs. The white text for me gets converted to a grey that's the same color as the drop shadow and the background color is removed completely in the process. As a result, the letters are less than legible. Imzadi 1979 → 05:46, 16 March 2011 (UTC)

California used white on black guide signs in the early days...don't know about other jurisdictions. I think either color combination would be fine for this purpose. -- LJ ↗ 06:37, 16 March 2011 (UTC)

Having looked through old MUTCDs, black on white used to be the standard, but I won't advocate that look here. (Iowa pics [4] [5]) –Fredddie™ 12:07, 16 March 2011 (UTC)

Support adding a new header type to differentiate historic routes from former routes. I agree with the proposed grey color.  VC  14:27, 16 March 2011 (UTC)

• In thinking more about it, I support the "former" header type, specifically with the gray color proposed. Uses of the former type should also look at other appropriate modifications to the infobox (i.e. not automatically fill in the 'maint' parameter with the DOT).

Good idea, I didn't consider turning off |maint=. –Fredddie™ 04:21, 17 March 2011 (UTC)

Suggestion: Optional Latitude and Longitude for Terminus A/B?

{{Infobox road
|country=
|type=
|route=
|map=
|length_mi=
|terminus_a=
|lat_a=8.302
|long_a=98.784
|terminus_b=
|lat_b=9.158
|long_b=99.517
...
}}

South and East would be negative°.

By adding Lat/Long of A&B to the template their value can be included in top right of the page like the Template:Coord currently does with titles.

Minor Suggestion: gross_climb_ab=1000m and gross_climb_ba=900m

{{Infobox road
|country=
|type=
|route=
|map=
|length_mi=
|terminus_a=
|gross_climb_ab=1000m
|terminus_b=
|gross_climb_ba=900m
...
}}

I'm not sure of the technical term for this, but for large loads of a lorry a longer route may be preferred to avoid a shorter route with several big hills. In the example above could be two 500m climbs, and two 450m descents from A to B, giving a net climb of 100m.

At [6] it is referred to as "Total Gross Climb"... and seems useful figure for determining the difficulty of the harriers run.

03:14, 19 March 2011 (UTC)

Consensus has been not to include coordinates on highway articles in the past. For those countries' articles that do include them, they either do so through footnotes in the junction list or just use {{coor}} wherever they want to insert them. Sorry, I oppose changing this template to insert something that consensus says we don't want. As for the elevation stuff, that should be in the body of the article. As it is, we're getting horrendously long infoboxes in articles. Adding more data would worsen that issue for minimal benefit. Imzadi 1979 → 03:17, 19 March 2011 (UTC)

Sorry about that, I did a quick search of the archive and didn't spot any poll. Can you give me a link. Was the vote for a mandatory lat/long or an optional one?

NevilleDNZ (talk) 03:25, 19 March 2011 (UTC)

It wasn't specifically with this template. It was over at WT:HWY, the parent project for highway articles on Wikipedia. The discussion has been archived, but the consensus has been to avoid geocoding the articles until a satisfactory way to display the coordinates without cluttering the articles is found. Unlike many things, roads are linear features and so one point isn't a good measure of a road's location. Imzadi 1979 → 03:31, 19 March 2011 (UTC)

It seems to me that Infobox road already has "human" descriptions of terminus_a=, junction=, terminus_b then adding the coordinates is reasonably logical. Something like "coord_a=8.302N,98.784E" would be nice, (or even "coord_a=8°18.11′N 98°47.03′E" if MediaWiki Templates can handle human readable input.) eg.

{{Infobox road
|terminus_a=Surat Thani
|coord_a=8°18.11′N 98°47.03′E
|junction= Nakhon Si Thammarat, etc...
|coord_junction=9°01′N 99°01′E; 9°02′N 99°02′E; etc...
|terminus_b=Trang
|coord_b=9°9.47′N 99°31.02′E
...
}}

NevilleDNZ (talk) 08:09, 19 March 2011 (UTC)

A case by case basis seems OK, eg:

{{Infobox road
|terminus_a=Surat Thani {{Coord|8|18.11|N|98|47.03|E| type:landmark_region:TH|display=inline}}
|junction= Nakhon Si Thammarat {{Coord|9|01|N| 99|01|E| type:landmark_region:TH| display=inline}}, etc...
|terminus_b=Trang {{Coord|9|9.47|N|99|31.02|E| type:landmark_region:TH|display=inline}}
...
}}

NevilleDNZ (talk) 08:54, 19 March 2011 (UTC)

Interstate 375
Walter P. Chrysler Freeway
I-375 in red, BS I-375 in green
Route information
Maintained by MDOT
Length	1.147 mi (1.846 km) 1.06 miles (1.71 km) according to FHWA
Existed	June 26, 1964–present
NHS	Entire route
Major junctions
South end	BS I-375 in Detroit 42.331067°N 83.039453°W / 42.331067; -83.039453
North end	I-75 in Detroit 42.342178°N 83.043047°W / 42.342178; -83.043047
Location
Country	United States
State	Michigan
Counties	Wayne
Highway system
Interstate Highway System Main Auxiliary Suffixed Business Future Michigan State Trunkline Highway System Interstate US State Byways
← M-331 → I-475

Such a thing can already be done on a case by case basis just by adding {{coord}} after the highway name and location in the termini fields. For example, using the infobox from Interstate 375 (Michigan), all I did was add a <br/> and the coordinates template with the values after the junction and location. There's no need to insert additional parameters to the infobox, especially when there there is no consensus to be geotagging highway articles at this time. (For the record, negative values for geographic coordinates are south or west, not east.) Imzadi 1979 → 08:29, 19 March 2011 (UTC)

Gross climbs

I don't quite understand the climbing parameters. We have extensive topographic maps that show us elevations, but if the starting and ending points are at similar elevations, and the route has significant hills, how do you show that? It quite similar to the coordinates argument, actually. –Fredddie™ 03:36, 19 March 2011 (UTC)

The key point is that some roads are "mountainous" and this become the chief road operating cost.

"In the example above could be two 500m climbs (500m vertical), and two 450m descents from A to B, giving a net climb of 100m"

For example the report by the Asian Development Bank (page 1-10) contains these costs factors:

Heavy Truck on unsealed Road: Flat/Rolling Road=1.77, Hilly Road=3.64 & Mountainous Road=6.12

This gives is a factor of 3.5 times (6.12/1.77) increase in costs if the road is "mountainous".

Basically the vast majority of the CO₂ generated and Hydrocarbon's burned are on the climb, whereas descents are effectively CO₂ free. This additional cost can quickly be estimated by summing all the inclines and multiplying by the weight of the vehicle. Ironically AFAIK the typical consumer GPS typically prefers the short mountainous route in preference to the longer flat route, this works well if driver time is precious, and CO₂ emissions are not important.

A more complicated alternative is to calculate "average grade" c.f. Road Grade Estimation For On-Road Vehicle.

I have seen a summary of highway gross climbs was for the highways of Papua New Guinea, and reliably getting this information for any other country is potentially problematic. Effectively, at this stage, the "Gross Climb" suggestion is moot.

NevilleDNZ (talk) 08:09, 19 March 2011 (UTC)

Such data is too complex for the purposes of the infobox, which is a quick display of where a highway is located with the most basic facts about the roadway. Imzadi 1979 → 08:29, 19 March 2011 (UTC)

Another issue I see is that if you start talking about carbon footprints in articles, you have crossed the POV line. –Fredddie™ 16:46, 19 March 2011 (UTC)

I don't support either of these proposals. They're solutions looking for a problem. Coordinates add too much clutter to the infobox (and to the article), and aren't effective at all. Climbing stuff doesn't help either. Carbon footprints have no place in highway articles whatsoever. --Rschen7754 20:05, 19 March 2011 (UTC)

As I said "Effectively, the 'Gross Climb' suggestion is moot" due to the difficulty of getting access to the road geometry data. re: CO₂ & POV? ... Odd! NevilleDNZ (talk) 22:20, 19 March 2011 (UTC)

Just as a comment, but USRD's Featured Articles do not contain any of these things, and yet they're considered comprehensive by the community. Considering the project has submitted almost three dozen article through the process, if that data were really needed, it would have been requested by now. Thanks for the suggestion, but I think we're taking a pass. Imzadi 1979 → 00:57, 20 March 2011 (UTC)

Add 'divisions' entry for Ontario

Ontario uses Counties, Municipalities, Regions, Districts, District Municipalities, and Regional Municipalities. The latter two can be covered by the former, but unfortunately infobox road is not set up to allow the use of more than one of these parameters at a time. This doesn't work in Ontario, so this code will allow ONLY Ontario roads to have a "Divisions:" entry that does away with the need for separate headers.

|label68 = Major cities:
|data68  = {{#if:{{{cities|}}}|{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{cities|}}}|}}|}}
|label69 = Towns:
|data69  = {{#if:{{{towns|}}}|{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{towns|}}}|}}|}}
|label70 = Villages:
|data70  = {{#if:{{{villages|}}}|{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{villages|}}}|}}|}}
|label71 = {{#ifeq:{{{country|}}}|GBR|[[Primary status|Primary<br>destinations]]:|Primary<br>destinations:}}
|data71  = {{#if:{{{destinations|}}}|{{#ifeq:{{Infobox road/hide/destinations|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{destinations|}}}|}}|}}
<!-- HIGHWAY SYSTEM -->
|header72= {{#if:{{{state|}}}{{{province|}}}{{{country|}}}{{{type|}}}{{{system|}}}|{{#switch: {{{country|}}}
 |GBR|IRL= Road network
 |#default=Highway system}}
}}
|data73  = {{{system|}}}
<!-- LINKS AND BROWSE SECTION -->
|below   = {{#if:{{{state|}}}{{{province|}}}{{{country|}}}{{{type|}}}|{{#ifeq:{{Infobox road/browselinks/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|province={{{province|¬}}}|state={{{state|¬}}}|type={{{type|}}}|county={{{county|}}}|route={{{route|}}}}}|none||<p style="margin-top:0">{{Infobox road/browselinks/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|province={{{province|¬}}}|state={{{state|¬}}}|type={{{type|}}}|county={{{county|}}}|route={{{route|}}}}}</p>}}}}<!--
-->{{#if:{{{previous_route|}}}{{{browse|}}}|<table style="width:100%; background:none; border-collapse:collapse">{{#if:{{{previous_route|}}}|
{{Infobox road/meta/browse|country={{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|state={{{state|¬}}}|province={{{province|¬}}}|county={{{county|}}}|previous_type={{{previous_type|}}}|previous_route={{{previous_route|}}}|browse_route={{{browse_route|}}}|next_type={{{next_type|}}}|next_route={{{next_route|}}}|previous_dab={{{previous_dab|}}}|next_dab={{{next_dab|}}}}}|}}
{{#if:{{{browse|}}}|{{{browse}}}|}}</table>|}}
}}{{#if:{{{type|}}}|{{#if:{{{state|}}}{{{province|}}}{{{country|}}}||[[Category:Infobox road transclusion errors|# {{PAGENAME}}]]}}}}{{#if:{{{spur_of|}}}|{{#if:{{{spur_type|}}}||[[Category:Infobox road transclusion errors|$ {{PAGENAME}}]]}}}}{{Infobox road/meta/errors|country={{{country|}}}|province={{{province|}}}|state={{{state|}}}|{{{countries|}}}|{{{regions|}}}|{{{provinces|}}}|{{{rural_municipalities|}}}|{{{cities|}}}{{{towns|}}}{{{villages|}}}|{{{destinations|}}}|{{{tourist|}}}|{{{states|}}}|{{{photo|}}}}}{{#if:{{{header_color|}}}{{{header_type|}}}{{{map_custom|}}}{{{marker_image|}}}{{{name|}}}|[[Category:Infobox road temporary tracking category 1|{{#if:{{{header_color|}}}|1}}{{#if:{{{header_type|}}}|2}}{{#if:{{{map_custom|}}}|3}}{{#if:{{{marker_image|}}}|5}}{{#if:{{{name|}}}|6}} {{PAGENAME}}]]}}<noinclude>
{{Documentation}}
</noinclude>

change to

|label68 = Divisions:
|data69  = {{#if:{{{divisions|}}}|{{#ifeq:{{Infobox road/hide/divisions|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{divisions|}}}|}}|}}
|label69 = Major cities:
|data69  = {{#if:{{{cities|}}}|{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{cities|}}}|}}|}}
|label70 = Towns:
|data70  = {{#if:{{{towns|}}}|{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{towns|}}}|}}|}}
|label71 = Villages:
|data71  = {{#if:{{{villages|}}}|{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{villages|}}}|}}|}}
|label72 = {{#ifeq:{{{country|}}}|GBR|[[Primary status|Primary<br>destinations]]:|Primary<br>destinations:}}
|data72  = {{#if:{{{destinations|}}}|{{#ifeq:{{Infobox road/hide/destinations|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{destinations|}}}|}}|}}
<!-- HIGHWAY SYSTEM -->
|header73= {{#if:{{{state|}}}{{{province|}}}{{{country|}}}{{{type|}}}{{{system|}}}|{{#switch: {{{country|}}}
 |GBR|IRL= Road network
 |#default=Highway system}}
}}
|data74  = {{{system|}}}
<!-- LINKS AND BROWSE SECTION -->
|below   = {{#if:{{{state|}}}{{{province|}}}{{{country|}}}{{{type|}}}|{{#ifeq:{{Infobox road/browselinks/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|province={{{province|¬}}}|state={{{state|¬}}}|type={{{type|}}}|county={{{county|}}}|route={{{route|}}}}}|none||<p style="margin-top:0">{{Infobox road/browselinks/{{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|province={{{province|¬}}}|state={{{state|¬}}}|type={{{type|}}}|county={{{county|}}}|route={{{route|}}}}}</p>}}}}<!--
-->{{#if:{{{previous_route|}}}{{{browse|}}}|<table style="width:100%; background:none; border-collapse:collapse">{{#if:{{{previous_route|}}}|
{{Infobox road/meta/browse|country={{Infobox road/meta/mask/country|{{{state|}}}{{{province|}}}|{{{country|}}}}}|state={{{state|¬}}}|province={{{province|¬}}}|county={{{county|}}}|previous_type={{{previous_type|}}}|previous_route={{{previous_route|}}}|browse_route={{{browse_route|}}}|next_type={{{next_type|}}}|next_route={{{next_route|}}}|previous_dab={{{previous_dab|}}}|next_dab={{{next_dab|}}}}}|}}
{{#if:{{{browse|}}}|{{{browse}}}|}}</table>|}}
}}{{#if:{{{type|}}}|{{#if:{{{state|}}}{{{province|}}}{{{country|}}}||[[Category:Infobox road transclusion errors|# {{PAGENAME}}]]}}}}{{#if:{{{spur_of|}}}|{{#if:{{{spur_type|}}}||[[Category:Infobox road transclusion errors|$ {{PAGENAME}}]]}}}}{{Infobox road/meta/errors|country={{{country|}}}|province={{{province|}}}|state={{{state|}}}|{{{countries|}}}|{{{regions|}}}|{{{provinces|}}}|{{{rural_municipalities|}}}|{{{cities|}}}{{{towns|}}}{{{villages|}}}|{{{destinations|}}}|{{{tourist|}}}|{{{states|}}}|{{{photo|}}}}}{{#if:{{{header_color|}}}{{{header_type|}}}{{{map_custom|}}}{{{marker_image|}}}{{{name|}}}|[[Category:Infobox road temporary tracking category 1|{{#if:{{{header_color|}}}|1}}{{#if:{{{header_type|}}}|2}}{{#if:{{{map_custom|}}}|3}}{{#if:{{{marker_image|}}}|5}}{{#if:{{{name|}}}|6}} {{PAGENAME}}]]}}<noinclude>
{{Documentation}}
</noinclude>

-- ʄɭoʏɗiaɲ ^τ _¢ 18:38, 16 April 2011 (UTC)

 Done You need to sort out {{Infobox road/hide/divisions}} though. -- WOSlinker (talk) 18:46, 16 April 2011 (UTC)

{{editprotected}}

I made a minor mistake in the last code which prevents this from working. This:

|data69  = {{#if:{{{divisions|}}}|{{#ifeq:{{Infobox road/hide/divisions|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{divisions|}}}|}}|}}

Needs to be changed to date68:

|data68  = {{#if:{{{divisions|}}}|{{#ifeq:{{Infobox road/hide/divisions|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{divisions|}}}|}}|}}

Which should fix it for good :) - ʄɭoʏɗiaɲ ^τ _¢ 21:27, 30 May 2011 (UTC)

 Done -- WOSlinker (talk) 22:08, 30 May 2011 (UTC)

removing broken images

The infobox on Autostrada Catania-Siracusa has a broken image link to the file AutostradaA.CT-SR Italia.svg. I haven't been able to figure out how to remove it. Nick Number (talk) 20:14, 16 June 2011 (UTC)

Set |marker_image=none -- WOSlinker (talk) 20:45, 16 June 2011 (UTC)

Ok, thanks. Nick Number (talk) 23:38, 16 June 2011 (UTC)

Add Austria to states subtemplate

Could AUT be added to the no line on Template:Infobox road/hide/states? –Fredddie™ 17:08, 6 July 2011 (UTC)

 Done -- WOSlinker (talk) 17:29, 6 July 2011 (UTC)

Edit request from Imzadi1979, 14 August 2011

Pleas synchronize Template:Infobox road/meta/colors/sandbox to Template:Infobox road/meta/colors. This will set Italy's green color to work on the autostrade only, and set the strada statale to blue. It will also enable a gray shade for former highways using a header_type of "former" or "decommissioned"

Imzadi 1979 → 02:58, 14 August 2011 (UTC)

I copied over the parts you mentioned for Italy, former & decommissioned. There were other changes in the sandbox too but I didn't copy those over. -- WOSlinker (talk) 08:36, 14 August 2011 (UTC)

Related question: Is the decommissioned header type set up in the US? The decommissioned/former header type is not mentioned in the template documentation. -- LJ ↗ 09:24, 14 August 2011 (UTC)

It's set up for al countries, like historic and UC, it's not country-specific at all. I did not add it to the documenation until it was activated. Adding |header_type=former to U.S. Route 16 in Michigan worked just as planned. Imzadi 1979 → 21:03, 14 August 2011 (UTC)

Edit request from Imzadi1979, 20 September 2011

Sync over the code from template:infobox road/sandbox. The change being made is that if |deleted= or |decommissioned= are used, setting a date/year where a road designation was removed, then the headers will automatically switch over to the gray color without |header_type=former being explicitly defined.

Imzadi 1979 → 23:39, 20 September 2011 (UTC)

 Done -- WOSlinker (talk) 20:20, 23 September 2011 (UTC)

US banner in Nevada

Can the template be changed for Alternate U.S. Routes in Nevada to display the "ALT" banner instead of the "ALTERNATE" banner currently used. Nevada only uses the short-form ALT banner in its signing. {{jct}} already reflects Nevada usage. Thanks. -- LJ ↗ 14:36, 27 September 2011 (UTC)

Clarified request-- LJ ↗ 10:18, 4 October 2011 (UTC)

On {{Infobox road/banner}}, replace

|US-Alt|US 1926-Alt|US 1948-Alt|US 1961-Alt={{#switch:{{{state}}}
 |DE|MD|SC|WV=Alt plate.svg
 |#default=Alternate plate.svg

with

|US-Alt|US 1926-Alt|US 1948-Alt|US 1961-Alt={{#switch:{{{state}}}
 |DE|MD|NV|SC|WV=Alt plate.svg
 |#default=Alternate plate.svg

This should cover LJ's request. –Fredddie™ 21:35, 4 October 2011 (UTC)

Change made. Thanks for doing the coding Fredddie. Please let me know if this broke anything as I have to run along. Dave (talk) 16:50, 5 October 2011 (UTC)

Thanks all. -- LJ ↗ 11:07, 6 October 2011 (UTC)

Adding states= to Mexico

Would someone please add MEX to the no line on {{Infobox road/hide/states}}. Federal Highways are analogous to US Highways, so we should be allowed to use states on generic article pages. –Fredddie™ 21:00, 29 October 2011 (UTC)

Done Anomie⚔ 02:29, 30 October 2011 (UTC)

Thanks. –Fredddie™ 03:13, 30 October 2011 (UTC)

Edit request from , 8 November 2011

Ok, to address an issue on M-185 (Michigan highway), and simplify the coding a bit, let's change:

|data21  = {{#if:{{{beltway_city|}}}|[[Beltway]] around {{{beltway_city}}}|}}
|data22  = {{#if:{{{orbital|}}}|[[Orbital road|Orbital]] around {{{orbital}}}|}}

to:

|data21  = {{#if:{{{beltway_city|}}}|[[Beltway]] around {{{beltway_city}}}|}}{{#if:{{{orbital|}}}|[[Orbital road|Orbital]] around {{{orbital}}}|}}{{#if:{{{loop|}}}|[[Loop road|Loop]] around {{{loop}}}|}}

Imzadi 1979 → 03:05, 8 November 2011 (UTC)

Done seems sensible. Anomie⚔ 03:16, 8 November 2011 (UTC)

Error report

The code that links the "road shield" is not working for B1159 road.

The shield exists, see File:UK road B1159.svg

-Arb. (talk) 23:07, 12 November 2011 (UTC)

 Done. Thanks for catching my error! –Fredddie™ 23:13, 12 November 2011 (UTC)

Infobox road/banner

If you search for "= ", that is an equal sign followed by a space, the space is not rendering correctly. The space is valid, so it must be either &#32 ; or an underscore. Thanks in advance. –Fredddie™ 00:35, 29 December 2011 (UTC)

 Done --Rschen7754 03:42, 29 December 2011 (UTC)

terminus_a versus end_a

Could end_a be aliased to terminus_a, and the same for end_b? I would do it, but I can't figure out the coding. Thanks. --Rschen7754 10:22, 3 January 2012 (UTC)

Ditto all of the other terminus* parameters for the various sections, like terminus_a1 would need an end_a1, etc. Imzadi 1979 → 10:27, 3 January 2012 (UTC)

There's now something in the sandbox. -- WOSlinker (talk) 10:44, 3 January 2012 (UTC)

Looks good to me, but I think you might have missed adding "end_b1" through "end_b4" where needed. Unless I screwed up, I just added them. Imzadi 1979 → 10:56, 3 January 2012 (UTC)

Yes, I had missed them. I'll leave it for Rschen to check & copy over to live. -- WOSlinker (talk) 12:41, 3 January 2012 (UTC)

 Done --Rschen7754 19:49, 3 January 2012 (UTC)

Infobox colours

The heading colours are all currently set in a single template called Template:Infobox road/meta/colors. Just wondering if it would be better to split in up into separate countries, similar to all the other settings? -- WOSlinker (talk) 10:04, 3 January 2012 (UTC)

At this point, that's probably a good since there are some ideas to expand the number of countries that have specific color schemes. Of course, if we don't have a country-specific subtemplate, we'd need the coding to use the current default. Imzadi 1979 → 10:33, 3 January 2012 (UTC)

I've made the changes in Template:Infobox road/meta/colors/sandbox and the testcases look ok. Also checked some of the other countries & they look fine as well. -- WOSlinker (talk) 23:09, 3 January 2012 (UTC)

I was under the impression that there were some subtemplates created. The US subtemplate, for instance, would be located at {{Infobox road/color/USA}}? –Fredddie™ 23:31, 3 January 2012 (UTC)

I swear to the Flying Spaghetti Monster I checked that link and thought it was red before I posted that. –Fredddie™ 23:32, 3 January 2012 (UTC)

The color subtemplates are all listed on Template:Infobox road/doc/country. -- WOSlinker (talk) 23:35, 3 January 2012 (UTC)

Neat, thanks. I had not noticed that that was added to the links template. –Fredddie™ 23:44, 3 January 2012 (UTC)

 Done This is now live. -- WOSlinker (talk) 18:26, 4 January 2012 (UTC)

Translations

Translations no longer work for any location that uses them. I looked over the code and couldn't see anything that stuck out at me. –Fredddie™ 04:47, 7 January 2012 (UTC)

 Done --Rschen7754 05:09, 7 January 2012 (UTC)

Infobox tracking category

We have Category:Infobox road temporary tracking category 1, which lets us know which transclusions of the template have "edge cases". The category is well sorted; I think it's great. I just wish the articles that use |marker_image=none were not lumped together with the articles that have hard-coded route markers. The sorting could be added to the unused anchor 4. It would look like this on the category page:

• 4: using |marker_image=none.
• 5: using {{{marker_image}}}. For articles where using {{{country}}}/{{{state}}}/{{{province}}} + {{{type}}} would generate the same result, that method should be used instead.

Any thoughts? –Fredddie™ 21:50, 28 December 2011 (UTC)

To do this, the following would be changed at the very bottom of the template, before the documentation template. –Fredddie™ 19:50, 7 January 2012 (UTC)

Change this:

{{#if:{{{header_color|}}}{{{header_type|}}}{{{map_custom|}}}{{{marker_image|}}}{{{name|}}}|[[Category:Infobox road temporary tracking category 1|{{#if:{{{header_color|}}}|1}}{{#if:{{{header_type|}}}|2}}{{#if:{{{map_custom|}}}|3}}{{#if:{{{marker_image|}}}|5}}{{#if:{{{name|}}}|6}} {{PAGENAME}}]]}}

To:

{{#if:{{{header_color|}}}{{{header_type|}}}{{{map_custom|}}}{{{marker_image|}}}{{{name|}}}|[[Category:Infobox road temporary tracking category 1|{{#if:{{{header_color|}}}|1}}{{#if:{{{header_type|}}}|2}}{{#if:{{{map_custom|}}}|3}}{{#if:{{{marker_image|}}}|{{#ifeq:{{{marker_image}}}|none|4|5}}}}{{#if:{{{name|}}}|6}} {{PAGENAME}}]]}}

 Done -- WOSlinker (talk) 20:53, 7 January 2012 (UTC)

state2 parameter

I would like to discuss adding a second state and province parameter passed through to the shieldmain and browselinks subtemplates. This would allow us to handle routes that are primarily in one state/province but cross into another, such as Connecticut Route 168 or Highway 17 (Alberta–Saskatchewan). If there is a difference in route nomenclature (Route X versus State Highway X), current practice (at least in USRD) is to give primacy to the longer state. As such, I don't think it's necessary to extend state2/province2 to the other subtemplates. Wondering what you all think about this. –Fredddie™ 01:42, 8 January 2012 (UTC)

Works for me. Imzadi 1979 → 01:43, 8 January 2012 (UTC)

I know there's British Columbia Highway 15 though. --Rschen7754 01:46, 8 January 2012 (UTC)

I think that's a case of how not to do it. –Fredddie™ 02:03, 8 January 2012 (UTC)

{{Infobox road/sandbox |state=CT |state2=MA |type=SH |route=168}} {{Infobox road/sandbox |province = SK |province2 = AB |type = Hwy |route = 17}}

I've made changes to the sandbox version to support state2/province2/county2/type2 params, so it now calls shieldmain twice, once for each state. Or is it going to be better with type=2state and just passing the state2 param through to shieldmain? -- WOSlinker (talk) 10:00, 8 January 2012 (UTC)

I like the fact you have the browselinks popping up twice! :) I'll leave it to you guys to figure out the exact implementation, but I like what I'm seeing so far. Imzadi 1979 → 10:23, 8 January 2012 (UTC)

It might be a good idea to not call the maint param at all for 2state/2prov. The CT 168 example is a bit misleading if you just want the Massachusetts part of the route. –Fredddie™ 12:54, 8 January 2012 (UTC)

Done that now. -- WOSlinker (talk) 13:10, 8 January 2012 (UTC)

Header colors

When the "historic" parameter is put into "header_type", the header color appears as dark brown with white lettering according to the template Template:Infobox road/meta/colors. However, if a "decommissioned" date is entered, the header-type parameter is overridden, and the header boxes appear as light gray. For historic roads like auto trails it would be better if they remain brown. The color should only be gray if the "header_type" is entered as "former" or "decommissioned." BTW, if "history" is used instead of "established" and "decommissioned", then the headers remain brown. — ★Parsa ☞ talk 23:35, 25 January 2012 (UTC)

I can't speak for others, but I am aware of this "bug". It has to do with the order of the parameters. The established/decommissioned parameters will override the header_type parameter because the template will not even check for a header_type parameter if decommissioned is set. –Fredddie™ 23:45, 25 January 2012 (UTC)

To fix this, we need to change a few things. This in the main template:

|headerstyle={{#if:{{{header_color|}}}|background:{{{header_color}}};|{{#if:{{{decommissioned|}}}{{{deleted|}}}|{{Infobox road/meta/colors|header_type=former}}|{{Infobox road/meta/colors|country={{{country|}}}|state={{{state|¬}}}|province={{{province|¬}}}|type={{{type|}}}|subtype={{{subtype|}}}|header_type={{{header_type|}}}}}}}}}

to:

|headerstyle={{#if:{{{header_color|}}}|background:{{{header_color}}};|{{Infobox road/meta/colors|country={{{country|}}}|state={{{state|¬}}}|province={{{province|¬}}}|type={{{type|}}}|subtype={{{subtype|}}}|header_type={{{header_type|}}}|deleted={{{decommissioned|}}}{{{deleted|}}} }} }}<!--closing for meta/colors call--> }}<!--closing for header_color if-->

and change {{infobox road/meta/colors}} to:

{{#switch:{{lc:{{{header_type|}}}}}
|under construction|const|uc=background:#fc6;
|historic|historical|hist|scenic=background:#704214; color:white;
|decommissioned|former=background:#AAA;
|#default={{#if: {{{deleted|}}} |background:#AAA; |{{#ifexist:Template:Infobox road/color/{{Infobox road/meta/mask/country|{{#ifeq:{{{state|}}}|¬||{{{state|}}}}}{{#ifeq:{{{province|}}}|¬||{{{province|}}}}}|{{{country|}}}}}
  |{{Infobox road/color/{{Infobox road/meta/mask/country|{{#ifeq:{{{state|}}}|¬||{{{state|}}}}}{{#ifeq:{{{province|}}}|¬||{{{province|}}}}}|{{{country|}}}}}|state={{{state|¬}}}|province={{{province|¬}}}|type={{{type|}}}|subtype={{{subtype|}}}|header_type={{{header_type|}}}}}
  |background:#cedff2;}}}}
}}

This should move the automatic coding for decommissioned highways from the main template to the subtemplate. The second part should update it so that if the main template is passing a deleted highway's date, it will check to make sure that the historic/etc header type isn't being specified; if it is, is uses that anyway and otherwise defaults to the gray. Imzadi 1979 → 23:53, 25 January 2012 (UTC)

Someone else should double check, but I saw a couple errors in these examples that I think I fixed. –Fredddie™ 23:59, 25 January 2012 (UTC)

Ok, someone double check the last change. Basically, what I did is that the color template will attempt to use the header_type, and if it needs to use the default, it will check if the deleted value is present. If so, it uses the gray; if not, it then uses the country subtemplates. This should mean that historic/scenic, under construction will all work first, and if they aren't specified, then if the highway has a deleted/decommissioned value we get the gray. If all else fails, then we get the test for country subtemplates before finally getting to the default blue. Imzadi 1979 → 00:47, 26 January 2012 (UTC)

Thanks guys. I didn't want to mess with these templates as they are so widely used. I'm glad you folks know how they operate. — ★Parsa ☞ talk 02:17, 26 January 2012 (UTC)

Just noticed this tonight on Port Kent and Hopkinton Turnpike. – TMF 10:39, 16 February 2012 (UTC)

Bug has finally been fixed. – TMF 12:32, 7 March 2012 (UTC)

Edit request

Per MOS:DASH, en dashes should not be spaced when used to show a range of years (e.g. 1971–2001, 1854–present, and so on). As such, please change

|data11 = {{#if:{{{established|}}}{{{formed|}}}|{{{established|}}}{{{formed|}}} – {{#if:{{{decommissioned|}}}{{{deleted|}}}|{{{decommissioned|}}}{{{deleted|}}}|present}}|}}

to

|data11 = {{#if:{{{established|}}}{{{formed|}}}|{{{established|}}}{{{formed|}}}–{{#if:{{{decommissioned|}}}{{{deleted|}}}|{{{decommissioned|}}}{{{deleted|}}}|present}}|}}

Thanks in advance, Jenks24 (talk) 17:08, 6 March 2012 (UTC)

Hmmm.... The problem is this change would then make all the more specific date ranges contravene MOS:DASH, as only number to number ranges should have an unspaced dash. I believe a workaround would be checking the content of the decommissioned variable to see if it is an integer, and making the dash unspaced if so or if no decommissioned date is entered (ie present)... - ʄɭoʏɗiaɲ ^τ _¢ 17:56, 6 March 2012 (UTC)

Actually, here we go. This will create a spaced dash if there is a space in the midst of the entry for decommissioned. If there is one a single term/number, or nothing is entered, it will produce an anspaced dash. This will also add the appropriate nonbreaking space before the spaced dash. (Note to Admin: Make sure you edit this page and copy the code from the edit window, so as to include the html characters) - ʄɭoʏɗiaɲ ^τ _¢ 18:18, 6 March 2012 (UTC)

|data11 = {{#if:{{{established|}}}{{{formed|}}}|{{{established|}}}{{{formed|}}}{{#ifeq:{{Template:Str find0|{{{decommissioned|}}}| }}|-1|–| – }}{{#if:{{{decommissioned|}}}{{{deleted|}}}|{{{decommissioned|}}}{{{deleted|}}}|present}}|}}

Oh, I hadn't realised that dates more specific than years are sometimes used. Thanks very much for your solution. Cheers, Jenks24 (talk) 18:33, 6 March 2012 (UTC)

Just something to keep in mind... if we start encouraging the use of {{start date}} and {{end date}}, floydian's code will stop working. Those are two templates used in infoboxes to generate dates with metadata about the start and end dates of a feature, something that's used in many other infoboxes. I would leave the template alone. Imzadi 1979 → 21:47, 6 March 2012 (UTC)

Grrr. Imzadi, your comments came 10 seconds too late. =-) I was already starting to implement the changes proposed above when your comment came in. I have undone those changes and the template is back to the pre-this discussion state. I'll be online for the next 15 minutes. If an alternate coding can be agreed upon, feel free to ping me to have the template updated.Dave (talk) 22:23, 6 March 2012 (UTC)

Alaska boroughs

I'm too tired to work out some code at the moment, but I'll leave it to others to figure out in the meantime; if I can, I'll try to do so later myself. In short, for Seward Highway, and others, we need a boroughs label instead of counties because Alaska has boroughs instead of counties. Maybe a switch if state=AK, the label switches? Imzadi 1979 → 12:14, 13 March 2012 (UTC)

How do we handle LA? --Rschen7754 06:06, 14 March 2012 (UTC)

Looking at the template code, line 66 of the template is the place that counties/parishes/municipalities (the last is for Puerto Rico) are handled with the code:

|label66 = {{#if:{{{counties|}}}{{{parishes|}}}{{{municipalities|}}}{{{districts|}}}|{{#if:{{{parishes|}}}|Parishes|{{#if:{{{municipalities|}}}|Municipalities|{{#if:{{{districts|}}}|Districts|Counties}}}}}}:}}
|data66 = {{{counties|}}}{{{parishes|}}}{{{municipalities|}}}{{{districts|}}}

I think that if we changed that to:

|label66 =  {{#if:{{{counties|}}}{{{parishes|}}}{{{municipalities|}}}{{{districts|}}}{{{boroughs|}}}|{{#if:{{{parishes|}}}|Parishes|{{#if:{{{municipalities|}}}|Municipalities|{{#if:{{{districts|}}}|Districts|{{#if:{{{boroughs|}}}|Boroughs|Counties}}}}}}}}:}}
|data66 = {{{counties|}}}{{{parishes|}}}{{{municipalities|}}}{{{districts|}}}{{{boroughs|}}}

that it would use a new boroughs parameter to change the label to "Boroughs" instead of "Counties". Then we'd just have to update the affected Alaskan articles to change the parameter name to override the label name. We will also need to update the code for the section header as follows:

|header61= {{#if:{{{counties|}}}{{{parishes|}}}{{{municipalities|}}}{{{districts|}}}{{{boroughs|}}}{{#ifeq:{{Infobox road/hide/countries|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{countries|}}}}}{{#ifeq:{{Infobox road/hide/regions|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{regions|}}}|}}{{#ifeq:{{Infobox road/hide/provinces|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{provinces|}}}|}}{{#ifeq:{{Infobox road/hide/ruralmuni|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{rural_municipalities|}}}|}}{{#ifeq:{{Infobox road/hide/cities|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{cities|}}}{{{towns|}}}{{{villages|}}}}}{{#ifeq:{{Infobox road/hide/destinations|{{{state|}}}{{{province|}}}|{{{country|}}}}}|no|{{{destinations|}}}|}}{{#ifeq:{{Infobox road/hide/states|{{{country|}}}}}|no|{{{states|}}}|}}|Location}}

Since I got the code figure out, I'll toss up the edit request tag now then. Imzadi 1979 → 12:27, 14 March 2012 (UTC)

 Done with a slightly shorter version of label66. -- WOSlinker (talk) 14:45, 14 March 2012 (UTC)

Alberta specialized municipalities and cities

Izmadi's request above is similar in nature to a portion of my past request in the archives here that was not processed partially due my explanation of the Alberta situtation being TL;DR. Perhaps this more concise request, worded similarly to the above, will better explain an infobox need for Alberta.

Alberta does not officially have counties (like most states) that make up its provincial fabric. Instead, it has four different types of municipalities that are at the county-equivalent level – municipal districts, improvement districts, special areas, and specialized municipalities. The province groups the first three as rural municipalities. The infobox now allows usage of the "rural_municipalities" parameter to satisfy the first three as a result from my last request (thank you again). This leaves the fourth and final type not yet accommodated.

To accommodate, I request that when "state=AB", the "municipalities" parameter's label switches from "Municipalities" to "Specialized municipalities".

If there is a concern about maintaining geographic contiguity among the specialized and rural municipalities along a route, switching the label from "Municipalities" to "Specialized and rural municipalities" instead would resolve this.

In addition, I request that when "state=AB", the "cities" parameter's label switches from "Major cities" to simply "Cities".

Note there are only 17 cities in Alberta. Given the low quantity, and that cities are not a tier below the specialized and rural municipalities (while towns, villages, and summer villages are)[7], I feel this request is reasonable. Also note that I am aware of WP:USRD/STDS, and am also aware that a similar Canadian standard to exempt all cities from the infobox has not been established.

Cheers, Hwy43 (talk) 05:45, 14 March 2012 (UTC)

I can get on board with "Specialized and rural municipalities" for cases when |province=AB as it keeps geographic continuity in place. That continuity is important to avoid false impressions of the geographic progression of a highway through the province. Imzadi 1979 → 12:13, 14 March 2012 (UTC)

As the coding is beyond me, can someone process the above request to change the |municipalities= default label of "Municipalities" to become "Specialized and rural municipalities" for cases when |province=AB on my behalf? Hwy43 (talk) 04:02, 26 March 2012 (UTC)

 Done. For Alberta, continue to use |rural_municipalities=, but it will switch the label to "Specialized and rural municipalities". Imzadi 1979 → 04:29, 26 March 2012 (UTC)

Thanks! Hwy43 (talk) 05:02, 26 March 2012 (UTC)

More routes?

Is there any way this could be expanded to 5 or more routes for roads like Arkansas Highway 131 (5 segments), Arkansas Highway 159 (8 segments), or Arkansas Highway 74 (8 segments)? Don't ask me why they don't just use separate numbers, either. Brandonrush (talk) 22:43, 15 April 2012 (UTC)

We had informally agreed that with more than 4 segments, an article is better off to use {{infobox road small}} for each segment in a separate section of the article, and to have the main template up top as a summary of the whole thing. Imzadi 1979 → 23:44, 15 April 2012 (UTC)

Edit request on 8 May 2012

There are rare cases where this would be useful, but I think it would be nice to include it all the same. Some roads have special restrictions or permit requirements, or they are regularly closed. For instance, all of Brockway Mountain Drive or Pierce Stocking Scenic Drive and part of H-58 (Michigan county highway) are closed during the winter for use by snowmobilers or skiers. Other roads in Australia (and they can't be the only ones) require permits to use. I'm proposing that we add the following:

|label8= Restrictions:
|data8= {{{restrictions|}}}

along with: inserting {{{restrictions|}}} after {{{spur_of|}}} in the |header1= field. (This second part is needed to ensure that the header would appear if the parameter is defined.)

That way we can note that a road has restrictions, such as the total or partial seasonal closures or permit requirements. What good is summarizing all of the information on where a roadway is, how long it is, and who maintains it, if a motorist can't use it?

Imzadi 1979 → 21:34, 8 May 2012 (UTC)

Agreed. I see another use for this, to include length, height or weight restrictions for some roads. However, I would like to see a discussion on how this should be handled in prose verses a table. I'd also like to see some discussion on what should verses should not be included. Do we have any guidance on that? I have worked on 4 articles with such restrictions and so far I've just handled it in prose. However I do see value in adding this to the infobox. Dave (talk) 21:38, 8 May 2012 (UTC)

I support adding the parameter. It may behoove us to ping the non-North American projects to see if there are any WP:ENGVAR concerns. Then leave it up to each project to see how it should be used. –Fredddie™ 22:02, 8 May 2012 (UTC)

As for the ENGVAR issue, the row label ("Restrictions:") shouldn't have any concerns attached to it. As for guidance as to content, I'd kick that to the wikiprojects. The examples I cited (BMD, PSSD, H-58) all list the restrictions in prose now because there was no other way to accomplish that. An infobox should be a summary of the article in brief, so ideally everything in it save the map should be duplicated in the prose of the article in some fashion, and at greater detail. Imzadi 1979 → 22:12, 8 May 2012 (UTC)

Done Anomie⚔ 04:24, 12 May 2012 (UTC)