Wikipedia talk:WikiProject U.S. Roads/Archive 16

Archive 10

←

Archive 14

Archive 15

Archive 16

Archive 17

Archive 18

→

Archive 20

infobox road option to allow user to specify shield size

The following discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Enough already. Consensus is not there. Closing this before it gets out of hand. --Rschen7754 03:49, 21 January 2010 (UTC)

At the present time, even if you can adjust the shield size displayed by the JCT template, you still have a problem with the shields displayed for the bottom "browse" routes. I have made some changes to the infobox road templates to allow the user to specify shield size. I thought I would post this for comments / consensus about this change. To illustrate the problem, I have set up examples here: User:Stmrlbs/sandbox/road There are examples using 4 roads. Each section starts with the "public" version (what is seen with the standard templates) followed by what the templates look like with the new infobox template. The first example illustrates the problem with small shield size with the Kawartha lakes roads. The following examples are to show there is no change when the shield size option is not used. The changed templates in my user space are:

• User:Stmrlbs/Template/Infobox_road
• User:Stmrlbs/Template/Infobox_road/browse
• User:Stmrlbs/Template/Infobox_road/browse_route
• User:Stmrlbs/Template/Infobox_road/ON_browse

stmrlbs|talk 01:38, 17 January 2010 (UTC)

Those shields are for purely illustrative purposes, and designed to enhance the text, not replace it. I understand that Floydian found one style of route marker shield in North American that doesn't display well under the default settings. That is unfortunate, and there have been attempts to solve that issue without resorting to template forking. The problems I have with the examples you give is

1. I'm not seeing the point of repeating the KLR 8 shield in smaller form at the bottom of the infobox. Normally, the only shields I've seen placed in that location are for in situations such as M-26 (Michigan highway) where two other designations redirect to the same article and the larger "chain" formed by using the browser would "intersect" the infobox a second, or third time.
2. FYI, the WV 10 Alt example would likely be handled by using {{infobox road small}} and not the larger infobox as shown. (This isn't an absolute, however.)
3. Otherwise you've faithfully duplicated the functions of the current infobox in your userspace version.
4. This whole solution likely has come about because of the unique situation of the "flowerpot" shape of Ontario's regional/county roads. A much simpler solution may be in those isolated cases to eliminate the shield graphic from the browse. They are a bit superfluous, especially when the middle graphic is an exact duplicate of the graphic at the top of the same infobox.
5. Another solution may be to make a variation of the flowerpot shield that expands the number as large as possible, eliminating the rest of the text. This variation could be universally used for all infobox browse instances of a regional road in Ontario, meaning that one set of graphics would be useable on a much larger set of articles than the current regionally-specific graphics families.

I understand that the in-template and external documentation of the {{infobox road}} and {{jct}} templates may not be up to your liking. That's a project that those who have helped develop these two inter-related families of templates should undertake at some point to rectify. I don't see that as justifying cases of "throwing the baby out with the bathwater" (template-forking). I appreciate the work you've done, but in the examples you've created, I don't see much changes, and a few of them, I see other solutions that could work instead of changing a highly-transcluded template. (WP:USRD has over 10K articles tagged under its "jurisdiction" alone.)

Do you have other situations that would illustrate the current, and a future implementation of the infobox. Maybe situations what would highlight any perceived deficiencies in the output of the current template at this time? Imzadi1979 (talk) 03:03, 17 January 2010 (UTC)

How is making a mod to infobox road "template forking"? I am not discussing any "new" templates. All the templates involved have been modified only to allow the user to specify a shield size if the default one is too small. Other than that, the infobox road template will work as it always has. stmrlbs|talk 03:22, 17 January 2010 (UTC)

Actually, the middle shield I can make bigger as it stands, this is to add the functionality to the sides. If it is useless, then why does the template have the parameter for placing a route in the middle? Finally, why go about looking for some alternative solution when this can simply be added to the current template without interference?

Template forking will become a reality if Rschen is going to lock down the templates and if editors won't accept changes that aren't meant to interfere with other uses of the template, because now not only are the templates complicated, but you have to duplicate the friggen maze in your own userspace in order to test out any changes to it, and then go through additional steps for it to be implemented. - ʄɭoʏɗiaɲ ^τ _¢ 04:07, 17 January 2010 (UTC)

stmrlbs: by template forking, I was referring to the {{jct}} vs. {{jcon}} issue. I mentioned that only because your examples in your sandbox deal with that. If you want to confine this discussion to the infbox only, please let me know. Based on the way you present your sandbox, I though you were including that here, I'm sorry.

Floydian: I don't know why that was implemented in the infobox, as I didn't develop it. Back when I started editing on WP heavily in 2006, my home state of Michigan had its own infobox, which was based on the one California had. Eventually, the functionality of the various separate templates was merged together, and from that, the jct template was also born. Maybe it was designed for situations like the M-26 article where the infobox has browsers for the articles in the chain adjacent to M-26, but also adjacent to the M-111 and M-206 redirects. Additionally, I guess I was mistaken on something there. For the M-26 example, I used the browse= parameter with {{mi browse}} to generate the additional lines, which is a different situation. Saying that, simply duplicating the same shield from the top of the box at the bottom of the box in a smaller form is a bit redundant. I see stylistically where it's going, but it's overkill considering that there shouldn't be so many junctions listed in the infobox to extend the length of the infobox down the page so far that both ends aren't visible on a normal monitor. (Yes, some maps cause the same effect though.)

I appreciate what you're trying to do, but we have three options now suggested for the situation where a ~25x20px graphic renders the number on the shield too small to be legible: 1) size parameters (hopefully with a default so that existing articles don't need to be updated to effect the change.) 2) eliminate the graphic in the affected situations. 3) a browse-only version of the graphic with a larger number and no text. The third option is similar to what happened in the US with the Interstate Highway shield. In the 1950s and 60s when the shields debuted on roadsides across the country, they listed the state name in the blue section above the number. Now they don't because the state DOTs have realized that by removing unnecessary information, it frees up that space to increase the size of the numeral. Taking this concept into this situation, something similar could be accomplished where a single set of flowerpot shield graphics could be produced without the text above and below the number, allowing the number to be larger on the shield. You've proposed option 1, and I've tossed out options 2 and 3. That's all.

Now, last point for now, rschen's internal motives aside, the pages involved needed protection. WP:USRD has over 10,600 articles tagged. For the state of Michigan alone, there are roughly 220 or so articles that aren't lists. That means that this infobox is very widely transcluded. (The lists use the small version of the infobox or none at all.) It is policy on Wikipedia to protect the editing of heavily transcluded templates. That's life here, sadly. One misplaced character, even in a good-faith edit has the potential to affect thousands of articles. I don't like that fact, but it is what it is, and we live with that. I don't develop templates beyond the subtemplates to localize stuff for the Michigan highway articles I write. Could the documentation be improve, yeah, it could. Maybe that's what's needed before any additional changes are made to this template. As for right now, based solely on the examples provided, I don't see any changes made. Maybe that's what was intended, but I'm putting out there a few options on other ways to solve the problem that the Ontario regional/county/municipal road shield is an odd shape compared to the other shields in use out there. Imzadi1979 (talk) 05:37, 17 January 2010 (UTC)

the first example (the Kawartha Lakes 8) was to show what the option could do - it contrasts the way the shields look now (so small you can barely see them) versus with the size option used to make them a legible size. The other examples are to show that the infobox road display is not affected if the option is not called, even though the new template is used in the examples (the display using my template looks the same as the display using the public version). The WV 10 example is as it appears on Wikipedia today. My new template does not change that. The JCT versus JCON has already been decided in a different discussion and has nothing to do with the changes I'm presenting here. stmrlbs|talk 06:29, 17 January 2010 (UTC)

I am hesitant to change the template to show larger shields for a couple of reasons:

1. We have been accused of violating the policy at WP:MOSFLAG with the shields many times. By enlarging the shields, we draw even more attention to them and this risk even more criticism.
2. So far I have defended the use of shields in the infobox by stating they do serve a purpose beyond just decoration, they help with identification. Specifically in the US (and Canada, and the EU, and many others) there could be multiple "highway 40's" in the same region, and this helps clarify is this I-40, US-40, or SR-40, etc. As such the shields only need to be large enough to discern the basic shape, not big enough to read the minor details. If we enlarge the shields it would be harder to argue compliance using this reasoning.
3. The point of the policy at WP:MOSFLAG is that icons should be placed where they add value, not just for decoration, and definitely not added where they could be a distraction. The larger the icon the more likely someone will complain the icon is distracting from the prose of the article. Dave (talk) 06:55, 17 January 2010 (UTC)

If you look at the examples, the KL shields are just being enlarged enough so that the writing is the same size as the other (US) shields. If the writing is legible in one shield, and that is ok as far as WP:MOSFLAG, then I don't see how making another shield just as legible suddenly violates the same policy. stmrlbs|talk 07:05, 17 January 2010 (UTC)

That is a valid point. Although there also is the potential for confusion as somebody might infer significance from the different sized shields. No matter what you do, I'm sure someone wont' like it =-) Dave (talk) 07:48, 17 January 2010 (UTC)

I'd also like to mention that when we are talking about the browse section at the bottom of infoboxes, the shape is not important; the number is. As it stands the default size is too small to discern the number. An increase of 4–6 pixels or so seems to make them visible. - ʄɭoʏɗiaɲ ^τ _¢ 08:20, 17 January 2010 (UTC)

And complying with the guidelines at MOSFLAG, the number is given immediately after the shield graphic (or in the case of the browse on the right immediately before) in the form of a wikilink to the corresponding article. This is how it works in the junction list and the infobox. The number in the graphic itself is slightly less important. I'm not being difficult here, I'm trying to play devil's advocate before we change something that potentially affects 10K+ articles. I'm not against the change, I just want it to be the right change, and people understand that this process exists because of the ramifications. Imzadi1979 (talk) 08:36, 17 January 2010 (UTC)

Because this makes the image more readable is not a valid reason.. Wikipedia has readers with varying monitor sizes, from a reader with state of the art graphics card with 2 32" flatscreens, to users on a outdated public computer with a 12"VGA monitor (read fixed 640x480 resolution). If you make it more readable on one, you will make it less readable on the other. Wikipedia has policies against forcing image sizes for that very reason (infoboxes are excepted for obvious reasons, but still should try to be a compromise between high resolution and low resolution displays). With that said, I'm not totally opposed to this, but just pointing out that that reason isn't the best way to justify the change, it would bolster the argument that the images are there for decoration, not to convey information. However, the argument that the images should be slightly larger size so the text size is the same across multiple shields is an easier argument to defend. Dave (talk) 19:50, 17 January 2010 (UTC)

Ooh, call it option 4... we increase all the shield sizes slightly? Imzadi1979 (talk) 08:38, 17 January 2010 (UTC)

I don't like this option at all since the infobox is big enough as it is. Having 25 or 30px high shields in the browse row in the US would disrupt the graphic balance of the infobox. I think the best option would be to store the image sizes in a new subtemplate that would specify a specific size for different states or countries. – TMF 08:51, 17 January 2010 (UTC)

As an addendum, if I had to choose between increasing shield sizes across the board or removing the shields, I would prefer removing the shields for the reason stated above. – TMF 09:02, 17 January 2010 (UTC)

This is not "increasing shield sizes across the board". The only shield sizes that will be affected are those transclusions of infobox road which use this option. At this time, the only roads affected are the Kawartha Lakes Roads. This is a smaller subset of roads, a more flexible and applicable subset, than saying all roads for a state or country have a certain shield size. Actually, imo, the whole display is easier on the eyes if the writing on the shields is uniform - or at least intellible so it doesn't leave the reader squinting. stmrlbs|talk 17:31, 17 January 2010 (UTC)

It's also not so I can puff them up to 50px square. Its to increase them to 22px from 18px. I don't need to use the middle browse section, that is simply something I've copied from other existing articles. Once again, this will not affect ANY articles until such time as an author chooses for it to affect it by adding a "size=" parameter. Don't make option 5: "Make a new template to avoid headaches since this one is locked-down" the preferable choice - ʄɭoʏɗiaɲ ^τ _¢ 17:50, 17 January 2010 (UTC)

When a shield image is placed next to an appropriate link, the two work in tandem to aid in recognition of the route/link in question. This works almost on a subconscious level, regardless of whether you can actually read all the text on the shield. If you start changing the size of the shields, this begins to upset the balance of graphical images in the infobox, especially if some shields "need" resizing while others don't. Raising shield sizes also increases the length of the infobox, which could get pretty long if multiple shields are present. My biggest concern about all this is potential for abuse. Who's to say how big the graphic should be for it to be readable? There will likely be debates on this size issue, and it's another thing to monitor on 10,000+ USRD articles alone. I'm sorry, but I just don't see the value in adding an optional parameter for increasing shield size. In my opinion, this has the potential to decrease consistency across articles, which is something we're trying to avoid with road articles. --LJ (talk) 23:12, 17 January 2010 (UTC)

Excellent point. Given the history we've seen with wikipedia road articles, I can guarantee this option will be abused, if available. One needs to look no further than the misuse of the now removed Major Cities section, the misuse of the map parameter in the infobox, the insertion of shields in article prose, and the obscene amount of overbolding in some articles to know that this also will be misused.Dave (talk) 23:19, 17 January 2010 (UTC)

Checking out Google Street View, a blank trapezoid with no county information would certainly not be out of place. This would even be similar to how King's Highway shields are displayed (File:Ontario 401.svg vs. File:Ontario 401.png). --Fredddie™ 23:56, 17 January 2010 (UTC)

If you are going to stamp out progress for the sake of a potential for abuse, then we should just lock down wikipedia all-together. This is for a minute increase that does not disturb the "graphical balance"' of the page. Blank shields are inaccurate, and the examples you presented use two versions of a single highway sign in Ontario: a marker and a trailblazer. - ʄɭoʏɗiaɲ ^τ _¢ 00:06, 18 January 2010 (UTC)

I agree with this 100%. The people mentioning MOSFLAG are a bunch of idiots. You may as well object to having a photo of the Empire State Building in the Empire State Building article. —Preceding unsigned comment added by 170.170.59.139 (talk) 17:21, 18 January 2010 (UTC)

Please read WP:HRT. Here's an analogy: We have a lot of security for important government buildings such as the U.S. Capitol, the Pentagon, and the White House since if they are attacked, a lot of things go wrong, and it affects everyone in the country. We don't have security for some random farm in the Midwest because if it gets destroyed, it only affects a few people. --Rschen7754 02:10, 18 January 2010 (UTC)

this is not about national security. This is about wikipedia articles about roads. We are talking about adding an option to make it possible for a few displays to increase the size of the shields for a few roads that are now practically unreadable by just a few pixels. I doubt that if someone is going to vandalize wikipedia, that they would go to go to the trouble of finding out the latest template options to do it. And.. even if someone "abuses it" or uses it mistakenly, I'm sure the people here would notice soon enough and revert the changes. stmrlbs|talk 02:33, 18 January 2010 (UTC)

stmrlbs: You missed the point of the analogy above. There are two issues at play here, and rschen was addressing the protection aspect of the situation. Please see WP:HRT for the reasons why this template was protected. If a user edits the main template code, over ten thousand articles will be sent through the job queue system for updating. If that edit is reverted, another ten thousand job queue requests will be added to the log. That is in addition to all the other job queue requests for the rest of the three million English Wikipedia articles. If the edit intentionally or unintentionally screws up the template, until the job queue finishes processing all of those requests, some part of the ten thousand articles will have screwed up infoboxes. As rschen stated in his analogy, there are certain parts of the world with higher security than others because of the possibility of collateral damage over a larger cross section. If an edit messes up a template that's transcluded on only a dozen pages, it's probably not going to be protected, unlike this one. Imzadi1979 (talk) 02:47, 18 January 2010 (UTC)

If one template causes that many problems when changed, then perhaps having different infobox roads for say, each country would be a more "secure" solution. After all, it sounds like the infobox template is pretty much frozen for US roads, since for the most part, there aren't display problems with the US roads like there are for some of the Canadian roads. stmrlbs|talk 03:16, 18 January 2010 (UTC)

No, we keep using the same template. This allows for simpler coding and consistency, while avoiding the confusion of over 180 templates that will slowly become different as changes are synchronized to some templates but not others. --Rschen7754 03:26, 18 January 2010 (UTC)

Then you don't stonewall changes that are unnecessary because your articles all work fine as is. - ʄɭoʏɗiaɲ ^τ _¢ 03:40, 18 January 2010 (UTC)

(ec) Until this one case scenario appeared (Ontario Regional/County/Municipal Roads) appeared, there wasn't any issue with the infobox in regards to Canadian roads articles. In fact, the infobox works fine in the other provinces of Canada, and for the rest of the Ontario Roads. The reason HRT exists is because of the potential damage that altering heavily transcluded templates can have consequences. We've offered other options, which neither of you appear willing to consider. Current consensus is not to make any changes, and until a new consensus is forged that's the status quo. I know I"m willing to consider options, and I've even suggested 3 viable options on how to deal with what is one class of roadway out of many, many classes of roadways that work with this template. BTW, when it was mentioned that Saskatchewan and Manitoba don't have counties, but instead rural municipalities, that request was easily coded as the only viable option. This case has multiple, viable options. Imzadi1979 (talk) 03:48, 18 January 2010 (UTC)

(ec)Summarizing what I see so far: Pro allowing custom size images:

• Shield can be adjusted to allow consistent size of numerals
• Will allow road articles in Canada to have "neater looking" infoboxes with more readable numerals in the shields.

Con allowing custom size images:

• May exacerbate the problems we've faced at WP:FAC and other venues regarding perceived violations of the spirit, if not the letter, of the WP:MOSFLAG policy. Related points where this policy would be involved:
  • May falsely imply significance in the different sizes of shields in the same infobox, when there is no significance to the size difference
  • The shields are being justified as not subject to the policy as they aid in identification. Such justification only requires the shield be large enough to identify shape, identification of the numeral is not required.
• Would cause the infobox to take up more space, which is already an issue with small articles, and viewing road article pages on low-resolution screens.
• Is prone to abuse based on past experience. (i.e. people using this to emphasize junctions they feel are more important, etc.)
• Inherent risk in changing a relatively stable template that is used on 10,000+ articles with little to no perceived benefit.
• The complaint is that the shields need to be enlarged due to smaller numerals used by some canadian provinces. Some US states also use smaller numerals (Utah and Nevada come to mind). I also see "barely readable numerals" on these articles: Nevada State Route 375, Utah State Route 201. Yet, these articles have passed reviews without this being an issue.

Am I missing anything? Cause if I'm not missing anything, I think I know which way I'm leaning. Dave (talk) 04:13, 18 January 2010 (UTC)

Could you please tell us your basis for "The shields are being justified as not subject to the policy as they aid in identification. Such justification only requires the shield be large enough to identify shape, identification of the numeral is not required."? When browse_route is to browse routes of the same type (and thus same shield shape), the shape means diddly-squat, only the number matters.

I'd also like to know your basis for "Would cause the infobox to take up more space, which is already an issue with small articles, and viewing road article pages on low-resolution screens."

Because based on my experience of actually playing with the sizes, it doesn't affect the width or the height of any article I'd use it within.

Your only point with weight is that this has the potential for abuse. Might I add that any user can edit wikipedia, and add a big 600 pixel picture of penis.jpg to an article? Do you REALLY think that vandalism is going to come in the form of adjustments to road infobox parameters? - ʄɭoʏɗiaɲ ^τ _¢ 04:17, 19 January 2010 (UTC)

Yes, the infoboxes on road articles can and have been abused many times before. As an example, check a fairly recent archive where it was decided the major cities should be cut out, as we were tired of fixing the problems with them being abused. An even more recent example is on the very page cited above where on Kawartha Lakes road articles the map parameter is being abused to insert an image instead of a map. Anybody who is denying that these shields can cause problems when reviewing road articles has never submitted a road article for WP:FAC. Check out the FAC reviews for most of the road articles, and "get rid of those damn ugly distracting shields" is a fairly common objection. What I am saying is based on past experience, not any desire to be an obstructionist. I came into this debate hesitant, but open to the idea. However, I've yet to see a convincing argument on the pro side on how this helps build an encyclopedia.Dave (talk) 17:28, 19 January 2010 (UTC)

Well, I've got to agree - some of the shields in Nevada State Route 375 and Utah State Route 201 are barely readable.. I don't think the shape is that apparent either. Hey, these might be a couple of roads that could use this new option! :) But, even comparing the shields: to I still have to say they are better than Kawartha. stmrlbs|talk 05:48, 18 January 2010 (UTC)

If the shields were the only way that routes were identified in the browse row, I'd say this is an issue, but since the main form of identification is the link, I don't see a glaring issue here. – TMF 06:26, 18 January 2010 (UTC)

A lot of the pages for these roads are "in progress"/"don't exist". You click on the link, and get zip. Besides, people will look at symbols before they look at a link. An image will draw the eye before a link with words. To have an infobox - a visual box - where most of the shield symbols are barely legible (if legible at all) is just crazy.. especially when just a few pixels makes such a difference in the user friendliness of the displays. Is a reader of wikipedia going to say, "Boy, I can't read a lot of what is on this page, but I'm sure glad they followed standards. Wouldn't want to see an infobox for Kawartha Lakes 5 pixels bigger than the infobox for LA". No, they are going to squint, then click on the symbol to see if it will enlarge to a bigger size (which is what is a common thing on the internet for small symbols). And, then, when they realize they can't make it out, they will probably move on to something that won't frustrate them. Like another page where they can make out the images. stmrlbs|talk 06:47, 18 January 2010 (UTC)

If you think my protection was in the wrong, then go to WP:RFPP and request that it be unprotected. Don't just sit here on this page and whine about it. --Rschen7754 07:04, 19 January 2010 (UTC)

who are you talking to? stmrlbs|talk 05:51, 20 January 2010 (UTC)

a better illustration of the problem

a rendering of the infobox road template using all standard road templates: commented out as the infobox template has been overhauled.

Different train of thought

The KL Road shields are PNG, while the vast majority of shields elsewhere are SVG. Would creating a whole new set of svg shields alleviate the readability issue? --Fredddie™ 06:18, 18 January 2010 (UTC)

Demonstration here: or --Fredddie™ 06:40, 18 January 2010 (UTC)

The SVG is definitely clearer. The wikipedia policy is that icon type images should be rendered in SVG, UNLESS they are copyrighted and are used under a claim of fair use. (The reason is that SVG has infinite resolution and fair use requires a low resolution copy). However, if the government of Kawartha Lakes is claiming copyright, we can only use the image for the article in question, not in the infobox of intersecting or adjacent highways. So provided their are no copyright issues, this is a obvious fix, regardless of what is decided about the size rendered.Dave (talk) 06:46, 18 January 2010 (UTC)

yes, I agree. that is much clearer. As far as the copyright question, Floydian would know more. stmrlbs|talk 07:12, 18 January 2010 (UTC)

If there are no objections, I'll make the rest of the shields tomorrow, using the KLR list as a guide to how many are needed. --Fredddie™ 07:21, 18 January 2010 (UTC)

The SVG version is designed differently than the PNG version, which might also be why it looks better. Do we know if the PNGs and/or SVGs were based off of any official design standard? If there is a government standard that can be followed, it probably should be--otherwise, by all means replace the PNG shields with SVGs. --LJ (talk) 10:16, 18 January 2010 (UTC)

Even if Kawartha Lakes was trying to claim copyright, the shield is a mere geometric shape with text, meaning it's too simple/unoriginal to be copyrighted. Thus it would be tagged {{pd-ineligible}}. —Scott5114↗ [EXACT CHANGE ONLY] 16:57, 18 January 2010 (UTC)

Shields are uploaded. I did a little research and found {{pd-textlogo}} the better choice. --Fredddie™ 22:43, 18 January 2010 (UTC)

No, creating malformed images in order to bypass the task of modifying your template (I say your, as it is clearly the property of WP:USRD now) is not the solution. The solution is to either A) Change the design of the template so that the size can be set individually for each jurisdiction instead of for one and for all, or B) face the facts that when you make this much of a headache, it is clearly appropriate (and soooo much easier) to create a new template that doesn't require the approval of the US roads wikiproject to modify. - ʄɭoʏɗiaɲ ^τ _¢ 03:45, 19 January 2010 (UTC)

What images are malformed? Imzadi1979 (talk) 03:54, 19 January 2010 (UTC)

The SVG images are better than the PNG images. The numbers are clearer and the resolution is better. ---Dough4872 03:57, 19 January 2010 (UTC)

SVG's will always appear clearer than png images that are downscaled. Png blurs the image smaller, svg redraws the image smaller. I plan on recreating the png's in svg form (in which case my svg's are much larger, and not shrunk as the pngs. See this image, for example). However, the number size issue would still remain. The only reason these svg's are clearer' is because the number is much larger and bolder than it appears on the sign. Better is rather subjective, and they are certainly not better in my eyes. - ʄɭoʏɗiaɲ ^τ _¢ 04:08, 19 January 2010 (UTC)

Well, I think the current SVGs are good enough as the reader can easily see the number. ---Dough4872 04:10, 19 January 2010 (UTC)

Just a quick question... what font are you guys using? If I'm not mistaked, Canada uses (or at least used to use) the FHWA Highway Gothic font on road signs. They're available online as the roadgeek fonts, and if the SVG has the text converted to a path in Inkscape or Illustrator, then they will render the type correctly on here. (If you don't convert text to a path, then the font changes to something generic on the wiki servers.) That typeface may make a lot of difference in terms of legibility. The DRR 2 shield that you showed us, Floydian, doesn't look like Highway Gothic, instead it looks like Helvetica. Now if the Canadian authorities no longer use FHWA, then nevermind, but I'm curious. What font did you use, Freddie? Imzadi1979 (talk) 04:22, 19 January 2010 (UTC)

I'm using Arial, which is correct in base. I then mold it around into the right proportions height/width wise. - ʄɭoʏɗiaɲ ^τ _¢ 04:44, 19 January 2010 (UTC)

I see what Floydian is saying. The shield created by Freddie is not the same as the shield created by Floydian. In addition to the svg format, the number is thicker, and the lettering is closer to the edges to allow for a bigger number - Floydian is saying that this is not what the real shield looks like, and that his image is based on the actual shield proportions/shape. You can see the difference here: or
Can an Floydian's png shield be converted directly to a svg form? (I am assuming that Freddie created the svg shield from scratch?) And that way we can see if the svg is still clearer with the shape and proportions of the real Kawartha Lakes shields? stmrlbs|talk 04:17, 19 January 2010 (UTC)

I created mine with Flash. I can remake them as svg versions. - ʄɭoʏɗiaɲ ^τ _¢ 04:44, 19 January 2010 (UTC)

The number in the current SVG could be adjusted to a narrower font. However, the font seems accurate for two-digit routes. ---Dough4872 04:20, 19 January 2010 (UTC)

I'd qualify them as WP:OR. They are inaccurate, and that is enough for me to not use them. - ʄɭoʏɗiaɲ ^τ _¢ 04:36, 19 January 2010 (UTC)

Well, there are variations in the styles of shields. Plus, how can this be "original research"? ---Dough4872 04:38, 19 January 2010 (UTC)

Because a shield was created without any sort of basis. It's the same as artist impressions of exosolar planets. They were fine, and then the topic came up when a picture of one was on the front page. The end result was that the drawings are original research as they are not based on any sort of measurements. This is much more open and shut than that case. - ʄɭoʏɗiaɲ ^τ _¢ 04:44, 19 January 2010 (UTC)

Using that same criteria, the .png shields you made are OR as well. --Fredddie™ 04:47, 19 January 2010 (UTC)

Not when they are based on the measurements in the Ontario Traffic Manual. - ʄɭoʏɗiaɲ ^τ _¢ 04:58, 19 January 2010 (UTC)

Please see the Ontario Traffic Manual Book 1A: "Illustrated Sign and Signal Display Index", page 82. Three points I will make here regarding the official source: 1) the MTO did NOT give detailed drawings like in the MUTCD does with US marker shields. 2) The drawing given in the OTM uses the FHWA font that you didn't use if you compare it to known font samples. 3) And I will emphasize this very politely, Floydian, you could not have created your shield set based on the OTM when I had to find you a link to it and give you the page number and the correct volume of the set of books to replace a self-published source for your FLC. The shields existed before I pointed out the existence of the source you now claim you used to create them. I call foul on your claim to have used a source to create them. Imzadi1979 (talk) 05:14, 19 January 2010 (UTC)

My apologies, I spouted the wrong name, as that has been more a focus for me as of late. What I have is a manual from a place called 'The Road Authority',[1] which deals with all of the materials handling for Ontario road construction. It has the sheet metal measurements for all 40 odd regions/counties/cities in Ontario with a "county" road system (The signs in each region have slightly different dimensions based on the name of the county, and are on average 1.1 times taller than they are wide). The example in the OTM is clearly outdated since it shows a sign for a county that hasn't existed in 40 years. - ʄɭoʏɗiaɲ ^τ _¢ 06:44, 19 January 2010 (UTC)

I looked through that "source" and did not find anything in there. I'd appreciate the exact link to the page that gives the specifications you used. Then, you should add those specs to the source section on all the graphics. Freddie has already sourced his graphics to a photo you uploaded, which incidentally matches the MTO's OTM. I'm calling your bluff. I want your exact source, otherwise your graphics are OR and his are not. Imzadi1979 (talk) 07:04, 19 January 2010 (UTC)

Well, regardless of what you think, a manual from the producers of the signs is far more reliable than a photo taken through my windshield. I also only linked to their website. The website doesn't host any of the apecs. - ʄɭoʏɗiaɲ ^τ _¢ 08:07, 19 January 2010 (UTC)

So, in short, you have no access to the specs either? Ok. —Scott5114↗ [EXACT CHANGE ONLY] 08:11, 19 January 2010 (UTC)

There IS a world outside of the internet you know? - ʄɭoʏɗiaɲ ^τ _¢ 18:13, 19 January 2010 (UTC)

Yes, but it's not as accessible to us, and paper copies of sign specs aren't exactly easy to come by in most cases. If you do have a paper copy of the specs you're going off of, would you upload a scan for us so we can all have a look at it and see what it actually says? You could upload it to an off-Wikipedia image hosting site, perhaps, or email it to one of us if copyright is a problem. Otherwise we're all going to remain in the dark here arguing about things nobody knows is true. —Scott5114↗ [EXACT CHANGE ONLY] 21:29, 19 January 2010 (UTC)

The tone of this conversation is getting rather unpleasant. It's clear this is a stalemate. May I suggest either, a) inviting people outside the project to comment (as we are citing WP:MOSFLAG as a relevant policy, perhaps advertise this discussion there? Although, we've tried that with mixed results.) b)call for a straw poll. Consensus appears to be against, however asking everybody to put their vote on record will help make sure. c) accepting that people on both sides are taking this way to personal, and backing away for a couple of weeks.

Remember this is an encyclopedia, not a roadgeek fan site, plenty of those exist elsewhere. If the article prose isn't FA quality, THAT's where the focus should be, not on the trivial details in the infoboxes or exit lists. Way to many people around here don't seem to understand that. And no, I'm not picking on one side, I'm seeing an escalation of hostility on both sides.Dave (talk) 08:26, 19 January 2010 (UTC)

Arbitrary break

Here's my problem in succinct terms. I've offered alternate ideas to the issue at hand. The problem is really very simple: the county/regional road marker in Ontario is an odd shape. The current PNGs called by the template just don't scale down well to the ~20px size used by {{jct}} and the browser in the infobox. One editor who's actively writing articles on that subject ran into the problem, and wanted a solution. That, in and of itself, is the sort of issue that anyone here at USRD would help any other of our fellow editors solve. (The fact that this concerns Canada would actually be irrelevant because it is still Wikipedia and good-faith questions get good-faith answers.) Solutions have been offered, and discounted on what appears to be flimsy logic and false information. That's offended me because not only have I tried to offer solutions, but I've found false information being used in support of promoting only one option above the other, valid, potential options to solve this issue.

Now as to the original problem at hand, the display of the shield graphics, we do have options.

1. Modify widely transcluded templates to allow shield sizes to be specified.
2. Modify the browser template not to call the shield in a specific instance.
3. Modify the browser template to call a different version of the shield graphic.

Consensus doesn't seem to be going for option 1 because of the potential for abuse in other, unintended circumstances. The full reasoning has been given elsewhere above already, but at this time, that option is a non-starter for the moment. Option 2 has not been discussed much yet. Option 3 has generated the most interest though, because it seems the most viable. Either the alternate versions of the shield graphic are the county/regional road "flowerpot" shape without text to allow the number to expand in size, or as it could be, the fonts used for the current PNGs could be incorrect and the correct fonts help solve the issue.

Whatever solution is picked, there's a points to consider. At 20px, the word "INTERSTATE" at the top of the Interstate Highway shields is not legible. That is not a concern because the shape and color of the shield is distinctive enough. Only the Ontario county/regional roads use this version of a trapezoid shape. As long as the shape is apparent, a number on that shield is visible, and the link next uses the correct number, the meaning of the (shield) + (link) assembly will be clear. No change can be made to the templates unless there is consensus to support the change before an administrator can implement it. That's Wikipedia policy.

That's my take on things. Imzadi1979 (talk) 22:02, 19 January 2010 (UTC)

Isn't option 3 already in use in some parts of the world? In fact in Ontario road articles? (the 20px versions do look different then the full size shields). There is another benefit to option 3, it would allow images to be used in British Columbia, where the full size shield contains copyrighted elements, but a miniature version could be a simplified without the copyrighted elements. Dave (talk) 22:38, 19 January 2010 (UTC)

There is also a fourth option: taking the forced size parameter set in Template:Infobox_road/browse_route and moving that little snippet into a new subtemplate that uses a switch option to set sizes depending on the route type and place. This stamps out the potential for abuse. - ʄɭoʏɗiaɲ ^τ _¢ 22:46, 19 January 2010 (UTC)

That is a modification to the first option, which addresses the potential for abuse. However, this does not address concerns with that option that involve the issues from having different sized, larger size and redundant shields in the infobox. Dave (talk) 23:00, 19 January 2010 (UTC)

