Wikipedia talk:WikiProject Highways/Archive 3

Some long-term brainstorming

Nothing I'm about to suggest would be implemented tomorrow. We might not even get to all of it before the end of the calendar year. I'm tossing out a vision of some future changes to this project. I'd like to see the project break out taskforces by continent for those countries that aren't covered by a national-level highway project. (National-level projects that are devoted to all forms of transport wouldn't count. This is highway-specific stuff here.) So HWY would have a North American taskforce for all of North America except Canada and the US. There would be one for Europe with the exception of the UK. One for Asia except India. One each for South America, Africa and Oceana. As for Antarctica, there is a roads project there already, albeit a bit tongue in cheek.

Second step, I'd set up the banner for WP1.0 assessment with categories by country and continent. USRD is already broken down so that its banner feeds the state and territory categories as well as a national set of assessment categories. A future banner specific to CRWP, and INR plus the UKRD and USRD banners can be set to feed the continental and HWY categories. Then after the infrastructure is in place, we can set up HWY-level assessment criteria and do an assessment drive and audit.

The final step in this process would be the creation of a table similar to WP:USRD/A/S by country or continent. That table uses a metric called "WikiWork". To summarlize the metric, cumulative WikiWork (ω) is a measure of how many classes of improvement it would take to get to a theoretical goal of having every article in a project Featured. The relative WikiWork (Ω) is the average, or the ω/n where n is the number of articles. The Ω is a good measure of the average assessed quality of a group of articles. As of the moment, the Michigan State Highways Project has a Ω of 3.088, which means on average, the highway articles for the State of Michigan in the US are about a B-Class in assessment. USRD as a whole has a Ω of 5.034, so the national project is averaging about a Start-Class. We've used this metric in the past as a badge of friendly competition and a way to track progress. Our once monthly, now quarterly, newsletter highlights a "leaderboard" of the top ten states in the US in terms of their relative WikiWork score. I think as we cultivate some interest in an editor base, a little friendly competition could be a good incentive towards improving the average quality of highway and roads articles on Wikipedia. We're only as good as our worst article. No matter how many Featured Articles we have, if a reader only finds stubs, they'll be left with a poor impression of highway articles in general.

After we get the infrastructure and criteria to do assessment, the very last goal I'd have is to create an A-Class Review process for WP:HWY. The USRD ACR works pretty well to help identify and resolve concerns with articles that will likely be nominated at FAC at some point. Some articles that go through the process are never intended to be sent to FAC, but it still rewards work done to improve an article above and beyond the GA criteria. Now, we could either create a separate HWY ACR, or move the USRD ACR forum to HWY. That will be decided when the time comes that there are non-USRD HWY articles ready to be reviewed. In the past, we reviewed a CRWP/ONRD article at the USRD ACR. We could continue to do that until HWY or CRWP were ready to set up ACRs of their own.

Does anyone else have any long-term brainstorming ideas for the future of HWY? Imzadi 1979 → 21:20, 7 September 2010 (UTC)

I agree with you except for the divisions of task forces - I'm not sure about the specific divisions. There's some dispute over what exactly is Europe and what is Asia, for example, and we'll need to discuss that. Also, I think that INR and UKRD should be under the Europe and Asia task forces to deal with the E-road and AHN networks. We could merge Central America and the Caribbean into South America and give Greenland and St. Pierre/Miquelon to Europe, and then we wouldn't need a North American task force (though Central America doesn't connect with South America by road, the setup of the roads seems to be similar). --Rschen7754 00:20, 8 September 2010 (UTC)

I was thinking in generalities about the task force divisions. UKRD wouldn't need to be included in the European task force because while E-roads are designated there, it's my understanding that they aren't signed at all in the UK. In my mind though, the task forces were for any areas not covered by highway project. I'd set the project banners though to feed the assessment categories for country (if in a project), continent and the whole project. So in that sense, UKRD's articles would also populate the European task force's assessment categories, but otherwise UKRD and the European task force would be separate. Imzadi 1979 → 08:41, 14 September 2010 (UTC)

TfD

See here for a discussion over {{infobox Australian road}}. Imzadi 1979 → 21:49, 9 September 2010 (UTC)

Highways articles have been selected for the Wikipedia 0.8 release

Version 0.8 is a collection of Wikipedia articles selected by the Wikipedia 1.0 team for offline release on USB key, DVD and mobile phone. Articles were selected based on their assessed importance and quality, then article versions (revisionIDs) were chosen for trustworthiness (freedom from vandalism) using an adaptation of the WikiTrust algorithm.

We would like to ask you to review the Highways articles and revisionIDs we have chosen. Selected articles are marked with a diamond symbol (♦) to the right of each article, and this symbol links to the selected version of each article. If you believe we have included or excluded articles inappropriately, please contact us at Wikipedia talk:Version 0.8 with the details. You may wish to look at your WikiProject's articles with cleanup tags and try to improve any that need work; if you do, please give us the new revisionID at Wikipedia talk:Version 0.8. We would like to complete this consultation period by midnight UTC on Monday, October 11th.

We have greatly streamlined the process since the Version 0.7 release, so we aim to have the collection ready for distribution by the end of October, 2010. As a result, we are planning to distribute the collection much more widely, while continuing to work with groups such as One Laptop per Child and Wikipedia for Schools to extend the reach of Wikipedia worldwide. Please help us, with your WikiProject's feedback!

For the Wikipedia 1.0 editorial team, SelectionBot 23:07, 19 September 2010 (UTC)

Article importance assessment

I have noticed that as of September 27, 2010 that only 273 out of 4,892 WP:HWY articles have an importance classification assigned to them. Furthermore a quick review of those classified suggests lack of criteria for such an assessment - for instance there are motorway related articles assigned to high, mid and low class articles. Granted, some motorways are more important than others, but division here seems more along national lines (high - Russian, mid - Italian, low - lots of different ones, but a lot of Indian and Polish) and since there are only 4 categories available, I think there can hardly be such detail in categories to distinguish importance within a well defined set of topics.

To be proactive, I would like to propose a categorization guideline similar to the Wikipedia:WikiProject_Psychology/Assessment#Importance_scale that has been pointed out by someone a while ago, from which I shall now borrow heavily:

Categorization proposal
Top	Subject is a must-have for Category:Road transport and is considered a core topic. The article is a likely target for encyclopedic research. Experts in the field will generally be well-versed on the topic, and many non-experts will likely have some familiarity with it. Examples: core topics such as Traffic, Road, etc.
High	Subject contributes a depth of knowledge to the field. Most experts in the field will be familiar with the topic. The subject can be found in most academic studies of the field, and a significant amount of published research exists for it. Example: road networks such as Autostrade of Italy, German Autobahnen, etc. Articles assigned to this category would describe in detail those assigned to top class.
Mid	Subject fills in more minor details but is still important to the field. Many experts are knowledgeable of the topic. Published research from a variety of sources exists for the subject. Example: major roads such as European route E33, Bundesautobahn 8, A1 (Croatia), etc. (major roads, in this case, might stand for trunk roads, freeways, expressways and motorways) Articles assigned to this category would describe in detail those assigned to high class, as for instance Bundesautobahn 8 is a part of German Autobahnen.
Low	Subject is peripheral knowledge to the field and possibly trivial but still notable. There may be limited research on the topic, or most professionals in the field have not yet taken note of it. Example: by default, articles not included in the above categories, mostly comprising other (non-major roads), bridges, tunnels and other articles that are part of the project, such as Maslenica Bridge (A1). Articles assigned to this category would describe in detail those assigned to mid class, for instance Maslenica Bridge (A1) is a part of the A1 (Croatia).

This would give us a clear (or a clearer) set of rules and importance categorization might be carried out for thousands of articles in this project for which there is no such category assigned right now. Any thoughts?--Tomobe03 (talk) 16:09, 27 September 2010 (UTC)

WP:USRD/A is how the US handles this question. If we're doing importance criteria, it's probably wise to handle assessment criteria at this time too. --Rschen7754 16:19, 27 September 2010 (UTC)

That appears to be very similar in spirit to this. As noted in WP:USRD/A no rule here should be followed blindly - a short, feeder motorway may belong to a lower category - to name one example.--Tomobe03 (talk) 21:11, 27 September 2010 (UTC)

Since this is a generic global project, it would probably be a good idea to include some more ballpark parameters limiting inclusion of relatively short local roads in higher tiers, even if they are part of a longer route/system. For example, .hr A1 could be mid-importance, but I'd think twice before doing the same with A6. E33 doesn't sound mid-importance to me, E61 is borderline, but E80 is fine. --Joy [shallot] (talk) 21:56, 16 October 2010 (UTC)

That's possible, e.g. minimum length or traffic volume or both could be required to include in s specific category. E-roads appear to be a bit more straightforward affair: A-class (double digit) E-roads terminating in "5" are major North-South roads, and the ones terminating in "0" are major East-West roads. Including the zero and five ending E-roads in a category and demoting all other ones is clearly an objective rule, but it still confuses the matters - is, say Austrian A13 a major motorway since it does not connect to Vienna, and since it is merely 35 km long? The length and remoteness arguments favor demoting the road by one category, but perhaps it should be considered a major road since it is a part of E45 and forming a motorway link across Brenner Pass connecting Italy to Germany via Austria? European country size certainly limits lengths of motorways and clear objective rules are needed, otherwise the categorization shall be entirely arbitrary. Besides, speaking of motorways, is it really of any use to divide them into two importance categories? Granted some of them are more important than others, but what end is served by that division?--Tomobe03 (talk) 09:27, 3 November 2010 (UTC)

Can I make a suggestion? I appreciate the need to have some sort of guidelines and some sort of consistency. Moving forward on importance ratings might be slightly premature right now. I think we could be better off backtracking for a moment and setting up some sort of taskforces for the larger project. Most of this discussion is centered on European highways, and will come up with some sort of criteria on Europe, but that will leave the other continents out. This slight detour need not be long, just a discussion on yes, some regional groupings are good and some brief discussion on what groupings. I'd propose Europe, Latin America, Africa, Asia and Oceania. That way the European articles can follow a European set of criteria, just like the American articles follow the USRD set of criteria and the Canadian articles follow the CRWP criteria. (Editors from the other regional groupings can tackle the issue when they're ready for it.) Imzadi 1979 → 09:57, 3 November 2010 (UTC)

In that vein, maybe we need a subproject Wikipedia:WikiProject European highways? In that setting, assessment would be easier and clearer. And we could at least split a huge chunk off the 4,500 unsorted articles into more manageable parts. --Joy [shallot] (talk) 12:41, 3 November 2010 (UTC)

For the moment, I don't know that it needs to be a full project. I guess what I'm thinking about with my idea was adding some minor transformation to WP:HWY following a bit of the model of WP:USRD. Not all US states or territories have subprojects or taskforces, but the banner template is set up to tag each article by which state(s) it is in, and what type. Then you get categories like: Category:C-Class Michigan road transport articles which track which C-Class articles are for a specific state. We could do something similar using ISO 3661-1 alpha-3 codes (like {{infobox road}} uses) and the banner would filter the articles into categories based on continent, and even country if desired. Then people could work through a "Category: Unassessed European road transport articles" to assess the articles bit by bit. At least at the moment, we could then also have a WP:WikiProject Highways/Europe page set up to hold European-specific resources. That subsection talk page could be used to coordinate purely European activities and discussions. Later if activity warranted, the taskforce could be split off and a separate banner created if desired. Ditto the other continental/regional groupings.

As for a second classification, USRD tags articles with a type code, so that the national Interstate Highway System and United States Numbered Highway System components are also tracked. The analog here could be to have a type=E for E-routes in Europe, type=AHN for the Asian Highway Network, etc. How does that sound for a start? Imzadi 1979 → 13:02, 3 November 2010 (UTC)

I agree completely, that would be a meaningful and manageable subproject. Is there any way to tell what portion of the 5,000 WP:HWY articles could be included in such subproject? As far as quality assessment I think that WP:USRD/A criteria would be a good way to go.--Tomobe03 (talk) 13:07, 3 November 2010 (UTC)

The best estimate I can give you would be around 900 or so articles. I excluded the UKRD count, since those articles aren't currently tagged under HWY's banner. That would add 1300 articles to the total, if you assumed UKRD under the scope of the grouping. My preference is to make the regional taskforces whatever isn't directly under a highway project for a specific country in that region. (That would be CRWP. INR, UKRD, USRD). Imzadi 1979 → 13:23, 3 November 2010 (UTC)

Right, I quickly went through Roads by country and there appears to be about 1,400 articles on european roads and e-roads, excluding UK, where there is about 600 additional articles on UK roads, which would give a combined total of approximately 2,000 existing European road articles. Even if other "road-associated" articles are counted (viaducts, tunnels, named interchanges) I suspect that would still be under 3,000 articles.--Tomobe03 (talk) 13:47, 3 November 2010 (UTC)

Replying to both subthreads here - any technical method that allows us separate categories with the least manual effort is fine by me. --Joy [shallot] (talk) 13:50, 3 November 2010 (UTC)

Me too. As long as we get a meaningful way to address categorization within the WP:HWY in the process.--Tomobe03 (talk) 13:56, 3 November 2010 (UTC)

Since there seems to be some agreement here, let me solidify a proposal. It will take a little time to code up the changes to the template, but what I'll propose is this. We add in coding to the template so that we can add a country code to each article. (Yes, that would mean a process to insert the tags, but that could be semi-automated.) That way we should get "X-Class European road transport" categories and an Unassessed category. In the mean time, let's start WP:WikiProject Highways/Europe and WT:WikiProject Highways/Europe so that we can get the ball rolling there on what criteria to use for the importance ratings. I think the quality ratings will end up being a HWY-wide modification of what's used by USRD. (CRWP uses a variation of the USRD quality assessment criteria as well.) Once my template gurus awaken here in the States, I'll get to work on the banner. Imzadi 1979 → 14:10, 3 November 2010 (UTC)

Fine by me. Since the present WP:HWY banner features a picture of Brazilian Rodovia dos Imigrantes, a new image shall be needed. I'll be bold and propose this image for the purpose since it is of similar format (upright) taking up less banner space and IMO sufficiently interesting.--Tomobe03 (talk) 14:23, 3 November 2010 (UTC)

Ok, the taskforce is open for business! Now, about that image, since this is still a task force, it uses the parent banner template, which is global in scope yet. How about we find an image that's not specific to any country. Imzadi 1979 → 14:31, 3 November 2010 (UTC)

There's this one showing E-road network, but the borders are pre 1990, missing a dozen new countries. Maybe if the red borderlines were removed?--Tomobe03 (talk) 14:38, 3 November 2010 (UTC)

For the global nature of the template, I was almost thinking something along the lines of File:Autoroute icone.svg which is completely country-independent. I will state though that I don't like that graphic much. Remember this graphic is in the banner for a global project. The European Highways task force won't be getting its own banner template at this time. It will be sharing the global template, which will be modified to allow for task force tagging by country. If the Brazilian photo is too specific to one country, both of your proposed images are as well. Imzadi 1979 → 14:49, 3 November 2010 (UTC)

Oops... just realized "no banner" part. The Brazilian image is a great picture and I don't think anyone could reasonably object to it used for a global banner. I thought we were talking about a Europe-specific one. Sorry!--Tomobe03 (talk) 14:54, 3 November 2010 (UTC)

It's ok. Now, the task force page has been started, and the talk page for it is tagged. I have a friend coming into town to visit this afternoon. I'll drop a note with some other editors to get the ball rolling on setting up the banner parameters to tag the articles and start populating the necessary categories for the task force. Imzadi 1979 → 15:03, 3 November 2010 (UTC)

How are we defining Europe? Obviously not the UK, but what do we want to use as the eastern boundary? --Rschen7754 23:22, 3 November 2010 (UTC)

Highway Route Marker Bot

I have created a new bot that can create and upload a full sequence of highway markers. I have already used it to complete Alberta's highways markers and I am looking for new projects. If you provide me a completed SVG template and which signs you are requesting, I will run the bot. At this point this bot only runs on Commons, and will only create "free" images. --Svgalbertian (talk) 08:06, 10 October 2010 (UTC)

Following up on brainstorming

WP:CRWP has recently started the process to restore and update its banner template. We should get the ball rolling here on updating this project template. Soon CRWP and WP:USRD could be passing their article assessments into this project's categories so that this project can get a better view of the overall quality of highway articles on the English Wikipedia. To help with this process, and to further the ability of the new European task force, I'm going to suggest that in the short term, we implement task-force-style tagging for Asia, Africa, Latin America, the Caribbean and Oceania. The easiest solution in the short term would be to add parameters along the lines of |europe=yes |asia=yes |africa=yes |oceania=yes |latin-america=yes |caribbean=yes and use those parameters to populate categories for each continent for each assessment class. (FA, A, GA, B, C, Start, Stub, FL, List, Book, Category, Disambig, File, Portal, Project, Redirect, Template, Unassessed). There is one lone road in Antarctica which could stay outside of the task-force scheme. Whether or not actual task forces are created at this time, we can still implement the tags and update the displayed links as they are created. Imzadi 1979 → 23:20, 30 November 2010 (UTC)

Ok, just a followup on my comments, but I've started the banner template's sandbox. We can support 5 task forces easily. To add more than that (up to another 10) is more complicated in the coding, but possible. Shall the Caribbean and Latin America be a single Americas task force? The understanding is that of course like Europe, CRWP and USRD wouldn't be included in it. Imzadi 1979 → 23:48, 30 November 2010 (UTC)

Task forces

Ok, the banner is about to come online with the task forces. We will need to run through and add the appropriate tags for each task force group. The parameters will be as follows:

• |europe= for those countries that would be eligible for membership in the Council of Europe, or that have components of the International E-road network minus WP:UKRD.
• |asia= for those countries that have components of the Asian Highway Network, including India. (WP:INR does not have a separate banner. Once it does, they can be removed from the Asian task force.)
• |africa= for those countries that have components of the Trans-African Highway network and Madagascar. (Basically Africa)
• |oceania= for those countries in Oceania
• |latin-america= for those countries in Latin America, that is all of the Americas not covered by WP:USRD or WP:CRWP

There will be some grey areas. Please discuss them so we can decide. A country or even just a single set of highways can be tagged in two or more task forces.

I've set the graphics for each task force to a map image like for Latin America. Let me know if that works ok for now. Imzadi 1979 → 10:32, 3 December 2010 (UTC)

The template is sandboxed at Template:WikiProject Highways/sandbox and the tests samples are at Template:WikiProject Highways/testcases. Imzadi 1979 → 10:46, 3 December 2010 (UTC)

Those look good!--Tomobe03 (talk) 11:28, 3 December 2010 (UTC)

Looks good to me. Good job! --Admrboltz (talk) 14:22, 3 December 2010 (UTC)

Ok, task forces are live. I will set up the categories as needed here, but the parameters are in operation to tag the articles. Imzadi 1979 → 19:48, 3 December 2010 (UTC)

Tagged the first one, works fine - A7 (Croatia)!--Tomobe03 (talk) 20:02, 3 December 2010 (UTC)

The categories are all created. Just need to start tagging. Once the articles are tagged with their task force, we can move on to phases II and III (creating the leaderboard and assessing the unassessed articles.) BTW, the importance for the article now falls into its regional categories for importance. I'd worry more about getting the TF tags on the articles now so we are break them into groups for later assessment. Imzadi 1979 → 20:48, 3 December 2010 (UTC)

Article alerts bug

Resolved

 – Bug was resolved with 12/24 update to Article Alerts. --Admrboltz (talk) 20:38, 24 December 2010 (UTC)

See WP:AAlerts/BUGS#Pluses instead of underscores --Admrboltz (talk) 23:52, 23 December 2010 (UTC)

Article assessemt question

At Category:Highways articles by quality, 80% of the articles are unassessed. Would it be worth getting Xenobot Mk V or DodoBot to go through the list and do some auto-assessment? -- WOSlinker (talk) 00:00, 26 December 2010 (UTC)

Not a bad idea. I would support this. --Admrboltz (talk) 00:30, 26 December 2010 (UTC)

I'm not for this as other projects use different assessment scales. It is possible for us to assess 4,000 articles - just like we did with USRD several years ago. --Rschen7754 00:38, 26 December 2010 (UTC)

There is an option just to assess the stub articles and not to inherit from other projects assessments as well, which would probably reduce the 4000 down quite a bit. -- WOSlinker (talk) 01:00, 26 December 2010 (UTC)

I'm not worried about the assessments yet. The plan was to get the task force tagging done, and then use the regional groupings to break down the list into parts to tackle the assessments. We're probably about ready to make that transition though, so if we auto-tagged the stubs based on stub templates on the article page, that would be fine. Honestly, that would probably tag about 3,000 of the 4,000 articles. Imzadi 1979 → 01:57, 26 December 2010 (UTC)

I've added a tracking category for those articles not yet asssigned to a taskforce. -- WOSlinker (talk) 13:51, 26 December 2010 (UTC)

I would agree to tagging stubs, but yeah, probably should hand code the rest of the stuff... --Admrboltz (talk) 17:04, 26 December 2010 (UTC)

Floydian and I are purging the tracking category of articles that should be assigned to regional taskforces today. What's left should be stuff that's not region-specific. Imzadi 1979 → 17:14, 26 December 2010 (UTC)

The stubs have been assessed by a bot. That still leaves 1,930 unasssessed articles to look at. -- WOSlinker (talk) 08:45, 31 December 2010 (UTC)

Image in the template

So... we should look for a new icon/image to use in the template. Not that I have anything against the current image, but its 2.33 mb file... The current "icon" we have for HWY is... ugly to say the least. Anyone have good ideas for a global icon we can use? --Admrboltz (talk) 01:47, 5 January 2011 (UTC)

If I can be blunt, the icon sucks. The photo in the template has an associated article that's a poorly written stub. I'd love to redesign a "slicker" icon of some kind. I'll see what I can do in the coming days. Imzadi 1979 → 04:03, 5 January 2011 (UTC)

How about this? I'm working on expanding the size of the roadway so it's more visible at smaller sizes. Imzadi 1979 → 20:41, 6 January 2011 (UTC)

Er, I'm a bit biased in this discussion, having slapped together that userbox icon in order to replace an IMHO much worse one (see here and also here, amusingly enough) but I have to point out that your premise in the first issue is wrong - the image in the WP template is not that entire file, it's a once-upon-a-time autogenerated cropped copy at http://upload.wikimedia.org/wikipedia/commons/thumb/6/62/Vistadarodoviaimigrantes2.JPG/80px-Vistadarodoviaimigrantes2.JPG - which is just 3921 bytes. If you don't want that picture to link to the original large image, that can be accomplished trivially - just put |link= in that [[Image:]] tag. --Joy [shallot] (talk) 00:10, 7 January 2011 (UTC)

MOS:RJL question

See: Wikipedia talk:Manual of Style (road junction lists)#Dashes and or emphasis in RJL --Admrboltz (talk) 03:40, 5 January 2011 (UTC)

lots of lists up for deletion

See Category:Proposed deletion as of 6 January 2011, where many lists of highways have been prodded for deletion. 184.144.162.245 (talk) 05:14, 7 January 2011 (UTC)

Most of them also show up on WP:HWY/AA, the ArticleAlerts page for the project. Imzadi 1979 → 06:04, 7 January 2011 (UTC)

I tagged all the List of .. articles with the HWY banner apart from the Lists with letters in the road names as those seemed to be just US & Canada releated. -- WOSlinker (talk) 07:58, 7 January 2011 (UTC)

Rename the project (to WikiProject Roads)

I see that this project assessment template is included in all kind of roads articles, not only highways. This is upheld by the project's description: "This WikiProject aims primarily to standardize the format used in articles about highways, including freeways, expressways, throughways, and other major forms of road." This is confusing, as the project name implies it is limited to highways only, and editors may remove the assessment template from non-highways articles (I almost did that). I'd like to suggest this project is renamed to Wikipedia:WikiProject Roads, and its assessment template is renamed accordingly. --_{Piotr Konieczny aka Prokonsul Piotrus| talk} 18:54, 31 January 2011 (UTC)

This is definitely something to be submitted for further discussion; for example, WP:USRD does not cover all roads, despite the name. --Rschen7754 19:02, 31 January 2011 (UTC)

You're missing the simple fact that a WP Roads would also include various minor forms of roads, as well as streets. That means that the change would not be a normalization of title but a significant change of scope. --Joy [shallot] (talk) 19:37, 31 January 2011 (UTC)

Highway and road are synonymous terms. - ʄɭoʏɗiaɲ ^τ _¢ 21:35, 31 January 2011 (UTC)

As I explained above, no, they are not. The same can be seen at wikt:road#Noun vs. wikt:highway#Noun. --Joy [shallot] (talk) 21:47, 31 January 2011 (UTC)

I assure you, the terms are synonymous. The only difference is there is no "private highway", but there is "private road". Highways are always public. - ʄɭoʏɗiaɲ ^τ _¢ 03:57, 1 February 2011 (UTC)

Think of it this way. A highway is always a road, but a road is not always a highway. Try telling people who live on dirt or gravel roads that they live on a highway. –Fredddie™ 04:04, 1 February 2011 (UTC)

There is nothing wrong with the current project title. Dough4872 02:43, 1 February 2011 (UTC)

The name is accurate and should remain. If the scope statement is misleading, it should be changed. Streets, and other minor types of roads, are not in the scope of the project. Imzadi 1979 → 02:46, 1 February 2011 (UTC)

Perhaps the scope's language should be added to the talk page template: "highways" ==> "highways, including freeways, expressways, throughways, and other major forms of road."--Hjal (talk) 04:07, 1 February 2011 (UTC)

Provincial highway

The usage of Provincial highway is under discussion, see Talk:Provincial highway. 184.144.164.14 (talk) 07:58, 13 February 2011 (UTC)

Should the "List of highways numbered" pages have browsing?

Earlier today, a user added a crude browse box to the bottom of several of the "List of highways numbered" dab pages. I don't think there's any reason to have browsing between the pages since the pages are just targets for generic redirect links - hence why they're dab pages - and linking to and from each page adds extraneous entries to the "What links here" of each page. My question to those interested: should these pages have browsing interconnecting them? – TMF 05:27, 21 February 2011 (UTC)

Well, M6 has a navigation box that links to M5, M7, L6 and N6. *shrugs*. Imzadi 1979 → 05:32, 21 February 2011 (UTC)

The way I see it, the WhatLinkHere page is to help us as editors with our duties. This navigational aid would provide a benefit to readers. If its put near the top and made to look good, I see no reason not to have them. - ʄɭoʏɗiaɲ ^τ _¢ 05:37, 21 February 2011 (UTC)

I could care less either way. --Rschen7754 06:13, 21 February 2011 (UTC)

Another dab page point

While we're on the dab pages, that same editor added links to A# and M# roads in Britain to all of the dab pages (i.e. List of highways numbered 1), even when separate lists for A# roads (List of A1 roads) and M# roads (List of M1 roads) exist. It seems silly to me to list the roads on both the "generic" page and the A#/M# pages, and I think they should be removed from the generic pages. Alternatively, the A#/M# pages could be folded into the generic ones. – TMF 05:31, 21 February 2011 (UTC)

Since no one's commented, I'm going to remove them as I see them. – TMF 11:22, 4 March 2011 (UTC)

A-class review

Because of its rather new state and dark murky corner status, I figure it would be good to bring to light the nomination of Ontario Highway 401 at the Canada Roads A-Class Review page. Any reviews would be greatly appreciated - ʄɭoʏɗiaɲ ^τ _¢ 02:47, 8 March 2011 (UTC)

Citation templates now support more identifiers

Recent changes were made to citations templates (such as {{citation}}, {{cite journal}}, {{cite web}}...). In addition to what was previously supported (bibcode, doi, jstor, isbn, ...), templates now support arXiv, ASIN, JFM, LCCN, MR, OL, OSTI, RFC, SSRN and Zbl. Before, you needed to place |id={{arxiv|0123.4567}} (or worse |url=http://arxiv.org/abs/0123.4567), now you can simply use |arxiv=0123.4567, likewise for |id={{JSTOR|0123456789}} and |url=http://www.jstor.org/stable/0123456789 → |jstor=0123456789.

The full list of supported identifiers is given here (with dummy values):

• {{cite journal |author=John Smith |year=2000 |title=How to Put Things into Other Things |journal=Journal of Foobar |volume=1 |issue=2 |pages=3–4 |arxiv=0123456789 |asin=0123456789 |bibcode=0123456789 |doi=0123456789 |jfm=0123456789 |jstor=0123456789 |lccn=0123456789 |isbn=0123456789 |issn=0123456789 |mr=0123456789 |oclc=0123456789 |ol=0123456789 |osti=0123456789 |rfc=0123456789 |pmc=0123456789 |pmid=0123456789 |ssrn=0123456789 |zbl=0123456789 |id={{para|id|____}} }}

Obviously not all citations needs all parameters, but this streamlines the most popular ones and gives both better metadata and better appearances when printed. Headbomb {talk / contribs / physics / books} 02:55, 8 March 2011 (UTC)

New contest

User:Dough4872/GA by number, a contest encouraged to improve articles to GA quality. Dough4872 03:44, 10 March 2011 (UTC)

Nomination for deletion of Template:OmahaBlvd

Template:OmahaBlvd has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Plastikspork _―Œ^(talk) 00:52, 30 March 2011 (UTC)

An RfC that could affect the project

WT:No original research#Are maps secondary sources? Imzadi 1979 → 16:41, 4 June 2011 (UTC)

Austrian highway problem

I've just translated the article on the Hochkönig Road in Austria, but can't get the infobox to display properly. The problem is that, unlike Germany, there aren't many Austrian highway articles yet on English Wikipedia, so no-one's set up the infobox before. I've tried to use "Infobox road" as much as possible, rather than import all the German Wikipedia templates, but it's screwing up. There are likely to be many more of these articles eventually, so it would be good to get it working. Can anyone help? --Bermicourt (talk) 06:56, 13 June 2011 (UTC)

One thing I do notice is that on the English Wikipedia, we don't have the entire junction list in the infobox. It goes in a separate junction table. The junctions section in the infobox is only for listing the 5-8 most important junctions in the route. --Rschen7754 06:59, 13 June 2011 (UTC)

I don't think it matters too much provided the table is collapsible. Also converting the hundreds of road sections that are yet to be transferred from de.wiki would be a massive piece of work! --Bermicourt (talk) 18:33, 14 June 2011 (UTC)

It actually does, because WP:RJL is in the Manual of Style. Of course, this doesn't have to be done immediately upon conversion. --Rschen7754 18:37, 14 June 2011 (UTC)

I substituted the template the article was using to get the infobox road code it was generating (which is what should be done on all articles in the future once this is figured out) and I found tons of German-language parameter names coming through which I had to delete to follow what was going on.

• Are the marker graphics (i.e. File:Tabliczka B 164) on de.wp or Commons? If they're only on de.wp, get them moved to Commons so that they'll appear here.
• Whatever {{Infobox road/configuration}} is, it was screwing up the infobox. Once I pulled that configuration subtemplate, the name and shield stuff came through. Whatever it's trying to do, it wasn't doing anything.
• If a map isn't specified, don't use "none". IR will try to display File:none, resulting in a redlink.
• As for the collapsible list, you'll need to look at {{Collapsible list}}. Note, that when we converted the German articles over, the collapsing list was working in them, but they are not now, so that template has been changed. Maybe ping WOSlinker (talk · contribs) for help there.
• I updated the browselinks for the bottom of the infobox so that it links to all the types of highways in Austria. Once lists are made, those links can be added as well. (This is standard practice in the infobox road usage around the world.)

I hope this helps. Imzadi 1979 → 19:18, 14 June 2011 (UTC)

Collapsible list was updated in March 2011 to use li tags rather than div tags which broke things. I've created an alternative version at {{Collapsible area}}. -- WOSlinker (talk) 19:42, 14 June 2011 (UTC)

Need help

Hi I need help in creating New article and Articles alerts for both roads WP:INR and railways projects WP:INRI --naveenpf (talk) 03:26, 23 June 2011 (UTC)

Wikipedia:WikiProject Indian roads/Article alerts with the shortcut WP:INR/AA has been created. Ask Tedder (talk · contribs) for help with the new article alerts. WP:Article alerts/Subscribing has the instructions for subscribing to Article Alerts, but it doesn't look like INRI can be subscribed because that project doesn't have separate assessment categories from WP:WikiProject India or WP:WikiProject Transport in India. New articles works off rules for article content, so it doesn't matter if the talk page of an article has a wikiproject banner at all. Imzadi 1979 → 04:23, 29 June 2011 (UTC)

TfD on template:Shc

The template {{Shc}} is up for discussion. Please join the discussion here. —EncMstr (talk) 22:44, 11 August 2011 (UTC)

Refactored from [1] to provide more neutral message per WP:CANVASS. --Rschen7754 02:10, 12 August 2011 (UTC)

I don't see how WP:CANVASS applies to my original text; was it non-neutral? I kind of agree that the bit about what Shc doesn't do is close to the line. —EncMstr (talk) 03:19, 12 August 2011 (UTC)

It was encouraging people to vote in a certain way, which is against WP:CANVASS. As an admin, you should know this. --Rschen7754 03:57, 12 August 2011 (UTC)

Proposal to geotag all highway articles

There is currently a proposal to modify WT:RJL to allow geotagging of highway articles in the junction lists, at specified important points along the route. Your input is welcome. --Rschen7754 02:25, 20 August 2011 (UTC)

Road marker templates

There are numerous templates in Category:Road marker templates, several of them duplicate each other. Looking through them, I see a number of issues:

1. Duplication. Several of them serve the same function. There are more than one that make links to European routes in white text on a green background.
2. Output. A number of them output a link to an article using colored backgrounds and stylized text. That's not good for a couple of reasons. First, in running prose, the text shouldn't be stylized to match a road sign. Second, in a junction list, it would be better to create a graphic of the sign and separate the styled text from the link to the article, like {{jct}}

In fact, my proposal is that we work on eliminating all of these various templates. {{jct}} can handle additional countries going forward just by building the proper subtemplates. Imzadi 1979 → 21:55, 24 August 2011 (UTC)

Hi Imzadi, it is better to use Highway_Route_Marker_Bot than road marker temple . Road marker is not working when creating book --naveenpf (talk) 05:12, 25 August 2011 (UTC)

Removing duplication sounds good in principle, but I'd like to understand the impact. The ones I recognise, BAB-E and BAB-E1, are part of the German autobahn template and already used a lot in the infobox route displays. I don't mind if they redirect to a common template and still produce the same effect, but eliminating them entirely will screw up a lot of articles. --Bermicourt (talk) 06:26, 25 August 2011 (UTC)

Temporarily, but would make them comply with the manual of style. Most of them are copied from the German wikipedia. - ʄɭoʏɗiaɲ ^τ _¢ 10:50, 25 August 2011 (UTC)

Navennpf, yes, but that's not quite what I was getting at. To create: M-6 I just add {{jct|state=MI|M|6}} to an article's infobox or junction list. The jct template already supports |country= and |province= in place of |state=, so it's just a matter adding the appropriate subtemplates to call the marker graphic, the full link and the abbreviation. If the marker graphics are going to appear, they'd need to be created though.

Now, M1 ({{jct|country=GBR|M|1}}) works. If we could, at the very least, code the European routes for each country in Europe, then {{jct|country=GBR|E|05}} could work to produce E05. If so, that would eliminate several redundant templates. In the short term, those templates could be modified to call {{jct}} as needed and then a bot could substitute them before deleting them. Imzadi 1979 → 20:36, 25 August 2011 (UTC)

{{jct|country=EUR|E|05}} works: E05 -- WOSlinker (talk) 21:49, 25 August 2011 (UTC)

With I-96 / M-37 ({{jct|state=MI|I|96|M|37}}) as a guide, E05 / M74 ({{jct|country=GBR|E|05|M|74}}) should work as well. It does now for the UK, but it should for all countries as things are set up going forward Imzadi 1979 → 21:56, 25 August 2011 (UTC)

Was already done for ESP & FRA but the link text is currently slightly different. (see Template:Jct/testcases/shield5) -- WOSlinker (talk) 22:19, 25 August 2011 (UTC)

It may make sense to shim or forward certain foreign highway related templates to the default template, but please keep them until the work of translating their highway articles is complete. That will greatly speed up the transfer of information and knowledge. In fact, if the original language information changes, there is some merit in retaining them, otherwise it will be incredibly difficult to keep information up to date! --Bermicourt (talk) 11:30, 6 September 2011 (UTC)

FAC for Croatian A1 motorway

Hi! I have recently updated and 'polished' the A1 (Croatia) article and now it is a FAC, so I thought to note that here and invite comments. Thanks!--Tomobe03 (talk) 17:28, 3 September 2011 (UTC)

A-class review

With the improvement of highway articles in several countries, it may be beneficial for an A-class review to be set up for HWY. Currently, USRD has WP:USRD/ACR and CRWP has WP:CRWP/ACR as a venue to review articles for A-class. This A-class review process serves as a useful venue to prepare a road article for FAC. However, HWY articles outside the US and Canada do not have this kind of luxury, and articles such as A1 (Croatia) have gone to FAC unprepared because it could not benefit from an A-class review. In setting up an A-class process, I would like to see what everyone's thoughts about how it should work as well as the possibility of merging in the USRD and CRWP ones to draw from a wider base of editors. Dough4872 02:46, 6 September 2011 (UTC)

I think our first priority is to get the A-class review set up for HWY - just copying USRD's ACR and going from there. We have an article that needs to go through there pretty quickly. We can worry about merging CRWP / USRD's ACR department in later. --Rschen7754 02:55, 6 September 2011 (UTC)

It will be great help if you can guide to create A-class articles for WP:INR and budding road wikiprojects--naveenpf (talk) 03:03, 6 September 2011 (UTC)

(edit conflict)Thinking long term, I think the best solution is to move USRD's ACR to here so all the subprojects can benefit from it. CRWP has an ACR as well, but I think only one article has tried to pass through it and it's still there. –Fredddie™ 03:05, 6 September 2011 (UTC)

I agree with Fredddie. If a HWY ACR is set up and the USRD ACR remains, then there will be a tendency for the USRD editors to continue to only pay attention to articles under USRD. Given how much action (or lack thereof) there has been at the USRD ACR lately, I do not think a transition period is needed. Once there is consensus to merge all of the ACRs into HWY ACR, put together a merger plan and execute it.  VC  11:22, 6 September 2011 (UTC)

I agree with Fredddie and VC on this. It's a simple matter of building the forum page and moving/transcluding the few existing review subpages there and pointing WP:USRD/ACR and WP:CRWP/ACR to redirect to WP:HWY/ACR. When time allows, the older review subpage archives can be moved. The last change would be to add the acr parameter to {{HWY}} and {{UKRD}} and change where it points in {{USRD}} and {{CRWP}}. (WP:INR does not have its own banner at this time.) Imzadi 1979 → 18:39, 6 September 2011 (UTC)

Ok, so WP:HWY/ACR has been set up. For the moment, the other two ACR pages still exist in their current form, but HWY/ACR has the review subpages transcluded. No archives have been moved around. We will need to update the banner templates yet to complete the transition in the short term. Imzadi 1979 → 19:04, 6 September 2011 (UTC)

Everything has been moved over. The only thing left is the edit request on {{USRD}} so that new ACR review subpages for USRD will be created in the correct location. I did not move previously archived ACR subpages because that could mean fixing all of their {{ArticleHistory}} templates. Imzadi 1979 → 20:18, 6 September 2011 (UTC)

Project talk page banner bug

The project's talk page banner {{WikiProject Highways}} is not correctly categorizing assessed importance by task force:

Latin America road transport articles by quality and importance
Quality	Importance
	Top	High	Mid	Low	NA	???	Total
B			1				1
C	2		15	2		3	22
Start	1	2	46	18		8	75
Stub	2	3	520	330		73	928
List	2	11	8	6			27
Future			1				1
Category					69		69
Disambig					2		2
Project					4		4
Redirect			2	1	30		33
Template					23		23
Assessed	7	16	593	357	128	84	1,185
Total	7	16	593	357	128	84	1,185
WikiWork factors (?)		ω = 6,034			Ω = 5.88

Fortguy (talk) 00:27, 20 November 2011 (UTC)

I think generally, task forces have their own importance field - don't think the Highways template does. Can someone confirm this? --Rschen7754 00:40, 20 November 2011 (UTC)

Yes, they have their own importance field. For Latin America, it's |latin-importance=. The template could be changed so that the taskforce would inherit the main projects importance setting if the task force specific importance has not been set. -- WOSlinker (talk) 01:12, 20 November 2011 (UTC)

Actually, only Latin America seemed to have its own importance parameter, which I have now removed so that all TFs use the main importance rating consistently (which has been the practice at WP:USRD and WP:CRWP, for instance. Imzadi 1979 → 06:12, 20 November 2011 (UTC)

 Done Thanks to all for fixing this. Fortguy (talk) 01:30, 23 November 2011 (UTC)

Not a problem. I've noticed your Latin America work over the last few days - good to see that we're getting started there. --Rschen7754 01:33, 23 November 2011 (UTC)

Ah, so we can get the assessment tables for each taskforce, but oddly enough only one was actually generated. I went through the bot manual and saw that it was supposed to run automatically. So, to prod it, I linked the table pages, and then ran it manually myself, which resulted in it generating the tables for the first time. We should check back in three days time to see if they're getting updated. --Joy [shallot] (talk) 11:37, 23 November 2011 (UTC)

Article Nominations and Promotions

Hey guys, we're looking for additional help with the nomination and promotion of our articles. The more reviewers we have, the more robust and rounded the articles will be. One such example is Wikipedia:WikiProject Highways/Assessment/A-Class Review/Ontario Highway 401, an A-class promotion of the Highway 401 article as I'm looking for additional help here. Keep checking the Wikipedia:WikiProject Highways/Assessment page for others or feel free to nominate articles you've worked on that you think are ready to take the next step. Thanks and all the best! Haljackey (talk) 18:11, 24 November 2011 (UTC)

documentation broken

FYI, your documentation is broken with this edit [2] -- the change to using {{tlx}} removes the visibility of the switches that are activated. 76.65.128.198 (talk) 13:32, 11 December 2011 (UTC)

Navbox

I rebuilt the navbox along the lines of what WP:USRD has. It now links to all of our project task forces, the subprojects (that are primarily highways/roads based) and the various subpages. Since we have it, I reorganized the project page to spin off items to subpages that are linked from the navbox. I also condensed related sections together to simplify the organization of the main page. In the end, we have six main sections to the project page instead of 20. This should make it easier to find stuff for the project now. Imzadi 1979 → 02:48, 19 December 2011 (UTC)

Idea

FYI, I've proposed a solution to this whole Infobox Roads/ Infobox Australian roads debacle. Feel free to add your thoughts at User talk:ClaretAsh/Roads. For the record, I've put this discussion in my userspace as it is a bit more neutral than if it were at either teh Australians talk page or here. ClaretAsh 00:56, 9 January 2012 (UTC)

User Box

Exactly what code do I add to my user page to put the user box on there? The page wasn't very clear. Allen (talk) 00:15, 22 January 2012 (UTC)

Just add {{Wikipedia:WikiProject Highways/Userbox}}. Imzadi 1979 → 00:35, 22 January 2012 (UTC)

citing Google Maps for routes and route names

I want to remind everyone to be very careful about citing Google Maps for the names and locations of routes, as most countries' roads and features on Google Maps can be edited by everyone via the Google Map Maker tool, and thus may be susceptible to spam. Please tell all descendant WikiProjects about this, including the ones handling the Philippines, as we don't want to propagate bad data like calling the North Luzon Expressway Regional Highway 95 or something like that. --Geopgeop (talk) 19:52, 26 November 2011 (UTC)

While this is true, and Google can oft be susceptible to errors, all user submissions are checked by Google. This editorial oversight grants some reliability to it. That said, really, Google maps should only be used for its visual satellite data. Printed maps are far more accurate for route information. - ʄɭoʏɗiaɲ ^τ _¢ 21:52, 26 November 2011 (UTC)

Also, Google Maps seems to only be able to apply one name per route—last time I checked, all of Interstate 35 is labeled as "Stemmons Freeway", from Laredo to Duluth. That might be its name in Dallas, but it's not called that outside of that city! —Scott5114↗ [EXACT CHANGE ONLY] 01:32, 27 November 2011 (UTC)

Yeah, I use Google Maps (really this would include Yahoo! Maps as well as Bing Maps, etc., as well) in conjunction with a printed paper map or two. Any citations using {{google maps}} in articles I work on should be to the satellite (or hybrid) view only. Imzadi 1979 → 02:29, 27 November 2011 (UTC)

Pretty late of a comment, but Wikipedia is even more editable and susceptible to spam.

Multi Trixes! (Talk - Me on Wikia) 19:39, 25 January 2012 (UTC)

Which is why it isn't a reliable source: User submissions appear without editorial oversight. Also, Google Maps appears to have fixed its one name per route issue (I asked them to make Ontario Highway 403 the Chedoke Expressway only in the city of Hamilton). - ʄɭoʏɗiaɲ ^τ _¢ 21:57, 25 January 2012 (UTC)

Running with Proposal 11: Start & End coords in infoboxes are always welcome

In the enthusiasm to implement shape files, this proposal that has received wide support has fallen out of focus. Can we suggest a way to take this forward- would it be worth mocking up a suggestion on a user sandbox then bringing it back to the project talk page? Or is there a better way or will it just happen? --ClemRutter (talk) 12:51, 25 January 2012 (UTC)

I think the understanding is that if Proposal 9 is implemented then Proposal 11 would be unneccessary, given that the terminus coordinates would already be included in the shapefile/KML. I may be wrong judging people's thoughts on that one, though. With all that in mind, however, the best place to discuss implementation of Proposal 11 would probably be at Template talk:Infobox road since that is the infobox that is used on the vast majority of road articles. —Scott5114↗ [EXACT CHANGE ONLY] 13:01, 25 January 2012 (UTC)

Yes partially my point. Maybe they will be superceded but this is an improvement that we could get up before the end of the month, and will require no learning curve for editors doing the occasional edit, or those experienced in other fields, who just occasionally find themselves with an article that requires an Infobox road.--ClemRutter (talk) 15:18, 25 January 2012 (UTC)

It would make data extraction by third parties a lot more complicated if they had to start looking for KML files, too. A better solution would be to hide rather than remove the coordinates in articles that use shapefiles. --Dschwen 17:40, 25 January 2012 (UTC)

Dschen: Does that mean you are giving a steer to add the coord data to the Infobox- or saying that would make the shapefile task harder. I see them as separate tasks.--ClemRutter (talk) 18:15, 25 January 2012 (UTC)

Why waste time/resources on implementing something that will soon be removed when we are trying to implement a better solution? - ʄɭoʏɗiaɲ ^τ _¢ 18:24, 25 January 2012 (UTC)

There is no evidence that this fantastical shapefile solution will be available "soon"; much less that it will render redundant the current methods for displaying (and emitting machine readable-) coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 25 January 2012 (UTC)

All of us have limits to our time and abilities. I, with Dschen and your approval, can knock up infobox with coordinates by the end of the month, while you clever guys sort out a shapefile solution. I haven't the time or ability to work on shapefiles. Software development has always been an incremental process. Ubuntu uses a six month release cycle etc. The questions I posed still stand. Can we suggest a way to take this forward- would it be worth mocking up a suggestion on a user sandbox then bringing it back to the project talk page? Or is there a better way or will it just happen? --ClemRutter (talk) 20:05, 25 January 2012 (UTC)

Unless I'm mistaken, {{infobox road}} doesn't need any parameters added to it; if an editor wanted to add coordinates to the termini, they can add them to the input for the termini parameters. Imzadi 1979 → 20:18, 25 January 2012 (UTC)

While it's possible to do so, having separate parameters makes life easier for parsers and scrapers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:01, 25 January 2012 (UTC)

Coordinates should not be hidden, for reasons that have already been explained ad nauseum. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 25 January 2012 (UTC)

We're here to benefit readers; not machines, parsers, nor Google Map's wikipedia layer. It has been argued ad nauseum that the display of coordinates adds no benefit to the reader on highway articles. - ʄɭoʏɗiaɲ ^τ _¢ 21:11, 25 January 2012 (UTC)

Coordinates should be displayed for the benefit of human readers. We've been over this many times, and the supposed arguments against displaying coordinates do not hold water; nor find consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:26, 25 January 2012 (UTC)

Floydian, you've made it abundantly clear that you don't like co-ordinates. But others do, and others find them useful. You can always ignore them if they're there. But for someone who wants them when they're not there, then Wikipedia will have let them down. Bazonka (talk) 21:27, 25 January 2012 (UTC)

I started this sections so we could discuss ways of quickly implementing Proposal 11, so could we all just focus on that issue. The questions I posed still stand. Can we suggest a way to take this forward- would it be worth mocking up a suggestion on a user sandbox then bringing it back to the project talk page? Or is there a better way or will it just happen? --ClemRutter (talk) 22:54, 25 January 2012 (UTC)

Again, if you're just adding coordinates to termini in the infobox, no template changes are required from a technical perspective. Unlike {{infobox road junction}}, which is used for a single location, an infobox row just for coordinates is not required nor ideal for a linear object. Imzadi 1979 → 23:27, 25 January 2012 (UTC)

Thanks for your input. What you have said has been discussed several times before.A proposal was made which gave a very strong lead, editors used to working with for example 'Infobox settlement' look for somewhere specific to add coord fields, because that is what they are used to. A work around is possible sure but so is adding then the two fields to Infobox road. I am focusing on the issue of how to make it happen, just that. So the questions I am posing are: Can we suggest a way to take this forward- would it be worth mocking up a suggestion on a user sandbox then bringing it back to the project talk page? Or is there a better way of getting it implemented?--ClemRutter (talk) 00:42, 26 January 2012 (UTC)

And where would these displayed coordinates appear? I will oppose adding a separate line to display coordinates in the template. If they're appearing in the same line as the existing terminal junction, no separate parameters should be required. (We have 5 sets of termini parameters: the standard a/b plus a1/b1 through a4/b4 if using the four segments. All of the parameters have alternate names substituting "end" for "terminus" as well.) You're not adding two fields, but 20, and if these parameters add additional display lines, you'll garner opposition. Imzadi 1979 → 00:54, 26 January 2012 (UTC)

I am asking about procedure. When we have a procedure- then we have something to talk about and that is the time to express preferences most of which are probably not contraversial. You have expressed strong views and other prominent editors have expressed strong support in the discussion to Proposal 11, how do suggest we progress? It is the procedure I want to establish.--ClemRutter (talk) 01:14, 26 January 2012 (UTC)

Parsing KML

To separate this from the closing/ed RFC, above, I figured its best to hash out some ideas on whether we can do anything with kml files. As some may know, you can draw a path in Google Earth, right click it > Save Place As... and change the filetype to .kml - Voila, any path, on roads, offroad, rivers, tracks, flight paths, ad nauseum can be plotted with geographical coordinates. I made a short but detailed line for the confirmed extension of Highway 427 near Toronto, and this is the content:

kml code

<?xml version="1.0" encoding="UTF-8"?> <kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom"> <Document> <name>427 Extension.kml</name> <Style id="s_ylw-pushpin_hl1"> <IconStyle> <scale>1.3</scale> <Icon> <href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href> </Icon> <hotSpot x="20" y="2" xunits="pixels" yunits="pixels"/> </IconStyle> <LineStyle> <color>ffff55ff</color> <width>4</width> </LineStyle> </Style> <StyleMap id="m_ylw-pushpin1"> <Pair> <key>normal</key> <styleUrl>#s_ylw-pushpin1</styleUrl> </Pair> <Pair> <key>highlight</key> <styleUrl>#s_ylw-pushpin_hl1</styleUrl> </Pair> </StyleMap> <Style id="s_ylw-pushpin1"> <IconStyle> <scale>1.1</scale> <Icon> <href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href> </Icon> <hotSpot x="20" y="2" xunits="pixels" yunits="pixels"/> </IconStyle> <LineStyle> <color>ffff55ff</color> <width>4</width> </LineStyle> </Style> <Placemark> <name>427 Extension - Confirmed</name> <description>Confirmed 427 Extension to Major Mackenzie</description> <styleUrl>#m_ylw-pushpin1</styleUrl> <LineString> <tessellate>1</tessellate> <coordinates> -79.63373960418063,43.76878712368649,0 -79.63903097044471,43.79633371050091,0 -79.63953706566628,43.79813462605291,0 -79.64014339880654,43.79990192230872,0 -79.64105546367523,43.80158746205122,0 -79.64217024302441,43.80332261683535,0 -79.64400186455735,43.80499391970488,0 -79.64602914490877,43.80637475945654,0 -79.6475803133375,43.80750755947232,0 -79.64887313738049,43.80874147161496,0 -79.6499710856201,43.80996480300379,0 -79.6508287093325,43.81114225406859,0 -79.65163203756102,43.81241649371911,0 -79.65223685017578,43.81370235674524,0 -79.6532277614819,43.81636283490142,0 -79.65425432825268,43.81821638700773,0 -79.65536423972627,43.81966365767966,0 -79.65651937492518,43.8211104966409,0 -79.65788902057551,43.82245631485755,0 -79.65939061053443,43.82356669235759,0 -79.66054617443874,43.82434399790651,0 </coordinates> </LineString> </Placemark> </Document> </kml>

Now nobody (and I'm looking at you, Andy) can say that is not machine parsable. In fact, I believe we can parse it here using string functions and some regex to pull out pairs.

Now here's something different!

By having a kml at a location, ie Template:KmlRoute/country/state-prov/type/number.kml, we can load it into Google Maps using the URL http://maps.google.com/maps?q=http://en.wikipedia.org/wiki/Template:KmlRoute/country/state-prov/type/number.kml The bonus is that since kml are text-only, we do not need any special adaptation to utilize them! - ʄɭoʏɗiaɲ ^τ _¢ 16:42, 4 February 2012 (UTC)

Even more simply, we could possibly put the KML text at, say, Talk:name-of-article/KML, then have some sort of template that would create that url with &action=raw (which causes the software to return just the wikitext, nothing else). No uploading required! (The sticking point, which I have not tried, is whether the parameters in Wikipedia's URL would interfere with the parameters that Google Maps uses.) This could be a mechanism to pass the KML to a modified GeoHack as well. —Scott5114↗ [EXACT CHANGE ONLY] 17:14, 4 February 2012 (UTC)

Just pasted this code into User:Scott5114/futurehwy, and it works marvelously: [3] Google Maps interprets the Wikipedia URL correctly, and parses the KML with no problem. Great find, Floydian! —Scott5114↗ [EXACT CHANGE ONLY] 17:23, 4 February 2012 (UTC)

And another, more substantial test: Talk:Oklahoma State Highway 82/KML, and displayed on Google Maps: [4]. This took maybe five minutes to export from my Oklahoma Highways QGIS project. —Scott5114↗ [EXACT CHANGE ONLY] 17:40, 4 February 2012 (UTC)

It also appears that, at least in Google Maps, the map is loaded properly centred and zoomed. I'm going to try and see if other services support this. - ʄɭoʏɗiaɲ ^τ _¢ 19:44, 4 February 2012 (UTC)

Bing also supports, [5]. However, I'm not sure if the 200 coord limit applies here as well. OSM does not support KML (oh well, maybe if we do they'll adapt). I've emailed MapQuest regarding that service's ability to display them. The two largest mapping services work now. - ʄɭoʏɗiaɲ ^τ _¢ 20:24, 4 February 2012 (UTC)

Ok, I thought I understood he lecture about road concurrency. Why does the OK 82 test omit the section that is concurrent with OK 28? --Dschwen 00:58, 5 February 2012 (UTC)

Apparently when I created this map a few months ago I forgot to include that data as part of OK 82 (it was probably tagged as OK 28 only and I overlooked it because of the comparatively low resolution of the PNG map I created with this data). On closer inspection there is another concurrency missing, as well. This is basically a result of my own ineptness, not anything intentional. :P —Scott5114↗ [EXACT CHANGE ONLY] 01:28, 5 February 2012 (UTC)

This has now been corrected. —Scott5114↗ [EXACT CHANGE ONLY] 04:24, 5 February 2012 (UTC)

I have created {{AttachedKML}} and placed it in the Oklahoma State Highway 82 article as a proof-of-concept. Unfortunately, the Google Maps link is busted for now (I need some way to convert the URL to the percent-sign notation used above for Google to accept the URL), but everything else works. —Scott5114↗ [EXACT CHANGE ONLY] 04:55, 5 February 2012 (UTC)

Thanks to some IRC help from Rschen7754, the Google link now works and the template is fully functional. —Scott5114↗ [EXACT CHANGE ONLY] 05:20, 5 February 2012 (UTC)

Very interesting approach. Looks good. Just thought I'd throw some positive encouragement in there. DubhEire (talk) 21:54, 5 February 2012 (UTC)

That is excellent. I think we have a winner here. Mangoe (talk) 22:07, 5 February 2012 (UTC)

Yeah, I think it's good. I think there's some finer details that may need to be worked out, and more testing done before wide deployment, but it's promising. (For example, we're storing the files as a subpage of the talk page... is this what we want to do?) --Rschen7754 22:14, 5 February 2012 (UTC)

I am not sure; we might want to do a straw poll or some such to see what the community prefers. I don't really have strong feelings on the matter, personally. Obviously, this is what is easy to deploy now, and is a valuable proof of concept, which will be useful to illustrate to people what we're trying to do if we are going to ask for KML files in the file namespace. Another important point is that the links to Google Maps and Bing are also just a proof of concept. Ideally we could eventually get something much like Geohack going that would list all services that will take a KML and provide other useful tools. —Scott5114↗ [EXACT CHANGE ONLY] 02:16, 6 February 2012 (UTC)

I'm creating a test at Ontario Highway 401. At this point I have far exceeded 200 sets of coordinates, and the line still shows on Bing. - ʄɭoʏɗiaɲ ^τ _¢ 04:14, 6 February 2012 (UTC)

The AttachedKML template is now detected by the WikiMiniAtlas. Check it out on Oklahoma State Highway 82. A blue globe (and the word 'Map') appear in the top right corner of the article page. Zoom in a bit to see the KML data overlayed over the map. Tested in Firefox and Chrome. Still some performance issues on page load, but displaying takes no time. --Dschwen 06:28, 7 February 2012 (UTC)

P.S.: The KML structure as used in the Ontario 401 article is not yet supported. And it makes my Firefox freeze hard... Working on that. --Dschwen 06:48, 7 February 2012 (UTC)

P.P.S.: For now the new code is run only on the Oklahoma State Highway 82 page. Must go to sleep now! --Dschwen 06:50, 7 February 2012 (UTC)

Could it be because of the number of points? There's probably close to a thousand coordinate pairs. - ʄɭoʏɗiaɲ ^τ _¢ 14:57, 7 February 2012 (UTC)

A thousand coordinate pair is nothing that a modern Javascript engine should worry about. That should take a few hundred milliseconds at most. I'm not doing complicated stuff. My guess is that I either made bug that is triggered with your KML (coordinates tags inside the linestring tags, rather than raw data directly inside the linestring tags), or it is a bug in the built-in XML parser in firefox. --Dschwen 15:03, 7 February 2012 (UTC)

Its a good opportunity right off the bat to compare the output of qgis to Google Earth though, better now than later. - ʄɭoʏɗiaɲ ^τ _¢ 15:18, 7 February 2012 (UTC)

My mistake, the KML is identical. Must have overlooked the coordinates tag. Will investoigate the firefox issues further. --Dschwen 17:29, 7 February 2012 (UTC)

Ok, should work now on the Ontario Highway 401 article as well. For technical reasons there still is a red dot on the map, which is taken to be at the arithmetic average of all lat and long components respectively. This is not the ideal solution. I may rather pick a point on the line data, close to the geometric center of the dataset. Does this work for other people? I haven't had a chance to test in IE yet. --Dschwen 20:52, 7 February 2012 (UTC)

P.S.: I will be using similar algorithms for the extraction of start- and endpoint coordinates (if there are no ambiguities) in the future, if the use of coord should be prohibited on highway articles (although I don't see that coming just yet). --Dschwen 20:54, 7 February 2012 (UTC)

Closure of RfC: clarification

For clarity, though the RfC closed with consensus "to use shapefile software to illustrate the the area of highway mentioned", there is no consensus for proposals to remove or prohibit the use of other coordinate display methods also. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:52, 6 February 2012 (UTC)

Well, you keep living in your own world Andy, but this is not for you to interpret, it's for the closing admin to interpret. In fact, they did:

Proposal 2: limited use of coordinates - This statement is not found to be a consensus of the community at this time.

Proposal 3: Start and end points of highway only - This statement is not found to be a consensus of the community at this time.

Proposal 5: Status Quo - This statement is not found to be a consensus of the community at this time. (bolded so you don't continue to play ignorant)

Proposal 6: Strengthen use of coordinates in MoS - This statement is not found to be a consensus of the community at this time.

Proposal 7: Minimalistic entry in existing junction table - This statement is not found to be a consensus of the community at this time.

Proposal 11: Start & End coords in infoboxes are always welcome - This statement is not found to be a consensus of the community at this time.

So no, you're wrong. - ʄɭoʏɗiaɲ ^τ _¢ 13:21, 6 February 2012 (UTC)

Pigsonthewing is right inasmuch as the decision that was made does not give users the right to remove existing information from articles until such time as shapefile data is added. Floydian is right inasmuch as the continued adding of co-ordinates to articles would go against the spirit of the decision. The question I am left with is, when is all the shapefile data going to be added? Dadge (talk) 12:31, 7 February 2012 (UTC)

(Since other geographical pages on Wikipedia will continue to use co-ordinates, I do disagree with the decision that was made. I have dabbled with shapefiles but I'm not up to speed on their potential in this field, so I'm willing to be won round.) Dadge (talk) 23:36, 7 February 2012 (UTC)

I'm rolling it out in Ontario now, but I believe there needs to be a little brainstorm on the finer details. I'm going to contact the trains, rivers, aviation and ships wikiprojects, as I believe they will stand to benefit from this over the current coordinate system. - ʄɭoʏɗiaɲ ^τ _¢ 14:54, 7 February 2012 (UTC)

In USRD, it depends on how much help we get from outside. It's instructive to look at how USRD generates regular maps to see how the addition of shapefile data will most likely be handled. We still have 7,069 articles that need regular maps. Articles usually get maps when A) someone who works on a particular state does all of the articles on that state in one large batch, or B) as an article rises up through the ranks towards FA: a lot of Bs have them, most GAs do, and a map will certainly be present by the time an article is brought to FAC. The result is that map coverage varies from state to state—in some states, all articles have a map, in others, coverage is patchy, in still others there's no maps at all. (Most of the time this is states like Wyoming, Montana, etc. where there are is a lack of editors with personal connections to the area, which tends to inhibit interest in those articles). Another reason I bring up maps is because they're linked to the KML—if you create a map in QGIS, then with one or two clicks, you can create the KML too at the same time. If we could get a band of a dozen or so editors together willing to learn QGIS and generate maps and KMLs, I bet we could get 100% completion by summertime. If not, well, it will probably take years; there's probably 8 or so core USRD members, and we usually put our focus on improving articles' prose most of the time. For anyone that wants to help, we have a tutorial for how to create maps—I can expand it in the next couple of days to cover KML generation as well. —Scott5114↗ [EXACT CHANGE ONLY] 15:02, 7 February 2012 (UTC)

Wouldn't it make sense to have a unified task among the various projects to work out a common format/protocol/tool/whatever for everyone? Mangoe (talk) 17:36, 7 February 2012 (UTC)

We do have such a project ;-) --Dschwen 17:53, 7 February 2012 (UTC)

I've invited four wikiprojects (rivers, ships, aviation and trains) to the discussion here, but eventually it should be worked into the geo project as this is something that has a lot of use across Wikipedia. - ʄɭoʏɗiaɲ ^τ _¢ 18:05, 7 February 2012 (UTC)

As far as USRD implementation, it will be slowly phased in. We'll wait until there's a standard, and then it will probably become something we start requiring at WP:HWY/ACR. The FAs and GAs will get the priority, then we can start adding to the rest of articles. --Rschen7754 19:26, 7 February 2012 (UTC)

Excuse me for having an opinion, but there are several unresolved issues here. The RfC has closed that is a fact. The results of their deliberation were contradictory and Andy is totally right is saying clarification is needed. All I got out of the dogs breakfast was near total agreement that fields should be provided in the infobox for geotags at start,point endpoint and most significant point. But further debate did not happen, as all the key players were folowing the hare of shapefiles. Now we understand that this will go to consultation with the trains, rivers, aviation and ships wikiprojects. How narrow is that! Rochdale Canal is a typical article about a canal- a linear structure if ever there was. Look carefully at the Wikiprojects that it is in- tell me how those editors views will be represented. Or look at the Nico Ditch an FA in need odf a Infobox road. Via Domitia I have mentioned before. In the Deansgate article the coordinate|title geotag is not in the Infobox but lower in Further Reading section and on Android phones this does not display if it were in the infobox I could pick it up from the infobox and via Geohack to Google Maps. There are a lot of issues here but it does demonstrate that it is easier to parse from within a infobox. It is far from clear. To lighten up a little

Proposal 2: limited use of coordinates - This statement is not found to be a consensus of the community at this time. So that means-

Proposal 2: unlimited use of coordinates - This statement represents a consensus of the community at this time. Doh!

In the meantime, this may seem academic to some but it is holding back editors- and me. I am making a coffee- anyone fancy to join me? --ClemRutter (talk) 20:31, 7 February 2012 (UTC)

What point are you trying to make? I just see illogical reasoning and someone that didn't make it as far as proposal 6. Andy did not request clarification, he gave his opinion and presented it as fact.

What is narrow about contacting other projects that may see a use in having a line instead of one point? It's this "only {{coord}} can EVER represent any object on this planet" attitude that is holding back editors. An attitude that is shared by about three editors, one of whom will whine until the sun explodes. - ʄɭoʏɗiaɲ ^τ _¢ 21:25, 7 February 2012 (UTC)

No, Floydian, you are doing Clem injustice. He did not say that "only coord can EVER represent any object on this planet", and neither did he imply it or did anybody else on this page. As far as I understand Clem, and I might me injecting my own opinion, he thinks it is a better than nothing approach. And coord has an existing infrastructure behind it, has a very broad application across hundreds of thousands of articles and is a lowest common denominator. KML etc. is probably a great idea for linear features, but I don't see why we couldn't have coord, too. --Dschwen 21:33, 7 February 2012 (UTC)

Don't forget that using Coord - among its other benefits - enables KML to be generated; and for points of interest, such as junctions, bridges etc., not merely the line of a route. Proposal nine does not obsolete that function; nor did it claim to. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:33, 7 February 2012 (UTC)

I think Dadge's comments summarize the situation pretty well. I've asked DeltaQuad to come in and leave a few comments to clarify. --Rschen7754 21:37, 7 February 2012 (UTC)

My statement above was "there is no consensus for proposals to remove or prohibit the use of other coordinate display methods". Floydian and others may choose to pretend that's wrong; or that it's merely my opinion. I invite them to show which proposal to remove or prohibit the use of other coordinate display methods achieved consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:30, 7 February 2012 (UTC)

-oo-

It is incredibly difficult to hold a conversation, when an editor fails to read what you have said and fails to follow the links you have given them. It is incredibly difficult to hold a conversation when editors think that a contrary view is an attack. It is incredibly difficult to build an encyclopedia when you are spending so much time on the Wiki talk pages. So, without trying to offend I will revert to experience gained over 40 years in academic life and the classroom. If you feel hurt or slighted, you are personalising the issue and this not good. If you can think of an acronym starting with a WP: to describe the syndrone you are becoming over involved.

1:What point are you trying to make? None- I try very hard to not treat Wikipedia like a gladiatorial contesth, I respect one editors tenacity in producing a vast body of work on roads in Ontario, while still thinking they could be a whole lot better if the features could have had a geotag so I could locate even one end of these roads on a map, and preferably on a clickable map which in 4 stroke of the mouse button, links me to external reality. Ontario Highway 401 is brilliant writing but for missing the one element of a geography article that is essential-- but I will live with that if it means that the article gets written.

2:Illogical reasoning: That seems a little pointed - but are we perhaps mistaking Deductive reasoning with Inductive reasoning, or Inductive reasoning with Mathematical induction (This time don't follow those links). Or perhaps we missed the joke- the logic was perfect.

3:Andy did not request clarification: I didn't read it that way- I too nearly requested clarification 2 days ago. In certain branches of acedemia and indeed government simple statements are equivalent to requests, and it is considered to be more polite to do it that way as it is less threatening to an official. As such the official sees it as a request and of his own violition volunteers the information. The RfC has only served to obfuscate.

4:It's this "only {{coord}} can EVER rep...: The word I used was coord, and not {{coord}}. Personally I prefer to unwrap it into the lower level start_lat, start_long, end_lat, end_long, principal_lat, principal_long, principal_coord_caption. I do use the common abbreviation coord when I mean a WGS84 co-ordinate pair.

5:What is narrow about contacting other projects:It is narrow to contact three selected projects when there are many more. I gave links to the talk pages of three articles I have read, edited or added photos to. All need an infobox and all are linear features. Open each page and look at what projects they belong to. Rochdale Canal is a typical article about a canal. A linear feature- it is not in the narrow group of projects you want to contact. Look carefully at what project it is in. These are the projects you need to contact to prove uou are not being narrow, By induction you will see, that if you contact WikiProject Greater Manchester, WikiProject Yorkshire you need to contact each English County Group! WikiProject UK Waterways suggests that there will be an equivalent WikiProject French Waterways and so on. Open the link on Via Domitia and we have two more project groups to contact including WikiProject Classical Greece and Rome. You would notice that none of the three articles had a road, aviation or a river in their ownership tree. None of the editors working in these fields would thus have an opportunity to submit ideas. That is why the suggestion is narrow.

6:If I remember a few weeks back. A consultation was opened within this project. Someone helpfully brought it to my attention- (and others attention) and instead of being thanked for widening the consultation sample, he was vilified- WP:acronums were spat at him and...: this process does seem to be in danger of becoming recursive.

7:An attitude that is shared by about three editors, one of whom will whine until the sun explodes.: Lets have naming of names here- I have found about 140 dangerous individuals and listed them here. Move the the discussion to the Wikipedia:WikiProject Geographical coordinates page and perhaps we will have a wider range of input. Hyperbole makes great reading but is inappropriate in a dissertation or theses.

8:All this debate seems to taking place from the POV of a PC User- but I have just got a smart phone and Wikipedia is another animal on that- and the apps interlink. We need to stop just thinking in terms of a static XVGA screen and see Wikipedia as part of the infrastructure and plan ahead while implementing what is currently possible.

So, to sum up. Please follow the links in my post before posting a reply. Please address the arguments rather than formulating a withering reply. Please seek clarification on the meaning of the RfC. It is logically flawed. Please, in spite of the RfC work on improving the MoS advice. Please consider Smart phones: the technology of the generation one behind us. In the medium term sort out shape files. In the short term, add the fields I suggested above to the Infobox (even if you can't decide yet how to render them- they need to be there so they are available to parsed). And in the even shorter term- stop treating this as Student Union debating society balloon debate, and treat it as strategic planning. Most editors find this sort of thing off putting and tedious- senior editors have a duty to act responsibly. --ClemRutter (talk) 00:11, 8 February 2012 (UTC)

Shapefile needs to be replaced with KML, as that appears to be the more technically feasible way of doing things. I contacted the four projects not to sway discussion, but to brainstorm a way of working with a solution that clearly has consensus, above. I assumed these were good starter points, but since you know of other please feel free to draw more people in, but I'm not obligated to contact every project. Naturally, since the RfC occured here, the continued discussion has taken place here; I see no fault in that. The RfC is clearly closed, as has been pointed out. The time has come to move forward, not to continue with the now closed debate.

Yes, it is illogical reasoning to deduce that the "no consensus" on proposal 2 means the opposite does have consensus, especially when several other proposals to maintain coordinates or expand their use also did not gain traction.

I am moving forward with implementing KMLs; the route map it has provided on Highway 401 is far superior to anything coordinates alone could produce. There is no need to supplement that data with start and end coordinates when that data already includes start (the first) and end (the last) coordinates, and when Google and Bing and the WikiMiniAtlas all automatically centre the map. You can work with us or you can bicker among yourselves. I look forward to hearing from editors that have constructive criticism rather than those trying to continue the closed RfC. - ʄɭoʏɗiaɲ ^τ _¢ 01:28, 8 February 2012 (UTC)

Regarding point 6: I'd like to bring to your attention that WP:CANVASS is not just a suggestion; it's part of the rules here. Tagishsimon violated the rules and was appropriately warned by several administrators. If you have a problem with that, then I honestly don't know what to say... we are a consensus-driven community, but there are house rules and if an editor chooses not to follow them, there are usually consequences for that. --Rschen7754 05:53, 8 February 2012 (UTC)

Technically you are right- but the core problem is that a RfC that has global significance needs to be placed where people will see it. Having an interest in geotagging of settlements, canals, tracks I watch the Geographical coordinates where it should have been posted- I studiously avoid project pages that I don't need to view. Time spent there is time wasted- a bit like student union politics. Technically Tagishsimon needs to be threatened with the naughty step. But similarly RfC are totally disruptive, and a form of vandalism if placed in the wrong place- the sample size needs to be large, and should not be skewed to canvas one interest group. I resent the fact that this was not better placed- and further resent the fact that it is now being extended to a narrow group of projects. In point 5: I give a list of projects having a legitimate interest in consultation- it is huge. I resent the fact that a detailed knowledge of arcane Wikipedia procedures is being used to prevent useful work being done. Doing a controlled trial of a new facility is good, leading in the medium term to abandonment or adoption but it should be done with discussion where the greater community can be informed and kept on board.

Thanks, for taking time to reply, I am sure that everyone on this page has tremendous experience- but suspect that experience is hindering the resolution of this problem.--ClemRutter (talk) 15:29, 8 February 2012 (UTC)

If you look, I crossposted (neutrally) to relevant WikiProject talk pages, including the coordinates project's talk page: [6], and every project talk page linked off the coordinates project page, and also {{Centralized discussion}}. If people missed all those posts, there's not a whole lot I can do about it. As DeltaQuad posts below, the scope is related to highways only, so this page is the most appropriate place.

Many coordinate editors have complained that they have been "left out" of the discussion, which I have addressed above, and also are making the assertion that they are the most qualified ones to be making this decision. This statement implies disenfranchisement of those who work on highway articles, which completely ignores whatever expertise we have that the coordinates people would not; furthermore, this sentiment flies in the face of everything Wikipedia stands for. As a Wikipedia editor and administrator, this sentiment would be quite disturbing to me even if I had no connection with the highways projects. I urge those who have made this remarkable assertion to reconsider, and realize that we're all working on the same encyclopedia, and that compromises have to be made, and that now that we have had the RFC, we need to move on. --Rschen7754 19:16, 8 February 2012 (UTC)

• I have been asked to make comment on the closing of the RfC. As far as the scope of this RfC, other wikiprojects may be interested in this discussion and may have wanted to comment on this RfC (if this is not what's being said above, then my apologies), but the scope of this RfC is just limited to Highways. As for the comment about my closure of not being consensus, to assume the opposite as consensus, is not what the consensus was. If you read the proposal, it was to have a limit of 10 coordinates, and it proposed a format. So what's the opposite of ten? The inverse of ten? 1/10? I didn't know we could do that. Just because something is said not to be consensus does not mean that the opposite is, because the opposite is not always tangible in words. There was no consensus to put a limit, but if we apply some common sense, if someone posts a huge list of coordinates (i'm thinking in the 20 range, but then again i'm an outside view) then revert it and follow up. And yes there could very well be a flaw in the RfC, but I can't really do anything about it now. I hope I have addressed what needs to be addressed, as I do have to run now, let me know if I missed anything. -- DQ (ʞlɐʇ) 18:03, 8 February 2012 (UTC)

• The logical inverse to a limit would generally be no limit, which you state in saying "There was no consensus to put a limit'. YMMV, of course. If we're back to a discussion of arbitrary limits, then we have not progressed far: except that we do have a most excellent shapefile implementation on Highway 401, which, all discussion of {{coord}} aside, I hope we can all get behind. It doesn't provide for a great many of the use cases I'm concerned about, but it is a very very effective and welcome addition to our toolset - for which thanks. --Tagishsimon (talk) 19:42, 8 February 2012 (UTC)

• Ahh yes, thank you for correcting my math, I should know this ;) And sometimes it does take a misstep to decide where to go in the future, and that's always if there is a misstep, something I am hoping comes as a result of my RfC closures. But that's how we all learn, and how things on an encyclopedia are made better. -- DQ (ʞlɐʇ) 21:13, 8 February 2012 (UTC)