You say bigger as if its a noticeable size increase to go from 18px by 19px to 22px by 22px? If they are redundant (I don't believe they are, as people are more familiar with seeing the shields), then they should be removed outright. - ʄɭoʏɗiaɲ ^τ _¢ 00:23, 20 January 2010 (UTC)

Option 1a, if it contained switches that changed the size in very specific instances, AND if those exceptions to the rule were discussed ahead of time, might be acceptable to me. The template would have to be protected so that changes without consensus could not be made. Having said that, I still think that in this situation, the better solution is related to the graphics used, not the templates that are calling them. Option 3 has other benefits outside Kawartha Lakes, in fact, as Dave says, all of British Columbia would benefit. Imzadi1979 (talk) 01:00, 20 January 2010 (UTC)

The Kawartha Lakes shields aren't copyright though, so why would we sacrifice accuracy for the sake of not modifying a template, when the change isn't something that will disturb the template? - ʄɭoʏɗiaɲ ^τ _¢ 02:38, 20 January 2010 (UTC)

In the case of the KL shields, there's a question about the accuracy of the shields you created. They look good, but PNGs don't scale well, at least not as well as SVGs will scale. Additionally, Canada has used the same FHWA typeface as the US, and your shields don't look that way. Unless and until any of us get specifications, the best source is the Ontario Traffic Manual and photos from in the field. Based on those, the SVG shields that Freddie created look more accurate. The BC shields, as well as Alberta would have copyright concerns, which is an issue we don't encounter in the US often except with regards to toll roads. In both cases though, switching to another set of shields looks to be the best answer at this time. (P.S. Once we get better specifications, the graphics can be replaced by uploading a new version over the old filename.) Imzadi1979 (talk) 03:17, 20 January 2010 (UTC)

Are the shields on Wikipedia supposed to be truer to the manual or what the signs actually look like on the highways. When I compare what is in the manual on page 82, it doesn't look the same as what I see for the county road sign in this photo [2]. Even the shape of the sign is a little different when I blew up the manual shield to match the photo. The base is a little narrower in the manual. The top Lettering is bigger in the manual, and are placed a little differently (closer to the edge in the photo). stmrlbs|talk 05:17, 20 January 2010 (UTC)

The images in the manual are very out of date and for a county that no longer exists. Signs with only numbers are used on street signs, where space does not permit and gantry signs on freeways, solely because the conditions (high speeds, low attention spans) call for it. The reassurance markers, which WP:USRP uses for thier articles, have the text (the visibility of which is unimportant, but the proportions are a different case). I used a similar photo for my design as well, more similar to the one in this photo[3]. Yeah, I have the specifications to back it up, but drawing programs are not autocad, and it is far easier to trace a photo than to use precise measurements in flash. I will create the svg versions of the Kawartha Lakes shields now that I have the programs to do so, and upload them. We will see if clarity is enough to improve the situation. - ʄɭoʏɗiaɲ ^τ _¢ 05:24, 20 January 2010 (UTC)

And now for the "damn kids get off my lawn" portion of the show

Did the U.S. recently annex Kawartha Lakes? If not, discussion should probably be held at WT:CRWP... —Scott5114↗ [EXACT CHANGE ONLY] 08:10, 19 January 2010 (UTC)

I think it was held here to find an admin to edit the template. However, if there are admins who monitor WT:CRWP, you are 100% correct.Dave (talk) 08:26, 19 January 2010 (UTC) what tells the admin to edit the template. The discussion was logically held here as this was a change to the entire template, and we use the template the most. That being said, it quickly went off onto other subjects. --Rschen7754 08:34, 19 January 2010 (UTC)

Can I really ask why a consensus needs to be reached on this? Before protection, we all just modified the template to the needs of the articles. People reverted it if it screwed up an article, and things worked out fine. Now it seems we need the approval of WP:USRD (which by the way, like any group of editors, you guys are going to band together) in order to modify it. I could take this to WT:CRWP and build consensus with me, myself and I, or I could just go throw {{editprotected}} on the template and request the changes be carried out by a neutral and uninvolved admin. - ʄɭoʏɗiaɲ ^τ _¢ 18:12, 19 January 2010 (UTC)

Consensus is the governing principle of Wikipedia, it's one of the 5 Pillars.Dave (talk) 18:26, 19 January 2010 (UTC)

Thanks for the introduction lesson. - ʄɭoʏɗiaɲ ^τ _¢ 23:23, 19 January 2010 (UTC)

The administrator is supposed to check for broad consensus before making an edit to a protected template. --Rschen7754 18:39, 19 January 2010 (UTC)

Yeah but the template was just protected, BY YOU! So basically, because of a self-governing decision by rschen, consensus with WP:USRD must be made before any country can change infobox road or jct? Thanks, but I'll just go make my own template now. - ʄɭoʏɗiaɲ ^τ _¢ 23:23, 19 January 2010 (UTC)

If you think my protection was in the wrong, then go to WP:RPP and request that it be unprotected. --Rschen7754 00:09, 20 January 2010 (UTC)

No I think this self-appointed bureaucracy is wrong. Where do I go for that? - ʄɭoʏɗiaɲ ^τ _¢ 00:18, 20 January 2010 (UTC)

... then go to Wikipedia:Dispute resolution, just as you would with any other dispute. --Rschen7754 00:27, 20 January 2010 (UTC)

Honestly? Dispute resolution over a shield? This is one reason why USRD is broken. While we've gotten into squabbles over some trivial stuff, this certainly takes the cake. CL (T · C) — 03:55, 20 January 2010 (UTC)

CL, USRD isn't broken. CRWP is. Historically any assistance that's been offered in the past has been rejected. That project has been in such disarray for so long that I don't even think the project functions anymore. It could be summed up that Floydian doesn't like Rschen, and he's blaming him for any number of reasons why his FLCs haven't passed, nor is this template immediately changed to suit him. Imzadi1979 (talk) 04:09, 20 January 2010 (UTC)

I don't think this project is broken at all. USRD members are contributing and offering solutions to reach consensus. --Fredddie™ 04:13, 20 January 2010 (UTC)

Okay, "broken" was certainly a huge exaggeration. The project is sound. However, periodically on this page you get these disputes that just create too much controversy, like shields. Of course, not the fault of USRD as well. Hmm... I'm having trouble putting what I'm trying to say in words. I suppose I'm directing this to Floydian: have we not offered viable solutions to help your project? Yes, some users here have gotten snippy. But, threatening dispute resolution is not the way to go. Granted, I've neglected reading the entire thread. I'm probably being a bit naive too following the break I took from the project. Let's just not turn this into another Arbcom. CL (T · C) — 04:49, 20 January 2010 (UTC)

(edit conflict)I don't blame Rschen for my list failing. I am angered at how last time I nominated it he hounded me around a for a bit. I won't speculate as to the reasoning nor continue to care about it. I have not been involved with the Canadian Roads project in the past. It irks me that this group has taken ownership of the templates. Yes I've had good solutions offered. I've had somebody make many many svg's to try and alleviate the problem. Do these solve the problem however? No.

I decided to check out articles for the systems in Europe. Sure enough, we have templates such as {{Infobox Bundesautobahn}} (Germany), {{Highway in Spain}}, {{Infobox Italian Motorway}}, {{Infobox European road}}, {{PRC Expressways}} (China), etc.

Other groups or lone editors have created their own templates to comply with the needs of the several dozen odd articles that use them. Things are simpler and easier to maintain with this method, and you don't get stupid scuffles like this, over a potential for vandalism and an unwillingness to bend. - ʄɭoʏɗiaɲ ^τ _¢ 05:18, 20 January 2010 (UTC)

The potential abuse question

I was talking to another editor about another idea for improving testing templates (in general - not just infobox road) and also about the problem of updating a heavily used template. He shared a method that he used to find people who used deprecated values of parameters. He would test the parameter for the deprecated value, and if the particular transclusion used it, the template would place that page in a category for deprecated values (to be fixed). We could do a similar thing for the size parameter. Test the parameter to see if the size is over a certain limit, and if so, put that page in a certain category to be "fixed". I can make this change to my test infobox road template this weekend so you can get a better picture of what this will do. What this will do is put on one category page any articles that are "abusing" the new size parameter of the infobox road template. stmrlbs|talk 06:06, 20 January 2010 (UTC)

But what if we don't want to add the parameter in the first place? This is a solution in search of a problem. In addition to this, we at the USRD project tend to get several poor editors who abuse template parameters (we've gotten people putting pictures in the map= parameter, for example. That's how bad it gets). I'm really loathe to introduce another one of these parameters to watch for abuse with - this just creates more work for us. --Rschen7754 08:50, 20 January 2010 (UTC)

Wow, thats awful vandalism. Taking advantage of a feature already encoded the same was as an image parameter to add an image instead of a map? What a world we live in. I mean, they totally should have just used the image para... oh wait. There is none. Huh. - ʄɭoʏɗiaɲ ^τ _¢ 20:38, 20 January 2010 (UTC)

That's not the point he was making. We decided as a project that we want a map in the infobox and images illustrating the other parts of the article, so that maps can be found in a consistent place. We have users on occasion who are not involved in the project as heavily not as careful with the infobox, misusing parameters to create odd duck articles that don't match the others, thus violating the Principle of least astonishment. —Scott5114↗ [EXACT CHANGE ONLY] 21:25, 20 January 2010 (UTC)

Wherein Scott5114 borrows a rhetorical point from NE2

I should note that this discussion really shouldn't be as heavily invested in by members of the Canada project as it is; the issues involved here are largely of style and do not materially improve the content. Canada is far behind the U.S. in terms of road article development. There are only nine articles rated GA (0.5%) and no articles exceed that standard. Nearly 78% of Canada is stubs (compared to 54% in the U.S.). Comparing the relative WikiWork statistics to CRWP, we get 5.686 for Canada and 5.195 for the U.S. That means that the average Canadian article is halfway between a stub and a start while the U.S. average article is just a bit worse than a start.

Furthermore, the articles involved are of low importance; Kawartha Lakes has a population density of 24.4 to the square kilometer, and the articles of contention are local city roads. The Kawartha Lakes articles are of exactly the same low-importance type that the U.S. project is currently phasing out. Attention should instead be focused on improving the provincial route articles as those cover more important roads and thus will be seen by more readers.

Rather than scrabbling amongst yourselves and international editors to modify a template for the sole purpose of making a minor stylistic improvement to a series of unimportant articles, effort should be applied to improving articles. This is a lesson that I believe the U.S. project is finally learning. Please don't consign your project to the backlogs, the masses of stubs, the contention that the U.S. project has gone through. Don't sacrifice article quality in favor of stylistic tumult. Learn from our mistake. —Scott5114↗ [EXACT CHANGE ONLY] 21:25, 20 January 2010 (UTC)

Move to close discussion

It is clear that there is consensus against adding the custom size parameters to {{Infobox road}}. I therefore move that we close this discussion as it is an obvious lack of consensus for the change. Of course, any party to this discussion can go to Wikipedia:Dispute resolution if they feel that this discussion was unfair. --Rschen7754 09:16, 20 January 2010 (UTC)

• Support closure as above. --Rschen7754 09:16, 20 January 2010 (UTC)
• Support closure — at this time the proposal to add additional parameters to the infobox template has not been supported. There are other options that are viable to resolve the immediate issue, and they need to be supprted first. Imzadi1979 (talk) 14:11, 20 January 2010 (UTC)
• Support closure this is going nowhere and the lone supporters of this have already indicated they are willing to develop their own template, which is fine with me. Dave (talk) 17:13, 20 January 2010 (UTC)
• Support closure There is an easier way to get around the custom_size issue that doesn't involve changing the base template. --Fredddie™ 21:57, 20 January 2010 (UTC)

a separate testing suggestion

Perhaps this group and the groups for non-US areas could put together a list of roads that use infobox in various ways and that are the most heavily viewed. That way, anyone modifying any of these templates would have varied set of roads for testing, instead of randomly picking up roads which may or may not be a good composite of varied infobox transclusions. There really isn't a good way on wikipedia (that I know of) to find all the variations of how a template is used. It is something that a group of experienced users could put together to improve testing and reduce problems with new changes to a heavily used template like infobox road. stmrlbs|talk 20:45, 17 January 2010 (UTC)

As far as I've seen, there aren't that many variations on how infobox road is used, other than the inclusion or exclusion of various parameters. There are some state-specific versions which call infobox road and fill certain parameters automatically.

A better suggestion would be to discuss first the proposed changes (or new template) in an appropriate forum. That way, editors who use the template can weigh in on whether the change is necessary, what problems it could create, and how to best go about implementing agreed-upon changes that won't break/disrupt the template or articles it's transcluded to. This is a better method because (1) other users are notified in a proactive manner ("This is what I'm thinking of doing to template X") instead of a reacting to a change ("This is what I did to template X"), and (2) if the change is ultimately unwanted, the person proposing the change hasn't wasted time coding something that won't be used. --LJ (talk) 23:37, 17 January 2010 (UTC)

This is a proposal for something that would be in addition to discussion - not in lieu of it. As has been repeatedly pointed out by the regular editors here, the infobox road template is used by over 10,000 pages. I think that creating a test list of roads for testing would improve any implementation of changes to this template. So, I am not proposing a "better method" than discussion, but proposing a way to better test any change discussed. stmrlbs|talk 00:51, 18 January 2010 (UTC)

Well, like I stated above, I don't think there are any real differences in the implementation of infobox road other than parameters used or the state-specific versions. So unless there are versions of the template I'm not aware of, putting together a list won't really help your case.

The reason that I mentioned discussion first is that you haven't really seemed to do that in the past, but rather gone ahead and did your own thing and then faced backlash when editors tried to indicate problems. {{jcon}} comes to mind, and the shield size issue is similar--compare to the {{infobox road small}} discussion above, which was discussed for a few days before TMF started on it. --LJ (talk) 02:29, 18 January 2010 (UTC)

Look at the history of Jcon - my name does not appear in the history. I had nothing to do with the creation of the template. However, I did defend back in NOVEMBER what Floydian was trying to do with the template, because of the problems that he had with the standard templates, and because his template did not interfere with any existing work. And, when the template was put in for TFD, consensus was to keep JCON. So, why is that entering into this discussion here? I think that there is even resistance to a suggestion for improving testing by just finding a few roads with a variety of parameter usage is telling, in that it says that the members here are more concerned about perceived past indiscretions than in trying to find a solution to a problem or considering a solution from someone who hasn't . I am now coming here to discuss changes to this template with this group, but I am regretting it, because it seems everyone wants to get in a lash rather than discuss what is on the table. stmrlbs|talk 02:58, 18 January 2010 (UTC)

Stmrlbs: First, let me apologize for my previous response. I recalled your name from the junction/jcon debates, but didn't immediately recall that it wasn't you behind creating that template. Yes, the consensus ended up being to keep the jcon template, but only after junction template was deleted. Second, I'm not trying to impede any attempts at testing changes to a template. I pointed out that there aren't actual variations in the template, only the degree in which parameters are utilized.

My point here is that having a list of infobox usage of certain parameters isn't necessarily constructive due to the possibility that changes will eventually be made and that list won't be updated. In my opinion, it is much more practical to discuss a proposed change, and other editors can chime in on how the change might affect infoboxes using certain parameters. In the discussion, you could ask for examples of articles that use various parameters based on whatever changes are proposed--this would be more practical than maintaining a set list which may or may not be updated. That's my reasoning behind my suggestion. I don't intend to comment further on this, and will not stand in the way of any requests to make a list of articles for testing purposes. --LJ (talk) 04:06, 18 January 2010 (UTC)

[undent] I'm not talking about a list of infobox parameters.. I'm just talking about putting together a list of roads that would give a well rounded test of the infobox template. A list like this:

1. Kawartha Lakes 8
2. Highway 2 (Ontario)
3. West Virginia Route 10 Alternate
4. Interstate 76 (west) (corrected)

that's it. Just a list of roads that use infobox in various ways. Then if a problem is found in a certain road, add it to the list of roads to test. A simple thing to create. stmrlbs|talk 06:07, 18 January 2010 (UTC)

I understand this is just a sample list, but I should note that I-76 is a dab page and WV 10 Alt. should be merged into WV 10 and use {{infobox road small}}. – TMF 06:22, 18 January 2010 (UTC)

the Interstate 76 was a typo on my part, and the WV 10 is an example of infobox where the spur parameters are used. stmrlbs|talk 06:57, 18 January 2010 (UTC)

I do think there is some value in having a group of test cases, but I think it's optimistic to say that we will be able to catch every possible error or bug in a proposed change to Infobox road by running it through a canned number of test cases. --Rschen7754 07:06, 19 January 2010 (UTC)

I never said that it would catch every error or bug. I said it would be a way to improve current testing of changes. stmrlbs|talk 06:11, 20 January 2010 (UTC)

Is there a way to generate random sampling of 5-10 pages in the mainspace that call {{Infobox road}}? While not perfect, it would at least make the test cases less canned. --Fredddie™ 00:37, 20 January 2010 (UTC)

Good idea. I was thinking more of finding articles that called infobox using different parameters. But also having a random sample would be good, too. stmrlbs|talk 06:11, 20 January 2010 (UTC)

As I recently learned in my software engineering class, a good way to get a test bank of cases is to make sure that every line of code is included in at least one test case - in other words, making sure that at least one element in the test bank covers each possible branch of the code. --Rschen7754 08:59, 20 January 2010 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made on the appropriate discussion page, such as the current discussion page. No further edits should be made to this discussion.

Another deletion discussion

Resolved

 – deleted and redirect created Imzadi1979 (talk) 04:08, 12 January 2010 (UTC)

See Wikipedia:Articles for deletion/Interstate 73 in Michigan. ---Dough4872 03:55, 5 January 2010 (UTC)

A mini version of {{infobox road}}

Resolved

 – Infobox created; changes to it can be suggested at Template talk:Infobox road small. – TMF 20:58, 11 January 2010 (UTC)

I was browsing through one of Erie County (New York)'s county route lists (namely List of county routes in Erie County, New York (1-32)) and I noticed that every entry has a full infobox, which is really excessive IMO. That led me to an idea: make a mini-infobox similar to {{shban}} or {{usban}} that could be used for each entry without crowding up the page. Shortly thereafter, I came up with the idea of making a mini version of {{infobox road}} and editing {{shban}}, {{usban}} and {{ibus}} to call the new template. Of course, this new infobox wouldn't be suitable for use as an article's main infobox, just for subentries within articles. A two-pronged question: 1) should we take this approach and 2) if so, how much information should the infobox display? – TMF 06:08, 6 January 2010 (UTC)

It doesn't seem like a bad idea to me. I think the values to include would be: shield & name (parameters available for custom shields/names), alternate name, length, date, and location and/or termini. Any more than that would defeat the purpose of using a small box. --LJ (talk) 06:52, 6 January 2010 (UTC)

I have long had the idea of creating a page with mini-articles for the secondary class Nevada State Routes in each county. Currently they are perma-stub articles and are slowly getting AfD'ed. IMO such as list of mini-articles is appropriate as NDOT clusters route numbers by county. Such a mini-infobox may come in handy for this. Keep in mind, this has been on my get around to it list for years.Dave (talk) 06:56, 6 January 2010 (UTC)

(EC) Dave, none of the Nevada articles have been put up at AfD for quite some time. However, I've also thought about combining some of the perma-stubs into list articles (especially those routes with no appreciable history). I'd agree that these mini infoboxes would be handy for such lists, as well as other lists, especially lists of business/bannered routes. --LJ (talk) 08:30, 6 January 2010 (UTC)

I'd say LJ's suggestions are good. I have the idea that location (for business loops and short routes) and termini would be mutually exclusive. If a route was long enough that it crossed out of a single municipality/location/county, then termini would be appropriate. Otherwise it would look too cluttered for the purpose of the mini-infobox. Imzadi1979 (talk) 08:16, 6 January 2010 (UTC)

Agreed. The mini-infobox should only accept input of either a location or termini. Once we get a shield, name, and 3-4 lines of parameters, the mini-infobox isn't so "mini" anymore. --LJ (talk) 08:30, 6 January 2010 (UTC)

I definitely think a mini-infobox would be useful in route articles that are merged to another article or a list, including bannered routes. Similar to {{usban}} and {{shban}}, the location and date should be included, in addition to termini only (no other junctions) and the length. This would keep the infobox at a suitable length. ---Dough4872 17:28, 6 January 2010 (UTC)

I tend to agree with the general consensus developing here. For me, I think it should have no more than the shield, the route number, a field for location, a field for when it existed, and possibly a field for length, which seems to go along with what's been considered above. I think that gives the reader enough of an overview without being excessive at the same time. The existence and length fields should be optional - assignment dates are unknown for 99% of county routes in the United States and I rarely see lengths for entries on bannered routes. If no one objects, I'll begin setting this infobox up in the next day or two. – TMF 04:15, 9 January 2010 (UTC)

Infobox is live at {{infobox road small}} – TMF 07:13, 10 January 2010 (UTC)

It's in use at U.S. Route 112#Suffixed routes for US 112S. Imzadi1979 (talk) 07:16, 10 January 2010 (UTC)

Bicycle routes?

Category:BicyclePA Routes Should these fall under USRD? Currently, they are. --Fredddie™ 05:38, 9 January 2010 (UTC)

I say no. They might be designated by a state DOT, but our primary purpose is vehicular transport, not bicycling. Imzadi1979 (talk) 05:46, 9 January 2010 (UTC)

I had created these articles a long time ago and at the time felt they would be appropritate for our project, as they were coordinated by PennDOT and have a lettering system, similar to numbered routes. In addition, most of these routes are along state highways. In addition, we have other bike routes that are tagged for USRD, such as United States Numbered Bicycle Routes, Delaware Bicycle Route 1, and North Carolina Bicycle Route 2. Maybe we should open a discussion to see if numbered/lettered bicycle routes should fall under the scope of USRD. ---Dough4872 16:02, 9 January 2010 (UTC)

USRD eligibility notwithstanding, should all these articles be merged into the list? --Fredddie™ 00:34, 10 January 2010 (UTC)

That could work, they have remained stubs for over two years since I created them. I will take care of the merge. ---Dough4872 00:39, 10 January 2010 (UTC)

I don't have a problem with these being under USRD's scope. Most Bicycle routs are non-notable and at best would merit a mention in a list type article. So it wouldn't be a maintenance burden. Plus the structure of the article will more closely resemble a road article than articles of almost any other project.Dave (talk) 00:45, 10 January 2010 (UTC)

I agree with Dave regarding the U.S. Bike Routes. On that note, though, since there are only two routes (1 and 76) I don't see why they couldn't be covered in the main article. – TMF 00:26, 12 January 2010 (UTC)

I would agree to a merge. ---Dough4872 00:29, 12 January 2010 (UTC)

Assessment question

The various Great Lakes Circle Tours are all assessed as Start-Class at the moment. Aside from cleaning up and fleshing out the prose in the RD sections, what else should be included to promote the quality assessments? I don't think a junction list would be appropriate given that these are multi-state/provincial tour routings. To keep them summarized at a decent level of coverage, then RDs are most likely going to be just better than turn by turn summaries of their routings, and if a reader really wanted better detail, the individual component highways will give better coverage anyway. The history isn't going to be much better than the formation dates, but again, any major routing changes will be in the component highways. I"m just looking for some ideas here as I work on cleaning up the articles. The Indiana section of the Lake Michigan Circle Tour was atrocious with duplicated references (ibid, op cite, etc) bulleted lists of attractions by community, second-person narratives, overlinking... but at the same time I want to include a bit more. Imzadi1979 (talk) 11:04, 9 January 2010 (UTC)

This reminds me a bit of the interchange discussion a little while ago. I would say a decent RD and a complete history of the byway would be enough to get C-Class if not B, as like you said a junction list would be incredibly cumbersome and redundant for the state highways along the byway. – TMF 00:30, 12 January 2010 (UTC)

Navbox formatting

After seeing this list Template:Matagorda County, Texas Highways, should we develop a standard for how navigation boxes look? I don't think there should be any shields on the navbox, unless there is a uniting route, like the I-80 shield on {{I-80 aux}}. --Fredddie™ 03:12, 10 January 2010 (UTC)

WP:NAV for reference. --Fredddie™

I believe that shields should not be illustrated for every route in the template as it makes it too cluttered. Recently, the shields were removed from {{NJ Expressways}}, and the current version looks cleaner than the older one. ---Dough4872 03:56, 10 January 2010 (UTC)

Also note that we have been criticized as a project for violating the spirit of WP:MOSFLAG with shield icons before. As such, I think we should be careful not to overuse them. Dave (talk) 20:29, 11 January 2010 (UTC)

Do you think we should set a guideline prohibiting non-uniting shields from navboxes? ---Dough4872 00:16, 12 January 2010 (UTC)

We definitely need some kind of guideline for navboxes, even if it's just a best-practice type of thing. Check out {{Warren County Highways}}, the layout of which is distinctly different than any other navbox I've seen. – TMF 00:23, 12 January 2010 (UTC)

WP:USRD/STDS already says do not overuse shields and lists some examples of when they are and are not appropriate. Perhaps just expand this? Dave (talk) 04:00, 12 January 2010 (UTC)

That would work. ---Dough4872 04:31, 12 January 2010 (UTC)

Merge discussion

Talk:El Cajon Boulevard --Rschen7754 20:24, 11 January 2010 (UTC)

County categories

Are we now categorizing state highway and state-detail articles by county? Interstate 96 (as a intrastate Interstate) has 10 county categories, plus several other categories related to the cities/regions of the state. I'm curious what the current preferences/standards are. The 10 counties would be overkill in my book if each county is already in the 3 regions of the state (West Michigan, Central Michigan, Detroit Metro). Imzadi1979 (talk) 14:01, 12 January 2010 (UTC)

It might be useful, but having dozens of county categories would probably be unwieldy. OK-3 would end up in 19 categories. —Scott5114↗ [EXACT CHANGE ONLY] 15:21, 12 January 2010 (UTC)

I think the county categories are useful, as a reader can find all the route articles within a specific category. However, there is an issue for routes that go through multiple counties. (Imagine how many categories Interstate 10 in Texas would be in!). ---Dough4872 16:33, 12 January 2010 (UTC)

I'm not sure if this is appropriate or not. However, I have seen non roadgeek wikipedia editors remove counties as categories from road articles with an edit summary of WP:OVERCAT. Dave (talk) 18:00, 12 January 2010 (UTC)

I-10 crosses 24 counties in Texas. I-96 is in 19 categories currently. As I said the 10 county categories duplicate the 3 regional categories because the county categories are subcategories of the regional categories. I-75 in Michigan would fall in 15 county categories, 4 regional categories, the 4 Great Lakes Circle Tours categories, plus categories for Interstates and the like. To keep from being unwieldy, I'd recommend that if a state has categories related to different regions of the state, that they're used instead of every single county. Imzadi1979 (talk) 18:37, 12 January 2010 (UTC)

That could work, but then there would be inconsistiency between articles, with some using county categories and others using regional categories. In addition, not every state has regional categories. ---Dough4872 19:48, 12 January 2010 (UTC)

I would think WP:OVERCAT#Intersection by location would be the most relevant policy here. I don't think we should be using the straight county category (or other geographical categories, for that matter) for road articles, unless there's something special about the road or the area the route traverses. I'm talking about a historical or cultural significance to the county/jurisdiction, something other than the fact that the article is about a road. However, if there is already an applicable "Roads in X County" or "Transportation in X jurisdiction" category, then that's fine to include--but let's not go creating such a category for every county. --LJ (talk) 21:21, 12 January 2010 (UTC)

In New York, every route is categorized by county. Of the state's 62 counties, 20 or so have "Transportation in..." categories. – TMF 23:00, 12 January 2010 (UTC)

I think I'm seeing a bit of a consensus forming here that I wouldn't be out of line to be bold and remove the county categories from the Michigan articles, and replace them with the regional categories Category:Upper Peninsula of Michigan, Category:Northern Michigan, etc. Only a few cities have their own categories like, Category:Transportation in Grand Rapids, Michigan etc. This would reverse this trend to WP:OVERCAT, especially the highways that traverse the lengths of either peninsula, but only cross one or two regional boundaries. Imzadi1979 (talk) 02:34, 13 January 2010 (UTC)

Yeah, if there are categories for regions of a state and the counties are subcats of that region category, replacing the county categories with the regional categories makes sense to me. No such categories exist in New York, which is why all categorization is done on the county level. – TMF 02:48, 13 January 2010 (UTC)

Which SH WPs are inactive?

I am proposing the demotion of all inactive state highway WikiProjects to task forces to cut down on the structure that we have to maintain (especially due to USRD losing activity over the years). Which projects do we think are inactive? The list to choose from is: California, Connecticut, Florida, Georgia, Illinois, Indiana, Iowa, Kentucky, Maryland, Massachusetts, Michigan Minnesota, Missouri, Nebraska, New Hampshire, New Jersey, New York, North Carolina, Ohio, Oklahoma, Oregon, Pennsylvania Rhode Island, Tennessee, Texas, Utah, Vermont, Virginia, Washington, West Virginia, Wisconsin.

Projects will be warned and given a chance to respond, and an official WT:USRD/SUB discussion will be launched before any project is actually demoted, so just because we say it is inactive here doesn't mean it will be demoted. --Rschen7754 (T C) 08:14, 24 December 2009 (UTC)

For my part, I think that California is active. :) --Rschen7754 (T C) 08:17, 24 December 2009 (UTC)

To be honest, I never got the point of having separate state level projects in the first place. Dave (talk) 08:52, 24 December 2009 (UTC)

New York is definitely active. – TMF 09:14, 24 December 2009 (UTC)

Oklahoma is active. —Scott5114↗ [EXACT CHANGE ONLY] 10:46, 24 December 2009 (UTC)

Jersey is obviously active,and so has Pennsylvania in the last few months, and concur with TMF and Scott above. Also Washington is as well.11:15, 24 December 2009 (UTC)

How are we defining active? I don't think one regular editor makes a project active. --Fredddie™ 14:27, 24 December 2009 (UTC)

New Jersey, New York, California, Utah, Washington and Maryland both have at least two active editors.Mitch32^{(A fortune in fabulous articles can be yours!)} 14:35, 24 December 2009 (UTC)

I agree and think we should only keep subprojects with at least two active editors, or other subprojects that have been recently active and have decent-written articles. The subprojects I would vote to keep are the ones Mitch listed in addition to OK, PA, and MI. The rest should probably be demoted to task forces. Personally, I feel all the projects should be demoted to task forces of USRD, as most discussions take place here. In addition, task force pages should be created for the states that do not have a WP. ---Dough4872 15:51, 24 December 2009 (UTC)

So far, we're left with the following as inactive: Connecticut, Florida, Georgia, Illinois, Indiana, Iowa, Kentucky, Massachusetts, Minnesota, Missouri, Nebraska, New Hampshire, North Carolina, Ohio, Oregon, Rhode Island, Tennessee, Texas, Vermont, Virginia, West Virginia, Wisconsin. (though are Maryland and Michigan really active?) Oregon has picked up a little bit of activity in the last few days, but I'm not sure it will last. --Rschen7754 (T C) 17:41, 24 December 2009 (UTC)

Yes on Maryland. My watchlist has edits daily if not hourly from roads. I think we can consider it active.Mitch32^{(A fortune in fabulous articles can be yours!)} 18:16, 24 December 2009 (UTC)

Texas is borderline active. One for sure active editor. One (me) normally active but working on another project attm. 25or6to4 (talk) 21:06, 24 December 2009 (UTC)

CT looks inactive - [5]. --Rschen7754 02:56, 27 December 2009 (UTC)

I would say demote it then. Maybe we should start a straw poll on which to keep and which to demote. ---Dough4872 03:01, 27 December 2009 (UTC)

We'll do that in a bit, after we notify the projects. --Rschen7754 03:51, 27 December 2009 (UTC)

FL has activity, but the wrong type - [6] - article quality is getting worse, not better. --Rschen7754 04:00, 27 December 2009 (UTC)

IL doesn't look that good. [7] --Rschen7754 04:33, 27 December 2009 (UTC)

IN has a lot of noise: [8] --Rschen7754 04:41, 27 December 2009 (UTC)

KY is ambiguous - just one day of active editing: [9] --Rschen7754 04:45, 27 December 2009 (UTC)

MA - no. [10] --Rschen7754 04:48, 27 December 2009 (UTC)

MO - no. [11] --Rschen7754 05:05, 27 December 2009 (UTC)

NE - no. [12] --Rschen7754 05:09, 27 December 2009 (UTC)

NH - no. [13] --Rschen7754 06:08, 27 December 2009 (UTC)

NC - not sure on this one: [14] --Rschen7754 06:27, 27 December 2009 (UTC)

OH - no. [15] --Rschen7754 06:33, 27 December 2009 (UTC)

TN - no. [16] --Rschen7754 06:46, 27 December 2009 (UTC)

VT - no. [17] --Rschen7754 06:48, 27 December 2009 (UTC)

VA - no. [18] --Rschen7754 06:49, 27 December 2009 (UTC)

WV - no. [19] --Rschen7754 06:50, 27 December 2009 (UTC)

WI - no. [20] --Rschen7754 06:51, 27 December 2009 (UTC)

Based on these recent changes, I would say the candidates for demotion would be CT, FL, IL, IN (a lot of the edits were minor fixes and the addition of a template taken to TFD), KY, MA, MO, NE, NH, NC (does not appear to have significant activity), OH, TN, VT, VA, WV, WI. We should send each of these projects a notice and take the demotion discussion to WT:USRD/SUB. ---Dough4872 17:24, 27 December 2009 (UTC)

First four projects (CT, FL, IL, IN) proposed. --Rschen7754 01:52, 28 December 2009 (UTC)

I will confirm that demotion of MA is indicated; I am the only editor that does much of anything (see below), almost always maps. I am the best person available to continue that map work, since I have already done maps for all of the major highways and most of the minor highways, and have been upgrading map labeling and detail from time to time as well, and I have the GIS and shields files for mapping set to go. I don't edit the project page, however. The need is for editorial work; I have done substantial work for a few of the highways but don't generally focus on roads writing. So, if MA is absorbed into USRD, which I think should be done, I would still be available to collaborate on maps and information if needed. Sswonk (talk) 02:08, 28 December 2009 (UTC)

Iowa can be speedily demoted to a task force. I asked the same question on September 19, and was the only person to answer. --Fredddie™ 04:04, 28 December 2009 (UTC)

We'll propose the demotion, but it still has to go through the typical procedure. --Rschen7754 04:54, 28 December 2009 (UTC)

I should have included User:Ktr101 in my comments about the Massachusetts project, as he has done a bit of work recently. I am dropping a brief note on the Ktr101's talk page pointing to this discussion. Sswonk (talk) 16:27, 28 December 2009 (UTC)

Got it. The Massachusetts Project is pretty active from what I have seen, but we only have ten participants. I know a lot of projects that are rather slow, but that's the price when you have ten people on the project. There seems to be a movement afoot on the project to merge a few articles in the state. These people aren't a part of the project, but are a part of this one. I would support keeping it, as I don't agree with a project having many task forces. It would also be odd to the outside observer to see state task forces or projects. Kevin Rutherford (talk) 17:17, 28 December 2009 (UTC)

Well, based on that I've stricken my support for demotion and am switching to a "neutral" stance at this point, leaning towards Kevin's position as he is obviously more active than I am at WP:MASH. Sswonk (talk) 19:10, 28 December 2009 (UTC)

I'm curious as to where the 10 number is coming from. There's only seven listed at the project page and all but two give their status as inactive or "semi-active". If there really were 10 people actively working on the project, there would be a lot more activity shown on the recent changes than what's shown above. There are states with only one or two participants that have more activity than MA. – TMF 19:47, 28 December 2009 (UTC)

Looking back at it, it appears as if I copied that. My bad, and I fixed it. I got the ten from a quick look at the project participant page. Andy 1One is active along with Tckma and Schzmo. We should contact them, since Polaron last updated the activity list in October, 2008. Kevin Rutherford (talk) 22:28, 28 December 2009 (UTC)

(od) But what about the activity level? The RC page showing all edits made to Massachusetts state highway articles in the last 30 days doesn't paint a very active picture, certainly not one like you're describing above. If JC and Rschen's quick cleanup edits are excluded (as they should be since those edits were made on a national level), there aren't very many diffs there at all. – TMF 23:47, 28 December 2009 (UTC)

Ah, you got me on that. When it comes to activity, do we know what "active" stood for on the participant page? I assumed originally that it meant activity in the project, but that is hard to discern with no inclusion criteria. I didn't mean to say that we are superactive, as I have no idea what is considered active on these projects. Kevin Rutherford (talk) 02:39, 29 December 2009 (UTC)

The most active projects today are CA, NJ, NY, and OK. --Rschen7754 18:28, 30 December 2009 (UTC)

Next five (IA, MA, NE, MO, KY) proposed for demotion. --Rschen7754 19:56, 30 December 2009 (UTC)

If a project has a route list, then you can use that along with Special:RecentChangesLinked to see the recent changes to that project's articles. I used that for WP:MDRD's recent changes link. As you can see, Maryland is active.-Jeff ^(talk) 19:55, 4 January 2010 (UTC)

Next four (NC, NH, OH, TN) proposed for demotion. --Rschen7754 21:33, 6 January 2010 (UTC)

Last 4 proposed for demotion. --Rschen7754 22:48, 15 January 2010 (UTC)

MFD

Resolved

 – Deleted. ---Dough4872 16:52, 17 January 2010 (UTC)

See Wikipedia:Miscellany for deletion/Wikipedia:WikiProject Ohio State Highways/Infobox. ---Dough4872 00:22, 17 January 2010 (UTC)

search box to search talk and all archives

The search box I added at the top of this talk page by the TOC will search this talk page, and all archives for WikiProject U.S. Roads, WikiProject Interstate Highways, and WikiProject U.S. Highways. stmrlbs|talk 08:09, 18 January 2010 (UTC)

A problem with infobox road small

Resolved

 – Fixed. ---Dough4872 03:06, 19 January 2010 (UTC)

I was trying to add a mini-infobox for CR 536 Spur at County Route 536 (New Jersey) but it had a problem displaying the shield image since bannered CRs in NJ use a custom marker image. Can a marker image parameter be added to the mini-infobox to remedy this problem? ---Dough4872 00:17, 19 January 2010 (UTC)

No need; simply changing the param values resolved the issue. See [21]. – TMF 02:02, 19 January 2010 (UTC)

Linking to USH in Alabama

Each US highway in Alabama carries an internal SR number. The SR articles mostly redirect to the US highway, that's not the issue. Is it necessary to link to both the USH and the SR? The infobox on Alabama State Route 13 demonstrates it pretty clearly. Perhaps {{Jct}} could be modified such that the SR designation is displayed in the USH link like this: US 43 (SR 13). --Fredddie™ 19:43, 19 January 2010 (UTC)

From my knowledge, AL does not sign the state routes along the US highways. Perhaps it is better to omit the state routes from the major intersections altogether. ---Dough4872 19:47, 19 January 2010 (UTC)

If the state route is completely concurrent with the U.S. route and the state route is never signed, I see no reason to link to the state route at all, in the infobox or junction list. (You'd think if they had to have concurrent state routes that Alabama DOT would give them the same number as the U.S. route to avoid confusion.) --LJ (talk) 21:21, 19 January 2010 (UTC)

I'd say a link is only necessary if the state route has its own article, meaning that it has an independent section somewhere (which the ones in AL may or may not have, I don't know - my experience on this issue is limited to a similar scenario in TN). For the ones that don't have any independent sections, the state route number just redirects to the USH page, so there's no point in linking to it. – TMF 21:32, 19 January 2010 (UTC)

IMO, an internal state route designation for a US or Interstate highway does not need any mention or links in the infoboxes, nav boxes or junction lists. A mere mention in the article prose somewhere that the portion in Alabama is internally designated XXX is sufficient. It probably should be in the lead as it is a redirect target. In this case there is an independent section, and the state route article should focus only on that independent section. IMO the infobox is terribly cluttered. Fire up the chainsaw. Dave (talk) 21:38, 19 January 2010 (UTC)

I have serious issues with including internal designations throughout the prose. One mention in perhaps the history section is fine, but to the general reader, internal designations are very unimportant, at least unimportant enough to exclude from the infobox. Just link the signed designations, IMO. CL (T · C) — 21:55, 19 January 2010 (UTC)

Yes. I think GA is the only state that actually signs their internal designations for U.S. and Interstate routes. All of others stay rightfully hidden. —Scott5114↗ [EXACT CHANGE ONLY] 21:58, 19 January 2010 (UTC)

Road lists at featured list removal

Three USRD-related lists have been nominated for featured list removal by Mitchazenia:

• List of highways in Hamilton County, New York (FLRC)
• List of highways in Essex County, New York (FLRC)
• List of highways in Warren County, New York (FLRC)
• List of state highways in Marquette County, Michigan (FLRC)

The nominator stated that the lists are "going to be axed after project consensus" (see discussion). Even though you all are probably aware of the lists' status, I invite you all to please join the discussion on whether this article meets the featured list criteria and to ensure that the consensus to remove the lists' featured status still exists. Articles are typically reviewed for two weeks; editors may declare to "Keep" or "Remove" the article's featured status. Thanks, Dabomb87 (talk) 04:43, 20 January 2010 (UTC)

P.S. The lists may be eligible for speedy removal if the aforementioned consensus is confirmed upon. Dabomb87 (talk) 04:43, 20 January 2010 (UTC)

TFD

Wikipedia:Templates_for_discussion/Log/2010_January_12#Template:Texas_state_highways --Rschen7754 08:02, 12 January 2010 (UTC)

It's been relisted: Wikipedia:Templates_for_discussion/Log/2010_January_20#Template:Texas_state_highways --LJ (talk) 08:40, 20 January 2010 (UTC)

WP 1.0 bot announcement

This message is being sent to each WikiProject that participates in the WP 1.0 assessment system. On Saturday, January 23, 2010, the WP 1.0 bot will be upgraded. Your project does not need to take any action, but the appearance of your project's summary table will change. The upgrade will make many new, optional features available to all WikiProjects. Additional information is available at the WP 1.0 project homepage. — Carl (CBM · talk) 03:27, 22 January 2010 (UTC)

AfD

Wikipedia:Articles for deletion/Patterson Creek Road Needs more input, I just relisted it. –Juliancolton | ^Talk 02:27, 23 January 2010 (UTC)

Closing out discussions at WT:USRD/SUB

Resolved

 – All pending discussions closed. --LJ (talk) 23:17, 24 January 2010 (UTC)

Would someone mind closing out the first four discussions at the top of the page? It has been the required 7 days. --Rschen7754 07:17, 4 January 2010 (UTC)

I closed CT, IL & IN. Florida seems a bit more debatable... --LJ (talk) 09:51, 5 January 2010 (UTC)

FL, IA, KY, MA, MO, and NE are ready to be closed. ---Dough4872 17:27, 7 January 2010 (UTC)

All closed. FL & MA were kept; the rest were demoted. --LJ (talk) 22:29, 7 January 2010 (UTC)

The next four can be closed out now. It has been over a week. ---Dough4872 16:34, 15 January 2010 (UTC)

NH, NC, OH, TN closed & demoted. --LJ (talk) 23:12, 16 January 2010 (UTC)

The last four can be closed out now. ---Dough4872 17:19, 24 January 2010 (UTC)

VA, VT, WV, WI closed & demoted. Looks like we're done with this now. --LJ (talk) 23:17, 24 January 2010 (UTC)

Can I get eyes on Arkansas, please?

Arkansas's article system is a complete mess. It's bad. If any state needs USRD help and attention, it's this one. Here's why, in order of importance:

1. Many of the articles are inaccurate or outright wrong. Sources are not cited but it would appear that bad sources like Google Maps are being used for the basis of route descriptions. Articles have been created for highways that do not exist and never have.
2. The Arkansas highway system is very complex, with some route numbers occurring in as many as eight sections, which makes article structure and infoboxes hard to apply
3. No roadgeek-run Arkansas highway website seems to exist, making the system that much harder for an outsider to be introduced to.
4. Stylistic, grammar, and spelling issues abound.
5. The state has been at the bottom of the assessment list for months. The vast majority of articles are stubs. No B-class article exists in Arkansas.

I call on the project to help me solve this conundrum and what to do next. —Scott5114↗ [EXACT CHANGE ONLY] 03:25, 23 January 2010 (UTC)

Do you have some sample links to show the issue?Dave (talk)

OK, I've found some examples of what you are saying. To me these articles look neglected. I don't see any thing consistently wrong with every article (implying there's one or two editors behind the problem and action needs to be taken). Many of these look like USRD articles did back in 2005-6 or so, when the idea of inboxes and the MOS were still being actively developed. The ideal scenario is for a resident to ping the DOT for some sourcing info to better understand the system. Until that happens just continue doing the best we can with what we have.Dave (talk) 04:12, 23 January 2010 (UTC)

I am unable to comment on the factual errors offhand because I don't know enough about the AR highway system to know an error when I see it without checking every statement against the AHTD map. Here's a grab bag of random other issues:

• Arkansas Highway 43 - no infobox, generic content (mentions termini of routes, not much else in way of routing), bad organization
• Arkansas Highway 88 - same issues as above; has minor factual errors (I've been informed that much like Utah, Arkansas officially doesn't have concurrencies)
• Arkansas Highway 74 - has one-line paragraphs, one for each of the route's eight sections, no infobox
• Arkansas Highway 25 - did have two route descriptions until just now, but I cleaned it up into an acceptable start.
• Arkansas Highway 45 - Backslashes? "I540"?

More can be found, I'm sure. To me the most important thing is the factual errors. I've had a couple AR residents emailing me over the past few days to tell me that in some of the articles the locations of junctions/termini/etc are completely bogus. —Scott5114↗ [EXACT CHANGE ONLY] 04:39, 23 January 2010 (UTC)

A lot of activity lately seems to be coming from Brandonrush (talk · contribs). He's been creating many stubs lately, and seems to have contributed to some of the articles on this list... --LJ (talk) 10:18, 23 January 2010 (UTC)

I looked at the article Arkansas Highway 74. Surprisingly, 2 revisions back the article had an infobox and a lot more content. User:US 71 removed the infobox and pared down the content to the 8 one-liners. The old revision made clear that AR 74 is a group of unconnected highways; I didn't get that from the current article (I'm from VA, so my knowledge of AR is nada). --Tim Sabin (talk) 21:27, 23 January 2010 (UTC)

Tracing the route in googlemaps I see two points: 1- Nowhere in Googlemaps is a SR-74 shield present, only a text label, most segments also show a county route designation. From my experience in other states this can indicate a decommissioned highway. 2-It's pretty obvious from google map that that highway is contiguous. The 8 segments come from concurrencies. My suspicion is that Arkansas is much like several of the western states, where officially there are no concurrencies, and where a concurrency is signed, the route is officially only one of the two numbers signed.Dave (talk) 02:00, 24 January 2010 (UTC)

Although, it is my understanding that in Arkansas, such "concurrencies" are not signed. The route simply disappears for the duration. —Scott5114↗ [EXACT CHANGE ONLY] 02:13, 24 January 2010 (UTC)

Point being is that there is a reason why these 8 segments have the same number. It's not just 8 random segments of highway that share a number. This is more or less the same scenario as Utah State Route 30, which has an article in somewhat better shape. However, the bigger question is, is the highway even still active, or has it been decommissioned, given what is stated above.Dave (talk) 04:27, 24 January 2010 (UTC)

No, it's still shown on AR state maps; it's just that Google Maps' quality has degraded beyond all belief. —Scott5114↗ [EXACT CHANGE ONLY] 04:47, 24 January 2010 (UTC)

Amen to THAT! Their info is often so wrong on so many levels. In VA, for instance, secondary routes do not exist in the independent cities, but Google Maps shows these routes sneaking through the cities to form contiguity. I only use them for the beginning of my research, and never the gospel truth. --Tim Sabin (talk) 18:31, 24 January 2010 (UTC)

South Carolina article names

Resolved

 – Moved. ---Dough4872 17:20, 24 January 2010 (UTC)

I was looking around at articles and noticed South Carolina Highway 22 redirects to Conway Bypass and South Carolina Highway 31 redirects to Carolina Bays Parkway. Shouldn't the article titles be the route numbers, not the road name? ---Dough4872 20:57, 23 January 2010 (UTC)

I would say you're right. SC 22 has two names, so linking to one and not the other is ambiguous. --Fredddie™ 22:01, 23 January 2010 (UTC)

I'll move the articles then. ---Dough4872 22:32, 23 January 2010 (UTC)

Project pages

I just wanted to let everyone know that I am in the process of trying to clean up some of the main project pages (reorganization, consolidation, and the like). I've already made a few changes over the last few days to the main page. I'll let everyone know before I do anything radical...although I'm not thinking about doing anything drastic. --LJ (talk) 10:44, 24 January 2010 (UTC)

Why did you hide the Article alerts? We started using them because this talk page was getting clogged with *fD announcements and the like. Hiding them kind of defeats that purpose. Out of sight, out of mind.

Also, if you're going around editing project pages, they should be tagged Project-class on {{USRD}}. --Fredddie™ 17:58, 24 January 2010 (UTC)

I'll keep in mind the Project-class tag. I think most of the project pages just use an "NA" tag.

I hid the Article Alerts because I'm trying to reduce the amount of stuff on the main page, to make it a bit more friendly and a quick-read to those unfamiliar with the project. I replaced it with a link to the actual page in the Articles section. I figure the members that are interested in the alerts would want to watchlist the page to better see the changes real time, and they'd need the link in order to do that. I've created a shortcut to the page at WP:USRD/AA, and I'll add Article Alerts to the project navbar later on. --LJ (talk) 21:32, 24 January 2010 (UTC)

I don't really get the purpose of Project-class. It just seems superfluous. --Rschen7754 23:13, 24 January 2010 (UTC)

If someone were browsing categories, it would separate the actual project pages from the other random pages marked NA... In any event, the template does not appear to be set up for Project-class, so I'll leave the issue alone unless that changes. --LJ (talk) 23:26, 24 January 2010 (UTC)

Resources

Resolved

 – Department page created. I think I got all the other pages that should have been moved. --LJ (talk) 23:26, 28 January 2010 (UTC)

One thing I'd like to do is create a new Resources "department" at Wikipedia:WikiProject U.S. Roads/Resources. What this would do is move the resources information off of the main page. All the internal databases listed under this section of the main page, as well as the Lengths page, would be subpages of this department. However, any resource information currently listed on state subproject/task force pages would remain in its current location. Are there any objections to moving in that direction? --LJ (talk) 00:39, 25 January 2010 (UTC)

IMO, we should create task force pages for each state without a WP in order to list resources as well as other standards and templates specific to the state. ---Dough4872 02:50, 25 January 2010 (UTC)

I have no objections to this proposal. In response to Dough, I think making a page for every state is excessive. – TMF 03:25, 25 January 2010 (UTC)

Agreed. Some states without a project only have one or two resources listed...some states have none. If there's no state project/task force now, that state uses USRD standards and templates. As such, a separate page is not necessary --LJ (talk) 03:28, 25 January 2010 (UTC)

Okay, I'm guessing this isn't controversial, so I'm going to go ahead and start on this. --LJ (talk) 07:51, 26 January 2010 (UTC)

US 27 Alt in FL

Is there any objection on merging U.S. Route 27 Alternate (Florida) to Bannered routes of U.S. Route 27? I had tried to merge it whenever we were setting up the bannered route articles the first time, but two users complained because "a decent article can be written here". However, as of a year and six months from that discussion, it's still a stub. Can we merge it for now, with an eye to splitting it back out should someone find the willpower to expand it to something worth keeping in the future (much like we've been doing on every other bannered route article)? —Scott5114↗ [EXACT CHANGE ONLY] 12:06, 26 January 2010 (UTC)

I tend to agree with this sentiment. At 94 miles (but according to the talk page only as much as 35 are independent from other USH), a decent article could easily be made; however, the current lack of content makes it a prime candidate for merging. I've always held the belief that we should merge articles based on what's present now and not what the article could contain if fully expanded later. – TMF 12:13, 26 January 2010 (UTC)

I agree too. With the current version of the article, it can easily fit into the bannered routes list. It could always be split out again if an editor is willing to expand. ---Dough4872 16:45, 26 January 2010 (UTC)

With the current state of things at the Florida project, it's safe to assume the article will stay the way it is for a while. I support a merger. CL (T · C) — 22:26, 26 January 2010 (UTC)

Who said nobody had the will power to expand it? I've been considering a whole new intersection chart to replace the existing one. ----DanTD (talk) 20:43, 27 January 2010 (UTC)

Honestly, the junction list was the least of that article's problems. – TMF 21:34, 27 January 2010 (UTC)

It has been unexpanded for 1½ years. If you're willing to expand it to a full article—with the junction list and references and history like all decent USRD articles have—then you can always split it out. As it is though, it's a stub, so it's not really worth having a separate article at this time if it's going to be in that sort of shape. —Scott5114↗ [EXACT CHANGE ONLY] 00:04, 28 January 2010 (UTC)

Fine. I hate to start a whole new sandbox considering all my others, but if that's what I have to do, I'll do it. ----DanTD (talk) 18:18, 28 January 2010 (UTC)

If you do re-create it, please do more than just fix the exit list. The prose needs to be scrubbed too. Picking on this little gem, "it is mostly signed secretly as State Road 55." is just one example of a reminder that we should have our work peer-reviewed once in a while. I'm sure the actual meaning of that sentence is not what the author intended to say. I'm guilty too, I'm not trying to pick on one person.Dave (talk) 18:36, 28 January 2010 (UTC)

It will need history and references as well. The standard that the average Florida article is written to is below that of the other states. —Scott5114↗ [EXACT CHANGE ONLY] 05:40, 29 January 2010 (UTC)

Deprecated template and possible errors

Please review I have edited out all instances of {{Ibus}}—as it was deprecated—and replaced it with {{Infobox small road}}, as indicated. In so doing, I may have made some errors (as I am completely ignorant on this topic.) Please review the following pages to make sure they are correct:

• Business routes of Interstate 5
• Business routes of Interstate 80
• Business routes of Interstate 10
• Business routes of Interstate 15
• Business routes of Interstate 35
• Business routes of Interstate 44
• Interstate 8 in California
• Interstate 40 in California
• Interstate 83
• Interstate 376
• Interstate 385
• Interstate 526
• Interstate 585

Also:

• Bannered routes of U.S. Route 1
• Bannered routes of U.S. Route 13

Thanks. If you need to reach me, please post on my talk. —Justin (koavf)❤T☮C☺M☯ 08:31, 29 January 2010 (UTC)

It looks like the wrong type was used; i.e. <state> instead of "BL" (Business Loop) or "BS" (Business Spur). A quick AWB run could probably fix this. – TMF 13:14, 29 January 2010 (UTC)

All fixed. – TMF 13:57, 29 January 2010 (UTC)

Two more TFDs

See Wikipedia:Templates for discussion/Log/2010 January 29#Template:MDUSbus and Wikipedia:Templates for discussion/Log/2010 January 29#Template:Ibus. ---Dough4872 19:26, 29 January 2010 (UTC)

WP:CACR discussion

What is to become of this task force? Currently, this has a bunch of borderline notable articles that are very malformed. One scenario that we've talked about on IRC is the "Rockland County" scenario, which is to restructure the articles into lists similar to the ones used for the county routes in Rockland County, New York. I thought I would move this discussion onto wiki to get more input. --Rschen7754 09:05, 7 January 2010 (UTC)

Most of these CRs appear to be non-notable and stubbish. In addition to the Rockland County Scenario, there was a similar thing done with the Michigan CDHs a while back. You could even split it up by letter like the CDH page. If the mini infobox described up there ↑ happens, you can use it. It's worked well for both MI and Rockland Co. since then, so I would not hesitate to initiate the Rockland County Scenario. —Scott5114↗ [EXACT CHANGE ONLY] 09:15, 7 January 2010 (UTC)

If the county routes aren't particularly notable by themselves, then converting to a mini-article list would be an appropriate solution. I feel it would be in accordance with WP:USRD/NT, so by all means, Initiate the Rockland County Scenario. --LJ (talk) 09:32, 7 January 2010 (UTC)

Incidentally, is there any real separation between this (inactive?) task force and the state project? It seems a task force on county routes might be a bit overkill, and could probably be absorbed into WP:CASH. --LJ (talk) 09:37, 7 January 2010 (UTC)

It started out as a full subproject and is now a taskforce of CASH. Rschen is more interested in what to do with the articles than the actual taskforce. —Scott5114↗ [EXACT CHANGE ONLY] 12:31, 7 January 2010 (UTC)

In my opinion, many of California's county routes are several miles long and span multiple counties, which makes them worthy of keeping their own articles. This is somewhat similar to New Jersey's 500 series county routes. As for WP:CACR, it could be left as-is as a task force or completely folded into WP:CASH. State projects can handle county routes, as WP:NJSCR covers both New Jersey's state and county routes, as indicated by the title. ---Dough4872 17:20, 7 January 2010 (UTC)

Except that's not enough to make them worthy of keeping their own articles. In NJ, perhaps "several miles" is enough to supply enough interesting things to say in the article, but out west, pretty much anything short of 20 miles is going to be bland unless it's an urban area. Put simply, there's a lot more empty space out here. In any event, if there's someone willing to work on them and make a decent article (not just a stub) about them sometime in the future, they could always split them out later. Right now there doesn't appear to be enough interest to make them maintainable as-is. —Scott5114↗ [EXACT CHANGE ONLY] 17:50, 7 January 2010 (UTC)

Dough, the CA CRs are like the MI CDHs in that regard, and all but 3 of the CDHs are completely merged into the list article. Once we get the mini infobox, I could really clean up that list and make it shine. The 3 that have been split out have articles that are fully expanded (1 is missing history, but a little map digging with my 1970s paper maps would solve that a bit). One of them is future GA material at some point. Imzadi1979 (talk) 18:48, 7 January 2010 (UTC)

I see now, it may make sense to merge some of the CA county routes to a list. The only ones that should be kept are articles that are well-written and/or serve as a major road (as opposed to a long lightly traveled road in a rural area) such as County Route S18 (California). ---Dough4872 19:01, 7 January 2010 (UTC)

I've always been a proponent of splitting articles out of lists that can have fully-formed and well written articles about them. Why else would I have M-28 Business (Ishpeming–Negaunee, Michigan) at FAC as a stand-alone article, instead of trying to shoe-horn all of that, plus M-28 Business (Newberry, Michigan) and U.S. Route 41 Business (Marquette, Michigan) into the parent article. All three have fully-formed articles that are all currently GAs. H-58 (Michigan county highway) is another example. It has a good history section, but it is also listed in the main list article using the {{main}} template. I'm not against some of the CA CRs having separate articles, but until then can be fully expanded, merge them and redirect to the list. Imzadi1979 (talk) 19:43, 7 January 2010 (UTC)

Most of them should be merged, but CR S18 should be kept as it is a GA. ---Dough4872 20:04, 7 January 2010 (UTC)

In this case, maybe, but "_ should be kept as it is a GA" is a bad argument. --Rschen7754 21:19, 7 January 2010 (UTC)

I agree with putting the articles into a list, because some of the templates seem to be flawed and some articles are difficult to navigate to. Also, it shows just how many routes are still red links. Pzoxicuvybtnrm 06:15, 19 January 2010 (UTC)

I see no reason not to enact the Rockland County Scenario here. Note that a few Rockland CRs still have their own articles, so if a route is somehow notable enough to warrant an article, there's no harm in letting it stand while merging the rest. – TMF 04:15, 9 January 2010 (UTC)

We should probably wait until the discussion above is resolved, though. --Rschen7754 07:19, 9 January 2010 (UTC)

Since the IRS (infobox road small) discussion wrapped up over a week ago, this issue should be revisited. – TMF 18:55, 22 January 2010 (UTC)

It seems to me that the only thing standing in the way is the proposing editor finding a block of time to getting this done. :| --Rschen7754 22:03, 22 January 2010 (UTC)

One page is done: California County Routes in zone A. Would appreciate another user helping out...contact me on IRC if you're wishing to collaborate. —Scott5114↗ [EXACT CHANGE ONLY] 17:06, 29 January 2010 (UTC)

What should happen to the WP:CACR page? --Rschen7754 23:56, 31 January 2010 (UTC)

It could probably be retained, to reflect that it is a task force of CASH. The content should be stripped down such that it only has information relevant to building articles on California's county route system...not unlike how we stripped down the Nevada task force page to remove redundancies with USRD. However, if the scope of CASH specifically includes county routes and there is not much difference between the California state route and county route articles, you could probably just get rid of CACR entirely. --LJ (talk) 00:44, 1 February 2010 (UTC)

Leaderboard bot

Resolved

 – Rschen7754 23:51, 31 January 2010 (UTC)

The leaderboard will not be updated until further notice. Unfortunately, when WP 1.0 bot changed to the new system, it broke the current bot (which parses the table output). Hopefully I will get the time to rewrite the bot soon. --Rschen7754 20:29, 23 January 2010 (UTC)

Fixed the bot. --Rschen7754 00:19, 24 January 2010 (UTC)

Six more TFDs

Wikipedia:Templates for discussion/Log/2010 February 1 - relating to California County Routes. --Rschen7754 00:46, 1 February 2010 (UTC)

Portal

Resolved

 – Updated. ---Dough4872 03:45, 1 February 2010 (UTC)

We need to decide on a selected article and selected picture for February for the portal. Currently, the SA has two candidates with one vote each and the SP has no clear consensus. ---Dough4872 01:29, 1 February 2010 (UTC)

Merge proposals

See Talk:U.S. Route 258#Merging U.S. Route 258 in Virginia. ---Dough4872 04:52, 28 January 2010 (UTC)

Another: See Talk:United States Numbered Highways#Shield merge? —Scott5114↗ [EXACT CHANGE ONLY] 18:07, 28 January 2010 (UTC)

And another: See Talk:List of Puerto Rico Highways#Merge. --Fredddie™ 09:47, 2 February 2010 (UTC)

Request for WISH shortcut

Hello, I noticed that the Wisconsin Roads task force is inactive, and I hope to use its shortcut (WP:WISH) for an essay that I am drafting, once it's ready for mainspace. Thank you for your consideration.--otherlleft 21:01, 5 February 2010 (UTC)

All of the WP:??SH shortcuts where the ?? is a state's postal abbreviation and SH is short for "state highways" are currently in use and assigned either to the task force of USRD or the active wikiprojects. There are editors active in WI, it just didn't stay at the level necessary to stay a separate wikiproject, so my gut reaction is to say no. We didn't release WP:MASH when someone started a project based on that TV show because of the WP:??SH convention. Others will need to weigh in here though. Imzadi1979 (talk) 01:50, 6 February 2010 (UTC)

A hatnote to the essay at the Wisconsin task force page would always work. ---Dough4872 02:04, 6 February 2010 (UTC)

"Be Careful What You Wish For" doesn't seem to be an appropriate title for the essay, based on the existing content (WP pages of organizations). Thus, I don't think changing the shortcut is appropriate. --LJ (talk) 09:31, 7 February 2010 (UTC)

Thank you, I agree that if the shortcut is needed for the project that changing it would be inappropriate.--otherlleft 18:14, 7 February 2010 (UTC)

Importance scale

Recently, it has come to the realization that our Importance scale is way too subjective and inconsistient. For example, in NY, cross-state New York State Route 17 is assessed at mid importance along with very short New York State Route 433. Currently our importance scale sorts routes by class and is somewhat vague. For example, a Mid-importance calls for "Most state highways and all U.S. routes and three-digit interstates not in High-importance. Select county routes". This seems to make certain routes selective as to what importance they should be classified. We need to come up with a more set importance standard for USRD articles. ---Dough4872 17:45, 7 February 2010 (UTC)

This is not unique to USRD, I come across articles all the time that are mistagged, usually with the importance rating set too high. For example, I've seen articles on villages with less than 100 residents tagged with high importance. With that said, these scales will be subjective, and I'm not sure this problem even can be resolved.Dave (talk) 18:06, 7 February 2010 (UTC)

The class system is not absolute; very minor state routes can be tagged as Low, for example. --Rschen7754 20:47, 7 February 2010 (UTC)

The class system shouldn't necessarily be absolute, because it is impossible to foresee all exceptions. An important cross-state highway would likely be in High Importance, instead of the Mid importance typical of state routes. NY 17 is given as a specific example of this in the current importance scale, so I'm not sure why it is currently classified as mid-class importance. --LJ (talk) 21:49, 7 February 2010 (UTC)

What is the Importance scale used for? My first impression is the scale is used when priorities need to be made on which articles to assess, create maps for, etc. Since a larger portion of our audience is likely to read an article about a cross-state highway that connects several cities and attractions than a very short rural county route that has only local use, it makes more sense to me to concentrate resources on the first highway. My conjecture may not reflect actual practice. Defining what the Importance scale is used for, not just which classes of highways are in which part of the scale, would be helpful in resolving this issue. Viridiscalculus (talk) 04:18, 8 February 2010 (UTC)

Need	The article's priority or importance, regardless of its quality
Top	Subject is a must-have for a print encyclopedia
High	Subject contributes a depth of knowledge
Mid	Subject fills in more minor details
Low	Subject is mainly of specialist interest.
Bottom	(Unused by USRD) Subject has no real significance to the project.
NA	(Unused by USRD) Subject is a disambiguation or redirect page, residing in article space.

According to the WP1.0 team, the importance scale is project-specific and only a means to help the editorial team select articles for the full release, if/whenever that happens. This was the handy chart on that page to determine an article's importance. --Fredddie™ 04:43, 8 February 2010 (UTC)

The problem is, what is the dividing factor between a "must-have" and an article of "specialist interest"? ---Dough4872 00:31, 9 February 2010 (UTC)

The way I view this is to say you were writing a comprehensive guide on road travel in the United States (which is essentially what we're doing). The most important information into understanding the U.S. road system is what road systems are in place. People using this guide would then probably want to know what the primary routes across the county are. Then, if so inclined, would delve deeper into less important routes to satisfy whatever personal interests or questions they might have. Approached from this perspective, I'd say the current importance scale is pretty much on target.

Ideally, our article improvement efforts would follow the importance scale, with top priority articles being written and expanded first. However, this is not always practical and may not necessarily coincide with the editing interests of all our contributors. --LJ (talk) 03:07, 9 February 2010 (UTC)

I've always ignored the importance scale. The assessments have always seemed so subjective to me, and well, it just never mattered to me. My personal priorities are probably different than anyone else, and I just expand the articles I want, when I want, and those criteria I use vary all the time. Imzadi1979 (talk) 05:22, 10 February 2010 (UTC)

I have a similar point of view, my "personal" importance scale places more value on scenery, history, and engineering marvels than length or traffic volume. However, I do see the point of having even a flawed importance scale. For example, using the above "friendly competition", I would place more value on improving the article on Interstate 95 to GA status than I would, California State Route 242 to FA.Dave (talk) 07:16, 10 February 2010 (UTC)

Infobox discussion

I've started a discussion about a proposed change to the infobox here. Imzadi1979 (talk) 06:15, 15 February 2010 (UTC)

GA Reassessment of Ohio Department of Transportation

Resolved

 – Delisted. ---Dough4872 17:52, 18 February 2010 (UTC)

I have done a GA Reassessment on the Ohio Department of Transportation article as part of the GA Sweeps project. I have found some problems with the article that I have outlined here. I have put the article on hold pending work. I am notifying all interested projects and editors. If you have any questions or concerns please contact me on my talk page. H1nkles (talk) 19:55, 10 February 2010 (UTC)

Revision to assessment quality scale

In my continuing effort to cleanup USRD project pages, my next proposal is to revise the quality scale table on the assessment department page. Before anyone gets excited, I am not proposing any changes to the current quality classification scheme. My goal is to make the table easier to read at a glance and perhaps clarify a few points.

I've worked on this over the last day or two, and my proposed revisions can be seen on my sandbox page: User:Ljthefro/Sandbox. What I've done here is blended the existing table with elements of the {{grading scheme}} template. The result combines the current full definitions and summary into one table, where the detailed explanations of each class can be viewed by clicking the "show" link in each row. I've edited each standard explanation from the template to blend some of the standard wording with the USRD specifics previously established, including some clarifications. I also changed some template wording and links to reflect USRD-specific policies and guidelines. Again, no major changes are there...it's mostly cosmetic.

I'd appreciate folks looking over this to make sure I haven't missed anything. If there's no major issues/concerns/objections, I'll move it to the assessment page in a few days. Regards, --LJ (talk) 10:08, 7 February 2010 (UTC)

Meh...it's still not really clear what separates a Start from a C and a C to a B in this revision. I've been blasted over this in the past when I've attempted to do reassessments, which is why I said "to hell with it" and am now expanding articles without bothering with the grading scale. In any event, in an attempt to turn my rant into a productive comment, I'll suggest that we have several examples of articles from each class to show the kinds of things we should look for in each level. B-Class is probably the most straightforward, but the composition of anything below that typically varies greatly. – TMF 16:47, 7 February 2010 (UTC)

To offer a suggestion, here would be good criteria for the lower-level articles. A stub would be a couple of sentences or an article with only one of the three big sections (RD, history, major intersections). A start would need at least two of the sections, a C would need all three sections, and a B would need all three sections with sufficent referencing. If a start or higher article is missing some information, it should be assessed one level lower. ---Dough4872 16:51, 7 February 2010 (UTC)

I agree with the gist of this. I think this basically puts B-Class on par with GA (as I don't see the difference apart from a formal review) but that's not necessarily a bad thing. It should be noted, though, the "missing information" should refer to the sections that are there, not any that are missing. So, if an article has a half-baked RD, a half-baked history, and a junction list, it would be start-class instead of C-Class for that reason. – TMF 17:07, 7 February 2010 (UTC)

Personally, I see B-Class as almost ready for GA assessment. I see A-Class as almost ready for FA assessment. There will be a few things that differentiate B from GA and A from FA, but in all, the articles at the lower level should be ready with some refreshing to be sent up as a nomination to the next level. Maybe it's changing some references, or copy editing. Maybe we dig for a photo or something else, but the effect for me is the same. Imzadi1979 (talk) 04:03, 8 February 2010 (UTC)

I'd just update those examples you have to be more recent - I'm not sure I-476 in 2007 would meet GA standards today. CL (T · C) — 17:20, 7 February 2010 (UTC)

I like where this is going, I agree these guidelines could be refreshed. We should keep in mind that the "big 3 sections" (i.e. Route description, History, and Major intersections) is only the typical structure for a road article, this structure is not practical for some road articles. Also, I'd like to see one thing become more spelled out: I'm seeing a lot of articles tagged as B class and even GA where the only source used throughout the article is maps. IMO, an article cannot be considered comprehensive if it is sourced entirely through maps. I don't know if we want to get that specific in this particular guideline, but IMO this is becoming a problem and needs to be mentioned somewhere.Dave (talk) 18:02, 7 February 2010 (UTC)

Well, I wanted to do this without rehashing the difference between the lower classes, as I know this has been debated previously. But if refreshing the criteria is the will of the project at this time, so be it. As far as the actual formatting of the table with the current blended content, I don't see much of any comments other than providing multiple and/or more recent examples--a good idea and one that can be implemented once the bigger issue is solved. --LJ (talk) 21:49, 7 February 2010 (UTC)

The quality of the references should be a matter for GA, not B-Class. – TMF 22:40, 7 February 2010 (UTC)

You certainly can write a serviceable article with only maps as references. It will be rather bland, but the most necessary information as found in the Big Three is there. Getting historic and "why was it built this way" type information from newspaper articles and other sources is certainly laudable, but it really when you look at it serves to add depth to the information found in map sources. Dunno how familiar you all are with meteorology, so not sure if this metaphor will work, but in a way the map sources are like the surface-level weather. It's what's most important to most people. Adding historic flavor from references is like studying the winds aloft. It gives you the background for what's going on at the surface, and if you want to know why things are the way they are at the ground, then it's critical to take into account. But most people don't need to know that. So I feel that map references only should be okay for the lower-half articles (B and below) but a wider spectrum be required above that. —Scott5114↗ [EXACT CHANGE ONLY] 02:05, 8 February 2010 (UTC)

As to the maps-only reference issue: One of the changes that came from blending the existing USRD table with the template table is in the A-Class. One sentence of the blended text states, "It should be well referenced by a broad array of reliable, third-party sources." So definitely using maps as the only sources could ding an article at ACR. I can add similar language to the GA criteria, but non-USRD GA reviewers probably won't know this--and I feel the language might be a bit restrictive at B-Class. --LJ (talk) 03:36, 8 February 2010 (UTC)

I'm inclined to agree with LJ here. We've tended to be a bit more lax about sources at the B-Class level. The importance there was on the quality of the referencing, not the quality of the specific references. By the time something is at that level, it's nearly ready for GAN, but one of the things that could be improved between the two levels is what types of references are used. The GA level can't have USRD-specific stuff added as assessment criteria because WP:WIAGA is the list of criteria used to assess a GA. What we define as the specific section headings, infobox requirements and the like really doesn't matter, and a GA reviewer is free to ignore them, like they'd be free to ignore our referencing guidelines, unless a article fails WP:CITE. Imzadi1979 (talk) 03:51, 8 February 2010 (UTC)

I stand by my ascertain that an article cannot be considered comprehensive if only map sources are used, as a map can't tell you why something was built, only where and sometimes when. However, upon further examination, comprehensive is an A class requirement, not a GA class requirement, so I stand corrected.Dave (talk) 04:04, 8 February 2010 (UTC)

I view B-Class as almost GA-Class. It basically follows the GA standards, except for the style of citations isn't quite there, or there's one or two things that aren't cited. Not much work should be needed to move the article to GA. --Rschen7754 21:40, 8 February 2010 (UTC)

What I've gathered thus far:

• The variety of sources issue (i.e. not just maps for references) should be addressed by the time an article reaches GAN, but will be of concern at ACR.
• B-Class is largely viewed as "GA-ready". (This is nothing new; I've linked Wikipedia's B-Class criteria as ideal for these articles, though.)
• It is desired to more clearly define the differences between Start and C, and between C and B.
• The "big 3" sections are not necessarily appropriate for all articles in this project.

Thoughts based on these observations:

• Perhaps adding a disclaimer of sorts might be helpful. Articles are typically rated on completeness of the three major sections typically found in road articles, but these sections may not be present due to unique conditions of the article/route (former route, certain trails, interchanges, system-level articles, etc.)
• Based on that, the assessment criteria might be revised to more clearly reflect the quality of the prose, sourcing and guideline adherence rather than completeness of individual sections of the "big 3".
• Whatever we do, the distinctions between the lower-half classes will never be clearly defined and universally applicable. We can tighten up the criteria all we want, but the interpretation will vary since article assessment is a subjective system.

Thoughts from others? --LJ (talk) 23:54, 8 February 2010 (UTC)

I'd say the Big 3 criterion helps make it less subjective and more objective. The overwhelming majority of articles will fit into that style of classification. The articles that don't, should have a reasoning for the assessment given on the articles' talk pages. Imzadi1979 (talk) 00:01, 9 February 2010 (UTC)

Okay, that makes sense. Perhaps mentioning this in the "disclaimer" would be a good course of action. --LJ (talk) 05:12, 10 February 2010 (UTC)

Sorry to lose momentum on this...I've been upgrading some Nevada stubs the past few days. Anyway, I've added the "disclaimer" to my proposal--it mentions that articles are typically rated on the "big 3", and articles without one/more of these should still be assessed based on completeness of info with justification left on the talk page. Thoughts? Other than some minor tweaks to the wording of a few of the lower classes, the rest is mostly the same. I'll update the examples before this is finalized, but adding more example links will likely bloat the table (the class links lead to the appropriate USRD categories on the left, so there are plenty of examples accessible). --LJ (talk) 10:40, 18 February 2010 (UTC)

But there's no guarantee that the articles in the class categories were correctly assessed. The whole point of additional examples are to provide more examples of correctly assessed articles for each class.

On a related note, the topic of U.S. Route 421 in Virginia's assessment came up online last night. I believe it's more than a stub - probably not more than start though - but I was told it was a stub because it only had one sub-section. I find that a bit, to be blunt, ridiculous, considering the history section is complete and fully referenced. The sandboxed quality table above defines a stub as "Content might be little more than a route log entry and maybe a junction list", which I interpret to mean a lead containing termini and not much else and a junction list. I believe US 421 (VA) exceeds that. – TMF 21:35, 23 February 2010 (UTC)

Yeah, the US 421 article is definitely a start-class article. CL (T · C) — 21:59, 23 February 2010 (UTC)

I see the point regarding the examples. Having a second example for each class might not make the table too big, but I wouldn't want to add more than that. As to the Virginia US 421 article, that should be start-class based on both the current and proposed scales. --LJ (talk) 22:29, 23 February 2010 (UTC)

Question: I want to update the examples used in the tables, and I'm considering adding an additional example for each class. Should the example links point to the specific revision where the assessment was assigned, or to a more recent version at that class level. An example is Kansas Turnpike, where the current example links to a March 2007 revision back when the article was rated FA. The article has had some changes since then (presumably compliance with updated standards and possibly further refined content), and is still listed as an FA. Is it more appropriate to link to the initial FA version or a more recent revision? --LJ (talk) 23:27, 23 February 2010 (UTC)

Speaking for myself, I still find typos and grammar errors in my nominations that have passed an FAC review. Most of my FA candidates are in better shape now than the day they passed. The other side of that is, FA and A class standards are a lot tougher now than they were even a couple of years ago; there hasn't been much change on the lower grades. Combining those two statements causes me to opine that the preferred choice for the examples of FA and A class would be the current version an article that recently passed the FA or A class review. I don't think it much matters on other grades. Also, if you are going for 2 examples per class level, I would try to ensure that the 4 examples of the top categories (2 for FA and 2 for A class) come from different authors, to show how different styles that can make it to FA.Dave (talk) 23:49, 23 February 2010 (UTC)

Deletion discussion

Wikipedia:Templates_for_discussion/Log/2010_February_21 - leftover CACR stuff --Rschen7754 21:46, 21 February 2010 (UTC)

And Wikipedia:Templates for discussion/Log/2010 February 26 --Rschen7754 22:50, 26 February 2010 (UTC)

And Wikipedia:Stub types for deletion/Log/2010/February/27 --Rschen7754 07:57, 27 February 2010 (UTC)

And Wikipedia:Templates for discussion/Log/2010 February 27 --Rschen7754 07:58, 27 February 2010 (UTC)

Manual of Style issue

Did you know that the MOS specifies when and when not to use boldface text in an article? Did you also know that items that span multiple columns in exit lists are not on the list of approved boldface usage? That's why I make changes like this when I find them in articles. The way to fix this is to remove the exclamation point "!" at the beginning of the row and replace it with the bar "|" character. Since that also reverts the cell formatting to left-justified, I add the <center></center> tags around the text.

One further comment about the MA Route 25 exit list, which isn't based on the MOS. The top and bottom column spans are unnecessary. The first states where the highway starts. Actually, doesn't the first junction listed at the 0.0 milepost already state that? The last repeats the information from the notes column of the last junction. Now this might be personal preference, or it might be based on some experience working with Featured Articles and the like, but why not condense these sorts of notes into the appropriate spots in the table? Imzadi1979 (talk) 20:04, 28 February 2010 (UTC)

Both excellent points, Imzadi. I usually suggest removal of bold from junction lists when reviewing upper-half articles. There are some articles where this gets out of control (U.S. Route 395 in California#Major intersections comes to mind, with my efforts to reduce such notations being resisted by a certain exit list-focused editor). --LJ (talk) 02:53, 1 March 2010 (UTC)

IMO, there would not be too much harm in removing bold from colspan notes (such as a freeway terminus or a river crossing). They function just like the unbolded notes in the notes column, except they are not keyed to a specific junction. ---Dough4872 23:48, 1 March 2010 (UTC)

I first heard about the first point a few months ago during some article's FAC, at which time I went through most (if not all) New York articles and eliminated the header colspans (in other words, the ones that used !). The only difference is that I used 'align="center"' in the cell's code, which accomplishes the same effect as the center tags. As for the second point, I agree 100%. To me, these are just as unnecessary as the notes in the junction list that say where the article route begins and ends. – TMF 01:45, 2 March 2010 (UTC)

Maryland Route Lists Discussion

You are welcome to participate in a discussion regarding problems with and solutions to issues with Maryland's route lists at the WikiProject Roads in Maryland talk page: Wikipedia talk:WikiProject Roads in Maryland

Viridiscalculus (talk) 07:05, 8 March 2010 (UTC)

Layout

Since this project has much more refined standards (and participants), I figured its the better place to ask about article layout.

From what I can tell, it's best to compress into only a select few major headers: Route Description, History, Future, Services, Exit List.

If a particular event in the history of a highway is significant enough, it may warrant a subheader.

However, how does this play in with events after this particular one? Should the particular events be listed after the general history, or simply merged into it chronologically?

Second, what is the stance for Lane configuration sections?

Finally, if genuine and sourced information is available on subjects directly, and only, related to a highway, should it be included?

To put this in perspective, I'm rewriting an article, and I want to know if the section on Traffic Cameras should be kept, and whether the Highway of Heroes / Advantage I-75 stuff should go at the bottom of the History section, or whether the incident on the Propane explosion (which is more recent) should be at the bottom? Should I do away with the lane configurations outright? - ʄɭoʏɗiaɲ ^τ _¢ 01:00, 6 March 2010 (UTC)

A couple comments. Not speaking as an accomplished USRD author (which I'm not), but from what I generally like about roads articles:

• Subheadings are appropriate not only in the history section, but in any section of a decent length that would divide the larger section into easily digestible chunks. In the history section, the subheadings need not be limited to specific events--for example, stages of the highway's existence (former routes; planning, construction, and opening; etc.) might be more manageable and give a greater balance to the prose than using specific events as subheadings. Similarly, subheadings in route descriptions can go by county, region of the state/province, type of highway segment (freeway portion vs. urban street), or other groupings.
• I feel the history section typically works best by describing the overall history in a chronological fashion, with certain specific events getting their own headings if particularly notable. I'm not a fan of talking about incidents that happened along the road (accidents, etc.) unless there's something particularly notable about such an incident that it would have gone beyond local news.
• Some of the best road articles not only talk about the road itself, but features along the road and how the highway impacts the areas it passes through. If there's something that's been affected by the road, it can't really hurt to put it in as it expands beyond the monotony of describing just the road--this can help create interesting points throughout the route description.
• Lane configuration sections aren't something standard at USRD, as it's usually worked into the prose. I would remove the section, or fold it into the route description. Traffic cameras could also be folded into the route description.
• A side note: are you using set widths for some of the table columns? Particularly in the exit list, it seems some of those columns could be narrower and would help other columns render on a single line (thus reducing length).

Hope this was somewhat helpful. --LJ (talk) 02:31, 6 March 2010 (UTC)

For historical events, they should be listed in chronological order in the history, and subheadings are generally not necessary for historical events. The lane configurations and traffic cameras sections are not included in an article as it is indiscriminate information. As for sourcing, reliable primary sources are fine to have, but secondary sources should also be used. ---Dough4872 02:34, 6 March 2010 (UTC)

Almost every single item I've written about (except about two sentences which I couldn't find a secondary source for because it's one specific event that isn't really substantial to most, but... well, anyways) is backed up by the various secondary sources that often accompany the primary sources. The primary sources are really amazing to look at and put everything into perspective (plus they detail things that the secondary sources miss or misjudge on, such as exact dates). The cameras are part of a special traffic management system, and aren't simply a discussion on traffic cameras - ʄɭoʏɗiaɲ ^τ _¢ 06:07, 10 March 2010 (UTC)

If I can toot my own horn for a moment... take a look at three FAs: U.S. Route 41 in Michigan, M-28 (Michigan highway) and M-35 (Michigan highway). Those three articles were all subdivided by geography in their RD sections, by topics in their Histories in chronological order. Other sections were divided out as apprpriate

Normally, I wouldn't cover accidents on highways in the articles. Let's face it, sadly, all highways will have traffic accidents. The M-15 (Michigan highway) article covers a specific accident as it was covered in the press, more so because that area of the highway is now given a nickname of "Death Alley", otherwise that wouldn't be included. For your rewrite, I'd suggest making some organizational changes. The section on "Carnage Alley" should be in a Route description section (or equivalent name). You should have a section where you start at one end and cover the path the highway takes to the other end. When you reach the part where Carnage Alley is located, break off to a subsection there to discuss it. Unless the speeding law was passed citing traffic on the 401 as a reason, I'd ditch that whole section. That's best covered in a separate article about the law. I'd make a section on the Names for the highway, move the Highway of Heroes subsection there after a section on the MacDonald-Cartier name, which I couldn't find discussed the the article at first glance. I had to do a text search to find it in the History section. Honestly, this article needs more on that name. The tables in the Future section could be removed and described in text better. One final word of note on your rewrite: the hidden image at the bottom of your infobox probably violates accessibility guidelines. Even if it doesn't violate the guidelines in a technical sense, you've hidden a photo that should be displayed, a photo should be in the M-C Freeway subsection. There are prose issues that I found that need to be cleaned up. (Highways can't conduct pilot projects on their own. Those are conducted by government agencies.) I also agree that the Lane Configurations should be in the RD section, and not a separate table. Imzadi1979 (talk) 03:42, 6 March 2010 (UTC)

I actually have been using your articles in Michigan as a guideline, I'll have you know :p

I am aware of most of the faults that you pointed out. The image will default to display, the history isn't complete past the first section whatsoever (just some sentences and refs at this point, as well as chunks from the old article). Same holds true for the Future section (except Mississauga and Durham, which are complete). I'll do some rearranging of my rewrite in the morning.

If I break a subsection off in the History or Route description section on a very specific topic (ie Carnage Alley; the big pileup was huge news when it happened, hence an article in Britain reporting it), do I just continue on into the general history after the two odd paragraphs, or should I have a new subsection header to bring the section back to a less specific tone? - ʄɭoʏɗiaɲ ^τ _¢ 08:06, 6 March 2010 (UTC)

Well, assuming that there's more recent events, then they'd just get a heading and you'd continue the section. The way you've done the History section in your sandbox is pretty much the way to do it. Imzadi1979 (talk) 18:53, 7 March 2010 (UTC)

Speaking of exit list questions

I would like some feed back on the most recent edits to the major intersections table for Sierra Highway. I knew someone would change it to look like this sooner or later, given the history of California Highway road articles. Is this kind of exit list appropriate? or should it be reverted to the version a couple of days ago? I was under the impression we should try to avoid redundancy in these tables (i.e. where due to concurrencies, etc. the same junction could be listed in multiple articles) as such I'm cringing at the latest addition, but would like some feedback to ensure it's not just me. For record the first sub-header is in error as the southernmost section is not entirely signed as SR-14U, only a small portion of it.Dave (talk) 22:15, 7 March 2010 (UTC)

I would revert the article back to the way it was. The approach that the article took prior to the recent edits is similar to the approach I took with Ridge Road, where I attempted to limit the amount of duplication that existed between the junction list on that article and those on the articles on NY 104 and NY 404. – TMF 23:19, 7 March 2010 (UTC)

My apologies, the above comment came out snarky, which was not my intent. I've copyedited my comment to better portray my true intent.Dave (talk) 16:24, 9 March 2010 (UTC)

On the topic of minor route lists...

List of minor routes in Pennsylvania still exists. I posted to the talk page last June, suggesting that it be disbanded due to its subjective inclusion/exclusion criteria (even though it offers one, who's to say that a 10.01 mile route is "major" and a 9.99 mile route is "minor"?) but that never really got anywhere. Since MD is currently evaluating their minor route list and ways to eliminate it, I figured I'd bring the PA one back to the table as well. – TMF 15:20, 8 March 2010 (UTC)

I would say split up the list and give the routes their own articles. Most of these routes had an article before the minor list was created. In addition, some of them are of a decent length in which a decent article can be written. ---Dough4872 18:45, 8 March 2010 (UTC)

I concur with Dough; all of these should be split into their own articles. Viridiscalculus (talk) 21:36, 8 March 2010 (UTC)

Pennsylvania's in bad shape as is. If we remake some of these articles, we do not need more stubs in their place. These should be forked as written to C or B, not cruddy stubs.Mitch32^{(We the people in order to form a more perfect union.)} 22:24, 8 March 2010 (UTC)

If I were to split up the minor list, I would give each article a brief route description and a junction list to make them at least start, in effort of avoiding creating more stubs. ---Dough4872 22:29, 8 March 2010 (UTC)

Why not leave them in the list until they have enough content to sustain their own Start+ article? —Scott5114↗ [EXACT CHANGE ONLY] 05:42, 9 March 2010 (UTC)

I concur. If the state's articles are in bad shape, having more of the routes on a list is probably better for the time being...unless there are editors that are going to be dedicated to improving those. There's plenty of other things to concentrate on. --LJ (talk) 08:04, 9 March 2010 (UTC)

I agree with this point. Yes eventually this page should be disbanded and the articles either expanded or re-organized in to a list that does not use a subjective criteria. However, I'd leave as is until the articles are expanded or until a better criteria for minor can be established, we've got bigger fish to fry.Dave (talk) 16:27, 9 March 2010 (UTC)

Something about this approach rubs me the wrong way. We should be taking steps to ensure these lists are never made again, and the way to do that is to eliminate the ones that exist. Whether it makes a state "worse" statistically by splitting the routes back out into separate articles should be irrelevant. I guarantee that if the approach suggested above is taken, this list will remain in place for another 2 1/2 years because editors will simply think "Oh, they're out of the way by being in the list, there's no need to work on them" and that is really the wrong mindset to have. – TMF 05:34, 10 March 2010 (UTC)

There a couple I ponder merging to somewhere else anyway (179 into either US 202 in PA or NJ 179, 261 with DE 261, etc). My only worry is not have to end up with stuff like Pennsylvania Route 958. I am content with a start, but not stubs everywhere.Mitch32^{(We the people in order to form a more perfect union.)} 13:31, 10 March 2010 (UTC)

I agree with your logic, just being practical. Everywhere you go there's lists like this, List of state highways in the United States shorter than one mile being an entire page with images, etc. that should be wiped using this same reasoning. If you're more wikignomish than me, by all means. =-) Dave (talk) 17:13, 10 March 2010 (UTC)

I didn't think about it that way, TMF. In splitting up the list, though, I would hope that each route could be improved to at least a start-class article before being pulled from the list. If there's any that are "perma-stubs", maybe those can be left alone until a better solution is found.

As to List of state highways in the United States shorter than one mile...why does this exist? --LJ (talk) 21:40, 10 March 2010 (UTC)

With the resources we have now for most states, I don't think it's possible to have a permastub article on a signed state highway. All that needs to be present for start-class is a lead, a good RD, and a junction list, and it really doesn't take that long to make any of those, particularly for routes under 10 miles in length. – TMF 00:38, 11 March 2010 (UTC)

That list exists when the category based on that criterion was "listified" at CfD. See Wikipedia:Categories for discussion/Log/2007 February 14#Category:State_highways shorter than one mile and Wikipedia:Articles for deletion/Log/2007 October 28#List of state highways in the United States shorter than one mile for more information. Imzadi1979 (talk) 22:34, 10 March 2010 (UTC)

If anyone wants, I could try to split up the minor list by making at least start-class articles for each road on the list or merge to other articles where necessary. ---Dough4872 03:24, 11 March 2010 (UTC)

Rockland County Scenario for Florida?

Judging by this Florida has a ton of stub county route articles. It seems the vast majority of them are one-county, but a few span county lines. Shall we do something like the Rockland County Scenario (lists of all CRs in each county)? —Scott5114↗ [EXACT CHANGE ONLY] 00:05, 5 March 2010 (UTC)

Two options, make county by county lists, or if there's some kind of zone system or number scheme, break into lists by numbers. If the list wouldn't be too unwieldy in the merger, merge them all together. Either method, I'm all in favor. Imzadi1979 (talk) 00:30, 5 March 2010 (UTC)

According to File:1946 numbering.jpg, there is a scheme. Do we group them by 100s? --Fredddie™ 01:27, 5 March 2010 (UTC)

That is always a possibility for sorting routes fit into a number scheme. ---Dough4872 04:35, 5 March 2010 (UTC)

That numbering scheme appears to be for Florida State Roads. Grouping the county route stubs by that scheme would not be appropriate, unless it could be shown that *all* county routes are former state roads. Many may well be former state highways, but some of them with four-digit numbers might suggest otherwise. A county-by-county listing might be more appropriate. --LJ (talk) 19:50, 5 March 2010 (UTC)

From what I know about FL, the county routes were former state routes that were turned over to the counties. Hence, the county route numbering system is intertwined with the state route numbering system. ---Dough4872 02:37, 6 March 2010 (UTC)

I think it would be nice if there were two sets of lists: a List of County Roads in X County, Florida, which would be RCS style, and a simple List of County Roads in Florida (x01-x00) that just showed the number and the counties through which the number passes. --Fredddie™ 03:17, 6 March 2010 (UTC)

That's always a possibility, but several county routes cross county lines. ---Dough4872 03:33, 6 March 2010 (UTC)

This could work like what California county routes did in making a list; all the one-county routes would go in the "County Routes in County X" list and the multi-county routes would be listed in all the counties it passes through. If any one is prominent, it can keep its own article. Pzoxicuvybtnrm 03:08, 12 March 2010 (UTC)

Off on a tangent: Category:Former State Roads in Florida lists several county roads that (presumably) were once state roads and later turned over to the counties. For those, it might be better to list RCS-style in an article devoted to former state roads in Florida. Now, I don't know how many county routes that would cover (probably a small percentage) or if it's even a viable option in this situation, but it's something worth looking into. – TMF 03:52, 6 March 2010 (UTC)

Another alternative

Are these even worth having articles on? Maybe before we try to come up with some way of organizing these, we should investigate their notability... —Scott5114↗ [EXACT CHANGE ONLY] 03:36, 7 March 2010 (UTC)

The ones that were once state roads are clearly notable. The idea that I presented above would take care of those. As for the rest, I personally believe Wikipedia shouldn't have any coverage of CRs, so I'm the wrong person to ask. – TMF 03:39, 7 March 2010 (UTC)

I think a list would be suitable for all county routes in FL. Most of them are not notsble enough for their own article, but we should not totally ignore their existence. ---Dough4872 16:51, 7 March 2010 (UTC)

Well, if they don't meet notability guidelines, we should ignore their existence since that's how WP works. However, I think the ship has long since sailed on that, unfortunately, so we're stuck with them. – TMF 03:35, 8 March 2010 (UTC)

Backlogs

• Category:U.S. road articles needing attention - 456
• Category:U.S. road articles with an exit list needing attention - 194
• Category:U.S. road articles without infoboxes - 230

—Scott5114↗ [EXACT CHANGE ONLY] 14:37, 10 March 2010 (UTC)

It probably wouldn't hurt for folks to take a brief look through these categories to make sure articles in their state are properly tagged. I've done a couple of spot checks and found a few not tagged correctly after changes. For example, Talk:Arkansas Highway 362 was tagged as not having an infobox and needing general attention, but the article itself redirects to List of Arkansas state highways--"class=redirect" had just been tacked that on the end of the USRD template without removing other tags (including the existing "class=stub" parameter). --LJ (talk) 05:08, 11 March 2010 (UTC)

In the infobox category, I noticed a few articles about traffic circles that were tagged. Is it even possible to give a traffic circle article an infobox? ---Dough4872 18:48, 11 March 2010 (UTC)

{{Infobox road junction}}. --Fredddie™ 21:01, 11 March 2010 (UTC)

ELG discussion

[22] --Rschen7754 17:49, 12 March 2010 (UTC)

Deletion discussion

Wikipedia:Articles for deletion/California State Route 30 --Rschen7754 01:46, 14 March 2010 (UTC)

USRD Announcements

I'm proposing to do away with the full version of our announcements template, {{USRD Announcements/Full}}, due to infrequent updates of state-level project information. The standard version would be retained. Please discuss at Template talk:USRD Announcements. Thanks. --LJ (talk) 01:37, 15 March 2010 (UTC)

DYK feedback

Resolved

 – Approved or DYK and appeared on Main Page March 12 --Fredddie™ 08:05, 16 March 2010 (UTC)

If anyone has a chance to comment at this DYK nomination for me, it would be appreciated. The hook on the odd one-way street configuration is referenced to 1) Google Maps, 2) the MDOT online official city inset. I could add a reference to the GIS data used to create the map made for the article. (If anyone wants, the reference for that is: {{cite web | title= MiGDL - Center for Geographic Information - Geographic Data Library | date=May 1, 2009 | work= [[Michigan Department of Information Technology]] | url= http://www.mcgi.state.mi.us/mgdl/?rel=thext&action=thmname&cid=14&cat=MI+Geographic+Framework+All+Roads+%28v7b%29 | accessdate=February 26, 2010 }} ) I'll be on the road today, so I can't check in until tonight sometime. Imzadi1979 (talk) 14:10, 8 March 2010 (UTC)

Please turn eyes to Wyoming

This doesn't rise to the level of being singled out in front of the entire project. There are times for that, but this isn't one of them. --Rschen7754 01:04, 16 March 2010 (UTC)

Extended content

I think we need to put another state on our watchful eyes here. Ngs61, a New York-editor who really does not seem to notice the really bad shape of his writing, is mass producing Wyoming articles, and after looking at the state of Wyoming Highway 116 (I've made major changes since), I think this needs to be halted fast. Even looking over his stuff, i.e. Wyoming Highway 114, there are a plethora of MOS violations state-wide, including bolding (like seen in 114), typos, concurrency colors still in use, unreliable sources, rather trivial information (a lot of these I had to pull from 116). I think we need to watch the state and its article conditions fast.Mitch32(We the people in order to form a more perfect union.) 22:23, 8 March 2010 (UTC) I fail to see the problem. - Algorerhythms (talk) 05:47, 9 March 2010 (UTC) I do see the problem, but I'm not sure that there's anything that can be done about it. --Rschen7754 07:17, 9 March 2010 (UTC) Agreed. WP as a whole is a bit (IMO, too) lenient when it comes to editors that edit in good faith but have poor editing tendencies or skills, as we've seen over the years. – TMF 05:42, 10 March 2010 (UTC) I'd ask, has the error been pointed out the person? If not, griping about it here isn't the appropriate course. (though I admit I do this myself, it's a bad habit) If the person has been shown where to find the newest standards; but continues, then I agree 100%. Wikipedia is too lax, and ideally would have ways of dealing with it.Dave (talk) 16:44, 10 March 2010 (UTC) It's been brought to his attention at least once (not by me), but as far as I can tell doing so hasn't done much - if anything - to change his ways. – TMF 00:34, 11 March 2010 (UTC) I'm not seeing flagrant violations of the manual of style. I do see some common errors that have been replicated throughout road articles being incorporated in these new ones. That's more of an issue of not understanding where to look for the latest standards than bad intent. In this case the articles being created are starter state highway articles. It's generally agreed that state highways deserve a mention in some form in Wikipedia. I'd say what's going on in this case is better than the mass production of county articles we've seen in some state projects, where the notability is less clear than with state highways.Dave (talk) 16:20, 9 March 2010 (UTC)

WP:USRD/ACR backlog

We need editors to review the backed up articles, some of which have been here since December. --Rschen7754 05:23, 16 March 2010 (UTC)

Proposal from WT:ELG international discussion

Resolved

 – This discussion is not at the correct forum, and discussions at the correct forum have rendered this moot. Imzadi1979 (talk) 06:31, 18 March 2010 (UTC)

There has been a proposal to adopt color-coded table headers and white-on-black. See potential mockups at User:Imzadi1979/Sandbox3. What are USRD editors' opinions toward this? --Rschen7754 20:51, 16 March 2010 (UTC)

All comments should be made at WT:ELG as the appropriate discussion forum. Imzadi1979 (talk) 20:56, 16 March 2010 (UTC)

I'm asking US editors to say here whether they want it or not. I have a right to ask that here. --Rschen7754 20:59, 16 March 2010 (UTC)

For the record, I don't think Imzadi was criticizing you; just trying to prevent a fork in the discussion. Dave (talk) 23:28, 16 March 2010 (UTC)

Yes but if those US editors want their opinions to matter, then they need to voice it at WT:ELG. - ʄɭoʏɗiaɲ ^τ _¢ 02:40, 17 March 2010 (UTC)

Is this a poll to get our opinions on (1) this scheme becoming a worldwide standard or (2) this scheme becoming an optional or mandatory standard for USRD? Viridiscalculus (talk) 03:15, 17 March 2010 (UTC)

2. --Rschen7754 03:28, 17 March 2010 (UTC)

Given that the white on black is being removed from the UK, per consensus at Talk:M25 motorway, and that consensus at WT:ELG is that the UK is getting a country-specific exemption for colored-colspans, and what I said below, this entire discussion here is a non-issue. I'm boldly ticking this entire section as resolved. Imzadi1979 (talk) 06:31, 18 March 2010 (UTC)

The issue is simple. I mocked up a variation of an American Interstate article using the UK-style headers. In the interim since those samples were made to show that it could be done in a measure of transatlantic consistency, Fredddie came up with a different way to denote the status changes between an A# road and a A#(M) segment or between sections of A roads that are primary and secondary. Also, since that sample was made, discussions on IRC have come around that the white on black headers are falling out of favor in the UK because of issues being discussed at Talk:M25 motorway concerning miles vs. kilometre measurements. No one has specifically advocated that the US make a change, only that the option has had a sample made. That's all. Imzadi1979 (talk) 03:22, 17 March 2010 (UTC)

In my opinion, I believe USRD is fine with its style of exit lists and that there is no need to adopt colors for US exit lists. Other countries such as Canada and the UK can use colors to suit their needs though. ---Dough4872 15:57, 17 March 2010 (UTC)

Should USRD adopt colors for junction rows again?

USRD should adopt the colors, both for the utility that colors provide, and for consistency with the other major road projects, which will probably use them rather heavily (Canada was the project which proposed the colors, while UK has been using them for quite some time). —Scott5114↗ [EXACT CHANGE ONLY] 05:09, 18 March 2010 (UTC)

I'm going to officially be no help on this issue. I am ambivalent towards either way. --Fredddie™ 05:32, 18 March 2010 (UTC)

My opinion on the issue hasn't changed. I opposed complete deprecation of them in the past, rather I favored making them optional. Yes, there are concerns with making information purely reliant on color, but I see maps all over Wikipedia that use color keys to denote which states have which laws, etc. When it is a map like those on the Powerball article, where the status is a binary yes or no, then it isn't an issue. Other articles like Abortion in the United States use the color key to denote multiple statuses. I'm not saying these examples are correct, rather that they are still common.

The position I favored before and favor still is that color is a secondary characteristic in terms of imparting the information. I have nominated four articles at FAC, three of which had concurrencies denoted in their junction lists with colors and text in the notes column to that effect. (The fourth was after the colors were deprecated, but doesn't have concurrencies so the deprecation of color wasn't relevant.) Out of the five FAC nominations for those three articles, no one commented on the colors in the backgrounds. These articles at the time had text notes in the Notes column and a color key at the bottom.

What I'm going to suggest is the following. Editors can use, on an optional basis, colors in the backgrounds of junction list tables. If a state subproject has no consensus either way, then whatever display methods in the table at the time the table is completed should remain. If a state subproject has a consensus to implement or not implement them, that consensus is controlling. I liken this approach to that which is taken about American vs. British English spelling, absent a geographical basis. Edit-warring over anything is bad, period. Forbidding something that can be done in an acceptable manner to prevent edit-warring is like throwing the baby out with the bathwater, IMHO.

If an article uses the colored backgrounds, they are a secondary method to denote the information. The primary method is always a text note of some kind in the table. If a table is using the colors, there must be the notes, and there must be a color key of some kind, either like the new {{LegendRJL}} or the older {{MIintlegend}}. Part of the problem with the colors previously was that the color key was removed from the bottom of the table as "bulky" or "clunky" without a replacement, but the new template produces a small row that spans the bottom of the table with the color key.

The last thought I have is that I agree with Scott. The biggest reason for the current, lengthy discussion at WT:ELG was to finally get some consistency in the standards. If we wanted to get others on board, we should have expected to compromise on some things, and this is one of them. To any editors who don't like the colors, don't use them. To those of us who do, we need to use them correctly. Imzadi1979 (talk) 06:17, 18 March 2010 (UTC)

I think the current proposal is much better than what was being done a few years ago. My concerns are with abuse (given past experience) not any reluctance about adopting the new standard being proposed. With that said, I have no intention of actively updating any articles to the new standard, but I will use them on all future work. Dave (talk) 06:35, 18 March 2010 (UTC)

I agree with Imzadi and Dave's comments. I'm not particularly keen on the colors, and it's a situation that rarely comes up in the Nevada articles that I focus on anyway. However, I've participated in the ELG discussion pertaining to colors in an effort to achieve uniformity in the colors for grander scheme of things. With the way the current color proposal is looking, it seems like there's adequate provisions in place to address the concerns raised. Thus, I think we should allow the use of color as an option to be decided upon at the state-project level.

My only suggestion for the USRD "policy" on this issue goes towards helping to stem possible abuse: Make "no colors" the de facto standard. State-level projects or task forces can opt to use color on articles under their scope. This way, in theory, colors are only used on articles that are more likely to be monitored in more active projects. I'm not sure if this is desirable or whether it would actually work, but I'll throw it out there nonetheless. --LJ (talk) 07:21, 18 March 2010 (UTC)

I am strongly opposed to adding colors back to the junction lists. Several months ago, we had a disucssion at WT:ELG over the issues colors presented for junction lists with roads that had freeway and non-freeway segments. At the time, colors were used in junction lists to denote concurrencies, former routes, etc. while exit lists were prohibited from removing colors. Because of this, roads with both freeway and non-freeway segments were divided into multiple tables in the Major intersections section (the list in this revision of New York State Route 104 was what motivated me to open the discussion). In the following discussion and straw poll, we had decided on one standard list for both freeways and non-freeways without the colors. There were multiple reasons for why the colors should be removed. If we decide to add colors back to the junction lists, then we will have several issues arise. Even worse, if we decide to make them optional, we will then have constant edit-warring between those who want colors and those who don't. ---Dough4872 15:33, 18 March 2010 (UTC)

Your reasons for opposition are baseless. The colors were removed for accessibility reasons—which are addressed by the new ELG. Exit lists were prohibited from having colors and junction lists could have them—now exit lists and junction lists both fall under ELG, which allows colors, and also prevents lists from being divided into freeway and non-freeway sections (not that that ever had anything to do with the colors). And if you have people edit warring over something as trivial as colors, ban their ass. Deal with the problem users, not try and make the whole encyclopedia into a padded cell for them. —Scott5114↗ [EXACT CHANGE ONLY] 16:05, 18 March 2010 (UTC)

Per Scott. Dough, if you don't want to use them, don't. It's that simple. As I said above, they are an optional formatting tool, and if a user edit-wars for any reason, colors, wording of text in an article, photo placement, "state-name" vs. "neutered" Interstate shield usage.... Edit warring is bad. It's so bad that it is an offense on Wikipedia subject to being banned from editing, termporarily or even permanently. If we really wanted to remove the ability to edit-war by disallowing things, the edit buttons would be removed from the articles. Imzadi1979 (talk) 16:10, 18 March 2010 (UTC)

I'll reluctantly support this as long as states that don't want to use colors aren't required to do so. In the case of New York, the overlap color is actively being phased out and what little articles use the unbuilt color probably use them in places that go against both the current and proposed text of ELG. – TMF 15:48, 18 March 2010 (UTC)

The only way I will support colors is if they are required for all junction/exit lists to mark concurrencies, former routes, etc. and are enforced and used properly. I would not like to see them made optional for the reasons I mentioned above. As a project, we have had problems with other aspects that have been made "optional". ---Dough4872 16:57, 18 March 2010 (UTC)

As to TMF's concern, this is why I suggested that the de facto position of USRD be to prohibit color unless a state project specifically wants to use them, which should be decided upon through consensus at the state project and that position indicated on the subproject page. Perhaps this wording is a compromise that will somewhat deter the proliferation of colors except for those. Right now, I get the sense that a few people would like to use background colors, but many others are hesitant at best.

As I see it, part of the problem before with exit lists having no color and junction lists having color was the fact that there was no guideline for the layout of junction lists. Looking back, that poll probably should have been divided into two parts, combining junction lists and the color issue. At any rate, junction lists are now part of ELG and the ELG provisions being discussed take many of the previous issues into account. (My previous problem with the colors was that there was no documented standard for them, which is being changed in the proposal.) If edit warring is going to come up over something this trivial, that is really childish and appropriate action should be taken—I would hope this project has moved beyond that by now. --LJ (talk) 18:55, 18 March 2010 (UTC)

Templates for Deletion

Wikipedia:Templates for discussion/Log/2010 March 19#Obsolete road infobox templates --Fredddie™ 00:46, 19 March 2010 (UTC)

Straw poll on ELG revision

There is now a straw poll at WT:ELG to decide on the proposed revision and renaming of WP:ELG. Imzadi1979 (talk) 02:08, 19 March 2010 (UTC)

Mile marker images

Just noticed that mile marker images have been added to some mileages on the junction list on the Interstate 10 pages (See Interstate 10 in Texas for example). Do we really want to go this direction? Or should the text mileages suffice? All the I-10 separated pages have some mile marker changes. 25or6to4 (talk) 20:50, 6 March 2010 (UTC)

Absolutely not, text conveys the information just fine. That user was also adding bold colspans. --Fredddie™ 22:31, 6 March 2010 (UTC)

I removed them from the I-10 pages, but it probably wouldn't hurt to do a sweep of interstates. --Fredddie™ 22:41, 6 March 2010 (UTC)

Wow...this might be the most blatant misuse of images I've ever seen. Using images of mile markers for mileposts in the junction list is akin to using shields for when a route is mentioned in article prose; in other words, a horrible idea. – TMF 02:09, 7 March 2010 (UTC)

I agree, images of mile markers should not be used in an exit list. On another note, is it really appropriate to use images of road signs (other than route markers) in an exit list, such as the green airport sign to convey an airport or the traffic signal warning sign to convey an at-grade intersection on a freeway? ---Dough4872 16:54, 7 March 2010 (UTC)

The key is that if the graphic is removed, is the meaning changed? In other words, are there notes or other text that convey the same information. The milemarkers failed that because they were replacing the text completely. As for Airport graphics, the Notes column should be providing a note, unless the airport is a destination. I don't see them as a problem since that graphic is on the BGSs. The traffic signal warning sign though is tacky, since that's not a graphic on BGSs. Imzadi1979 (talk) 17:46, 7 March 2010 (UTC)

In other words, you are saying that any graphics that appear on guide signs are acceptable to be included in an exit list? For example, guide signs for I-95 exit 4B in Delaware include a hopsital sign. Should this hospital sign be included in the exit list for Interstate 95 in Delaware then? ---Dough4872 18:09, 7 March 2010 (UTC)

I would say that it's only appropriate if the destination referenced is included. Interstate 275 (Michigan) has the airport sign for two exits where the signed access for DTW is indicated on the signs, and included in the Notes column. Usually in MI though, the Hospital symbol is used on blue supplemental signs, not the BGS itself. Imzadi1979 (talk) 18:32, 7 March 2010 (UTC)

So, in this case, the hospital sign would not be necessary? ---Dough4872 19:14, 7 March 2010 (UTC)

No. Imzadi1979 (talk) 19:26, 7 March 2010 (UTC)

The rational for the highway shields was aiding in identification when there are multiple highway types in the table. (i.e. US-40 verses I-40 verses NJ-40) If that is a gold standard, the hospital and airport shields would not be appropriate in most instances, as they serve no purpose as identification and are purely decorative in nature.Dave (talk) 22:15, 7 March 2010 (UTC)

Agreed entirely. To me, the hospital/airport/etc. shields/service signs are little more than fluff. – TMF 23:15, 7 March 2010 (UTC)

Should we do a sweep through articles to remove the decorative road signs? ---Dough4872 00:55, 8 March 2010 (UTC)

I would support that, but two editors != consensus. More input is probably needed. – TMF 03:36, 8 March 2010 (UTC)

I don't have a problem with airport signs, probably since I've used a few in junction lists. As long as they're not disruptive, unlike the mile marker images, they're fine. --Fredddie™ 04:06, 8 March 2010 (UTC)

I am in favor of retaining the airport signs, since airports are major destinations for which whole highways and multiple interchanges are typical built. Also, the airport symbol is universally known. The hospital H signs can go, though, since the footprint of a specific hospital, both physically and in relevance to the average person, is miniscule. Viridiscalculus (talk) 04:22, 8 March 2010 (UTC)

What about using the symbol for train stations, such as the Cornwells Heights station along Interstate 95 in Pennsylvania? ---Dough4872 04:28, 8 March 2010 (UTC)

I would have no problem with other intermodal signs. --Fredddie™ 04:31, 8 March 2010 (UTC)

The impression I'm getting here is that signs are okay for major transportation facilities such as airports and train stations but are not okay for facilities such as hospitals or for indicating a warning in the road such as a traffic light. ---Dough4872 04:40, 8 March 2010 (UTC)

The WP:TRAINS project's equivalent to our exit list guide, the rail station list, lists intramodel connection symbols. See California Zephyr for an example. If we follow their lead the airport symbol would be appropriate. However, I'm not sure how well the rail station list format passes the various accessibility and image tests. I'm not sure if an article like this has passed FAC scrutiny.Dave (talk) 04:50, 8 March 2010 (UTC)

I guess I'm fine with the usage of intermodal signs as long as its not mandatory (personally I think it's a bad idea). Then again, this project - well, some editors in it, anyway - has always had major issues with "optional" things. – TMF 04:44, 8 March 2010 (UTC)

We need to set an absolute standard that should be followed. ---Dough4872 04:57, 8 March 2010 (UTC)

Absolutely optional. --Fredddie™ 05:02, 8 March 2010 (UTC)

WP:IAR makes them optional. That said, I see no harm in allowing the intermodal symbols to be used. In Michigan, they're used on the guide signs in much the same way as highway shields are. Imzadi1979 (talk) 05:18, 8 March 2010 (UTC)

FYI, I have linked to this discussion from WT:ELG as I'd like to see the results of this discussion added to this guideline.Dave (talk) 18:17, 9 March 2010 (UTC)

I am a British Wikipedian who has never set foot in the US. For what it is worth, may I suggest that if the icon exists on the road sign, include it in Wikipedia, if it doesn't, then don't. Martinvl (talk) 07:05, 10 March 2010 (UTC)

I don't support the addition of any icons other than the highway shields. These icons are purely for decoration. --Rschen7754 07:12, 10 March 2010 (UTC)

In fact, I am against it. a) it's a waste of our time, b) it really looks tacky. c) it's probably a WP:MOSFLAG violation. d) How do you even source that? (And if the answer is "StreetView"... just... no.) --Rschen7754 07:48, 10 March 2010 (UTC)

Moreover, this is a solution (a bad solution at that) without a problem. --Rschen7754 00:39, 11 March 2010 (UTC)

In general, we don't include universities, county fairgrounds, airports, forestry services, lakes, parks, museums, zoos, amusement parks, arenas, greyhound tracks, DOT residencies, or any of the myriad of other things that would be signed on supplementary signage in the exit lists. Why would we include airports and other intermodal facilities just because they can be distilled into a MUTCD image? If we're going to start that, we may as well include "Ok. Dept. of Agric. Forestry Services" that are signed for the Goldsby exit from I-35. —Scott5114↗ [EXACT CHANGE ONLY] 08:50, 10 March 2010 (UTC)

Looking at more train articles, it's clear the WP:TRAINS has found a way to make it work. However, the challenges our project faces are different then those of the trains project. I'm not opposed to the idea of intermodal facilities having shields. However, I fully understand Scott and Rschen's logic and agree that the situation is more likely to spiral out of control with a road article than a train article. (I.e. with a train article, either the train stops at a place or it doesn't; there is no debate on what should be included, like we have with intersections on road articles)Dave (talk) 16:58, 10 March 2010 (UTC)

I agree that signs for intermodal connections off an exit are unnecessary in an exit list and WP:ELG and WP:USRD/STDS should be amended to reflect any changes we should make regarinf these signs. ---Dough4872 03:22, 11 March 2010 (UTC)

I propose adding something to ELG restricting the use of extra signs such as those described above. What do people think? --Rschen7754 08:03, 12 March 2010 (UTC)

I agree, we need a rule to eliminate the use of these signs. ---Dough4872 17:50, 12 March 2010 (UTC)

Refocus

After all.... that at WT:ELG... what do we think about this issue? --Rschen7754 07:17, 19 March 2010 (UTC)

Funny how this was completely missed in all that...

On one hand, you don't want a bunch of needless symbols in the lists. On the other, using an image to denote a major airport is not all that different from using an image to denote a numbered highway. If the airport/train station is signed on major guide signs in the field, I don't have a problem with including it in our lists. But honestly, I can go either way on this. --LJ (talk) 07:44, 19 March 2010 (UTC)

From the above discussion, it appears that the majority of users seem to be against the idea of including intermodal signs in the exit lists. This issue should have been brought up at the big discussion at WT:ELG. ---Dough4872 15:07, 19 March 2010 (UTC)

It is because that's decoration. --Rschen7754 23:53, 19 March 2010 (UTC)

Article alerts and recognized content

We have Article alerts and Recognized content lists being maintained by bots. Currently, links are provided for those pages, but the content can be easily transcluded onto WP:USRD. Should we keep them as-is or transclude? --Fredddie™ 04:44, 19 March 2010 (UTC)

Leave as-is. I cleaned up and reorganized the main page with the intent of reducing the amount of information on the page and making it more of an overview and summary of the project structure. Adding a bunch of transclusions gives the page a more cluttered look and adds more things to sift through if you're just trying to learn about the project at a glance. That's why there's a brief mention and some recognized content items there, but the main information is left to a subpage that lists everything for those that are interested. --LJ (talk) 06:41, 19 March 2010 (UTC)

Agreed with LJ; however, I have one issue with what's present on the recognized content subpage. I know the GA process isn't nearly as good as it used to be, but I still find it odd to list one-off things like articles featured on Did you know? (which any new article could be if they have a half-decent hook) and not list good articles. – TMF 14:32, 19 March 2010 (UTC)

When the bot first ran, good articles were included. But since there are over 350 good articles, the page got quite long and not at all suitable for transclusion. --Fredddie™ 22:07, 19 March 2010 (UTC)

If not transcluded on the main project page, it wouldn't hurt the recognized content page to list all of the good articles. --LJ (talk) 22:19, 19 March 2010 (UTC)

I found the diff where I removed them and added them back. When the bot runs next, they'll still be there. --Fredddie™ 22:20, 19 March 2010 (UTC)

Thanks. I kind of figured they were removed when the page was still being transcluded, but I didn't know if they were being purposely omitted or not after the transclusion was removed. – TMF 23:41, 19 March 2010 (UTC)

Article alerts lets us customize how long articles are listed, defaulting to 14 days. Is this appropriate or should it be shortened/lengthened? --Fredddie™ 01:01, 20 March 2010 (UTC)

Clarification: Each listing remains in the report until clearing a workflow. Afterwards, the entry stays on the AA report for a time before it is removed (default of 14 days).

I wouldn't extend that listing time, but it probably could be shortened to 7 or 10 days if desired. --LJ (talk) 02:07, 20 March 2010 (UTC)

I wouldn't mind shortening the interval to a week. Imzadi1979 (talk) 19:17, 20 March 2010 (UTC)

What if we put article alerts on the blog? --Rschen7754 07:27, 20 March 2010 (UTC)

No matter where is it or isn't transcluded, the only want to follow the updates to it is to watchlist the alerts page itself. Putting it on the blog might be appropriate, but maybe add a note with a link so that people know to watchlist the alerts page? Imzadi1979 (talk) 19:17, 20 March 2010 (UTC)

Help with {{Infobox road}}

I would like some help fixing bugs in a mockup of {{Infobox road}} that I have created. Once finished, I will propose making the changes permanent. Discussion is at Template talk:Infobox road#Assistance is required --Fredddie™ 03:39, 22 March 2010 (UTC)

TfDs

I nominated three old MI templates for deletion at TfD. Imzadi1979 (talk) 07:25, 23 March 2010 (UTC)

comments

Comments wanted here. Respective state Wikiproject is inactive. Griffinofwales (talk) 14:41, 24 March 2010 (UTC)

Shields on dab pages

See WT:HWY#Shields on dab pages. – TMF 03:46, 28 March 2010 (UTC)

Join the WP:USRDCUP 2010!

We're going to go ahead and try this again! The contest will begin April 1. It is a contest to encourage editors to improve teh quality of WP:USRD articles and participate in USRD. Precautions will be taken to make sure that people do not "game the system" and bring article quality down. Please sign up ASAP! Announcements regarding the contest will be made at WP:USRDCUP, Twitter, and/or IRC. --Rschen7754 06:51, 28 March 2010 (UTC)

U.S. Roads Portal

We have a portal located at P:USRD. The content for it automatically updates monthly, assuming that selections are made for the new month. In keeping with the spirit of April Fool's Day on Wikipedia, the portal will (should) automatically update itself for that day only with special, humorous content, which has already been selected. I need some help though. The DYK hooks nominated, save one, are all previously nominated hooks that have been rolled over. The previous pictures have been archived, and some additional nominations made. Please go to the portal and nominate some additional DYK hooks, and comment on the photo nominees. Hooks need not be from new or newly expanded articles. The only requirement is that the hook be referenced in the subject article, that the subject link in the hook be in bold, and that the fact from the hook be interesting in some way. We have until midnight on April 1 (UTC) to make the selections, so I'd like to be able to create the subpages sometime while the April Fool's edition is live, otherwise the portal will revert to the March content (except selected article) on April 2. Imzadi1979 (talk) 00:03, 29 March 2010 (UTC)

P.S. We do try to maintain a regional balance to the content on the portal. Feel free to make DYK nominations from any state all over the country. Previously used Main Page DYKs are perfectly acceptable at any time as long as the article hasn't been used for a hook on the portal before. If it was only used for April Fool's Day in a humorous way, it can be reused at a later time in a serious way. Imzadi1979 (talk) 00:07, 29 March 2010 (UTC)

Wikipedia:Articles for deletion/Ventura Freeway

See above. --Rschen7754 23:41, 28 March 2010 (UTC)

This nomination was withdrawn, with something to the affect of, "needs more discussion". Is there anything that should be discussed now? Dave (talk) 03:48, 30 March 2010 (UTC)

There is current discussion at Talk:California State Route 134. --Rschen7754 04:16, 30 March 2010 (UTC)

Wikipedia:Articles for deletion/Ventura Freeway

See above. --Rschen7754 23:41, 28 March 2010 (UTC)

This nomination was withdrawn, with something to the affect of, "needs more discussion". Is there anything that should be discussed now? Dave (talk) 03:48, 30 March 2010 (UTC)

There is current discussion at Talk:California State Route 134. --Rschen7754 04:16, 30 March 2010 (UTC)

Merge proposal: Interstate 695 (New Jersey)

Resolved

 – Merged.

Interstate 695 was never built, but before the freeway was cancelled, it was proposed as a realigned Interstate 95. I'd like to propose to the merge this with Interstate 95 in New Jersey, as having two articles is rather redundant. We also had Somerset Freeway, which was merged with I-95 NJ. Thoughts?Mitch32^{(We the people in order to form a more perfect union.)} 17:23, 30 March 2010 (UTC)

Merge. I-695 can easily warrant coverage in the I-95 article. ---Dough4872 17:24, 30 March 2010 (UTC)

I'll support a merge. Though, my question is why are we creating articles for routes that never existed? --Fredddie™ 22:06, 30 March 2010 (UTC)

This particular one was made by an IP in 2005, so hopefully we can say it's a relic of a bygone era of USRD. – TMF 22:13, 30 March 2010 (UTC)

What if we did a newsletter again?

So... WP:USRD/B, our blog, has died. :| I think the problem with the blog is that not very many editors know about it, and it's never updated.

My proposal is to revive our newsletter again. For those who have joined USRD since late 2008, we used to have a newsletter - you can see WP:USRD/N to look at the previous issues.

I believe that today as a project we are different and that we could try a newsletter again and have more success. Below were the issues with the previous implementation of the newsletter and ways to fix them:

1. Trying to do it once every two weeks was way too much work, and frequently there wasn't enough stuff to fill up the newsletter. We should do it less frequently.
2. We always had to have 3-4 featured stories for each edition. In a future newsletter, we shouldn't force there to be more than one featured story. If there is, great; if not, move on.
3. Featured member was awkward. If we didn't feel like someone should be featured member, we had to shoot them down; and nobody ever wanted to write the featured member section.
4. Project (USRD) updates were always copy-pasted from the last edition of the newsletter and weren't up to date.
5. There usually was one editor who wound up doing 75% of the newsletter because people were inactive or lazy. But this was in the days where the portal would go for months without being updated.
6. Comings and goings was lame.
7. We had two arbitration cases, and it was always awkward to write about those. I don't anticipate having any more for a long time. It's been almost two years since the last case.
8. Overall, we bit off way more than we could chew and generated too much work for ourselves, so that we procrastinated with the newsletter and sometimes it got delayed for a few months.

I believe that we could try a newsletter again. My proposal is to do a monthly newsletter that gets rid of all of the problematic sections that nobody wanted to write, and to reduce the size greatly. This way, it's not a monstrosity that never gets done, and it makes people feel connected to the project, increasing participation.

Thoughts? --Rschen7754 06:44, 30 March 2010 (UTC)

Here's my outline for a possible newsletter structure. We can borrow stuff from the portal and the blog. We can feature an article of some kind, like the portal. Toss in a photo feature. Pull in some updates on what's happening around the whole project, summarizing some of the stuff that popped up on Article Alerts (list of new GAs, FAs, AfDs, etc). The leaderboard is a popular concept that was being updated on the Blog, so that could stay. We could do a "recognized member" on an as-needed basis too. Imzadi1979 (talk) 07:04, 30 March 2010 (UTC)

Part of the problem with the blog is that it doesn't have a set schedule. You never know when the leaderboard update is going to be updated...Also blog is a silly word

If we go through with this, I think we should do it on a monthly basis. There's already a bunch of stuff that gets done at the first of the month—the graphs and some of the maps—so if we do the newsletter at the same time, the assessment stuff will tie into that. (I could resume my traditional role of providing assessment updates State project updates are a good thing to have—people have some pride in their project and like to share what they're up to and where work is occurring. But don't make every state submit something; if nothing much is going in a project they shouldn't be compelled to post a note to that effect. Stories should focus on the goings-on within the project; we had a few stories in the old newsletter about road stuff that's happened outside of Wikipedia (I remember one about a flood on I-5?), and that's not what the newsletter's purpose is. Maybe go over the archives of this page and have an article of all the important discussions that occurred over the month.

Can we secure a bot to distribute it? I remember one of the problems being getting someone to "deliver" the newsletter. We should be able to tell a botrunner "Okay, Lou, send them out!" and promptly get a reply of "My name's not Lou and never has been but whatever I'll have it deliver them" and they appear. Shouldn't spend too much time on this sort of meta-stuff, after all. —Scott5114↗ [EXACT CHANGE ONLY] 08:09, 30 March 2010 (UTC)

I can AWB it if needed - I still have User:Rschen7754bot which is still technically approved as the alternate. --Rschen7754 08:21, 30 March 2010 (UTC)

IMO, I think we could look in to reviving the newsletter. I do try to add updates to the blog though, particularly with recognized content and the stub count update. However, it would be cool to have a formal newsletter again as it is more structured. ---Dough4872 17:10, 30 March 2010 (UTC)

Thing about AWB is it still requires someone sitting there hitting the button, which is work. For something like this, there's really no call for that (especially since bot approval is really only needed for applications where someone isn't sitting there hitting the button). It should be as simple as executing a script that does foreach in @users_on_list { deliver_newsletter(); } —Scott5114↗ [EXACT CHANGE ONLY] 04:50, 31 March 2010 (UTC)

I can do it on automatic mode. --Rschen7754 02:08, 1 April 2010 (UTC)

The problem with the newsletter was that we often didn't have enough users contributing content to come up with a new issue every month. So what ended up happening is one month became 6 weeks, which became 2 months, then we said, screw it. We'll just replace this with a blog and update the blog as stuff comes in. I'm OK with the idea of a newsletter, but if we don't have enough content being submitted to keep the blog updated, are you sure we will with a newsletter? Maybe the answer is better promotion of the blog's existence. (it was never really advertised, it was more of a footnote in the last newsletter, without a direct link even). With that said, I think one thing that we should discuss is the "Featured Editor" we haven't had one in a year or so, and there are enough people working on road articles that a lot of people out west don't know what's going on back east, and vice-verse. IMO that's where sections like this help.Dave (talk) 17:40, 30 March 2010 (UTC)

Well, that's why I'm thinking we can "borrow" some content from the Portal to flesh out the content of the newsletter. Run with the selected article (or even any previously selected article from the Portal archives). Do the same with a selected photo. As situations warrant, we could have a "recognized member" that doesn't have to be a monthly feature. The leaderboard and stub count updates from the current blog would be transferred to the newsletter. The old one used to have a leaderboard feature, and the stub-expansion drive is a current project-wide activity. The final regular feature I'd have is a summary of the activity through Article Alerts. That bot-generated page (watchlist Wikipedia:WikiProject U.S. Roads/Article alerts if you haven't already) lists ever page tagged with the project's banner than is PROD-ed, AfD-ed, GAN-ed, FAC-ed, etc. Someone could skim through the history for a brief synopsis of deletion discussions, article promotions, etc. The only thing that isn't listed through there is the project's ACR process. If there are any big debates going on, like the ELG/RJL discussion, well, they can have a separate story in the newsletter. I'm sure we can even once in a while pull in stuff from CRWP and UKRD for variety. (Canada has had their own mini version of SRNC recently.) One last regular feature that's possible now is a "In this month of USRD history" with a peek at something from an old newsletter or blog posting. The newsletter doesn't have to be long to be effective. The best part is that it is delivered to project members' talk pages, where readers kinda have to seek out the blog now if they want to catch up. Imzadi1979 (talk) 21:58, 30 March 2010 (UTC)

I agree with Dave. I never sensed the "blog" (yes, let's change that name if we stick with it) was very well utilized. Then again, it's not like people referred to it all that often. Reinstating the newsletter certainly has its merits... but I feel that it'll lose steam as it did the first time around. We might as well try, I suppose. Might prod some people to start editing again when they see the latest issue of the newsletter on their talk page. CL (T · C) — 03:21, 31 March 2010 (UTC)

The newsletter is active - see Wikipedia:WikiProject_U.S._Roads/Newsletter/Issues/Volume03/Issue01 for the working copy of the first edition, and Wikipedia:WikiProject_U.S._Roads/Newsletter/Newsroom for the newsletter. --Rschen7754 05:01, 1 April 2010 (UTC)

Rockland County Scenario for Appalachian Development?

What are the possibilities for enacting a Rockland County Scenario-type page for the Appalachian Development Corridors? (Corridor A, Corridor B, etc.) Most of them overlay current or future routes (e.g. Corridor E is Interstate 68, Corridor X is future Interstate 22). I think some corridors overlay multiple other highways, so the RCS works better than straight merges. —Scott5114↗ [EXACT CHANGE ONLY] 04:14, 30 March 2010 (UTC)

I like this idea a lot as I think all of the corridors would fit into Appalachian Development Highway System without any problems. – TMF 04:26, 30 March 2010 (UTC)

Support. --Rschen7754 04:42, 30 March 2010 (UTC)

I concur. Imzadi1979 (talk) 04:47, 30 March 2010 (UTC)

Definitely. In addition, some of the ADHS routes that only follow one route should redirect to that article. ---Dough4872 17:12, 30 March 2010 (UTC)

They would still have their own section with a hatnote linking to the redirect target though. – TMF 17:47, 30 March 2010 (UTC)

This looks like a thumbs-up, so how should it be set up? Retain the "List of ADHS corridors" header and have the corridors in third-level sections? Once we decide on a format, I'm game for helping out with the conversion. – TMF 17:47, 30 March 2010 (UTC)

I would say that your idea of third-level headers would work. ---Dough4872 17:48, 30 March 2010 (UTC)

Sounds good to me. Do we need to make any changes to IRS so that a name parameter is added for these corridors? Imzadi1979 (talk) 22:01, 30 March 2010 (UTC)

Just did them. =) – TMF 22:28, 30 March 2010 (UTC)

Mergers done except for Corridors D, G & H. The were more developed, so I'll let us discuss what do do with those articles. They probably need to be summarized to be merged, or left alone. Thoughts? Imzadi1979 (talk) 01:02, 31 March 2010 (UTC)

Why were these merged? There's more than enough information about most of them for their own articles. The best example is Corridor H-to-nowhere (which is a better-known name than proposed US 48), but all of these are major highways. --NE2 01:36, 31 March 2010 (UTC)

Several of the corridor articles were redirects (which weren't changed) and the rest were permastubs. Nothing prevents splitting articles out that have been expanded. In the Rockland County Scenario (RCS), that's fine. The list of county-designated highways in Michigan has a few that are split out, leaving summaries behind. The rest redirect to the list. Imzadi1979 (talk) 01:40, 31 March 2010 (UTC)

In addition, most of the ADHS routes were either just one route or a collection of various routes. In most cases, separate articles would be redundant and short. Therefore, the RCS is the best way to handle these routes. ---Dough4872 01:46, 31 March 2010 (UTC)

But the upgrades were done by corridors; if anything the corridors are more important than the routes they carry. Corridor D, for example, is SR 32 in Ohio and US 50 in West Virginia, but across Ohio it's more important than US 50. Corridor V follows US 278, MS 76, US 78, MS 25, SR-24, and US 72, yet forms a cohesive corridor. The corridors, not the numbered routes, should (in most cases) be the bottom-level articles that describe the roads in detail. --NE2 02:46, 31 March 2010 (UTC)

I don't think you're going to get much support for that assertion around here. To the road user, the corridors mean nothing; the actual highway designations take top priority over these paper designations (Alabama alone seems to go through the pomp and circumstance of signing AHD corridors, and they're still secondary to the numbered routes, of course) because that's what is presented to the traveling public. It should be trivial to explain the changes brought about due to the AHD corridors within the history section of the article (Route X from Keenansville to Brockingrock is part of Appalachian Development Corridor Æ... Route X was upgraded to a freeway during the mid-2000s with funding from the Appalachian Development System.). If people are looking for a summary of the corridor and when its associated upgrades occurred, they can look at the list. And if someone wants to really job out and write an FA about Corridor Ø, then they can split that out of the list when the content is adequate enough to support its own article. —Scott5114↗ [EXACT CHANGE ONLY] 05:04, 31 March 2010 (UTC)

Really? Really? Really? WVDOT didn't open a new segment of "future US 48" or "relocated WV 55"; they opened a new segment of "Corridor H". The Sierra Club doesn't oppose "future US 48" or "US 33/WV 55"; they oppose "Corridor H". It's different for most corridors that follow one numbered route (such as E, S, and T), but many of the others comprise several routes that, prior to the improvements, weren't the best path through the corridor. There was no cohesive route until the corridor came along, and now that's a better-known designation than the number(s). --NE2 08:18, 31 March 2010 (UTC)

Your opinion has been noted and disagreed with. —Scott5114↗ [EXACT CHANGE ONLY] 08:50, 31 March 2010 (UTC)

I'm rising high above the Appalachians in a balloon powered by care. --NE2 12:25, 31 March 2010 (UTC)

While I find this mildly amusing, perhaps a better use of time would be to produce a list of the Appalachian development corridors and a suggestion if each is better suited to a single article, or articles for each numerical designation. I like the idea that we could have 1 article to maintain rather than 5 (especially if the 5 are permastub state routes). I'm all for combining articles where appropriate. However, I don't know enough about this region to make any kind of judgement call. Silly me, thinking I could follow the discussion and learn and make an informed opinion. For the record, this still means we could have a single article for the ADC system, just combine a few state route articles into an ADC article. I don't see these two ideas as mutually exclusive.Dave (talk) 15:18, 31 March 2010 (UTC)

• Corridor A: US 19, US 64, etc.; much of this is also State Route 515, so the latter could be merged into the former
• Corridor B: US 23 (including I-26 extension)
• Corridor C: US 23 (future I-73)
• Corridor D: State Route 32, US 50; forms a more cohesive corridor than US 50 itself
• Corridor E: I-68
• Corridor F: a bunch of routes; not sure how much of a cohesive corridor this is
• Corridor G: US 119
• Corridor H: road to nowhere with several designations (future US 48)
• Corridor I: KY 15 and Mountain Parkway (the latter built pre-ADHS, so maybe redirect to KY 15)
• Corridor J: a bunch of routes; not sure how much of a cohesive corridor this is
• Corridor K: US 74
• Corridor L: US 19
• Corridor M: US 22 and a bit of US 119
• Corridor N: US 219
• Corridor O: I-99
• Corridor P: US 220 and I-180
• Corridor Q: US 460
• Corridor R: Mountain Parkway and KY 40 (the former built pre-ADHS, so maybe redirect to KY 40)
• Corridor S: US 25E
• Corridor T: NY 17 (future I-86)
• Corridor U: US 15 (future I-99)
• Corridor V: a bunch of routes
• Corridor W: US 25
• Corridor X: US 78 (future I-22)

Over half are a single route, and can easily redirect, rather than the current setup (Appalachian Development Highway System#Corridor W talking about the entire length of US 25!?). --NE2 03:18, 1 April 2010 (UTC)

I like how the list has been set up and I support hatnotes to main articles about either the involved routes or the corridor itself if there is enough info for a standalone article. However, I am concerned about some of the contents of the list. For instance, the section for Corridor W is a summary of all of US 25. Only a small part of the US 25 corridor is part of Corridor W; only that relevant section should be explained. Also, the content in the infobox small is self-conflicting, describing the corridor as 750 miles long and existing since 1926, yet the distance between the stated endpoints of Corridor W is much less than 750 and ADHS was instigated in the 1960s. Furthermore, it would be disingenuous to have a search for Corridor W redirect to US 25 when Corridor W is such a small portion of US 25. Viridiscalculus (talk) 18:18, 1 April 2010 (UTC)

Project meetup

The topic of a potential USRD meetup came up once again this evening on IRC, and I think we should really look into planning one within the new few months to a year. Real-life meetups are excellent for building and maintaining a sense of community within the project, and induce productivity on-wiki as well. The main issue is finding a reasonable location to hold the meetup, which is accessible to as many folks as possible. A few of us seem to agree that late-summer would be ideal for this year. In any case, comments and suggestions would be appreciated with regard to a potential date and location. –Juliancolton | ^Talk 03:42, 1 April 2010 (UTC)

A few cities that have been mentioned include Pittsburgh, NYC, and Cincinnati, FWIW. –Juliancolton | ^Talk 03:53, 1 April 2010 (UTC)

Maybe somewhere more central? (Though I may not be able to attend). --Rschen7754 04:04, 1 April 2010 (UTC)

Well, ideally it would be west of the East Coast, but I think most editors are in the northeast part of the country. Alternatively, there could be a few meetups at different times to allow different regions to get together. –Juliancolton | ^Talk 04:09, 1 April 2010 (UTC)

Salina, Kansas, maybe? Close enough to Lebanon :P —Scott5114↗ [EXACT CHANGE ONLY] 06:15, 1 April 2010 (UTC)

JC, the regional idea comes more to mind than everyone at one.Mitch32^{(We the people in order to form a more perfect union.)} 00:10, 2 April 2010 (UTC)

USRD WIKICUP 2010 is effectively dead, unless...

See User:Rschen7754 for more information.

Unless someone else wants to step in and take over the cup, it's dead. --Fredddie™ 07:45, 4 April 2010 (UTC)

Considering I am not in the contest, but criticizing the noms, I can do the job if needed. Any thoughts?Mitch32^{(We the people in order to form a more perfect union.)} 14:51, 4 April 2010 (UTC)

I was thinking of taking over administration of the contest, but I think it would be preferable for someone not competing in the contest to take the lead there. I support Mitch taking over administration of the Cup. Viridiscalculus (talk) 17:16, 4 April 2010 (UTC)

After further reflection, yes, it was a bit irresponsible for me to suddenly abandon the contest, and I do apologize for that. However, as I only had two judging sessions and both sessions resulted in arguments on IRC, my position as a judge would have quickly become untenable regardless. I thank Mitchzenia for his willingness to step up to this position. --Rschen7754 05:32, 5 April 2010 (UTC)

USRD leaderboard

Coming soon will be a new leaderboard updated daily by WP 1.0 bot, the same bot that updates the stats that go into the leaderboard. This new leaderboard should function exactly like the old one, except no one will have to update it manually, ever. Until then, Imzadi1979 and I created a live-updating leaderboard. We tried to make it a full table, but technical limitations prevented that from happening. --Fredddie™ 02:40, 5 April 2010 (UTC)

Proposed move

An IP has proposed moving Interstate 110 and State Route 110 (California) to Highway 110 (California). See Talk:Interstate 110 and State Route 110 (California)#Move request for the discussion. – TMF 03:29, 5 April 2010 (UTC)

MOSICON discussion

I saw this posted to the Shields Task Force talk page and thought to list it here since not all USRD members watch that page. There is a discussion going on at Wikipedia_talk:Manual_of_Style_(icons)#Routes.2FHighways about the use of route marker images on "List of Highways numbered X" type articles. -- LJ ↗ 20:14, 6 April 2010 (UTC)

Notification regarding Wikipedia-Books

Hadronic Matter An overview

An example of a book cover, taken from Book:Hadronic Matter

As detailed in last week's Signpost, WildBot has been patrolling Wikipedia-Books and searched for various problems in them, such as books having duplicate articles or containing redirects. WikiProject Wikipedia-Books is in the process of cleaning them up, but help would be appreciated. For this project, the following books have problems:

• Book:Numbered highways in Amenia (CDP), New York (problems)

The problem reports explain in details what exactly are the problems, why they are problems, and how to fix them. This way anyone can fix them even if they aren't familiar with books. If you don't see something that looks like this, then all problems have been fixed. (Please strike articles from this list as the problems get fixed.)

Also, the {{saved book}} template has been updated to allow editors to specify the default covers of books (title, subtitle, cover-image, cover-color), and gives are preview of the default cover on the book's page. An example of such a cover is found on the right. Ideally, all books in Category:Book-Class U.S. road transport articles should have covers.

If you need help with cleaning up a book, help with the {{saved book}} template, or have any questions about books in general, see Help:Books, Wikipedia:Books, and Wikipedia:WikiProject Wikipedia-Books, or ask me on my talk page. Also feel free to join WikiProject Wikipedia-Books, as we need all the help we can get.

This message was delivered by User:EarwigBot, at 22:34, 7 April 2010 (UTC), on behalf of Headbomb. Headbomb probably isn't watching this page, so if you want him to reply here, just leave him a message on his talk page. EarwigBot ^{(owner • talk)} 22:34, 7 April 2010 (UTC)

Assessment discrepancies

Resolved

 – Subcategories removed, correcting the USRD total counts. Imzadi 1979 → 05:21, 12 April 2010 (UTC)

Since Rschen left, we've developed a few assessment tools that use the PAGESINCAT function to try and provide a live-updated equivalent of the work he did. However, I'm noticing these are giving different outputs than the "known good" bot values (which are supposedly derived from the same category); note the stub counter on the project page, and compare it to the bot output below. I purged the cache and did a manual run of the bot earlier, but the difference remains. Anyone know what the cause of this is? —Scott5114↗ [EXACT CHANGE ONLY] 06:57, 7 April 2010 (UTC)

The only ideas I had are that 1) that some categories might be counted twice somehow or 2) the server software might have a delay of some sort like the job queue. The queue idea can't be right because the {{AbQ}} template is how we figured out how to build those tools, and AbQ works live on all the assessment categories I've used it on. There must be some grouping that somehow is being counted twice or not counted at all. Imzadi 1979 → 07:14, 7 April 2010 (UTC)

WikiProject U.S. Roads  articles by quality     

FA	A	GA	B	C	Start	Stub	FL	AL	List	SIA	Future	Category	Disambig	Draft	FM	File	Portal	Project	Redirect	Template	NA	???	Total
84	21	1,183	1,587	3,763	4,457	1,324	10	0	985	128	48	1,686	286	15	6	808	51	313	10,044	128	1,839	0	28,632

Looks like it's providing the "wrong" count too—5,502 is what the stub counter on the project page is saying, while 5,486 is what the bot is saying. —Scott5114↗ [EXACT CHANGE ONLY] 08:05, 7 April 2010 (UTC)

It's possible that the bot isn't catching everything. When I did the manual table updates, I started by comparing the live table with the full table that I copied into a spreadsheet and printed. For any states/projects with differing WW numbers, I copied the live numbers to the printout, and looks up the tables for that state/project to update the class numbers. At least two states, I had to actually check categories and came up with a slightly different result. I wonder if the bot isn't updating all 58 sets of assessment tables correctly. If that's the case, the PAGESINCAT-derived tools might be correct, but the bot-derived numbers will never be totally correct. I'll take a look over the next few days to see what I can determine comparing each state/project's tables to the category numbers. Imzadi 1979 → 10:19, 11 April 2010 (UTC)

One thing I noticed just now is discrepancy in the categories the USRD project template is using. For example, the Articles by Quality table above only shows one NA article in the whole project. We've tagged all the project pages with NA-Class, so the table should show way more than one. The discrepancy seems to be that the Articles by Quality table is looking for Category:NA-Class U.S. road transport articles and the template is putting most NA pages into Category:Non-article U.S. road transport pages. I don't know if this provides any insights into the stub count discrepancy or not, but it should probably be fixed regardless. (The USRD template should probably also be set up to use Project-Class...it seems odd to have so many pages tagged as NA.) -- LJ ↗ 21:28, 11 April 2010 (UTC)

Agreed on the category comments. I took a quick look at Category:NA-Class articles and it seems the overwhelming majority of projects use the "NA-Class <topic> articles" format. Additionally, the Project-Class category for USRD was set up by Fredddie a couple of months back but was never coded into the template. Since I don't see these proposed changes (tweaks, really) as being controversial, I'll implement them right now. – TMF 21:47, 11 April 2010 (UTC)

 Done, plus I also added support for Portal-Class (the cat for which was also made months ago). – TMF 22:12, 11 April 2010 (UTC)

I think I have an explanation: It seems the PAGESINCAT function is returning the number of articles and additional categories residing in the category. As I'm writing this, the Articles by Quality table above and the stub counter on the main page (which is using PAGESINCAT) both say there are 5467 stubs in the project. When you click on the "articles by quality" link above, it says "(37 C, 5430 P)" next to the stub category link. Lo and behold, 5430 articles added to 37 subcategories equals the 5467 returned by the PAGESINCAT function. With this realization, our stub counter is counting 37 more stub articles than actually exist. This also means the live state assessment table may also be off, depending on what the category situation is. I don't anything about Wiki coding, so hopefully someone here can find a workaround for this issue. -- LJ ↗ 23:11, 11 April 2010 (UTC)

Seems like the solution then is to add in subtractions in the template's calculation formulas to correct for the subcats. Should be easy enough, until someone creates any additional subcategories. Maybe we should make sure that all the state subcats are created now, so we can add in just the one correction to each number. Imzadi 1979 → 23:15, 11 April 2010 (UTC)

Or, we remove the subproject assessment categories out of the U.S. road assessment category. Imzadi 1979 → 23:18, 11 April 2010 (UTC)

It would probably be a good idea to ensure that all the state subcategories exist. Whether we include all the subproject categories in the greater USRD categories can be debated. Having the state subcats under the USRD categories aids when reviewing items by category (although the subcats don't show up when looking at the USRD start and stub categories, presumably because there's too many articles). Removing the state subcats would ensure that AbQ tables and PAGESINCAT functions return accurate numbers without requiring modifications. It doesn't really matter to me one way or the other. -- LJ ↗ 01:40, 12 April 2010 (UTC)

I don't think we need to make the subcategories for every type though. For example, with the exception of New York, by-state portal-class categories would always be empty. – TMF 02:17, 12 April 2010 (UTC)

Question: Is there any function in wiki code that returns only the number of articles in a category and not all pages...maybe something that filters PAGESINCAT by namespace? Is this lack of functionality why bots were created for assessment purposes? -- LJ ↗ 01:44, 12 April 2010 (UTC)

Ok, I'm working on the fix. I will make sure that all 59 sets of article assessment categories exist (50 states, 5 territories, DC, IH, USH, auto trails). Then all we have to do on the stub counter and the other places using PAGESINCAT with USRD totals is subtract 59 from each class total, and it will calculate the correct total project numbers. The numbers for the individual states, territories and subprojects are currently correct and will still be correct without any adjustment. Imzadi 1979 → 03:44, 12 April 2010 (UTC)

I'd just worry about setting up the subcats for the article classes and list classes for now, not worrying about things like template and portal class as TMF suggests. Thanks for taking this on. -- LJ ↗ 03:59, 12 April 2010 (UTC)

Actually, the subcategories have all been removed. PAGESINCAT will now return just the article counts, no adjustments needed. Imzadi 1979 → 05:20, 12 April 2010 (UTC)

{{USRD}} categories

I'm clearing out Category:U.S. road transport articles without a state parameter and I've noticed a few things: —Fredddie™ 19:15, 15 April 2010 (UTC)

• The category, project, and template classes should not require a state parameter, but accept one if there is.
  •  Fixed. Also, the subtopic template was missing support for by-state Book-Class categories; that has also been fixed. – TMF 22:19, 15 April 2010 (UTC)
• There should be some additional types, like type=I or type=US
  • Non-roads articles, like Button copy, possibly type=non-road or type=NR
  • Government organizations, like state DOTs and AASHTO, possibly type=DOT.
  • Federal roads and laws, like Forest Highway or Federal Aid Highway Act of 1956, possibly type=fed

A single category would be useful for grouping all the non-highway articles together, especially so that we can see the overall status of these for statistical purposes. Subgroups can be further discussed, as we should probably ascertain what all the different types of these articles are before multiple types are created. -- LJ ↗ 23:29, 15 April 2010 (UTC)

Sounds good. I was just listing the groups that appeared when I was going through the category. —Fredddie™ 23:46, 15 April 2010 (UTC)

What value does the browse box add for highway articles?

Discussion at Template talk:Infobox road#Why previous and next routes?Dave (talk) 01:38, 19 April 2010 (UTC)

Dab pages

Looking at the highway disambiguation pages, I came across two for numbers that are only used once: List of highways numbered 20SY and List of highways numbered 6563. Is it really necessary to have a dab page that lists only one item? Is it possible for these dab pages to be redirected to their respective listed articles (NY 20SY and NM 6563)? Dough4872 02:46, 19 April 2010 (UTC)

I tend to agree with this take. The dab page (and the "Route x", "Highway x", etc.) redirects could be pointed to those pages, and if another like-numbered route is found or assigned at a later time, then the dab can be restored and the redirects can be retargeted. – TMF 03:46, 19 April 2010 (UTC)

Per WP:DAB, as a rule of thumb, a disambiguation page should not be created until there are 3 topics with the same title. It does provide some examples where a page may be acceptable for 2 topics with the same title. Dave (talk) 03:52, 19 April 2010 (UTC)

According to that, we shouldn't have dabs unless there are two routes of the same number (following the "two item, no primary topic" guideline, as there are few routes where a number is widely associated with a specific route). So...AFD the one-route pages? Delete outright? – TMF 03:57, 19 April 2010 (UTC)

Delete baby delete =-) Dave (talk) 04:03, 19 April 2010 (UTC)

I took a look at all the suffixes and all of the unsuffixed numbers above 400 and found these other single-route dab pages: 104B; 9C-D, F-X; 7C; 28B; 28N; 25D; 23A-B; 228T; 22B; 20B-N; 1D; 17D; 13A; 60A; 5S; 35A; 439A; 46A. If anyone knows of routes that should be added to them, please do; otherwise they should go. – TMF 04:30, 19 April 2010 (UTC)

Silly. Why delete when you can redirect? --NE2 22:02, 19 April 2010 (UTC)

I think deletion is best for a dab page with only one entry per the suggestions at WP:DAB, even though there is nothing wrong with redirecting either since that route is the only highway with that number. Dough4872 00:11, 20 April 2010 (UTC)

Long-term project priorities

I've been thinking about this idea for a while, and I think that we should develop or coordinate some strategies for long-term goals with Featured Articles. I'd like to see us develop a list of articles that the project places some priority on getting featured. The current stub-count reduction drive is great, but I'd like to see some brainstorming on where to go with future FACs within the project. From a Michigan perspective, my priorities in the UP are to work on the US 2 article and transition to some of the LP articles like M-1 (Woodward Avenue) and the Interstates like I-75 and I-96. On a national level, I'm sure we could come up with such a list, and the list would start with US 66. What other national articles should we as a project plan to collaborate on to get featured? Imzadi 1979 → 21:10, 19 April 2010 (UTC)

As an article I've done some research on, I'd like to see Lincoln Highway promoted. Project-wide, I'd like to see United States Numbered Highways and Interstate Highway System promoted since I consider them the capstone articles for the project. —Fredddie™ 21:23, 19 April 2010 (UTC)

Not in any specific order, here is where I think our priorities should be:

• Top level articles (as suggested by Fredddie) such as: Interstate Highway system, U.S. Highways and National Scenic Byways
• Major U.S. Highways that are now extinct or on the endangered species list, such as: US-66,US-99,US-91, possibly including US-80 and US-40
  • As an aside, I'm considering US-91 as my next project to work on
• The true transcontinental highways, such as: I-10,I-80,I-90,US-2,US-10,US-20,US-30,US-40,US-50,US-60)
• Highways that have been internationally recognized for engineering or scenic value, such as: most of the highways on National Scenic Byways, the Utah and Colorado portions of I-70, US-550, Historic Columbia River Highway, Blue Ridge Parkway, Pacific Coast Highway.
• The most well known of the Auto trails, such as: Lincoln Highway, Victory Highway, Dixie Highway

Dave (talk) 23:22, 19 April 2010 (UTC)

One other item to consider is the popular pages report. One example if here. If you concentrate on the pages with the most page views, you are reaching the largest number of viewers. Getting an article that very few people read to FA status is likely not the best use of time. Also consider any top importance from the project's assessment. If these were rated correctly, you have already identified what articles are important for a focused effort like this. Vegaswikian (talk) 23:44, 19 April 2010 (UTC)

I believe I will go ahead and make a request for one of those page view list generators. Perhaps it would be of use to help retool the importance scale, in addition to picking targets for future FA expansion. —Scott5114↗ [EXACT CHANGE ONLY] 09:07, 20 April 2010 (UTC)

The true transcontinental highways were mentioned, but the following north-south highways deserve consideration, too: I-95, US 1, US 11, I-75, US 41, I-35, I-15, I-5, US 101. That being said, I strongly concur with Imzadi that US 66 should be at the top of the list for its historical and cultural value. Viridiscalculus (talk) 00:55, 20 April 2010 (UTC)

The importance rating for this project has always meant very little. According to Category:Top-importance U.S. road transport articles, our biggest priority as a project are the by-state route lists, a couple of system and agency articles, and a few old auto trails. Only one numbered route is identified as being Top-importance, the aforementioned US 66. So, the importance scale isn't the best of barometers at all here. – TMF 01:47, 20 April 2010 (UTC)

I think a long-term goal is to try to get one featured article for every state, so every state can boast having a quality highway article. Dough4872 02:04, 20 April 2010 (UTC)

This is interesting to plan out as our goal for 2011, after the stub count target date has passed. If you're trying to coordinate something where everyone is helping to work to get specific articles through FA, the big problem is getting people interested in the topic. Roads editing is extremely regional; people don't like to work on roads outside their comfort zone. (For example, I'm wary about doing any serious work outside OK, KS, MO, and SD). You also have to have their priorities in mind; although US 66 passes through Oklahoma, I really don't have too much interest in it, since it's been done to death in mainstream press and there's little new to discover through research. My priorities are instead on getting the bog-standard state routes up to snuff.

If someone is planning on setting this thing up, a look at the similar WP:USRD/AID, with a specific eye to conducting a post-mortem on it, can be instructive. In hindsight, a lot of this drive's failure was due to the article selection: oftentimes short state highways or intrastate highway articles were nominated. Due to the provincialism of road editing, you're not going to attract much collaboration with these types of articles in the docket.

Perhaps a better way of doing this is for each editor to throw out their list of things that would interest them in taking to FA, and the other editors sort of pair up with them to help achieve the goals. I have over 100 sources for Creek Turnpike, which I've been wanting to take to FA since 2008, but haven't ever really had the time to sift through and apply other than limited sandbox stuff. Maybe reciprocal "pacts" could be done ("I'll help you with Creek Turnpike if you help me with K-32"). —Scott5114↗ [EXACT CHANGE ONLY] 09:01, 20 April 2010 (UTC)

WP:USSH noncompliance

No joy on education of DanTheMan474. Request backup and escalation if necessary. --NE2 05:12, 17 April 2010 (UTC)

You are right here with respect to WP:USSH, but I think the issue is minor enough that if it continues to be a problem then you should just ignore it and let it go. You and Dan are doing quality work in expanding articles, and anything that distracts from that right now is inherently damaging to the encyclopedia. The last thing we need is more drama at WP:AN. If it really bothers you, I'd advise just shifting your efforts to another state (Florida has 389 stubs, for instance). —Scott5114↗ [EXACT CHANGE ONLY] 06:14, 17 April 2010 (UTC)

I've changed to using SR for the Ohio project, NE2, so this should no longer be a major problem. The need right now is to start clearing out stubs on projects like Ohio, and my goal is I'd like to have 200 of these Ohio stubs upgraded to Start, C or higher by year's end. The stubs that currently exist are in horrendous shape, and it's important that we move toward improving these...and yes, I will be doing so using SR. I think that should be the key focus right now, and I'd welcome any help any other editors could provide in moving toward goal, whether in the Ohio project or elsewhere. DanTheMan474 (talk) 17:01, 17 April 2010 (UTC)

Yet you're still using "Ohio State Route". This is unacceptable and any further such actions will be cause for termination. Have a nice day. --NE2 17:26, 17 April 2010 (UTC)

I will use State Route. Would you be interested in working on improving stubs, though? DanTheMan474 (talk) 17:40, 17 April 2010 (UTC)

Thank you. My work is done here. --NE2 17:42, 17 April 2010 (UTC)

As long as we still have articles to expand and fix, all of us still have work to do... —Scott5114↗ [EXACT CHANGE ONLY] 14:53, 18 April 2010 (UTC)

Speaking of which, you skipped answering a previous question, NE2. Would you be interested in helping to (generally) upgrade stub articles for state routes in Ohio, some of which you actually started years ago? Just curious. Thanks. DanTheMan474 (talk) 16:40, 21 April 2010 (UTC)

Encyclopedia? What encyclopedia? --NE2 17:26, 17 April 2010 (UTC)

A template that is not a good idea IMO

Just ran across a good faith definition of a specific highway template that lists all major cities it interconnects. This seemed like a truly bad idea. I am discussing it with this third world editor, and may not get anyplace. It may actually make sense for a country like Haiti which has a single four lane highway, with median, dirt, running around the crescent shaped country. I don't know about others, but I would hope to keep it out of the u.s. and, hopefully all G10 nations which cities would have hundreds of these things at the bottom of the article, potentially. Even Mexico city. Wikipedia appears to lack a specific template policy. Here's one item that should be covered. Student7 (talk) 16:17, 21 April 2010 (UTC)

What is a "third world editor" and why is that relevant? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:22, 21 April 2010 (UTC)

If you go to WP:TFD there is a newly-opened discussion on the template there. Since the template is for a Turkey highway, this probably isn't the best place for a discussion about it. —Scott5114↗ [EXACT CHANGE ONLY] 16:24, 21 April 2010 (UTC)

(ec)A couple of tidbits. This project used to have templates for major cities. We got rid of them because we couldn't find any consistent, objective definition for what is major, see WP:USRD/STDS under depreciated sections. Second, the use of a template for a single article is inappropriate. The purpose of a template is to centrally maintain content that will be used on multiple wikipedia articles, per Help:Template. Last but not least, could you provide some links to the discussion in question? Without any links to the relevant discussion, this post is just a rant. Dave (talk) 16:29, 21 April 2010 (UTC)

TFD for Virginia "articles-in-county" navboxen

TFD discussion is underway. —Scott5114↗ [EXACT CHANGE ONLY] 16:25, 21 April 2010 (UTC)

Maryland related routes

I have noticed there have been some concerns about the minor related routes in MD articles such as Maryland Route 313 and whether is redundant for these minor routes to be mentioned in the history pertaining to a realignment and in the related routes section describing the minor route in question. Any thoughts? Dough4872 03:16, 22 April 2010 (UTC)

Certainly those 3 routes are not notable enough to have separate articles. Beyond that, I don't know the situation in Maryland well enough to say if they should be listed in the article of a related road, or in a list of minor routes type article.

As a side comment, the infobox for this article is misusing the alternate name parameter (as do many USRD articles). Alternate names implies the entire length (or almost the entire length) of a road is known by that name. This list looks like the names various small segments are known in various cities. Dave (talk) 03:54, 22 April 2010 (UTC)

Not only implies that, but per the {{infobox road}} usage instructions, the alternate name param should only contain names that apply to the entire road. Any names that don't apply to the entire route should be removed on sight, even if it results in there being no alternate names at all. – TMF 05:59, 22 April 2010 (UTC)

If they're already covered in the history, then IMO that's all the mention they need. The related routes section in those cases just seems like something used in order to display shields for the routes. I find that unnecessary for signed routes, and is somewhere between wrong and misleading for routes that are unsigned, such as MD 820. – TMF 06:05, 22 April 2010 (UTC)

Here's my problem with it. Not only with MD 619 & MD 313, but MD 485 with MD 404, and MD 674 with MD 413, which I pointed out to User:Onore Baka Sama was really unnecessary. Now, the problem I think its spreading like wildfire is this: Maryland 375 was merged into Maryland 374. According to the shrimpy section, its 0.06 miles from termini MD 374 and MD 818. The fact that we can't cherry pick the article to cover it in is one problem. Two, I don't see a relation to MD 374 outside of that at all, meaning if we need to cover it elsewhere, we'll have to. The final example is Maryland_Route_313#Related_routes - I have seen no mention of the section mentioning what relation off of MD 313 these have. The real question is its precedence and consensus ever coming to it. In theory doing this you could cover New York State Route 418 in U.S. Route 9 in New York or New York State Route 421 in New York State Route 30 because they spur off of it and randomly end (like most of MD does), yet they have no relation internally. I know I am being very hostile on the situation but this isn't the best. Mitch32^{(Growing up with Wikipedia 1 edit at a time.)} 11:23, 22 April 2010 (UTC)

At WT:MDRD, we had decided to split up the minor routes list as that is the way our project seems to be going. It was suggested that most minor routes be merged with a longer related route as several MD route numbers are associated with former of short branch alignments of a route (for example, Maryland Route 7 with U.S. Route 40. However, there are the few cases where the minor routes have no place to logically fit in, and MD 375 is a perfect example that could lean to either MD 374 or MD 818. In addition, it does not seem right to just passingly mention routes like MD 619 in the history of MD 313. MD 619 is a current route that can have a short section describing its length and where it goes from to from. In addition, more detail could be added to the description of MD 619 in the related routes. If we cannot agree on how to handle these minor routes, then maybe it would just be better to keep the minor routes list for MD. Dough4872 01:12, 23 April 2010 (UTC)

The issue with MD 619 and similar routes was that the MD 619 section was repeating what was already said in the history section. It's not that more can be said, it's that it wasn't being said. —Fredddie™ 02:01, 23 April 2010 (UTC)

Well, I could always add a few details for the MD 619 entry in the related routes. Dough4872 02:33, 23 April 2010 (UTC)

Traffic - Seven Corners

I am guessing that the topic of "traffic" comes under this project. There is an intersection (and an article) on Seven Corners, Virginia. There are five roads which intersect with bumper-to-bumper traffic during the day. Mostly four lane each road or more. Not a trivial problem, nor is it unusual. The article itself really needs enhancing with that information. Right now, it only discusses the surrounding "community."

This is about the worst intersection I have ever seen, yet it is handled amazingly well all with stoplights. Somewhere, a traffic "expert" ought to explain how, superficially with maybe a more esoteric article somewhere else which addresses problems of this nature.Student7 (talk) 18:19, 22 April 2010 (UTC)

I'd redirect your query to the Virginia or U.S. Streets wikiprojects. This project focuses mostly on state highways in the US. As for "traffic experts", we're all amateurs and none of us work in transportation planning or for any state departments of transportation, at least to my knowledge. Sorry to disappoint. Imzadi 1979 → 18:55, 22 April 2010 (UTC)

Actually there the roads are mostly US and state highways with only one local "street." If you are saying that the Project "Streets" handles traffic considerations and "Project Roads" does not, then fine. But traffic should be considered in either project I would think. That is the only reason for highways and streets, after all. I appreciate that editors are mainly not professionals but some have taken classes or been exposed at their employment or know of a book. Or that is what I am hoping. The problem is not unique to Virgina though it does have the advantage of exposure - there is hardly any driver in Northern Virginia and nearby DC area that has not been through there at least once. Student7 (talk) 16:48, 23 April 2010 (UTC)

Busy intersections in and of themselves aren't that encyclopedic and this intersection doesn't seem any more important than any other busy intersection. I'd say check the library to see if they have a copy of a traffic study that was done on that intersection. —Fredddie™ 17:48, 23 April 2010 (UTC)

To clarify on my earlier comments, technically this project is misnamed. It should be US Highways, not US Roads, but at the time, there was a project called that. That other project was devoted to the US Numbered Highway System. (Recently, that second project was merged into the parent project along with the national project devoted to the Interstates.) In having a focus on highways, and not all types of roadways, specific intersections aren't always in our coverage. The closest we get to covering traffic in our articles is to quote traffic volume numbers from DOT traffic surveys. As for intersection design in a situation like this, we don't have that knowledge base. As Fredddie said, you'd be better off getting ahold of someone in Virginia (we have no active editors that specialize in that area) and looking for a traffic study on the intersections in question. Now, if we had an active Virginia editor, I could point you in his direction since he'd know where the DOT in VA would have the information you seek. If you would like a map created of the Seven Corners, it's possible that our Maps Task Force could do that for the article, but outside of current situation, we just don't have the resources to do much for non-highway articles like this. We're in the middle of a stub-elimination drive, working to reduce the number of stubs we have in the 10K+ articles already tagged in our project scope. Sorry, Imzadi 1979 → 19:38, 23 April 2010 (UTC)

I'm not going to let you off that easily. The only raison d'etre for roads or highways is the relief of traffic. The only reason. If I could get from point A to point B without running into another car, I would not need a roadway or traffic signs or lights or anything else. You should consider starting a superior Project WikiProject Traffic which would roll up both Roads and Streets.

Please don't tell me that traffic and road control is unique to the state of Virginia. I realize you don't feel comfortable with the subject/topic, but don't blow me off for that reason!

You might take a look at this sucker BTW (copies probably exist worldwide that are much much worse, but I would hate to encounter one). http://www.mapquest.com/maps?city=Seven+Corners&state=VA&country=US&latitude=38.871899&longitude=-77.155602&geocode=CITY

This type of article is not in our scope, and we don't have the apropos knowledge to help out. Try User talk:NE2; he may be able to be of more assistance, as he's done Virginia work in the past.—Scott5114↗ [EXACT CHANGE ONLY] 01:21, 24 April 2010 (UTC)

I'm not blowing you off, I'm telling you that what you want is related to traffic engineering. Yes, highways are the project of traffic engineers, but we don't have the kind of specialized knowledge. NE2 might, I don't know. Additionally, while traffic control is not particularly unique to one state, most of us are specialized to our geographic regions. If this were an intersection in Michigan, I'd e-mail my contacts at MDOT to get an answer. The rest of us aren't based in Virginia, so we don't have DOT contacts to tap for your answers. Sorry, Imzadi 1979 → 01:57, 24 April 2010 (UTC)

I can accept that the most verbal of you don't want to include traffic engineering as part of your project even though it already seems to be included implicitly as a part of Roads, automatically. Like Geology is included with Geography.

The other point which I have not been able to make, so far, is that traffic situations and traffic engineering (designing traffic solutions) is not unique to Virginia. I agree that Seven Corners is in Virginia. But five roads, or more, running together are probably found everywhere. The fact that no one has mentioned any yet merely shows how little these pages are monitored, not untypical of Project pages, alas.

A "generic" (or more likely several) solutions exist. There are people who study them somewhere. They are not all "in Virginia," as you appear to be claiming. This is like suggesting that paving a particular road with a particular substance when found locally, should be addressed "locally" even though the solution is being used nationally or worldwide. Why, for goodness sakes? Why do you think this? I feel quite frustrated that the responders don't seem to comprehend that the problem and solutions exist in every state and in every nation. Student7 (talk) 11:38, 24 April 2010 (UTC)

Well, wait. I've posted on Project Highways, which does seem to have a charter for traffic. Let me see what response I get there. Student7 (talk) 12:01, 24 April 2010 (UTC)

For the last time, Student7, situations like the intersection in Seven Corners aren't confined to just Virginia, although that situation is quite unique. We never said they weren't going to be found elsewhere. What we've said though is that the people with the engineering expertise to address your specific question are going to be in either Fairfax County, VA or at VDOT. Those are the people who actually designed that intersection. Barring that, the people who have contacts with VDOT are going to be Virginia-based editors, which neither Scott (Oklahoma), Fredddie (Iowa) or myself (Michigan) are. NE2 might have some contacts, so I'd ping his talk page. WP:Highways isn't going to be of much help. That's a container project for highways that aren't in the US, Canada, India or the UK. WP:Transport would probably be your better bet to see if they have any traffic engineers there. I'm sorry that you seem so frustrated by it all, but 1) we're all volunteers here covering areas of personal interest, 2) none of us who have replied here have the expertise you need, 3) none of us who have replied here are local enough to the area to help you find the information you need beyond generically telling you to contact VDOT. I'm sorry, but traffic engineering is an order of magnitude more detailed than this small pool of editors' interest level, but I'm sure there are people out there that can help. As a side note, User:Stratosphere used to be my key in-project resource for GIS and cartography questions, that is until he got a job doing GIS and cartography. He no longer edits on Wikipedia because his contributions mirrored his day job too much, and he needed the break. I'd say that there might be some traffic engineers lurking around on Wikipedia, but they edit areas related to their hobbies, not their profession, for similar reasons. Best of luck, Imzadi 1979 → 19:16, 24 April 2010 (UTC)

USSH question

Is Route 54 (Delaware-Maryland) titled properly? The parenthesis remind me of the losing "P2" from SRNC... —Scott5114↗ [EXACT CHANGE ONLY] 21:20, 23 April 2010 (UTC)

I absolutely agree that this doesn't match the naming convention established. However, there is precedent for it, see State Route 74 (New York-Vermont). Dave (talk) 21:24, 23 April 2010 (UTC)

Why highlights a flaw from P1, there's no good way to name bi-state highways. Unless of course it were renamed Delaware–Maryland Route 54. Imzadi 1979 → 21:47, 23 April 2010 (UTC)

I don't see any reason that we couldn't use that naming. USSH already says we should be referring to it as "Route 54" in prose anyway. —Scott5114↗ [EXACT CHANGE ONLY] 22:39, 23 April 2010 (UTC)

We had a go nowhere proposal discussion here already: here. Now if I had to choose I know what I'd change from SRNC, not going to happen though.Mitch32^{(Growing up with Wikipedia: 1 edit at a time.)} 22:53, 23 April 2010 (UTC)

I'm not seeing any consensus either way there; it mainly got sidetracked into a discussion of when these type of merges should occur. —Scott5114↗ [EXACT CHANGE ONLY] 00:11, 24 April 2010 (UTC)

Well we do have this too: North Carolina Highway 106 and Georgia State Route 246. Those are two separate numbers though, as opposed to two Route 54's. Eh, I don't have a problem with the status quo. I don't want another SRNC and well, such articles are so few and far between that a few anomalies shouldn't cause too much of a fuss. --Triadian (talk) 04:53, 24 April 2010 (UTC)

I had originally had the article moved from Delaware/Maryland Route 54 to match the convention of what has been happening with other multi state route articles, such as State Route 74 (New York – Vermont). I think it may help to have a naming convention for articles such as DE/MD 54 and NY/VT 74, we could simply name a few options and have everyone vote on them as in a straw poll. Dough4872 11:14, 24 April 2010 (UTC)

We have three options on how to procede here.

1. We could rename the affected articles into a format similar to <state name 1>–<state name 2> <type> <number> to match the convention set almost 4 years ago. In this case, it would be Delaware–Maryland Route 54 or New York – Vermont State Route 74.
2. We could ppen a discussion about either making these sorts of articles an exception to the P1 standard from SRNC, much like Kansas and Michigan are already exceptions, as are half of the Interstates and US Highways articles that need geographic disambiguation.
3. We could open a civil discussion about switching nationally to the P2 format from the old SRNC.

That's really what our options are here. Since paranoia reigns supreme on this topic, I assume option 3 won't be very popular meaning either we rename the few articles affected, or we actually craft an exception at WP:USSH for these types of article. As for the NC-106/GA-246 example, I'd be against merging them because of the disparate numbers. Imzadi 1979 → 19:50, 24 April 2010 (UTC)

I'm open to either option 1 or option 2. What needs to be determined either way is what should the "type" be if the two states involved have entirely dissimilar names (such as one using "Highway" and the other using "Route"). – TMF 23:59, 24 April 2010 (UTC)

I'm also open to #1 and #2, but #3 would open the floodgates to other problems? Considering I think NC 106 and GA 246 need to be forked, we should be Boldify-it.Mitch32^{(Growing up with Wikipedia: 1 edit at a time.)} 00:39, 25 April 2010 (UTC)

I prefer option 3. That would allow all highway articles that require disambiguation, be it State Route 14 (California), Interstate 84 (west), Interstate 405 (California) or State Route 74 (New York – Vermont) to have a consistent way of disambiguating. I think our current scheme of California State Route 14, Interstate 15 in Utah, but Interstate 405 (California) or State Route 74 (New York – Vermont) is dorky. Yes, doing it this way may have been a compromise when some immature editors thought their way was more important than working together. However, that time has passed, and I don't see why it's an unpardonable sin to suggest the issue be revisited. Dave (talk) 00:46, 25 April 2010 (UTC)

I don't see a problem with the current scheme, really. If the "State Route 74 (New York – Vermont)"-style NC is kept and P2 is implemented, there'd still be inconsistency since NY and VT would still use the P1 format as the full article title is the common name. – TMF 00:58, 25 April 2010 (UTC)

On that note, I'm more in favor of option 1 than either of the other two. – TMF 00:59, 25 April 2010 (UTC)

Why can't we have both? Why cant the State Route X (<state>) states use P2 and the <state> Route X state use P1? —Fredddie™ 01:05, 25 April 2010 (UTC)

That's what P2 was. – TMF 01:07, 25 April 2010 (UTC)

If New York Route 17 is the proper title, that is unambiguous. I'm referring to situations that require disambiguation, such as where several states refer to their highways as "State Route 17" without the state name to disambiguate. Also, I obviously have gotten used to our current system; just saying, IMO a different one is better. If I'm in the minority I'll continue to work with it. Dave (talk) 01:06, 25 April 2010 (UTC)

(ec) In all honesty, I agree with Dave. There are so many exceptions to the current convention that it almost looks like Swiss cheese with the numbers of holes in it. Michigan and Kansas use parenthetical disambiguation. The article titles used for "bannered" routes are parenthetically disambiguated. Auxiliary Interstates use parenthetical disambiguation as needed. In most cases, the state-detail Interstate articles use parenthetical disambiguation in redirects so that the templates don't have to judge the difference between a 2dI and a 3dI. The naming convention in place for the bi-state route articles uses parenthetical disambiguation as well. We already have a confusing set of rules that only makes sense to editors who have been around since SRNC 4 years ago, and makes no sense to editors from outside the project.

Yes, I know that elements of the project consider all things related to SRNC a third rail, but honestly, there are good reasons to discuss the change. If I can pre-emptively discuss one argument that will be made against changes, we need not worry about the time it would take to make the changes. Proper page moves would retain the current names as redirects to the new names, meaning no links in the articles would need to be changed. There are automated tools that would resolve double redirects. The links created by templates could be changed once, and the changes would propagate through the job queue automatically to the articles. As for the actual page moves, there would be no deadline to the process, so long as it moved along consistently. Imzadi 1979 → 01:14, 25 April 2010 (UTC)

Disclosure: I was alerted about this discussion, that is how I came to be here.

I'll be honest: I still prefer P1, but my opposition to P2 is not as vehement as it was back in SRNC. Therefore, I would strongly consider moving to P2 if it solved our problems. (It's not something to be taken lightly.) However, in this case it doesn't. There is the issue of State Route 74 (New York – Vermont), which breaks P2 as New York articles would still be the same under P2. This would bring further confusion than there is now (why is NY treated differently than, say, MD?) Also, there is the mess of Interstate 210 and State Route 210 (California), which still isn't solved. For all the work it would entail, and for the problems that would be left unresolved or made worse, it's not worth it.

My piece being said, I strongly urge you to discuss, discuss, discuss, before you move the pages. Make sure everyone is okay with it, make sure everyone says what they want to say, make sure everyone feels comfortable with saying what they want to say (without throwing out their opinion based on "oh, you've been here for over x years, you're resisting change, we're not listening to you)" and make sure there is not a minority at all, or the minority as small as possible. My concern is years of discussion and compromise being overturned for a solution that not everyone is on board with, causing a nuclear meltdown at USRD. I would not start moving pages tomorrow, or this week, if there is a significant minority in opposition. I would say that this discussion should last a minimum of two weeks, if not more, to make sure everyone sees it. I think a discussion of the SRNC issue is okay if everybody agrees to this. --Rschen7754 02:24, 25 April 2010 (UTC)

Well, I don't think any pages would/should be moved until at least the end of next month, and I'm all for finding a solution that harmonizes the disparate NCs we have. My firm opinion is that while what we have "works", it's full of holes and exceptions. Some exceptions will likely be necessary, but the goal should be that we find a method that eliminates as many exceptions as possible. The exceptions are what make the system strange outside of the project.

Since I did not participate in SRNC even though I was around and editing Michigan highway articles at the time, and others that are active weren't here for it, I'm discarding the P1/P2 nomenclature and starting over. My suggestion is that we toss into the collective hat any ideas of NC schemes, and assign Concept (C) numbers. Here's my C1 idea, with examples:

<Type> <Number> <Subtype> (<Geographic location>)

Route 43 (Maryland)

Highway 32 (Wisconsin)

State Route 2 (Ohio)

K-66 (Kansas highway) or Highway K-66 (Kansas)

Interstate 80 Business (Sacramento, California)

County Road 509 (Brevard County, Florida)

State Route 74 (New York – Vermont)

Under my C1, the Geographic location should appear in parentheses, even if a state uses it as part of their official name. That would harmonize where the state/county/city names would appear in all article titles. The "types" would likely be limited to State Route, State Highway, Route, Highway, Interstate, U.S. Route, County Road, County Route and possibly County Highway. For Kansas and Michigan, the "type" would be "K-" and "M-" respectively. The word "highway" could be moved to the front, or left as is currently. Imzadi 1979 → 03:43, 25 April 2010 (UTC)

Oh, as an addendum, for multi-state articles, like the SR 74 example, my idea is that should the two states differ in the type name, use the type that corresponds to the first state name listed, probably in alphabetical order. In the case of the I-/SR-210 example out of California, joint type name: Interstate and State Route 210 (California). Imzadi 1979 → 03:53, 25 April 2010 (UTC)

I feel that if we are to do any parenthetical type of disambiguation, we should stick to what was P2, where the official name is always used. That way, you can use the "pipe trick" to write [[Route 13 (Missouri)|]] and get Route 13. USSH says that we should not include any disambiguation in the prose, but if it's the official name, like "Alaska Route 1", then that should be mentioned in the prose.

The inherent danger in having this discussion is that everyone uses their intuition to come to a conclusion as to what "feels" right. As a result, nobody can really make any convincing arguments as to why things should be done that way. And since they can't make any convincing arguments, nobody is convinced, and everyone just drags their heels in to their preferred convention. The beauty of the current naming convention is that it's completely arbitrary and that's what was needed in this case to keep the debate from lasting until this day. Keep in mind that time spent fretting over this is time that can't be used expanding articles. I would hope that everyone here is mature enough to not start mass-moving pages because of what they think is Right and True, because as SRNC proved, there's no universal value of Right and True. —Scott5114↗ [EXACT CHANGE ONLY] 04:53, 25 April 2010 (UTC)

I like the this idea (of parenthetical disambiguation). However, I have two changes to propose

1. As Scott mentions by using a pipe line the disambiguation should automatically truncate to the proper name
2. For states where no disambiguation is required (i.e. where the official title includes the state name, such as New York 123) that we not add parentheticals just to be consistent. Dave (talk) 06:52, 25 April 2010 (UTC)

I would like to put forth C0 (C zero), the "no-build alternative." Much like the roads we write about, there would be no comprehensive changes to the current system. Maintenance would be performed as needed. It seems like the suggestions for a complete overhaul are based on 5% of the naming convention not working. Those are the exceptions we need to work around, the side effects that were never anticipated when SRNC was implemented a few years ago. We can either handle the exceptions as they come or come up with solutions to the minor issues as this group has been doing for years. For instance, I would much prefer coming up with a scheme for naming the multi-state routes that started this discussion rather than coming up with a massive new system designed in part to solve the problem of naming the multi-state routes by injecting a massive burst of consistency. Overhauling the system in an attempt to eliminate all of these exceptions at once seems like an excessive undertaking that will surely not anticipate future side effects. While I understand the desire for complete consistency across the project, there is the potential for great drama and numerous unintended consequences that would end up thwarting the intended consistency. A project of this magnitude will only distract us from improving articles. Viridiscalculus (talk) 05:54, 25 April 2010 (UTC)

I have to admit that I'm afraid of reopening a can of worms, and the current scheme, while clunky, is working. However, I've not liked our naming scheme since day 1; I'd like to at least test the waters to see if others agree.Dave (talk) 06:52, 25 April 2010 (UTC)

I'm just not seeing how switching to P2 would solve our problems. If it really and truly did, and it didn't cause any other side effects, then I would strongly consider it. But I'm just not seeing it. --Rschen7754 07:10, 25 April 2010 (UTC)

Arbitrary section break

I'd rather just keep the status quo and make a decision on the multi-state articles, which was what the original intent of this thread was. – TMF 07:11, 25 April 2010 (UTC)

If no changes are being made, then the current scheme for multi-state articles should be changed to get rid of parenthetical disambiguation as that doesn't fit the decisions of SRNC. State Route 74 (New York – Vermont) → New York – Vermont State Route 74. In cases where the two states' official names conflict, use the official name that corresponds to the state name that appears first, which should probably be following alphabetical order. Imzadi 1979 → 07:34, 25 April 2010 (UTC)

I like it. Not only does it bring the NC generally in line with the intrastate SH articles, it's also a good way to resolve what I consider the more pressing issue of what should the type be in instances where the type is different on both sides of the border. The alphabetical order bit matches the status quo, too. Full support. – TMF 07:55, 25 April 2010 (UTC)

I'm not 100% convinced on the alphabetical order bit—shouldn't the state with the longer section be listed first? Oklahoma does not participate in merged routes, but if Texas State Highway 79 and Oklahoma State Highway 79 were to be merged, I'd would completely expect it to be Texas–Oklahoma State Highway 79 (since the OK side is only a continuation of the highway to the next state highway junction). For highways running along a state line or with about equal lengths, alphabetical works. —Scott5114↗ [EXACT CHANGE ONLY] 14:40, 25 April 2010 (UTC)

I agree that we only need to look at the multi-state articles and not start another SRNC. IMO, one convention should be used for all articles, with the Route/Highway X (State 1 – State 2) and State Route/Highway (State 1 - State 2) being the most viable options. The big problem would be for multi-state articles in which one state may use "Route" while the other state uses "Highway", then there would be an issue deciding what the appropriate title should be. We could always do something like Delaware Route 54/Maryland Route 54 for the title, stating what each state refers to the route as in full. Dough4872 17:22, 25 April 2010 (UTC)

Scott: There is a NY/CT merger (New York State Route 343) where the whole article is under the NY name because the CT section is just a short piece to connect to the next junction. Let me modify my idea then slightly.

State Route 74 (New York – Vermont) → New York – Vermont State Route 74. States should be listed in alphabetical order, and the type that corresponds to the first state is used if they differ. In cases where one highway in one of the states only exists to connect to the next highway junction in that state, it can be omitted from the naming completely and merged into the other article, like the NY-343/VT-343 example. These multistate mergers should not be used if the numbers are different. Imzadi 1979 → 21:24, 25 April 2010 (UTC)

Apologies for coming into the discussion late, but I do have two thoughts:

• Rather than semi-arbitrarily listing the states in alphabetical or length order, I think the way that would actually make the most sense would be to list them in the order of the Route Description section. That is, list the western or southern state first.
• Remember that SRNC had two parts. After we finally settled the P1/P2 thing, for some states we still had to figure out what the official name was. I think it's just as egregious (in fact, possibly moreso) to use the "wrong" name in the title. Thus, I'd rather see the slightly wordier New York State Route 74 – Vermont Route 74, using the correct name for both sections of the route.

– Kacie Jane (talk) 20:18, 28 April 2010 (UTC)

I agree with this logic. I actually thought this was the unwritten practice already in place. -- LJ ↗ 21:18, 28 April 2010 (UTC)

Re point 2, it's probably the best option, but it's not one I'm enamored with. The name is a bit cumbersome for my liking, but I suppose it can't be helped. That said, would it be preferable to use the word "and" in the title instead of a dash? – TMF 05:36, 29 April 2010 (UTC)

Seven Corners again

A user has been tagging Seven Corners, Virginia as part of USRD because it has a section on an intersection (of questionable notability). Seven Corners is a census-designated place in Fairfax County, and the remainder of the article contains census information and demographics, as well as notable events occurring in the CDP. Does one section relating to highways, with several unrelated section make an article fall within USRD? —Scott5114↗ [EXACT CHANGE ONLY] 02:13, 27 April 2010 (UTC)

• I oppose the tagging of this article with USRD because just under 23% of the text in this article relates to highways. Even that is tenuous as to whether it should be included or not; I question the notability of this particular intersection. Even though it contributed the name of the CDP, that doesn't warrant the multiparagraph passage that the article has now. —Scott5114↗ [EXACT CHANGE ONLY] 02:13, 27 April 2010 (UTC)
• Oppose - This article focuses more on the CDP rather than the intersection. Dough4872 02:17, 27 April 2010 (UTC)

• Oppose – I reverted the tagging in the first place and opened the discussion with my reasoning on the article's talk page. Imzadi 1979 → 03:11, 27 April 2010 (UTC)

• Oppose – I haven't yet heard a compelling reason to support it. —Fredddie™ 23:49, 27 April 2010 (UTC)

• Comment - I don't see the point of this discussion. I've never seen "we don't want this article, don't tag it as part of our project" on any other project I've participated in. Granted, it's not a typical article for this project, but I don't see the big deal either. Dave (talk) 20:16, 4 May 2010 (UTC)
  • In my opinion, it's more a discussion reaffirming the existing consensus about the scope of the project. A certain user is of the opinion that the article is, or should be, under the scope of the project when it isn't. To summarize, our project scope is: 1) numbered highways and their related systems; 2) controlled access roadways; 3) historic auto trails; and 4) former alignments of the same, where notable. There is no fifth point to the scope that says "and anything else X tags as such." There are already 10,000+ articles tagged using that scope, and members of the project are not seeking to increase that number through a poorly enforced scope. Imzadi 1979 → 20:45, 4 May 2010 (UTC)

Thanks for the clarification. That makes more sense. I do supposed WP:California would probably object to every movie produced by a Hollywood studio being tagged as part of the project. =-) Dave (talk) 01:23, 5 May 2010 (UTC)

Great news!

The 2009 State Highway Log by the Washington State Department of Transportation has been released! A new spur route and a new highway have been added, as well as another being extended. Also, I'm back! –CG^Talk 23:40, 4 May 2010 (UTC)

Forgot to mention that we're featured in the Wikipedia Signpost's WikiProject report for this week! –CG^Talk 23:43, 4 May 2010 (UTC)

A heads-up

Special:Contributions/205.166.161.61 and Special:Contributions/65.10.136.3 - two IPs (maybe the same person) working almost in tandem that are making poor edits to articles relating to the eastern I-84. Some of the edits are questionable; some are outright wrong. Some extra sets of eyes on these IPs would be appreciated. – TMF 14:13, 4 May 2010 (UTC)

Another IP: Special:Contributions/98.67.107.117. I think this one's the same one that made all kinds of questionable edits to IH and USH articles a few months back. – TMF 02:12, 6 May 2010 (UTC)

Merge discussion

Looking for more opinions on Talk:Sunset Highway (Oregon), which is a part of U.S. Route 26 in Oregon. There's a good handful of other merges in Oregon I have my eye on, several cases similar to this, and at least one bannered/suffixed like the Oregon Route 18 Business he mentions I've already done, so I'd like to make sure this gets proper discussion before I start going crazy. –Kacie Jane (talk) 10:41, 5 May 2010 (UTC)

If you are going to seek out opinions, please post to all the relevant WikiProjects, specifically the ones posted on the talk page of the article. Aboutmovies (talk) 07:18, 6 May 2010 (UTC)

Dab page discussion

See Talk:Ridge Road. The core of the issue seems to be 1) should roads with a similar name be listed and 2) should roads with no coverage outside of the dab page be listed. The MOS is pretty clear on the latter; as for the first, the MOS seems to skirt the issue and leaves it up to editorial discretion. Comments welcome. – TMF 14:26, 5 May 2010 (UTC)

Another merge discussion

See Talk:Interstate 95 in Maryland#Merging Chesapeake House and Maryland House Dough4872 01:44, 6 May 2010 (UTC)

Yet another merge discussion

Talk:Interstate 84 (west) While this specific discussion is about I-84, it would also apply to a few others, such as US-2, I-86, I-88, etc. Dave (talk) 19:48, 6 May 2010 (UTC)

A discussion that relates to our project's ACR

Wikipedia talk:WikiProject Good articles#Should GA and A-class articles be recognisable through a symbol on the article page.3F has been started. Imzadi 1979 → 09:27, 7 May 2010 (UTC)

Stub elimination drive is no excuse for stupidity

Please stop deleting stubs just to score points for the latest contest. A stub should be deleted or redirected when the article should have never been created in the first place, or when the subject is appropriately covered elsewhere. If the article is about a notable subject, just lacking content, the appropriate course of action is to expand the stub article.Dave (talk) 06:19, 7 May 2010 (UTC)

Ok, I'll comment here with something that's strictly my opinion. If the subject of an article is notable, that will save it from deletion, but that doesn't save the current article from a merger with another article. I'm actually of the opinion that most stubs, when possible, should be merged someplace. Once the article content is long enough, it can be split into a separate article. To summarize: notability saves content from outright deletion. Length of an article (assuming the writing is up to snuff) saves from a merger of content on a notable subject to another article. A merger is a valid course of action, as is expansion, when dealing with short, stubby articles. Imzadi 1979 → 07:27, 7 May 2010 (UTC)

This is a valid opinion I certainly won't object to. Many stubs do deserve to be redirected/merged elsewhere, and I applaud the efforts of those working towards the goal of the stub elimination drive. However, there is a difference between actually merging the stub articles into the targets, and just merging/redirecting stubs blindly for the sake of reducing the count.

I just got done reverting redirects to some pre-1976 Nevada articles that were done rather questionably, and presumably in the guise of reducing the stub count. I'm assuming Dave is taking issue with a couple tunnel articles in Nevada that were unceremoniously redirected to their route article earlier today in a similar fashion. These pages were simply redirected without merging content and/or making sure there was appropriate mention in the target, and performed sloppily enough as to wipe out the appropriate categories on the page. Other articles were redirected to an article that wasn't necessarily the most appropriate target, as some of these routes have complex histories and routing that make it difficult to select a specific redirect target--an action I would have performed months ago if it were that easy. The editor was obviously not familiar enough with these routes, otherwise they would have realized why the articles hadn't already been redirected.

Here's the point: A merge or a redirect of a stub article is an appropriate course of action, where merging of content is appropriate due to related routing or history. On the other hand, such mergers and redirects need to be done properly, not recklessly, and not just for the sake of reducing the stub count. -- LJ ↗ 07:59, 7 May 2010 (UTC)

This has been brewing for a couple of days; however, LJ guessed correctly when he stated that the merging of Carlin Tunnel with Interstate 80 in Nevada was the straw that broke the camels back and caused me to fire up the undo chainsaw. I am not picking on one person, as I'm seeing questionable merges throughout the project. However, the plus side is this motivated me to get off my duff and expand the Carlin Tunnel article to make it crystal clear why it should not be merged with I-80.Dave (talk) 08:05, 7 May 2010 (UTC)

Just a side comment here. I'm all for intelligence in mergers, and I know I've made a few errors along the way myself. Something though to remember is that several of our editors in the project are not yet old enough to drive, ironically. I know of one editor from the San Diego area that has edited articles all over the Western US that is only 12. Sometimes youthful exuberance conflicts what others would call common sense. Imzadi 1979 → 09:26, 8 May 2010 (UTC)

Two new templates

For those of you that have used {{Jctint}} and {{Jcttop}} in the past to make at-grade junction lists, meet {{Jctexit}} and {{Exittop}} for exit lists. They work exactly the same as the previous, but jctexit has an additional |exit= parameter to specify the exit number for a grade-separated junction. Exittop creates a MOS:RJL compliant table header, and it has the additional exit_ref= parameter to handle a reference for exit numbering, should one be desired. All other functionality is the same. I did not create a template to match {{jctbtm}}, because at this time, all that template does is substitute for |} to close a table, and if a key for colors is needed, there is {{legendRJL}}. If in the future the jctbtm template is extended to do more, then a similar template can be created. Imzadi 1979 → 09:22, 8 May 2010 (UTC)

Article Alerts bot down

I'm not sure if everyone has noticed, but the Article Alerts bot has been down for about a month...the USRD Article Alerts page has not been updated since April 8th. There's no telling when the bot will be repaired.

I thought it might be a good idea that if someone should come across and XfD discussion that might be of interest to the project, they should mention it somewhere. Maybe either in this discussion section (so as not to bloat this talk page too much) or a manual edit to the Alerts page. Thoughts? -- LJ ↗ 21:44, 8 May 2010 (UTC)

• May 8 - TfD: {{Infobox U.S. Route}} & various state-specific route infoboxes. (Discussion)

If any editors have some spare time...

List of numbered roads in Kawartha Lakes needs reviews at it's featured list candidacy. The nomination has sat dormant for a while, so if any editors have a few moments to spare it would be much appreciated. Thank you, ʄɭoʏɗiaɲ ^τ _¢ 03:57, 17 May 2010 (UTC)

Similarly, Portal:U.S. Roads needs comments on its Featured Portal Candidacy. The nomination is slated to be closed and archived later this week without any further comments. Imzadi 1979 → 07:29, 20 May 2010 (UTC)

Right-aligned mileposts

Since this change was made following a discussion between two editors on IRC at 3 AM Eastern, I figured I'd present it here for a larger one. I understand the concept, but what about articles with tables that don't use templates? Are we going to go through them and add "align=right" to every mileage cell? Are we going to force those articles and, in some cases, states to use the templates? If we do neither, we're staring point-blank at widespread inconsistency. – TMF 15:05, 12 May 2010 (UTC)

I should add that while I'm not necessarily opposed to the concept, I am opposed to using monospace text (Courier New and such) to present it. From what I've seen, the default text works well enough. I also think the monospace text looks like crap and should be relegated to use in code editing programs only. – TMF 15:30, 12 May 2010 (UTC)

Personally, I am opposed to the idea of right-aligning the mileposts, as it looks tacky. There is nothing wrong with them being left-aligned. Dough4872 15:53, 12 May 2010 (UTC)

In the future, could you provide an example of each, so those of us who weren't on the IRC discussion at 3AM could see for ourselves what the change causes? =-) Here is what I found: Right aligned U.S. Route 206, not right aligned California State Route 14. To me the difference isn't significant, and I wouldn't force a standard one way or the other, other than to be consistent. Also keep in mind, many articles can't use the template, due to situations that are not supported by the template. For example, Utah State Route 279, which is intentionally missing both the county and city columns. There was no way to do this with the milepost templates at the time this article was under development, but I think that functionality has since been added. Still, it's just easier to not use the template for an list as short as this is, as figure out how to turn those fields off. Dave (talk) 16:05, 12 May 2010 (UTC)

I wasn't awake at 3 AM either; if I was I would've voiced my opposition to it then. I should add there's also inconsistency within some articles at the moment. – TMF 16:43, 12 May 2010 (UTC)

Just looking at US 206's makes me puke. The right alignment just doesn't look right as it leaves a lot of white space to the left and especially on US 206, is really unnecessary. (Also what happened to not making non-consensus decisions on IRC? This is a prime example of that.)Mitch32^{(Growing up with Wikipedia: 1 edit at a time.)} 17:12, 12 May 2010 (UTC)

What happened to WP:BRD? There was no "discussion" on IRC. I boldly decided to make a change, that can easily be reverted. Don't like it? Hit the undo button. Imzadi 1979 → 19:24, 12 May 2010 (UTC)

Didn't like it, so I hit it. – TMF 21:29, 12 May 2010 (UTC)

If there were a way to align by decimal point, not unlike setting tabs in MS Word, I would whole-heartedly support that; I can't support making all articles to right align. —Fredddie™ 07:17, 13 May 2010 (UTC)

All of the mileages should be to the same precision, anyway. The only reason it wouldn't is if you were mixing and matching sources. The monospace font is necessary to make the number places align; just right-alignment doesn't do that. The only real argument that can be made is that the right-aligned, monospaced columns make the number places line up nicely. This is essentially an argument over aesthetics; this is bound to boil down to a ILIKEIT vs. IDONTLIKEIT discussion. (Saying "it makes me puke" is needlessly over the top, though. You may wish to consult a doctor.) —Scott5114↗ [EXACT CHANGE ONLY] 14:59, 13 May 2010 (UTC)

Something to consider, in the U.S. Route 8 article, where Mn/DOT and MDOT give mileages to 3 DPs and WisDOT only gives mileage to 2 DPs, a non-breaking space after the WisDOT mileages would force them to align the decimal point (assuming monospaced font). With everything left-aligned, there's a mish-mash. The column will appear with a lot of white space on that article because there's 3 sources necessary for the WI section of the table. That will be an issue whether you shuffle the whitespace to the right (left-aligned) or the left (right-aligned). When you left align the mileages, and there's single-, double- and triple-digits before the decimal point, it makes the mileages line up funny. Switching to right-aligment will at least come closer to lining things up better. As for articles that don't use the templates, well, there's no need to force them to either switch to templates nor update them manually to include "align=right fontfamily=monospace" into the tables, but it might be a benefit to do so. As an aside, the MI-specific templates have been set to centering the mileage columns for a very long time. Imzadi 1979 → 02:42, 20 May 2010 (UTC)

I'd personally rather have a "mishmash" than resort to excessive measures to align the decimal points. – TMF 04:13, 20 May 2010 (UTC)

How is setting a template to right-align and use a monospace font "excessive"? The only thing that the US 8 article does that might be "excessive" is insert the non-breaking spaces after the mileage figures in the WI section. Those could be removed if the MN and MI sections are rounded down in precision. Either way, with nbsps or rounded precision, the DPs would align. Imzadi 1979 → 06:01, 20 May 2010 (UTC)

It's excessive if it requires significantly modifying the hundreds of articles that don't use the templates to be consistent. Also, I detest using monospace font in articles. Like I said earlier, that font should be relegated to use in code editors and nowhere else. In any event, regarding your comment above re MIint, I suppose you wouldn't be opposed to states creating their own templates to keep the status quo if the right-align is re-added to {{jctint}}? – TMF 06:08, 20 May 2010 (UTC)

For now, there is a second series of templates. {{Jctintr}}, {{jctexitr}} and {{jctbridger}}, with the "r" appended to indicate right-alignment. They're transclusions of the regular templates, with the mileage (and exit) columns' formatting overridden to right-alignment, mono-spacing. Feel free to consistently use whichever series of templates in an article you wish. In the name of consistency, articles need only be internally consistent. Although it is generally a good thing to have groups of articles consistent with each other, the key is that the article is consistent with itself first.

We have hundreds of articles that don't use templates which have not been updated to the latest rounds of changes to RJL. Just tonight, I fixed this revision of Interstate 94 in Indiana to remove the dual mi/km columns, and correct the header to the current RJL specs. In the process, I switched it to the regular exit list templates. I'm sure there are many other articles that have similarly non-compliant tables that need updating at a minimum to comply with the changes to the table headers. I know there are many lists in various states that use the table colors that haven't had color legends added yet. It would be a little extra work to switch them to right-alignment in the process of other updates, if desired. Imzadi 1979 → 07:32, 20 May 2010 (UTC)

I'd say that's a fair compromise until this issue gets rehashed again down the line. The templates should be using "font-family:monospace", not "font-family=monospace", though. Since it's CSS, the equal sign doesn't work. – TMF 08:00, 20 May 2010 (UTC)

Ugh, too many ways to do things (CSS vs. HTML vs. wiki). Oh well, colons swapped in place of equal signs. Imzadi 1979 → 08:30, 20 May 2010 (UTC)

P.S. All of Michigan's articles that use templates (which should be all of them by now) have been switched over. The only question I have for the project at large is where a span of mileposts are used on a single line, like in the M-35 article. The CR 492 junction is given as MPs 126.715–126.744, but the <br> is set after the en dash. The effect of this is that it shows as:

126.715–
 126.744

I don't know that it really matters if the dash is shifted to the start of the second line or left on the end of the first. Shifting it would make it look like:

 126.715
–126.744

Thoughts? Imzadi 1979 → 10:20, 20 May 2010 (UTC)

TFD

See Wikipedia:Templates for discussion/Log/2010 May 20#Template:NJSCR-SA Dough4872 01:28, 20 May 2010 (UTC)

• Also see Wikipedia:Templates for discussion/Log/2010 May 18 for {{NYSR-SA}} and {{Featuredpash}} and Wikipedia:Templates for discussion/Log/2010 May 17 for {{U.S. Highway WikiProject}} and {{Interstate Highway WikiProject}}. Dough4872 01:41, 20 May 2010 (UTC)
• And Wikipedia:Templates for discussion/Log/2010 May 20#Template:Jct convert Dough4872 18:12, 20 May 2010 (UTC)

Category sortkeys

Hi,
can I get someone in the know to comment about the proper category sort keys of Interstate categories?
The edit I have in mind is this one, changing "[[Category:Interstate 84 (east)|384]]" to "[[Category:Interstate 84 (east)|84-3]]", to bring it in line with other articles from the series. The edit was reverted, and the IP made the same edit previously, and similar edits on other pages. WP:WikiProject U.S. Roads/Standards#Categories doesn't really say anything about it. Can someone clear (and clean) this up?
Thanks, Amalthea 17:18, 20 May 2010 (UTC)

As far as I know (i.e. unless it's been changed and I'm not aware of it), "84-3" is the proper sortkey, since it will allow the three-digit interstates to sort as "184", "284", "384", etc. (Note that the "84" in the interstate number denotes its connection to I-84.) The IP is probably one of those well-meaning but clueless sorts that this project seems to attract for some reason. —Scott5114↗ [EXACT CHANGE ONLY] 23:29, 22 May 2010 (UTC)

The IP was the one changing it to "84-3", actually. :) Amalthea 16:45, 28 May 2010 (UTC)

Future Interstate Highways

I reassessed Future Interstate Highways as a list since that's really what it is; however, I was reverted. Thoughts? – TMF 19:19, 21 May 2010 (UTC)

The article acts like a list because it lists all the routes that are future interstate highways, however, it can be assessed like a regular article too as it discusses to some detail a few of the routes. Roads and freeways in metropolitan Phoenix, a GA, is a similar case of a list that acts like an article. Dough4872 00:19, 22 May 2010 (UTC)

Honestly, most of the RCS-style lists should not not be assessed as "list-class" since most of them aren't tables of data. At one point, the precursor lists in Michigan were assessed like other articles. It's a little more complicated, but since each article/section in an RCS list could have a mini-RD, mini-history and even a mini-RJL, whether or not actual subheadings are used. In fact, they usually didn't have subheadings, just the actual content of those sections. In theory the whole article could be assessed as the average level of quality of the highway sections that make up the larger article. Simple to say that, "most of the future interstates here are roughly at start-class quality, so the whole thing is start-class" and tag it as such. The presence of IRSs in the articles only serves to make them less list-like and more "summary article", especially when some sections have {{main}} tags used. To me, a list-class article is really a bulleted list or a table of data on several highways, with a prose section that acts as a lead to summarize and explain the content of the list. Imzadi 1979 → 00:45, 22 May 2010 (UTC)

Well, if we're not going to assess them as List-Class, then we need to develop a concrete standard for the RCS and other articles. Right now, there isn't any, so any assessment grade other than list is subjective. – TMF 01:05, 22 May 2010 (UTC)

Also, if we're not going to consider the future IH a list, it shouldn't be listed as a list in the Interstate navbox; on the same token, all of the RCS lists should be renamed if they're not lists. – TMF 01:11, 22 May 2010 (UTC)

List of highways in Hamilton County, New York is pretty much in the RCS style, but has passed as a Featured List. That puts their assessment pretty solidly in the List class for me. —Scott5114↗ [EXACT CHANGE ONLY] 22:48, 28 May 2010 (UTC)

Interstate and US Highway navboxes

Back in 2008, it was proposed that {{U.S. Routes}} be remade using the {{Navbox}} meta-template. While, I don't like the execution in that proposal, I do like the idea. The same idea would then be applied to {{Interstates}} as well. Any objections to doing this? —Fredddie™ 06:54, 29 May 2010 (UTC)

Examples here. —Fredddie™ 08:24, 29 May 2010 (UTC)

While the navbox style seems more standard for Wikipedia, the current style is easier to read based on the numbering scheme. Personally, I would not mind either. Dough4872 23:32, 29 May 2010 (UTC)

For whatever reason, I'm not keen on the proposed redesigns. The redesigns remind me a lot of the state highway navboxes that were canned years back in that the primary USHs and IHs are just bunched together and listed off numerically with no efforts made to fully utilize the navbox template and further organize the routes. I'm also not a fan of using boldface and italics to denote major or former routes. Maybe the latter two could be moved to their own groups in the navbox? I should note that I'm not saying I think this is a bad idea; I'm just saying I don't like the current implementation of it. – TMF 06:07, 30 May 2010 (UTC)

Two deletion discussions

See Wikipedia:Articles for deletion/PA 3006 and Wikipedia:Articles for deletion/SR 3017 in Farrell. Dough4872 00:21, 31 May 2010 (UTC)

Pageview stats

After a recent request, I added WikiProject U.S. Roads to the list of projects to compile monthly pageview stats for. The data is the same used by http://stats.grok.se/en/ but the program is different, and includes the aggregate views from all redirects to each page. The stats are at Wikipedia:WikiProject U.S. Roads/Popular pages.

The page will be updated monthly with new data. The edits aren't marked as bot edits, so they will show up in watchlists. You can view more results, request a new project be added to the list, or request a configuration change for this project using the toolserver tool. If you have any comments or suggestions, please let me know. Thanks! Mr.Z-man 22:52, 1 June 2010 (UTC)

List of "mother roads"

A while back, there was a discussion on IRC about project-critical articles which need to be improved; US 66 comes to mind. I was hoping to create a list of "mother roads" and get some input on how we can organize to get these articles moving in the right direction. —Fredddie™ 06:03, 31 May 2010 (UTC)

U.S. Route 66

Lincoln Highway

U.S. Route 1

U.S. Route 50

U.S. Route 40

U.S. Route 30

U.S. Route 101

Interstate 95

Interstate 5

Interstate 75

Interstate 80

Interstate 90

National Road

Interstate Highway System

United States Numbered Highways

I've added 3 US Routes and 5 Interstates for the list.Mitch32^{(Growing up with Wikipedia: 1 edit at a time.)} 19:43, 31 May 2010 (UTC)

I don't think a list of "mother roads" is going to work as it is too subjective. Editors appear to choose whatever roads they feel is important to them. The current list only selects a few of the cross-country interstate and U.S. routes, as well as one auto trail. If we want to have a list of "mother roads", we need a set standard for what can be included on the list. Dough4872 22:03, 31 May 2010 (UTC)

I think you're misunderstanding where this is going. There isn't going to be an article that's a list of important roads, which indeed would be subjective. This is a list that we the project feel need to be better articles. Take a look at WP:Core biographies, the same concept is in use there. While, I don't think we need to be nearly as formal as Core biographies, it's a good idea to identify articles that we need to get right. —Fredddie™ 22:10, 31 May 2010 (UTC)

Ok hold on. "Mother Roads" is meant, at least to me, as a term for, most important roads with articles. Whether or not standards comes to mind, the 11 up there are rather important,especially because like a) US 66 being US 66, b) US 1 being the big N-S, c) 50 and 30 are important cross-countriers, d) 95, 5, 80 and 90 are important cross country interstates (and some of the best known). We're not looking for anything official, this is just a project's opinion, not anything set in stone. We just never seem to get around to doing anything. If we could dedicate more time to AIDs, it would help, but we just can't.Mitch32^{(Growing up with Wikipedia: 1 edit at a time.)} 22:11, 31 May 2010 (UTC)

The thing I am concerned is that we are cherry-picking. Why is I-90 considered to be important and I-10 not? Why is US 40 considered to be important and US 70 not? I think a good idea for the "mother roads" list is for it to include what AASHTO defines as major for US and Interstate routes as well as other significant roads such as US 66 and Lincoln Highway. In addition, articles such as Interstate Highway System and United States Numbered Highways need our attention too. Dough4872 00:20, 1 June 2010 (UTC)

Dough, you're way overthinking this. The idea, which didn't go anywhere when I proposed it last time, is to come up with a list of articles that the project feels are important. Articles that should be FA-, A- or GA-class at some point in the future. For this project to work, it must be cherry-picked to keep it to a manageable size. IMHO, we should have only a couple of each type on the list at any time. As articles are brought up in quality, they can be replaced on the list. Imzadi 1979 → 01:02, 1 June 2010 (UTC)

As a side note, one of the articles (US 50) is a GA already. Dough4872 02:11, 1 June 2010 (UTC)

I don't think it's unrealistic to have a goal of FA for all of the articles we decide upon. —Fredddie™ 02:43, 1 June 2010 (UTC)

I forgot where it is, but I've always wondered if USRD could open some sort of "vital article" thing like on the complete Wikipedia. As a "centralized watchlist", if one of you is really bored you could try to do that with these articles. The levels could be based on traffic or people living on the route. --PCB 15:23, 2 June 2010 (UTC)

WP:VITAL. I kinda like this idea. WP:VITAL has four levels, with Level 1 being the most general. Each level narrows the category. For our use, Road could be a Level 1, United States Highway System could be Level 2, U.S. Route 101 could be Level 3, and U.S. Route 101 in Washington could be Level 4. —Fredddie™ (oops forgot to sign)

TfDs in June

Wikipedia:Templates_for_discussion#June_12 has TfDs for {{Infobox Iowa Highway multiple}}, {{Infobox Arkansas Highway multiple}}, {{Infobox Oklahoma Highway 2}} and {{Start srbox fl}}. Imzadi 1979 → 11:02, 12 June 2010 (UTC)

The infobox TfDs have been closed already based on earlier consensus. Imzadi 1979 → 23:31, 12 June 2010 (UTC)

AWB run needed

Would someone with AWB capabilities please do a run on the national USH articles? With the {{Infobox road}} revamp completed, articles that have |state=US don't show the links that were handled previously by {{Infobox road/US links}}. Changing |state=US to |type=US will fix this. —Fredddie™ 23:24, 12 June 2010 (UTC)

I made a run... not sure though if that was all of them. Imzadi 1979 → 00:04, 13 June 2010 (UTC)

I changed over a lot of them last night when I made an AWB run to fix errors regarding the length parameters. – TMF 01:56, 13 June 2010 (UTC)

There are many articles that still use state=US, some of which are state-detail or intrastate articles that need the state corrected along with moving US to the type param. I posted a full list of articles at User:TwinsMetsFan/Sandbox/1. – TMF 05:53, 14 June 2010 (UTC)

Merge discussion

Talk:Richard M. Nixon Parkway --Rschen7754 08:59, 13 June 2010 (UTC)

Template:U.S. Routes

What happened to 0 or 1 only? --Rschen7754 21:54, 13 June 2010 (UTC)

More poor IP edits

Special:Contributions/98.81.9.230 - this is the same guy who keeps making poor edits to articles, including adding spaces around the hyphens in the abbreviations of Interstate Highway numbers. – TMF 18:06, 12 June 2010 (UTC)

Well, what can we do about it? --PCB 16:52, 15 June 2010 (UTC)

Revert them if he makes any more, clearly. – TMF 17:04, 15 June 2010 (UTC)

Another merge discussion

See Talk:Pennsylvania Turnpike#Merging Interstate 276 Dough4872 03:57, 17 June 2010 (UTC)

Two AFDs

Wikipedia:Articles for deletion/County Route 8 (Hampshire County, West Virginia) and Wikipedia:Articles for deletion/Kentucky Route 595 Dough4872 15:37, 18 June 2010 (UTC)

MA Route discussions

Talk:Massachusetts Route 3A#Merge proposal and Talk:Massachusetts Route 8A#Split proposal – TMF 16:08, 21 June 2010 (UTC)

Another: Talk:Storrow Drive#Merge proposal – TMF 22:13, 21 June 2010 (UTC)

Kansas county codes

At the time that Kansas's subproject was established, it was in the standards for that project that counties were to be included in the infobox, abbreviated to their two-letter county code, as defined by the state. This standard seems to have silently disappeared without discussion, either at the time that KS was demoted to task force or when USRD/STDS was established. This has resulted in some people going around removing them. I would like to talk about it for the next thirty minutes or so.

Unlike similar codes in other states, Kansas's county codes are well known to the residents of that state. A complete list of them is given on the state map. The code is prominently displayed on the license plate, and I believe on driver's licenses as well. Johnson County's code, JO, is frequently used as a shorthand for that county and its culture; the Johnson County Transit bus system is branded as "The JO", with the "JO" part of the logo designed to resemble the "JO" sticker found on license plates. Wyandotte County's code, WY, is also frequently found in Kansas City popular culture. Perhaps most prominently, the Wyandotte County–Kansas City consolidated government calls itself the "WyCo Unified Government".

The county codes' prevalence leads me to believe many Kansas residents, upon seeing them used, would instantly know what they are. If unfamiliar with the codes, a user could mouse over them and, because they are links, be informed of what they stand for instantly (or could check the exit list to see them in expanded form). Using the codes allows a long list of county names to be considerably compressed, saving space in the infobox. I therefore wish to see them readded to the state-specific standards for Kansas. —Scott5114↗ [EXACT CHANGE ONLY] 12:48, 14 June 2010 (UTC)

The purpose of allowing abbreviations and ISO dates, in infoboxes that wouldn't be appropriate in article text is space. I'm not sure the space savings gained outweigh turning the counties in the infobox into Easter Eggs. Imzadi 1979 → 05:01, 17 June 2010 (UTC)

• Scott, Lane, Ness, Rush, Barton, Rice, Ellsworth, McPherson, Saline, Dickinson, Morris, Wabaunsee, Shawnee, Jefferson
• SC, LE, NS, RH, BT, RC, EW, MP, SA, DK, MR, WB, SN, JF

The space savings on a long route like K-4 are rather dramatic (and are even more so in context given the small width of the infobox). As stated, Kansas users would be familiar with these abbreviations. They are the first thing mentioned in the articles about the counties they are in—Rush County (standard abbreviation RH) is a county located in the U.S. state of Kansas... These abbreviations are highly standardized, sourceable to Kansas state documents, and help keep the infobox from being overwhelmed with a massive block of county names. Again, it hardly matters if they are condensed, since they are repeated spelled-out in the junction list anyway. —Scott5114↗ [EXACT CHANGE ONLY] 03:44, 19 June 2010 (UTC)

If the abbreviation standard for counties is well-known in KS, which appears to be the case, I would say go with it. Dough4872 03:07, 20 June 2010 (UTC)

I disagree. Outside of Kansas residents, these abbreviations aren't very useful to 99% of Wikipedia readers. Even then, who's to say they're really useful for Kansas residents. I don't think we should be confusing the masses to save a half-inch of space in the infoboxes. —Fredddie™ 03:30, 27 June 2010 (UTC)

I agree with Fredddie, and sometimes state conventions need to conform to national conventions for consistency. Imzadi 1979 → 03:43, 27 June 2010 (UTC)

I'm not aware of a national convention on how and whether to abbreviate county names. I would be inclined to say that if we are not to abbreviate these in the infobox (remember, the spelled-out county names are also included in the article), there is not much need to include them in the infobox either, since they take up a lot of room and don't add much value to the infobox. The spelled out county name is probably not very useful to 99% of Wikipedia readers, either; if you aren't familiar with "LN" standing for "Lane County" you're likely to not be able to pick it out on a map, either. —Scott5114↗ [EXACT CHANGE ONLY] 03:13, 28 June 2010 (UTC)

TFDs

• See Wikipedia:Templates for discussion/Log/2010 June 21#Template:Dubuque Expressways Dough4872 02:06, 21 June 2010 (UTC)

Also Wikipedia:Templates for discussion/Log/2010 June 21#Template:Champaign–Urbana expressways Dough4872 02:17, 21 June 2010 (UTC)

• Comment - Id appreciate it if next time you notified me (the author of the templates) as well if your going to list something I created for deletion rather then notifying an outside group first. Thanks -Marcusmax(speak) 03:33, 21 June 2010 (UTC)

• Template:VA facility and Template:VA facility/route —Fredddie™ 21:57, 29 June 2010 (UTC)

Discussions going "stale"

I find that many of the discussions here have gone "stale". Important discussions are archived before any mutual consensus is reached or any more content can be commented. Is there a way to fix this? --PCB 23:42, 26 June 2010 (UTC)

If a discussion on this page is truly that important, USRD members generally respond in a timely fashion and the issue is discussed well before the conversation is archived. This talk page has a relatively short archive period (10 days) to accommodate those times when there are multiple important conversations going on and the page size can get rather large. Sometimes, just a single entry is needed for a topic, because the main discussion is taking place elsewhere. Keep in mind also that sometimes there may being discussions going on off-wiki (like on the IRC channel), with the intent of bringing final proposals or actions back here.

If for some reason the discussion of a seemingly important issue appears to have gone stale, you can edit that topic with a question like "what's the status on this?" or "It's been a few days, anybody have new opinions on this?". Such an action will keep the discussion on the page a bit longer, and may serve as a reminder to those watching the discussion/page that a final consensus or decision wasn't reached and prompt a revival of the discussion. I wouldn't do this for everything though--just topics that are really important to the overall project. If an important discussion does happen to get archived without a final resolution, there's nothing prohibiting the topic from being brought up again in a new thread (just link to the previous discussion in the archive for easy reference). -- LJ ↗ 02:04, 27 June 2010 (UTC)

With the nature of this talk page, I think a bot archiving is not necessarily the best idea. Sometimes, several discussions can arise in a couple days and quickly be resolved, but remain on the talk page until the bot archives them. Other times, there may only be a few discussions that go stale and are archived without resolution, not allowing more time for the issues to be addressed. Therefore, manual archiving may work better for this talk page. Dough4872 02:30, 27 June 2010 (UTC)

The bot will archive 10 days after the last comments. If you comment with a "what's the status of this?" and sign the comment, the bot will not archive the discussion for 10 more days, thus extending the discussion time. Yes, sometimes some discussions happen on IRC, which isn't really a good practice to come people, but I prefer it for one situation. Rather than propose an idea with draft 1.0 and spend a week on-wiki to discuss it to come up with draft 2.0 only to spend another week to come up with final consensus version 2.5 or 3.0, we can discuss something faster on IRC sometimes and skip to 2.0. Imzadi 1979 → 02:42, 27 June 2010 (UTC)

In related news: user Kslotte (talk · contribs), in what appears to be a quest to revise archiving across Wikipedia, changed the archive settings on this page to minthreadsleft = 10 and |algo = old(20d) (20 day archive delay). Are those settings something we want to keep, or should they be adjusted? -- LJ ↗ 17:52, 27 June 2010 (UTC)

Given the random and unilateral nature of the archiving changes, based dubiously on a guideline that applies to articles, and not talk pages, I'm going to oppose that change and suggest we revert to the previous settings. Imzadi 1979 → 19:21, 27 June 2010 (UTC)

The change I made leave more threads and longer time on this page before archiving. Wasn't it that what PCB asked for? --Kslotte (talk) 20:55, 27 June 2010 (UTC)

Not really, and the solution to his inquiry isn't changing the archival settings, it's as simple as just posting a status inquiry question, which 1) will prompt people to reply and 2) extend the time before a thread is archived. This talk page is well-watched by active members of the project, so 20 days is really too long for us. Imzadi 1979 → 19:30, 28 June 2010 (UTC)

Should we leave as such with 10 days or try for example 14 days? --Kslotte (talk) 16:46, 29 June 2010 (UTC)

I don't see how that would change something. As has been pointed out, if a discussion ends without a conclusive decision, simply adding a "What's the status?" will prevent the thread from being archived, and it will cause the talk page to show up on watchlists, bring attention back to the issue. When the matter is settled, what difference does leaving it on the main talk page for 4 more days before archiving make? I could say that once the discussion is settled, the thread should be immediately archived. Additionally, since the Article Alerts bot went out of commission, we're back to adding notifications about proposed mergers and deletions. At a 14-day archival window, the AfD will be closed a week prior to the initial notice being archived. At least with a 10-day window, that time is reduced. Imzadi 1979 → 17:30, 29 June 2010 (UTC)

PCB, move threads back here from archive, if there are threads that are still "open". --Kslotte (talk) 21:13, 27 June 2010 (UTC)

Mass Change of Reference URLs

I discovered Friday that the links to the highway location reference files used to reference mileposts and other information for Maryland roads are no longer working. That is because the files have been moved to a new server, from www.sha.state.md.us to apps.roads.maryland.gov. I will need to confirm, but I believe the file names have remained the same. Is there an easy way to update all of the references in the hundreds of Maryland road articles? Or will these updates need to be done "by hand?" Viridiscalculus (talk) 11:29, 27 June 2010 (UTC)

If only the server name and directory is changing, I can easily use AWB to change that part of the URL on all of the articles. Imzadi 1979 → 19:23, 27 June 2010 (UTC)

Just let me know what parts of the URLs that are changing, and I'll run AWB over Maryland's articles for you. Imzadi 1979 → 18:31, 28 June 2010 (UTC)

Thank you Imzadi for working on this. There are several sets of files that link to the MDSHA website affected. The first set, and the highest priority, are from the Highway Location Reference. The old server is www.sha.state.md.us. The new server is apps.roads.maryland.gov. The directory structures appear to be identical. The next set is the Traffic Volume Maps. The directory structure has been simplified for these, with only the filenames being identical. For instance, the old link to the 1984 map was www.sha.state.md.us/shaservices/mapsbrochures/maps/oppe/trafficvolumemaps/years/84_Traffic_Volume_Maps.pdf. The new link is www.marylandroads.com/Traffic_Volume_Maps/84_Traffic_Volume_Maps.pdf. Finally, the server for SHA project pages has changed from www.marylandroads.com to apps.roads.maryland.gov, with no changes to the directory structure. Viridiscalculus (talk) 02:12, 29 June 2010 (UTC)

Running AWB now. AWB run done, 434 pages edited. Let me know if anything is wrong. Imzadi 1979 → 20:47, 29 June 2010 (UTC)

Merge discussions

Talk:Centennial Corridor, Talk:Westside Parkway --Rschen7754 18:29, 28 June 2010 (UTC)

Both have been nominated at AfD here. Imzadi 1979 → 19:12, 30 June 2010 (UTC)

New infobox parameter

M-64
Route information
Maintained by MDOT
Length	64.12 mi (103.19 km)
Existed	1930–present
Tourist routes	Lake Superior Circle Tour
Major junctions
South end	CTH-B near Presque Isle, WI
Major intersections	US 2 in Marenisco M-28 in Bergland
North end	US 45 / M-38 in Ontonagon
Location
Country	United States
State	Michigan
Counties	Gogebic, Ontonagon
Highway system
Michigan State Trunkline Highway System Interstate US State Byways
← M-63 → M-65

In updating the infobox for New Zealand, two new parameters were added. The |tourist= parameter was created for NZL as a way to display their tourist routes. In creating the update, I set it up so that only a white list of approved countries can display the parameter, much like how the various types of locations are done now. I initially set up this new parameter to allow the US to display tourist routes in addition to NZL and CAN. I'm starting this thread here because while it is possible to indicate in the infobox that a highway follows a tourist route, like the different Great Lakes Circle Tours or the Great River Road, I would like to know what the project thinks of it. Personally, I'd only use it to indicate that a highway in Michigan is part of one of the Circle Tours, or a National Scenic Byway. I've added a copy of the M-64 infobox showing how the output looks, if used. I imagine that other states could use it for the Great River Road or National Scenic Byways. I would say that if we use it, we develop clear guidelines for inclusion now, rather than later. Imzadi 1979 → 19:24, 5 July 2010 (UTC)

I'm not sure what I think about this. In the case of the Seaway Trail, the most prominent NSB in New York, it follows many routes as it goes across the state, and rarely is an entire route part of the byway. I think it's misleading to list the Seaway Trail in the param if just a short portion of the route is part of the byway, and entering enough detail to make the entry more accurate would likely make the cell a bit oversized, which goes against the (what should be) concise nature of an infobox. (I've seen how New Zealand uses the parameter, and how they use it - listing every section of a route that's part of a "tourist route" - is less than desirable IMO.) – TMF 20:12, 5 July 2010 (UTC)

Right, and for the US, I agree that the NZL practice won't work for us. I guess my idea is that we'd use it where either: a) a highway has more than one (I-75 in MI has 4 of the GLCTs) or b) a substantial portion of the highway has the route, but not all of it (M-64 carries the LSCT from M-28 north to its terminus, but not south of the M-28 concurrency). In both cases, using |alternate_name= isn't appropriate, but it would be desirable to list it somehow. I would say that "memorial highway designations" aren't to be used here at all. Just these types of tour routes or National Scenic Byways/All-American Roads. Imzadi 1979 → 20:35, 5 July 2010 (UTC)

Agreed on limiting the use of it to NSBs, AARs, or significant byways like the GRR or the Circle Tours. As for the formatting of it and the articles it should be used on... I don't know. I'll let others chime in on that, see if they have some ideas. – TMF 20:47, 5 July 2010 (UTC)

I agree that a tourist parameter would be useful for roads that are part of a tourist route. Dough4872 02:23, 6 July 2010 (UTC)

Hatnotes on dabbed articles

Talk:Interstate 88 (east) - should an article that's disambiguated to distinguish it from other routes with the same number have a hatnote linking to those other routes? This is an issue that comes up once every year or two years, and I'd like to finally put it to bed one way or the other. – TMF 08:03, 7 July 2010 (UTC)

I don't see the need of a hatnote if a disambiguation page already exists. Dough4872 15:26, 7 July 2010 (UTC)

WP:NAMB is pretty clear on this -- no hat. Yes I realize the project could override this guideline, but there is no good reason to, IMO. -- KelleyCook (talk) 19:14, 7 July 2010 (UTC)

Random CA stubs

Resolved

I found the following articles tonight: County Route 145 (California), County Route 502 (California), County Route 505 (California), and County Route 515 (California). No clue as to whether they're notable, they're in counties that apparently use a different county route system than my part of CA does. --Rschen7754 06:59, 8 July 2010 (UTC)

Since they are all one-sentence stubs, couldn't they be merged into a nice table or list in the Lake County, California article? Imzadi 1979 → 16:17, 8 July 2010 (UTC)

I would say to merge all the above county route stubs into a new list article called County routes in Lake County, California. Dough4872 01:12, 9 July 2010 (UTC)

Since we have the lists by zone for the CRs that use that system, perhaps we could have a list for "unzoned" highways like this. —Scott5114↗ [EXACT CHANGE ONLY] 09:28, 9 July 2010 (UTC)

Apparently, it appears that Lake County is the only county in CA that does not have zoned CRs, so the list title for Lake County may be the way to go here rather than a Unzoned county routes in California list. Dough4872 16:57, 9 July 2010 (UTC)

If someone gets to it, that would be great; I'll do it by the weekend if nobody has done it. --Rschen7754 19:56, 9 July 2010 (UTC)

I created the Lake County list. It's not much to look at, but they've all been merged and redirected there, with links to the list from other appropriate articles. Imzadi 1979 → 20:28, 9 July 2010 (UTC)

Thanks! --Rschen7754 20:42, 9 July 2010 (UTC)

Florida SR 293

Stale

From my understanding, Florida State Road 293 is little more than the Mid-Bay Bridge and its approaches. I don't see a need for both articles to exist, so the question is should the bridge be merged into the route or vice versa? (Interestingly, the bridge is tagged as USRD while the route isn't at the time of this posting.) – TMF 17:54, 9 July 2010 (UTC)

It depends if the bridge or the route number is more noted in the area. In this case, it appears the bridge article may contain more detail so SR 293 should be redirected there. Dough4872 18:22, 9 July 2010 (UTC)

My gut-level reaction on first glance is to merge to the bridge article title. (It doesn't matter which has more detail or not. The merged article will have all the detail of both from before the merger. The question is which name is better, and the other one will redirect there.) I'd make the main infobox a {{infobox bridge}} with appropriate information, and follow that up lower in the article with a section/paragraph on the SR 293 designation with {{infobox road small}} for the SR-designation specific stuff, displaying both the regular and TOLL shield styles (using type=Both). Imzadi 1979 → 20:12, 9 July 2010 (UTC)

It should be noted that the both type is incompatible with IBRS, which is only capable of displaying one shield per transclusion when using the types. Both shields can be used if hardcoded in using {{{shield}}}, however. – TMF 20:16, 9 July 2010 (UTC)

Rats, but my idea still stands though. Imzadi 1979 → 20:29, 9 July 2010 (UTC)

I detagged the article from USRD not knowing about this discussion here. (Merge tags are your friend!) If this is true I'd advocate for a merge. —Scott5114↗ [EXACT CHANGE ONLY] 01:42, 10 July 2010 (UTC)

Deleted page

Resolved

The following page was deleted without any prior discussion: List of Farm to Market Roads in Trans-Pecos Texas. This was a completed list. What happened? Fortguy (talk) 02:40, 1 July 2010 (UTC)

It was moved to List of farm-to-market roads in Trans-Pecos Texas. – TMF 02:42, 1 July 2010 (UTC)

That doesn't make sense. All the other regional lists of Farm to Market Roads are capitalized as "Farm to Market Roads" is how TxDOT refers to them. Fortguy (talk) 03:00, 1 July 2010 (UTC)

I didn't move it, but I suspect it has something to do with the fact that the so-called "parent" article is named farm-to-market road. – TMF 03:01, 1 July 2010 (UTC)

A while ago, we had a discussion saying that "Farm to Market Roads" needs to be capitalized as is. Therefore, this page should probably be moved to that title. Dough4872 00:14, 3 July 2010 (UTC)

I just hope to see a stable consensus built. These pages have been moved by different people over time between capitalized and lower case titles sometimes including hyphens (which TxDOT doesn't use). That way we could avoid the confusing page moves and have an agreed nomenclature for describing these roads generically. Fortguy (talk) 02:15, 3 July 2010 (UTC)

Since there are farm-to-market roads in Iowa as well as Texas, I'd like to see the main farm-to-market road article to stay as is (lowercase). The lists should be in Title Case; it's the same difference between an Interstate Highway and an interstate highway. —Fredddie™ 02:59, 3 July 2010 (UTC)

However, in TX, TxDOT capitalizes the term "Farm to Market Road" [23]. Therefore, the titles of the TX lists should be capitalized. This had been decided in a previous discussion at WT:USRD. Dough4872 16:07, 3 July 2010 (UTC)

I agree with Fredddie on this one (and wonder why Dough seems to disagree with Fredddie's statement backing up his opinion). The generic article title doesn't get titled, but components of the Texas system do. The article on "business route" is not capitalized as a generic concept, but "M-28 Business Route" is capitalized as a part of a proper name in the lead of those two articles. Imzadi 1979 → 19:24, 3 July 2010 (UTC)

I only said the TX lists needed to be capitalized in my post, not the main farm-to-market-road article. I should have made that a little more clear. Dough4872 12:16, 4 July 2010 (UTC)

That's what I said, but it seemed like you were in disagreement. Thanks for clarifying. —Fredddie™ 22:17, 4 July 2010 (UTC)

In this case, should we move the TX FM list articles back to the capitalized versions? Dough4872 17:18, 6 July 2010 (UTC)

All of the affected lists were moved now. Imzadi 1979 → 03:29, 13 July 2010 (UTC)

Auxiliary route navboxes

WP:USRD/STDS#Auxiliary routes currently states: "Place the 3di template in this section if the article route is a primary interstate." For most primary Interstate Highways, this results in a section like Interstate 87 (New York)#Auxiliary routes, where it has a navbox and nothing else. I propose eliminating the "Auxiliary route" section and moving the navbox to its rightful location unless no navbox exists for the route and some auxiliary routes do exist (like with Interstate H-1, where its navbox was rightfully deleted a while back for having only one link in it). – TMF 00:36, 12 July 2010 (UTC)

For the section, I think it would be a good idea to list the auxiliary routes in bullet form, but the navbox already serves the purpose. I don't see too much harm with where the navbox is now. Dough4872 00:58, 12 July 2010 (UTC)

So you support a bulleted list and the navbox in the Auxiliary routes sections? "Where the navbox is now" is in that section, per WP:USRD/STDS. I don't necessarily like how the I-XX aux templates look on the main interstate page, but I definitely don't think they should be under a section heading. —Fredddie™ 02:31, 12 July 2010 (UTC)

I do not support both simultaneously, as that would be redundant. Articles with only one auxiliary route should use a bulleted list while articles with the navbox should use that. Dough4872 03:15, 12 July 2010 (UTC)

If there was only one aux route, it wouldn't be much of a list... —Scott5114↗ [EXACT CHANGE ONLY] 15:51, 12 July 2010 (UTC)

If there's only one auxiliary route, it should be linked elsewhere in the article and that's that. If there's enough for a template, the template belongs at the bottom of the article with the others, not in a separate section. Otherwise, the "Auxiliary routes" section is acting as a renamed "See also" section, which is only to be used when there are other related articles that aren't linked in the text already. Imzadi 1979 → 17:03, 12 July 2010 (UTC)

Nav boxes really should be at the bottom of an article--having a navbox in a prose section with nothing else doesn't make much sense. With that said, I don't think the "Auxiliary routes" section is completely without merit, even with the navbox at the bottom--a bulleted list with short information about the location of the auxiliary route would be fine for this. -- LJ ↗ 21:36, 12 July 2010 (UTC)

Pasadena Freeway

If interested in the proposed rename for this article, check in at the nomination. Vegaswikian (talk) 21:21, 12 July 2010 (UTC)

Newsletter

Stale

I have started the proceedings to get this season's newsletter going. I entered July 12 as the deadline; I think we can put something together in a week. WP:USRD/NEWS. —Fredddie™ 05:11, 6 July 2010 (UTC)

The deadline has passed and the newsletter is still incomplete. We need some more help to get it ready. Dough4872 17:02, 14 July 2010 (UTC)

Featured sound candidate

The project's first FSC has been nominated at: Wikipedia:Featured sound candidates/Eisenhower speech, October 9, 1954. Imzadi 1979 → 06:14, 18 July 2010 (UTC)

Geocoding discussion

See Wikipedia talk:WikiProject Highways#Geocoding_of_highways for a discussion on the use of coordinates on road articles. - ʄɭoʏɗiaɲ ^τ _¢ 19:32, 22 July 2010 (UTC)

Infobox road color

Current default

Proposed color

I'm going to propose something here. I've been reviewing other countries' infoboxes, and while I love the look of the new infobox road, the blue shade feels a little blah to me. I've been looking for an answer, and I think I have it, and I'd like to urge others to adopt it. I would like to switch the US to use a default shade of green to approximate MUTCD guide sign green as the background for the headers in the infoboxes. Already, editors can switch confirmed highway proposals, or roads currently under construction to have orange, as M-231 (Michigan highway). Other roads can also be switched to brown for scenic, historic or park highways. The blue is fine as a default, but I don't want the US to settle for the default anymore. Imzadi 1979 → 04:06, 6 July 2010 (UTC)

Support: I think it's important to be consistent here. Those of us who have been implementing the infobox across the wiki have been emphasizing that the color(s) should be representative of the locations. MUTCD green is a fine choice and is perfectly in line with what's been going on elsewhere. —Fredddie™ 04:11, 6 July 2010 (UTC)

I would not mind seeing the MUTCD green being used in the infoboxes for US roads. However, I am also fine with the default blue. I am opposed to any sort of color-coding in the infoboxes for future or scenic roads, as that will lead to problems. Dough4872 04:23, 6 July 2010 (UTC)

There wouldn't be problems if we spell out the rules for it, and add that to the project standards. This proposal though is on the green only, not the orange or the brown. Imzadi 1979 → 04:44, 6 July 2010 (UTC)

Can we see a mock-up of an infobox road with the green replacing the light blue? Viridiscalculus (talk) 05:01, 6 July 2010 (UTC)

I have edited the example from the discussion above to serve as a mockup. —Fredddie™ 05:04, 6 July 2010 (UTC)

Comment I temporarily (using preview) added the proposed color to an in-practice infobox on an article, and I think the color looks good. However, what I also saw is that the color is bold enough that it distracts a bit from the article. The default blue is subtle enough that it really doesn't do that. Perhaps it's because I'm not used to the green or whatnot, but that's my kneejerk reaction to it. – TMF 05:17, 6 July 2010 (UTC)

We can't use light green or something? I do think the darker green is distracting. --Rschen7754 05:22, 6 July 2010 (UTC)

I've also been thinking the bluish color was a bit bland. The green as proposed is a bit bold though. Perhaps make the MUTCD colors like 50% transparent or something so it's not so striking...that or just use a lighter green (the Caltrans spec for green is a bit brighter than the federal MUTCD, but would probably still have the same problem). -- LJ ↗ 05:35, 6 July 2010 (UTC)

But what of the general concept? Imzadi 1979 → 05:49, 6 July 2010 (UTC)

I believe the general concept has merit, and I'm for it. The only part I have an issue with is the shade of green that's used, but that's resolvable with some tweaking and experimenting. – TMF 06:28, 6 July 2010 (UTC)

I think the concept works: Green for most routes, brown for historic/scenic routes, maybe even the purple for roads that are fully toll facilities. I just think the header colors should not be so bold and vivid as to detract from the remainder of the article...hence my suggestion to have the colors be somewhat transparent or otherwise muted from normal. -- LJ ↗ 06:38, 6 July 2010 (UTC)

Ok, for sample purposes, the orange and brown are live now. M-231 (Michigan highway) has the orange as "under construction" (it's not started yet, but MDOT's contracting the Grand River bridge for it.) Saginaw Trail has the brown. A second article that I'll switch for a test is U.S. Route 66 in New Mexico. The starting green is above. Now, we just need to tweak the colors until we're satisfied. The orange in use is not MUTCD orange, which was too bright. I'm hesitant on the purple, but I'm sure a darker "lavender" would work, if others want to go there. I think the brown is good as is. Imzadi 1979 → 07:02, 6 July 2010 (UTC)

How historic are we talking for historic? Decommissioned highways? Auto trails? Abandoned New England turnpikes? —Scott5114↗ [EXACT CHANGE ONLY] 09:14, 6 July 2010 (UTC)

If the maintaining agency uses brown signage, or it's an old auto trail, I'd use the brown personally. For regular decommissioned highways, stick with the green. That's just my opinion, and that's part of what we're figuring out here is guidelines ahead of time. Imzadi 1979 → 16:27, 6 July 2010 (UTC)

I think the brown is less bold than the green above, but still too bold for use in the infobox. – TMF 15:56, 6 July 2010 (UTC)

I still think having a color for historic roads would be subjective with the point Scott brought up. Also, there may be edit-warring over the uses of colors for future or toll roads. I think we need to either use the MUTCD green or stick with the default blue for all US road articles. Dough4872 16:27, 6 July 2010 (UTC)

Edit-warring is a blockable offense, no matter what the reason. People edit war over the content in exit lists, words used in articles and any other number of reasons. Every edit war is bad, period. Why throw the baby (the color option in this case) out with the bathwater? Imzadi 1979 → 17:26, 6 July 2010 (UTC)

Does this bring any issues for people that are colorblind in the green spectrum? 25or6to4 (talk) 16:14, 6 July 2010 (UTC)

As long as the text is white, we should be ok. However, your line of thinking is quite correct. This should be tested on a variety of computer screens for visibility. The worst case scenarios I've seen are Windows XP on CRT display (tends to draw images very dark, due to Windows lower gamma settings) and mac on older non-backlight LCD displays. Dave (talk) 16:19, 6 July 2010 (UTC)

I've run the battery of colorblindness and contrast tests from WP:COLOR on 3 pages: this one, M-231 and US 66 (NM). This page had elements that failed, not because of the infobox sample above... our project banner failed the contrast test on a few elements. Otherwise the currently in use orange and brown, and the proposed green pass according to the tests. Imzadi 1979 → 17:26, 6 July 2010 (UTC)

Discussion about specific colors

Ok, so it looks like the basic concept above has some general agreement, but needs details hashed out. If you want to know, the FHWA has a published list of the Pantone color numbers for the non-fluorescent colors used in highway signs. Green is Pantone 342, Brown is Pantone 469 and Orange is Pantone 152. To convert them into the hex values used for the formatting, I consult this website, which is like the rack of paint chips at the paint store, ordered by Pantone numbers with the hex conversions. Any suggestions? Imzadi 1979 → 21:57, 6 July 2010 (UTC)

Default	Historic	Under Construction	Blue	Purple	Red	Yellow
MUTCD	MUTCD	MUTCD	MUTCD	MUTCD	MUTCD	MUTCD
Green	Brown	Orange	Blue	Purple	Red	Yellow
Pantone 355	Pantone 464 2x	#FFCC66	UK, Pantone 300
Pantone 369		UK, Pantone 1375	Pantone 293
Pantone 375 2X

Here are a few more colors that I like compared against MUTCD green. —Fredddie™ 00:40, 7 July 2010 (UTC)

I like Pantone 355. It seems to best represent the color of a highway sign without the boldness of the MUTCD standard. Fortguy (talk) 01:02, 7 July 2010 (UTC)

For the sake of discussion, I added the rest of the MUTCD colors. —Fredddie™ 01:42, 7 July 2010 (UTC)

I added in the two UK colors that are different than the MUTCD colors. My current preferences are: Pantone 355, Pantone 464 2X, and either Pantone 1375 or "Orange". I've personally invited Floydian into this discussion because Canada is getting a similar colour scheme, which will include a shade of blue and a shade of green. For a little regional consistency, I'm suggesting that Canada use the same shade of green. In other words, if he can help us pick a green, can we help him pick a blue? If MUTCD Blue is Pantone 294, I'm actually thinking that or 293 for that color. Imzadi 1979 → 18:47, 7 July 2010 (UTC)

Of the two colours that will be used over here from that list (blue / green), I like the Green pantone 369 (though the 355 is closer to the correct colour and 369 is pretty bright) as well as the blue 293. - ʄɭoʏɗiaɲ ^τ _¢ 20:46, 7 July 2010 (UTC)

I like Pantone 355, Pantone 464 2x, Orange, Pantone 293, and the MUTCD Purple, Red, and Yellow. However, I don't know for what we would use those last three colors. —Fredddie™ 22:30, 7 July 2010 (UTC)

Of the three Pantone values for green, only Pantone 355 even marginally has enough contrast with white text to meet the W3C's Web Content Accessibility Guidelines. All three, however, pass with black text. An online color contrast analyzer can be found here. For the brown colors, the HTML/CSS Brown looks too much like MUTCD Red. The other two browns don't seem to have much difference between them. I'm fine with any of the orange colors, I prefer Blue Pantone 293, and the MUTCD values for purple, red, and yellow. Fortguy (talk) 00:45, 8 July 2010 (UTC)

I'll have to see how it fares against the contrast checker, but I added a 1px drop shadow where white text is used. It's subtle, but I think it pops a lot more than it does without the shadow. It also reminds me of demountable copy. —Fredddie™ 02:53, 8 July 2010 (UTC)

What about a grey for old historic routes that aren't signed as old historic routes? I can't think of a US equivalent, but any important route that preceded the highway system and didn't become a tourist route. - ʄɭoʏɗiaɲ ^τ _¢ 12:17, 8 July 2010 (UTC)

Sounds good to me. Were you thinking of a darker gray like      Grey, something lighter like      Silver, or even lighter like      Platinum? I ask because I find it really hard to read black text on Silver, so there are some accessibility concerns to address. —Fredddie™ 13:00, 8 July 2010 (UTC)

I don't see a need for another color. In the US, the brown=historic/scenic/park convention is well established. For those the old auto trails, many of which just faded into obscurity and didn't have modern tourist routes created for them, I say that the brown color works just as well, as I discussed below in the section on usages. Otherwise, you'd have some auto trails in brown (Lincoln Highway) and some in grey (Theodore Roosevelt International Highway, Saginaw Trail) which would muddy the waters. Imzadi 1979 → 16:15, 8 July 2010 (UTC)

So essentially brown will be for any historical route? Works for me. If we did go with a grey colour, the darker one is what I currently use, but I'm not picky on it. - ʄɭoʏɗiaɲ ^τ _¢ 17:35, 8 July 2010 (UTC)

I count three supports and an approving nod for Pantone 355. I also count four supports for Pantone 293. Any other comments?

I'd like to see the colors in an actual usage situation before I make a decision. It's one thing to pick a color out of a palette; it's another to find a color that doesn't graphically clash with articles. – TMF 22:24, 10 July 2010 (UTC)

I put MUTCD Brown on the infobox at Farm to Market Road 390 for review. It is the only TX FM road with a scenic designation by the Legislature, and the only one with a shield with a brown background instead of black. Texas Recreational Roads would probably qualify and their signage also have brown backgrounds, but none have any individual articles about them yet. Fortguy (talk) 03:41, 11 July 2010 (UTC)

Samples

The following three pages show sample articles (lead and RD) with the selected colors and their MUTCD counterparts.

• User:Imzadi1979/SandboxGreen
• User:Imzadi1979/SandboxBlue
• User:Imzadi1979/SandboxOther shows the proposed brown and orange. The current brown and orange are in use in Farm to Market Road 390 or M-231 (Michigan highway)

Thoughts? I'd like to get this proposal put to bed soon. Imzadi 1979 → 20:45, 13 July 2010 (UTC)

I'll preface this by saying I'm not the biggest fan of any of the colors. In my opinion, they all have some kind of flaw, whether they're too eye-catching to be appropriate for an infobox or there's contrast issues between the header color and the header text.

• Green: Pantone 355 is the better of the two. As stated above, the MUTCD green is too bold to use in an infobox. Pantone 355 is still somewhat too eye-catching, but it's markedly better than the MUTCD green and could be a viable header color. I don't really like how the white header text clashes with the header color, though. The drop shadow definitely helps, but it doesn't resolve the issue entirely.
• Blue: Pantone 293 is better, but it's still a bit bold for my tastes. As far as I know, though, this color isn't going to be used in the US, so I'm really indifferent on it.
• Brown: At minimum, I would use Pantone 464 2X without the drop shadow. IMO the shadow looks weird when it's added to text already on a dark background. I would water the brown down even more, but only a subset of articles would use it, so I guess it's not a big deal either.
• Orange: I think the one already in use on M-231 is much better than the sandboxed sample. It's 1) much easier on the eyes and 2) has about the same intensity as the "preferred" proposed shades of green and blue.

I think a big mistake in this process was having a pastel blue as the default color. I can't speak for others, but for me, it's harder to make the jump from that to these colors than it would have been if the default was a bolder color. – TMF 21:45, 13 July 2010 (UTC)

The pastel blue would remain the default for Infobox road I believe. - ʄɭoʏɗiaɲ ^τ _¢ 22:20, 14 July 2010 (UTC)

Yes, but what I'm saying is that I've gotten used to that default - a pastel blue - and that for me it's jarring to switch to any color that isn't as unassuming and easy on the eyes. And all of the proposed colors are much more eye-catching than the pastel blue. – TMF 23:59, 14 July 2010 (UTC)

I'll restate my preference for Pantone 355 for green and Pantone 293 for blue. For brown, I prefer MUTCD because it matches the road shields in the infoboxes of Farm to Market Road 390 and U.S. Route 66 in New Mexico. The example U.S. 40 Alternate infobox has a black and white shield that doesn't demonstrate how the brown will compare with the MUTCD Brown shields many historic and scenic routes already have. The orange, and for that matter the blue are colors I don't anticipate ever having to use. Fortguy (talk) 22:15, 14 July 2010 (UTC)

My preference hasn't changed. Pantone 355 and 293. As for the brown, either MUTCD (which is Pantone 469) or the Pantone 464 2X. (Many of the brown signs in articles are not quite the correct MUTCD shades as is.) As for the Orange, I'm preferring the "orange" color, but can live with the current color. The rarity of the articles that will use it makes the exact choice for the Orange less of a deal than the others. Imzadi 1979 → 22:32, 14 July 2010 (UTC)

How about a proposal. We implement the proposed colors, and review the choices in 3 months. At that time we can revise the colors as necessary, and add any additional colors, like blue for Interstates and maybe the purple for toll roads. In essence, a live test for a few months to see how they look. Imzadi 1979 → 23:22, 16 July 2010 (UTC)

I could go with this; however, I'd like to leave open the possibility of re-evaluating them sooner if all of a sudden there's a massive backlash to the changes. I'm not saying like a week from now, but more like a month. But if the project's fine with how they look over the first month, waiting another two to take a hard look at them is fine with me. – TMF 03:09, 17 July 2010 (UTC)

Does this mean colors are go? —Fredddie™ 03:29, 20 July 2010 (UTC)

Colors installed, with the provision of reassessing them in three months time (or sooner if necessary) as discussed above. – TMF 17:40, 24 July 2010 (UTC)

What's the link to the colour subtemplate so I know what codes I need to use? - ʄɭoʏɗiaɲ ^τ _¢ 18:05, 24 July 2010 (UTC)

They'll be documented shortly, but the template is at {{Infobox road/meta/colors}}. – TMF 18:09, 24 July 2010 (UTC)

Any chance of switching |freeway=#0051ba;|#default=#009e49 to |freeway=#0051ba;|highway=#009e49|#default=#cedff2? Right now the green that's just for highways up here is showing as the default for all roads. - ʄɭoʏɗiaɲ ^τ _¢ 18:53, 24 July 2010 (UTC)

And by the way, my first impression is that it works well. The shock of the colour change lasts for all of 10 seconds. - ʄɭoʏɗiaɲ ^τ _¢ 19:14, 24 July 2010 (UTC)

If there's consensus to do that with CRWP, then it can be done. I just implemented what was discussed above, and since it looks like the US side of things is done, perhaps this discussion should shift to WT:CRWP. BTW, it's "header_type", not "type" for the header colors. Since "freeway" is only intended to change the color of the header and not meant to indicate a different numbering system (like Interstate Highways vs. U.S. Routes), it doesn't make sense to use {{{type}}} for it. – TMF 19:16, 24 July 2010 (UTC)

The agreed upon colours for Canada since the beginning have been the green for highways, blue for freeways, and either the previous default or a grey for county roads (with arterials either taking that colour or switching to infobox street). This was discussed above as well as being the swaying point for me at Wikipedia_talk:ONRD - County roads need to be differentiated from highways and freeways. The browse section uses "type", does it not? - ʄɭoʏɗiaɲ ^τ _¢ 20:25, 25 July 2010 (UTC)

My point is that this isn't a USRD issue; thus, it doesn't belong here. – TMF 20:58, 25 July 2010 (UTC)

Ummm... The colours have always been a joint issue, since the beginning; hence why half of USRD was so hellbent on converting IOR. There are no admins people at CRWP, and your group currently locks down this template. I'm not starting a pointless discussion at CRWP, nobody will respond, and I'll wait two weeks to make non-controversial changes. The exact same people will respond here as they would at talk:Inofbox_road if I add {{editprotected}}, so I don't see the difference in approaching the situation at this established venue over starting a new discussion at the template. - ʄɭoʏɗiaɲ ^τ _¢ 21:04, 25 July 2010 (UTC)

I have to agree with Floydian here. The whole reason he's commenting here at all is Imzadi asked him to do so. While the usages would be different, slightly, the colors used between USA and CAN were going to be the same. –Fredddie™ 21:40, 25 July 2010 (UTC)

I think having separate colors for freeways, highways, and everything else is dumb, but whatever. Change made to the color template. – TMF 02:01, 26 July 2010 (UTC)

Also, we're not "locking down" the template to supposedly protect the interests of USRD, as you're implying; they're protected per WP:HRT and the potential for mass vandalism. – TMF 02:02, 26 July 2010 (UTC)

I'm only replying here to follow up on what's been said above. Any further issues should be moved to another forum though. TMF just edited the color template. Now, if the header type is freeway, or the type code is set for a Quebec Autoroute, it goes freeway blue. If the road's type is set to one of the provincial highways, it goes green, otherwise the infobox defaults to the old blue from before. That should solve the above dilemmas once the job queue processes it all. Imzadi 1979 → 02:41, 26 July 2010 (UTC)

Discussion about specific standards for use

My proposal:

1. Orange (rare) for confirmed/contracted completely new highways. Extensions of opened roadways, or planned redesignations don't apply.
2. Brown: two part test, does the maintaining agency use brown signage or is it an auto trail. This should cover historic roads signed with brown shields, NPS/NFS roads with brown guide signs or shields and the auto trails.
3. Green: everything else.

Green and white guide signage dates to the formation of the Interstate system, and at the time of the auto trails, there was not yet a consistent signage standard. That's why I'm using the brown=historic convention for them. Imzadi 1979 → 21:57, 6 July 2010 (UTC)

As LJ noted above, we could possibly use purple for toll roads such as the Pennsylvania Turnpike, New Jersey Turnpike, or the New York State Thruway. But the problem with this idea is what colors should be used for roads such as Delaware Route 1, which is part toll road and part free road? Dough4872 00:00, 7 July 2010 (UTC)

Roads that are completely toll facilities could use purple headers, but roads that are only partly tolled would use standard green. -- LJ ↗ 00:08, 7 July 2010 (UTC)

I'm not in favor of purple myself, at this time. I haven't seen it in wide usage yet except in the EZPass/I-Pass logos. Of course, Michigan is a toll-free state save bridges, and the MBA uses blue signs to list the bridge fares for the Mackinac Bridge. Imzadi 1979 → 00:11, 7 July 2010 (UTC)

Would another color such as blue work for toll roads then? Dough4872 00:12, 7 July 2010 (UTC)

At this time, I don't think we need to separate toll roads, but that's my personal opinion. Imzadi 1979 → 00:16, 7 July 2010 (UTC)

I agree with Imzadi, here. There's no need for differentiation. —Fredddie™ 00:23, 7 July 2010 (UTC)

Under that proposal for orange, it would be exceedingly rare and very temporary. Most new highways are built in phases over many years with varying portions completed and open for traffic before the entire length is completed. Fortguy (talk) 22:28, 14 July 2010 (UTC)

Well, for it I was thinking of situations like M-231. It's announced, the bridge contracts for the Grand River crossing are being bid or let, but it will still be years before enough of the roadway is built to connect that bridge to something else to make it usable. Or situations like MD-200, the Intercounty Connector that is being build in one phase and opened at once. Until opening, it exists, but it's not drivable. Imzadi 1979 → 22:42, 16 July 2010 (UTC)

What do you think about making the headers blue for Interstates? I'm not proposing the ridiculous blue with red top that's in my sandbox, just a blue box. —Fredddie™ 22:35, 16 July 2010 (UTC)

I could go with that, but that opens up the issues of highways like US 131 (concurrent with the hidden I-296) or M-6 that are built to Interstate standards. I'm on the fence about this. I'd like to get the colors implemented before we tweak usages further. Imzadi 1979 → 22:42, 16 July 2010 (UTC)

I was thinking only articles about signed interstates. That way the Alaska and Puerto Rico "interstates" would be out, but the Hawaii interstates would be in. —Fredddie™ 23:00, 16 July 2010 (UTC)