Wikipedia talk:WikiProject Highways

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		16	2		3	23
Start	1	2	50	18		8	79
Stub	2	3	523	330		73	931
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	601	357	128	84	1,193
Total	7	16	601	357	128	84	1,193
WikiWork factors (?)		ω = 6,076			Ω = 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)

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)

documentation broken

FYI, your documentation is broken with this edit [1] -- 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)

RFC on coordinates in highway articles

Note to closing admin: Please consider what effect excessive cross-posting may have had on this discussion. --RA (talk) 21:58, 17 January 2012 (UTC)

Comment: Whilst User:Tagishsimon's canvassing was unacceptably spammy, he/her was merely bringing this discussion to the attention of the Geographical coordinates expert community, who would clearly have valid opinions on this subject, and would not necessarily oppose it. The opinions of those canvassed in this way are no less valid than those of others. Bazonka (talk) 22:43, 17 January 2012 (UTC)

I strongly disagree: before Tagishsimon began there were 18 supports and 6 opposes for Proposal 1 (75%); as of now there are 19 supports and 21 opposes (47.5%). The 1 additional supporter was not canvassed to. Cross-posting to more than 100 users is going to affect the outcome; of course people from the coordinates project are going to oppose a ban on all coordinates from highway articles! --Rschen7754 08:54, 19 January 2012 (UTC)

There are two issues here. First, do the Geographic Coordinates community have something valid to contribute to this discussion? Answer: yes, of course they do because the RfC is clearly related to their area of interest. Second, was the discussion brought to their attention fairly? Answer: yes, on the project talk page, but at Christmas (when many Wikipedians have better things to do) and this notification was quickly hidden under other threads - easily missed. The subsequent canvassing was unacceptably spammy, but does this make the opinions of those who responded any less valid? No, the means by which someone found a relevant discussion should not affect their right to comment or the validity of their argument. Complaining about an increase in opposes from a relevant community seems like a case of WP:SOUR to me. Bazonka (talk) 10:21, 19 January 2012 (UTC)

It's a textbook case of votestacking - please read the appropriate section on WP:CANVASS. --Rschen7754 10:43, 19 January 2012 (UTC)

Sometimes, per Wikipedia's recent SOPA blockout, you need to put a rocket up people to get them to pay attention. Whinging that having been poked to pay attention, a great many of them find that proposal 1 sucks says far more about proposal 1 than it does about so-called canvassing. YMMV, of course. --Tagishsimon (talk) 10:49, 19 January 2012 (UTC)

So, Rschen, because of the action of one editor, you would like to disenfranchise the valid opinions of others who are completely blameless of any canvassing violations? Bazonka (talk) 14:52, 19 January 2012 (UTC)

None of the participants have that power; only the closing admin does. This is analogous to RFA, where anyone can make comments regarding validity of the oppose or if the user is eligible, but the crat has the ability to determine whether the "vote" is counted or not. Vote is in quotes because this isn't a pure vote anyway. We can make comments here as much as we want in small font; whether the closing admin regards them or not is up to them. --Rschen7754 18:10, 19 January 2012 (UTC)

I would disagree that this is an example of pure votestacking. Votestacking requires prior knowledge of the users opinion on a topic (Such as pointing deletionists to a random AFD discussion). In effect this means that you are arguing that the entire geolocations wikiproject would be known to oppose by default. For one i wouldn't necesarily oppose the removal of the coordinates, since the argument that two geographic points can't truely describe a small, nonlinear feature sounds reasonable (Though i prefer fixing that issue as described in proposal 9, rather then just deleting the data)

If i would mention an issue, it would be campaigning, since the message was rather sensationalist and biased. However, i see little harm in personally messaging the members of a wikiproject that a relevant discussion is taking place, since the impact of it seems rather high for the project. For me it wouldn't have mattered anyway, as i would have seen the discussion on WP:CENT a day after. Excirial ^{(Contact me,Contribs)} 15:54, 19 January 2012 (UTC)

Does it seem likely that if you signed up to join a group for putting coordinates in articles, that you would be willing to ban them from any class of article? And, by the above logic, would you be open to my posting a message on all the WT:HWY and subproject members' talk pages since they definitely have expertise on the matter as well? --Rschen7754 18:10, 19 January 2012 (UTC)

If we were adding coordinates to operational ships or other moving objects, would a complaint from wikiproject ships be sunk once it was brought to attention just because they state it would not make sense to do so? Of course not, since geotagging moving objects is a ridiculous thing to do, and the used time could better be spend elsewhere.

Unless i am mistaken a wikiproject's goal is to improve Wikipedia, which at times that means changes may be needed to actually improve things. In the same train of thought i would welcome calling more people with expertise to this discussion, as it could lead to new ideas on how we should deal with the issue. Only thing i would really like is that the aim of the discussion would be more about trying to improve the situation by tackling the underlying flaws of the system, rather then having an "Less remove all coords without even trying to think of alternatives" versus "One or two points on a map can accurately mark a road, so we are not going to change a damn thing!" vote-wreck of a discussion, were two sides are just digging in without ever trying to see common ground. As for myself i acknowledge that single coordinates are not that useful for describing roads, but if we could find a way to accurately represent irregularly shaped entities from within Wikipedia, we would not only solve this particular issue, but also work towards creating more informative content (on highways) and more useful geolocation on this and other types of content (Rivers, anything with an odd shape). And that, would be a win-win for both projects and the readers at large. Excirial ^{(Contact me,Contribs)} 18:56, 19 January 2012 (UTC)

Replying to you below, as we're getting off the topic of canvassing (finally!) --Rschen7754 19:11, 19 January 2012 (UTC)

Should coordinates be included in highway articles? If so, how should this be done, in terms of 1) what points of the road should be tagged or how certain roads are tagged and 2) the style that the coordinates should be presented in? 01:25, 26 December 2011 (UTC)

Proposals may be added by anyone, but should address the questions above. Please indicate Support, Oppose, or Neutral for each proposal that you wish; you may also indicate "first choice", "second choice", etc. Any relevant discussion is welcomed; any irrelevant discussion may be collapsed.

The actual wording of changes to WP:RJL or other guidelines / project standards will be determined at a later date; this will address the main principles.

This RFC will run for 30 days 31 days including the time the English Wikipedia is locked due to the SOPA initiative, at which time the RFC bot will remove the RFC template. At this point, a post will be made at AN(I) requesting closure by an uninvolved admin.

Please make sure that any crossposting to users, WikiProjects, and project noticeboards remains neutral and in compliance with WP:CANVASS. If you need help in doing this, there are some good instructions at WP:RFC, or you can use {{please see}}. Any violations of this will be noted to the closing administrator. --Rschen7754 01:25, 26 December 2011 (UTC)

Note: The RFC will be closed after 01:25, 26 January 2012. --Rschen7754 03:10, 17 January 2012 (UTC)

Proposal 1: No coordinates - Original research

I'll start straight out by saying that I believe that until our geotagging system is better equipped to tag convoluted linear features (something that may require a bit of coordination with Google), I fully oppose their usage what-so-ever on road articles. There are many reasons why that reasoning extends across roads in general.

1. The inherent failure of picking a single point to represent something as a whole.

   

   Scatter plot visualizes the issue

   1. The main issue at play here is that a linear feature is not necessarily a straight line that can be easily discerned from similar features; to create an analogy, think of a scatter plot line graph representing 20 values. All of these lines are the same colour, and a label is applied to one point. Is this graph readable, or is it even possible to trace the labelled line across the graph? Probably not. This is what you do when you label a road or a highway with a single point.
   2. Ring roads are a big problem... What point is the point to label?
   3. For other types of roads, how can we objectively chose one point to represent the whole?
2. The lack of a reliable source of coordinate data
   1. Even if picking a single point weren't subjective and we were to apply coordinates to several "significant" (subjective) points, or all points, there is not a single reliable source of data for these coordinates. Google maps/Navteq is notorious for inaccuracies, OpenStreetMaps is user generated (WP:OR), and no road maintaining authorities supply coordinate data (access to such information is expensive and generally limited to professional surveyors, not to mention nearly impossible to correlate with a certain feature).
3. Numbered highways can change roads
   1. This makes picking a single point to represent the whole impossible, as you could never follow it. Unfortunately, unless the article is very detailed, you probably would not know whether any particular numbered road has this issue. Therefore, all numbered roads may have this issue and cannot be represented by a single point without imparting possibly false impressions.
   2. Unless we can highlight the entirety of the subject route, it is subjective and original research to pick one point to be representative of the entire subject when it is in fact not representative. See also WP:CHERRY
4. Consistency
   1. If they all can't have them, none of them should have them. It is unprofessional looking otherwise.
5. Original research
   1. Most of the above issues are indications that applying coordinates to roads is inherently original research
   2. How can we pick one point on a line for the title coord, which by its very nature and placement indicates that it is representative of the subject as a whole, unless there is a source which states that the point chosen is representative of the entire line?
   3. How can we assign coordinates to other points along the line without a reliable source to tie the WGS 84 coordinates system to the physical location?
   4. How can we chose a start and end point for roads that are circles?

Just my 2 cents. - ʄɭoʏɗiaɲ ^τ _¢ 02:36, 26 December 2011 (UTC)

Discussion of Proposal 1

1. Support as proposer. - ʄɭoʏɗiaɲ ^τ _¢ 03:15, 26 December 2011 (UTC)
2. Support as second third choice. --Rschen7754 02:59, 26 December 2011 (UTC)
3. Support on the basis that there are no easy coordinates for roads as there are for towns or buildings. Roads start here and meander there. The OR argument is specious, no more "original research" than is looking up a population or date of construction. Carrite (talk) 04:46, 26 December 2011 (UTC)

   For a city or other "point" object, yes. But since we can't mark the whole road (or other linear object) with a coordinate, what points do we mark? We have to arbitrarily choose what points to mark. Floydian has taken one particular view/approach on this problem, and I have taken another. --Rschen7754 05:01, 26 December 2011 (UTC)

4. Support Armbrust ^{Talk to me about my edits}_review 06:34, 26 December 2011 (UTC)
5. Support: there are really too many issues with singling out a single point as "representative of the entire length of a roadway" to tag an article with a single point, which can't be a junction for reasons I discuss below. As for adding additional coordinates that would be collected together through {{GeoGroupTemplate}} to output links to external mapping services, there are other issues. None of the departments of transportation with which I've dealt for researching highways here in the Midwestern US give out coordinate data for their highways; they just don't define waypoints along the routes of their highways. They do log the mileposts of junctions and other features, which is what we use to create the junction lists in our articles. We then filter the log data to junctions important enough to appear on the state map, produced by the same department or independent cartographers. All of these activities are based on data in the reliable sources. The various online mapping services do not define individual waypoints along the length of a highway, although you can personally measure coordinates with them to add coordinates to the article. We don't, however, allow editors to drive the length of a roadway and log their odometer readings or similar methods to obtain mileage data.
   In the end, we'd be left with Wikipedians defining the waypoints along the length of a highway. They'd have to pick which points are significant enough to receive coordinates. (Points for which we have photos present in the article? Junctions with other Interstate/US/state highways shown on that state's map? Just the termini?) You could say that if you plot the coordinate location of a given point, you could verify the location given exists along the road, but you could also get out a surveyor's tape to verify the DOT's mileage log. Either way, that's OR.
   What this boils down to is simple: the reliable sources don't define sets of waypoints for highways, which is what some people have asked Wikipedians to do. A line, by definition, has an infinite number of points along it, limited only by the level of precision of the measurement apparatus. We can't single out data without a source identified for the limited data. The listing for a building on the National Register of Historic Places defines its single location, and government data defines the coordinate location of a town, but no reliable source defines the specific waypoints of these linear features. Imzadi 1979 → 08:27, 26 December 2011 (UTC)
6. Support per #1 and #3 (the question of which points to choose) - Let's take, for example, Highway 1 (Israel). This highway starts in Jericho, goes through Jerusalem (which route through Jerusalem? Depends on who you ask), and then becomes the "Jerusalem-Tel Aviv highway", which is the main part of it. The route from Jerusalem to Tel Aviv is basically west from Jerusalem to right near Latrun, the north until Ben Shemen Interchange, and then mostly west but also somewhat north. Choosing one point to represent that would be very misleading. עוד מישהו Od Mishehu 08:46, 26 December 2011 (UTC)
7. Support for all the reasons given above. It just isn't practical or especially useful to give coordinates for highways. Kaldari (talk) 09:38, 26 December 2011 (UTC)
8. Invalid per WP:LOCALCONSENSUS - current consensus (and around three quarters of a million instances) is that the use of coordinates on Wikipedia is not OR, and any decision to prohibit their use on that basis must apply to the whole of Wikipedia, not just a sub-set of articles looked after by one project. Furthermore, the use of a single set of coordinates for a linear feature describes a bounding circle for the purposes of displaying a map, or a marker in (for example) Google Maps' Wikipedia layer, or Wikipedia's own mobile app. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:16, 26 December 2011 (UTC)

   Where was this consensus obtained? Do you have a citation? Further, this is an RfC, not a project discussion; this RfC will determine the non-local consensus, you see. A bounding circle is far too general and does not help with anything, not to mention that this circle is invisible and browser windows are SQUARE! WP:SILENCE (which is consensus by lack of discussion or opposition) is the weakest form of consensus, and any other form (especially a RfC) overturns it. - ʄɭoʏɗiaɲ ^τ _¢ 13:44, 26 December 2011 (UTC)

   By definition, a circle fitted within such a rectangle describes the width of the smallest side of such a rectangle, if you don't understand how such things work, you should stop voicing opinions as to why they can't, in your opinion, work. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:14, 26 December 2011 (UTC)

   Right, that addresses a third of what I asked... the other two-thirds? Also, are we going to put that blurb in a footnote next to each set of coordinates? Euclidean geometry generally isn't covered in such depth until post-secondary math courses, which we can't expect our readers to have under their belt. Really, I'd never heard of this "bounding circle" concept for mapping services until this morning. - ʄɭoʏɗiaɲ ^τ _¢ 17:24, 26 December 2011 (UTC)

   So, despite your expressed opposition to the use of {{Coord}} in the articles under discussion, over many months, you haven't read (or understood) its clear and simple (no knowledge of Euclidean geometry is required) documentation, or asked about how it works? Please do so, in order to realise that that opposition is misfounded; and take any concerns which you may be left with to the template's talk page, rather then throwing the baby out with that bathwater Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:35, 26 December 2011 (UTC)

   I'm looking at things from the reader's standpoint here as well. How is it being explained to users what the map they are being shown means? If I have to read the template documentation to find out what it is, then the concept is way to detailed for our readers to make use of without any instructions. Also, the other two thirds. - ʄɭoʏɗiaɲ ^τ _¢ 17:50, 26 December 2011 (UTC)

   From the reader's standpoint, no such explanation is necessary; they can simply make use of the map link and other tools and features, which work well. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:05, 26 December 2011 (UTC)

   Sounds to me like "invalid because I oppose it." --Rschen7754 16:34, 26 December 2011 (UTC)

9. Support A road is not a single point on a map. /ƒETCHCOMMS/ 16:41, 26 December 2011 (UTC)

   Nobody says it is. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:14, 26 December 2011 (UTC)

   Using a single coordinate set in the title of an article, in the infobox of an article, and/or as the representative point for the wikipedia layer on Google Maps, implies that it is, or that the point supplied is the most important or representative point. - ʄɭoʏɗiaɲ ^τ _¢ 17:22, 26 December 2011 (UTC)

10. Oppose (as a whole): If including any coordinates on a roads article is described as original research, then the same could be argued for all coordinates on all articles. I support not having a single coordinate in the title but for roads that are not ring-roads then at least start and end coordinates could be included within the article somewhere. -- WOSlinker (talk) 17:44, 26 December 2011 (UTC)

    They are, unless those articles have a reliable source of coordinates, which is available for most non-linear features from some governing body. The same is not true of roads. - ʄɭoʏɗiaɲ ^τ _¢ 17:50, 26 December 2011 (UTC)

    I haven't seen many village/town/city articles with references for their coordinates. -- WOSlinker (talk) 17:59, 26 December 2011 (UTC)

    You need to look at US municipalities, which in 48 states (Minnesota and Michigan somehow got missed) have the Template:GR template in their geography sections. Nyttend (talk) 18:54, 26 December 2011 (UTC)

    Exactly. I would think that you would need references for tagging Los Angeles, for example, since it's such a large city. --Rschen7754 05:20, 29 December 2011 (UTC)

11. Support - Roads are linear objects and are therefore hard to pinpoint coordinates or a set of coordinates to. In addition, there is the major issue of which points should be selected to represent the coordinates of a road as there are an infinite amount that can be used. The subjectivity of selecting points can lead to endless edit wars. Dough4872 18:03, 26 December 2011 (UTC)
12. Concurring opinion in support When we know that a road exists in a certain spot, it's not original research to provide the coordinates of that location as the coordinates of the road. However, it's not representative: we'd need either start and end points or an indefinite number of points, and neither of those ideas can represent the roads in a useful manner. The reference down below to beltways, which have no terminus, is a good reason to oppose that idea, and the impossibility of finding a precise standard by which to judge the sufficiently significant number of intersections for all roads causes that idea to be unworkable. Nyttend (talk) 18:54, 26 December 2011 (UTC)

    It's not about "representing" the road, it's only about locating it. Giving locators for the endpoints does this adequately. Dadge (talk) 12:24, 5 January 2012 (UTC)

13. Oppose, at least as far as original research goes. It is ridiculous to say it's original research to look at a map and pick a point where a geographical feature is visible. Calliopejen1 (talk) 10:39, 27 December 2011 (UTC)

    No not for something that at a point only, but to pick a point as representative of a line? To pick one point as representative of a 1000 km highway? That is original research. - ʄɭoʏɗiaɲ ^τ _¢ 15:20, 27 December 2011 (UTC)

    Please see above for an explanation - addressed to you, Floydian - of how it is not; because such points describe a bounding circle. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:50, 27 December 2011 (UTC)

    I decided to use the Toronto article, since I know it has title coords. Please tell me where in the text "Coordinates: 43°42′59.72″N 79°20′26.47″W" that the bounding circle is described, explained, defined, or anything other than existing only in your imagination. - ʄɭoʏɗiaɲ ^τ _¢ 18:15, 27 December 2011 (UTC)

    I have already referred you to the documentation of {{Corod}}, and advised you to use its talk page if you have any questions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:29, 27 December 2011 (UTC)

    So let me get this straight: I have to refer to the template documentation to figure out what this thing is. Readers, however, you expect to just be handed a possibly mislabelled (by Google or other providers' inaccuracies) map and to find the road and make use of it?[2] See my graph above to the right. Labelling one point is not helpful in the title. - ʄɭoʏɗiaɲ ^τ _¢ 20:25, 27 December 2011 (UTC)

    Users are given a choice of maps, not handed one. Your fatuous picture is a red herring. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:38, 27 December 2011 (UTC)

    Ok, so they get handed a selection of possibly mislabelled maps from which they can chose... that doesn't change the issue at hand, which the picture serves to illustrate. Labelling a single point in the title of an article (which infers that point represents the whole subject), is pointless amongst a network of line. The maps we make for articles may as well not have the subject route highlighted a different colour than other roads, because users can figure it out...makes no sense at all. - ʄɭoʏɗiaɲ ^τ _¢ 20:48, 27 December 2011 (UTC)

14. Support, Unless the road follows a 100% shortest path line, anything else is a average between the start and end points. I know from attempting to put a route map together for Belt Line Road (Texas), each jurisdiction moves the road just slightly to make various stakeholders happy. If someone wants to find out more, the descriptive text should be plenty without cluttering up the page with extra wikitext that is really just meta info. Hasteur (talk) 18:06, 27 December 2011 (UTC)

    Which "anything else" would that be? What's wrong with metadata? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:29, 27 December 2011 (UTC)

15. Inconsistent argument - The proposal is for "no coordinates", but the argument centres around publishing coordinates for every point. I reject the "Original research" argument - plotting coordinates of a point is a mechanical process. Martinvl (talk) 21:18, 27 December 2011 (UTC)

    What do you mean... most of the argument is against coordinates in the title of an article. That idea is extended to the junction tables by some of the points, but the majority focuses on coordinates overall and in the title. Also, while I do at one point argue that without a source, we are going by Google Maps reliability, which has been less than proven, the case I am making is that choosing coordinates on a non-straight line as a single "representative point" of that non-straight line is original research. - ʄɭoʏɗiaɲ ^τ _¢ 21:27, 27 December 2011 (UTC)

    Your evidence that we are relying on Google Maps is..? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:35, 28 December 2011 (UTC)

    Can you provide ONE, SINGLE, non mapping service source of coordinates for roads? If you can provide but one, only then can you try to convince me that the coordinates are not obtained using an online mapping service (ie. "What's Here?") - ʄɭoʏɗiaɲ ^τ _¢ 17:26, 29 December 2011 (UTC)

    Is that your evidence that we are relying on Google Maps? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:54, 29 December 2011 (UTC)

    I'll assume your non-sequitar means you cannot provide any evidence of even you yourself not using an online mapping service provider (sure, maybe another one besides Google Maps, not that it makes a single iota of difference) to obtain the coordinates of something. - ʄɭoʏɗiaɲ ^τ _¢ 18:08, 29 December 2011 (UTC)

16. Support. I have come into this RFC with an open mind but the concerns that I have with coordinates haven't been appreciably addressed, instead being dismissed as "edge cases" (when there are hundreds of such situations). This leads me to believe that coordinates are unworkable for linear features, and I must oppose their inclusion. —Scott5114↗ [EXACT CHANGE ONLY] 22:55, 27 December 2011 (UTC)
17. Support. See Scott5114's handling of Oklahoma State Highway 9 below to see why bounding circles (or any type of coordinates) are not appropriate for many highway articles. (What would you do for Interstate 40?) The only really adequate solution to this issue (visualizing a non-linear path) is a shapefile, which would supersede the need for coordinates. Titoxd^{(?!? - cool stuff)} 19:29, 31 December 2011 (UTC)
18. 'Support Having coordinates for a quasi-linear road makes no sense to me. Using a single point to represent a 2 dimensional object don't work. Most of the (limited number) of implementations that I have seen don't even fall on the road. All 5 of the points for this proposal are why. Royalbroil 13:56, 2 January 2012 (UTC)
19. Support I disagree with the original research argument, but the other points, especially the one about representing a one-dimensional construct with a zero-dimensional construct, are spot on.  VC  01:25, 4 January 2012 (UTC)
20. Support. I disagree with the point about original research, and have reservations about other points. However, the meat of this argument is point #1, in that there is no definitive and clear-cut way to have a single point represent a linear feature that spans multiple miles. -- LJ ↗ 07:18, 4 January 2012 (UTC)
21. Support based on point 1. A multi-thousand mile highway (or railroad) cannot be accurately referenced by a single point. Especially when they aren't straight lines. oknazevad (talk) 03:37, 5 January 2012 (UTC)
22. Oppose I think I disagree with every part of this proposal. Wikipedia has a responsibility to give the locations of such items and I'm astounded that some people believe that it should avoid that responsibility just because it is difficult to do. Dadge (talk) 12:09, 5 January 2012 (UTC)

    It's not "difficult to do", it's literally impossible! No single coordinate can describe the location of a 1000 mile long road (or even 10 mile long one) because there is no single location. If one tries to use an over-broad resolution, then it's becomes meaningless as the supposedly limiting circle actually contains more stuff that's not the road than the road itself. Either way we don't factually describe anything of value. oknazevad (talk) 07:16, 7 January 2012 (UTC)

    The purpose is not to "describe", but simply to locate. Giving the location of any geographical feature requires compromise, and roads are no different. Giving locators for the endpoints of roads is helpful to users of the encyclopaedia, and therefore it should be done. Dadge (talk) 22:40, 9 January 2012 (UTC)

23. Support. Coordinates are, generally speaking, OR. Roads are not single points. --TorriTorri(^talk/_contribs) 09:01, 13 January 2012 (UTC)
24. Oppose radically on all points. OR includes giving coordinates???? If that is to be so much as taken seriously then ANY item that includes info is OR "WIA (Which Is Absurd) QED" (Or should be!) Looking up coordinates in an atlas or GE or FTM GPS, is like any other reference work, and just as verifiable. A point cannot satisfactorily represent a non-zero-D structure? Bang goes another cherished delusion<tsk!>. Sure it can't, but it can distinguish between say, Tripoli, Lebanon and Tripoli, Libya., or Main Street, Sydney and Main Street, Perth, or FTM Main Street Paarl. If you happen to be thinking of the Indian-Pacific railway, then big deal; think big: go ahead, break the data bank -- give TWO coordinates! That doesn't give you the whole road? <sheesh! I'll never crack this maths thing!> Then give as many as will enable the reader to know where to begin looking, just as you might give the coords of one or two corners of a map on the surface of the planet. Wherever one (or two, or ten) coords can help the user more than none, give the info; if some user somewhere (coordinates please!) is too unskilled to benefit by dealing with some info rather than none, that is no reason for depriving those who can manage an appropriate branch-and-bound... (All right! Who was that who muttered "Non-problem"? Stay after class and ... JonRichfield (talk) 15:17, 14 January 2012 (UTC)
25. Oppose. thumb|No, this is the road. Why would you want to lose the ability to do that? Worst proposal ever, completely and utterly antithetical to the aim of encyclopedia making. We are here to provide verifiable information about article subjects. The location of a road is one of the most fundamental attributes of the road. Coordinates are the best and to my mind the only way to provide information on a road's location. Coordinates are verifiable against the many maps which show the road and provide the coordinates. The OR argument is specious nonsense. OR would be me visiting the road and used a theodolite and wristwatch to try to calculate the coord from first principles. Looking up a coord on a map is the use of other people's published & verifiable research. No benefit whatsoever accrues in denying users the ability to look at roads on a map - the chief functionality provided by {{coord}}. Why would anyone wish to deny users an easy means of viewing the subject matter on a map? It makes no sense whatsoever. It's one thing not to like coords, quite another to seek to enforce your crepuscular views on the whole community, not least when there is abundant evidence that others value this sort of information. There are a number of good ways in which coords can be used. Consider M11_motorway#Junctions, for instance, or the infobox in A20 road (England), the points of interest table in A36 road. Floydian and his pals have largely managed to keep coords off US road articles, but the majority of UK roads have coords; have had them for years; have had them without complaint or debate. At what point did it become reasonable to seek to remove from wikipedia content which has been happily accepted by the community. Let's look at the proposer's arguments in full:
    • The inherent failure of picking a single point to represent something as a whole. So use multiple points. Or try to understand that the purpose of a single point is to enable the whole road to be displayed on a map: that's the approach taken on UK roads.
    • The lack of a reliable source of coordinate data ROTFLOL. I mean, really, because maps showing coords haven't been invented yet.
    • Numbered highways can change roads. Then use multiple points. Indeed, the fact that numbered highways can change roads seems to me to be an argument for the use of multiple coordinates so as to lend support to users wishing to track that highway across the range of roads.
    • Consistency. Easy. They can all have them. And aside from that, from where comes this puritan desire to insist that all articles comply with your lowest common denominator? That is not the way to make progress
    • Original research. ROTFLOL part 2. Identifying road features on a map and abstracting coords is unambiguously the use of someone else's research. I can see that a weak challenge can be made to the use of a mid-point, but is there really any original research involved in determining the position of the ends of a road, or the positions of junctions?

    Bottom line for me is that good faith in this matter involves understanding that wikipedia is a broad church, one in which contributors should seek to support the broadest set of interests in an article. This proposal entirely fails to do that and instead starts from a prejudice and posits a number of bogus ex post facto arguments in support of that prejudice. It is one thing not to value coordinates on a personal basis, another entirely to seek to deny them to the community. --Tagishsimon (talk) 10:01, 17 January 2012 (UTC)

    And what do your propose we do about the hoardes of blue DMS numbers, which are not necessary for highways (If you want the coordinate data to make a kml, that's one thing, but drivers don't use DMS. - ʄɭoʏɗiaɲ ^τ _¢ 17:10, 17 January 2012 (UTC)

    You refer in your edit summary to "blue numbers that are useless to readers". Please do not project your apparent lack of understanding on the rest of us. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:20, 17 January 2012 (UTC)

    Can you provide any proof that those numbers are used? Again, they're on the geohack page, and there is no need to clutter the article with them when they can be obtained, for those that actually want them, on the next page. Further, the placement of a string of blue numbers next to the functional globe icon is an accessibility violation - Who knew the globe did something? Can you name a single driving navigation GPS that even makes use of coordinates? Garmin, Tom Tom, and Magellan (the makers of GPS that sell in my corner of the globe) do not offer latitude/longitude mapping. They'll tell you your current coords, but you can't say "go to these coordinates". - ʄɭoʏɗiaɲ ^τ _¢ 13:48, 19 January 2012 (UTC)

    It is up to us as Wikipedians to provide information to the readers - it is not up to us to define how people use it. I think this discussion really boils down to two factions: those who like co-ordinates and those who don't. Readers who don't like co-ordinates can ignore them if they're there, whereas readers who do like co-ordinates are disappointed if they're not there. Bazonka (talk) 14:43, 19 January 2012 (UTC)

    Your proposal to use the word "Coords" (or similar) to link each instance of coordinates is an accessibility violation; since WCAG & Wikipedia guidelines & accessibility best practice say that link text should be meaningful in isolation; and uniquely distinguishable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:57, 19 January 2012 (UTC)

26. Strongly oppose: Coordinates (even a single arbitrary point) are beneficial to readers who are unfamiliar with the route location: from a point on a map, they can zoom in or out to see other parts of the route. In most cases, if more than one point is provided (such as start and end points, or key junctions), so much the better. Either way, it is preferable to having no way of linking readers to a relevant map. The precise choice of coordinates is not original research, just as the precise wording of an article is not original research: in both cases, editors are expected to use their personal judgement and skill to convey information through appropriate wikitext. There is no disadvantage in having at least one coordinate link in an article about any geographical feature that is much smaller than a continent; and, in a globally-read encyclopedia like enwiki, there is a real disadvantage in depriving unfamiliar readers with map links. The coordinates do not have to be a perfect representation of the feature to be useful, in the same way that the article text will never perfectly describe everything about any subject. — Richardguk (talk) 12:52, 17 January 2012 (UTC)
27. Oppose A net plus for the project, and per Tagishsimon. Spencer^T♦C 13:05, 17 January 2012 (UTC)

    This vote has been canvassed: [3] --Rschen7754 19:23, 17 January 2012 (UTC)

28. Oppose Don't remove valid & useful information. If there is a better alternative (e.g. representing a line segment by a line segment rather than its midpoint), then go ahead and improve the information, but don't delete what we've got because it's non-optimal. --99of9 (talk) 13:35, 17 January 2012 (UTC)
29. Oppose Just because there is disagreement over what coordinates to provide doesn't mean that there should not be any at all. — TransporterMan (TALK) 14:24, 17 January 2012 (UTC)

    This vote has been canvassed: [4] --Rschen7754 19:23, 17 January 2012 (UTC)

    Yes and no; I was unquestionably canvassed to give an opinion at Wikipedia_talk:WikiProject_Geographical_coordinates#Proposal_for_the_closure_of_this_project and that may or may not have been a pointy ruse to draw my opinion here (along with several other opposers of this proposal). If it was, it worked, but the opinion I expressed is my honest and independent opinion: I do not have an opinion about what the right way to do road coordinates may be, but eliminating them altogether is not the right answer. Even a single ordinarily coordinate helps a reader find the road on the map; whether they need more guidance than that can be resolved here. Regards, TransporterMan (TALK) 03:29, 18 January 2012 (UTC)

30. Strongly oppose: Totally and absolutely. Every road is firstly a series of points on a document submitted to a planning authority- when it passes through committee it becomes a published document, it is only then that the contract is given and the set of points guide the developer on where to lay the concrete. Repeating the contents of a published document is the opposite of Original Research. The proposers seem never to have sat on a planning committee, approved an application for road funding or attended a public enquiry, or even bought land or looked at a land terrier. From that starting point they raise five points, each of which doesn't bear scrutiny. In detail:

    1. Difficulty in knowing which single point to label, I concede there are different systems, the end closest to Paris, the end furthest from Paris, the highest point and the median are systems I have encountered. Most major roads have junction numbers and each are spot locations. I do prefer a two point system, but lay down the convention used in each country and the problem becomes trivial. Ringroads are not a problem, they always have junction numbers- so state you label Junction 1.

    2. Obtaining reliable source of data. This is all public domain- in certain cases you may need to travel to the Mairie/Council Offices to see the published data often it is on line. By all means do use Google maps to verify or as a short cut. Lack of effort on a editors part does not mean that the data is not available. If the planning authority in the country you document is not publishing adequate data you seem to have an issue of democratic deficit- that needs to be sorted at the ballot box.

    3. Numbered highways can change roads is just incoherent. If the proposer is saying that the road number may change in future? This has no affect on the situation today. Every article needs to be maintained, things do change and editors need to change the article to suit. This affects every article that makes claim to being the worlds longest tallest highest most expensive- roads are no exception- they have to be monitored and in some cases rewritten.

    4. The consistency- this is a lovely argument. In essence it says if I am too incompetent to write and article properly (yes, I am talking about myself here too) every other article should be stripped down to look like mine! Reduce all GAs to stubs!

    5 A little repetition here: No OR- just you haven't located the document. It is just a POV that the point should be representative- what we are providing is a location so a user can find the said road, I could not find a point that is representative of a large area such as France, or Brazil or Egypt but I can follow a set of rules to help me locate it. Then we are appealing for advice on where to find data- I am tempted to be facetious and say try asking on the talk page, or talk to your local librarian- but joining the Wikipedia:WikiProject Geographical coordinates group would be a good start. And then it's back to not realising that highways authorities already have systems in place for describing circular roads.

    From the proposers sign off- my two cents- I can only assume he has a limited regional perspective, and indeed there are few names on this page that I have seen contributing to Autobahn, Autostrada or Autoroute articles either. --ClemRutter (talk) 14:48, 17 January 2012 (UTC)

    This vote has been canvassed: [5] --Rschen7754 19:27, 17 January 2012 (UTC)

    This is very uninformed. All road types can or can not have junction numbers, including ring roads (only ring freeways would really have numbered junctions). Secondly, you assume that stationing system used to lay out roads (a system invented FOR long linear features, because, and I quote my professor "Coordinates are an unruly method of laying out an object that is far longer than it is wide.") is equivalent to a single (or two) coordinates. That is absolutely preposterous! Shapefiles (see proposal 9) are the only government supplied data that is available on a regular basis. To number 3, what I am saying is that Highway 33 can follow John Street for half it length, then at a traffic light it turns 90 degrees on to Charles Street and heads in a completely different direction. What single, or two, points represent this? Next, consistency is huge: We shouldn't have half of the articles on one topic providing a certain set of data while excluding it from the remainder, else it invites your "lazy" argument. It's easy to find technical plans for freeways built in the last 20 years, but stuff before the 1970s is not always available. What systems do engineers have in place for describing circular roads? It certainly isn't coordinates; it's stationing. To point 5, I'll repeat, how do you translate documents that DO NOT USE COORDINATES into coordinates without using either A) Google maps or a similar online map service known for errors, or B) a GPS device... which again is akin to me measuring the length of a bridge of the height of a building. I don't think where we edit highway articles matter at all, but maybe you could enlighten me as to why it makes a difference if I edit highways in Ontario or in Germany? - ʄɭoʏɗiaɲ ^τ _¢ 16:44, 17 January 2012 (UTC)

31. Oppose The best thing to do here is to fix the system, not to just erase everything. And I think ClemRutter stated everything I would want to say, much more eloquently than I would have as well. Silverseren^C 15:09, 17 January 2012 (UTC)

    What are you suggestions for fixing the system, and why should the broken system continue to be used if a better system could actually be informative? - ʄɭoʏɗiaɲ ^τ _¢ 16:44, 17 January 2012 (UTC)

32. Oppose. This is drivel. The location of a road is verifiable, just as the plot of a movie is verifiable -- from the object itself. And, yes, it is of encyclopedic value. Jheald (talk) 15:42, 17 January 2012 (UTC)

    So we can start just writing articles on towns, bridges, buildings, etc without any sources... we can just walk in there with a tape measure and start gathering information, and that will be our article source. /That/, is drivel. - ʄɭoʏɗiaɲ ^τ _¢ 16:44, 17 January 2012 (UTC)

33. Oppose. Yes it is drivel. The geotagging information is useful, it may not be someone's ideal of perfection, but that does not mean let's throw it out. Mdukas (talk) 16:05, 17 January 2012 (UTC)

    This doesn't actually address the issues raised by the proposal in any way. No information is better than misleading and inaccurate information. - ʄɭoʏɗiaɲ ^τ _¢ 16:44, 17 January 2012 (UTC)

    This vote has been canvassed: [6] --Rschen7754 19:23, 17 January 2012 (UTC)

34. Strong support. Per Floydian, per Proposal 9 (which is a far, far superior solution), and per the blatant CANVASS violations. –Fredddie™ 16:56, 17 January 2012 (UTC)
35. Oppose. I oppose Proposal 1 as I have read it so far. I appreciate the use of coordinates on article, though see the flaws of use of coordinates on large objects. I oppose a 'ban' as a ban is restrictive and potentially undoes a lot of contributions from myself and others. I do not have a 'solution' (for Floydian's expected comment), but I can oppose a proposed solution (the 'ban') that does not seem to work for me nor seems to me to be in a spirit of contribution to wikipedia. rkmlai (talk) 17:11, 17 January 2012 (UTC)
36. Strong oppose. Sure, what we currently do might not be perfect, but it's got to be better than nothing. Even one co-ordinate pair somewhere on the road will enable it to be located. Don't throw the baby out with the bath-water (and I think you might be wanting to throw out the bathtub too). As for this being Original Research, well that's just ridiculous. Working out where something is by looking at a Map of Google Earth etc. is really a form of translation - from cartographic into numerical/textual. Not OR. Certainly not. Bazonka (talk) 17:15, 17 January 2012 (UTC)

    This vote has been canvassed: [7] --Rschen7754 19:23, 17 January 2012 (UTC)

    Yes, I was canvassed by User:Tagishsimon, but I had already seen this discussion on WP:CD and was going to comment anyway. In any case, I don't think that a canvassing of the participants of Wikipedia:WikiProject Geographical coordinates is that inappropriate - it's clearly a relevant topic, and not necessarily biased. I agree that the canvassing was done spammily though. Bazonka (talk) 21:21, 17 January 2012 (UTC)

    It had more rhetoric than was necessary. --Rschen7754 21:28, 17 January 2012 (UTC)

    This isn't throwing out the baby with the bathwater. It's throwing out the bathwater and adding fresh water instead of leaving the baby immersed in filth. In other words, the system doesn't work in this context. Rather than just making do with it and continuing to waste resources expanding the system, there should be an active push to create a new system to deal with rivers, roads, canals and railways in an adequete and informative method, which may or may not involve DMS coordinates. - ʄɭoʏɗiaɲ ^τ _¢ 21:47, 17 January 2012 (UTC)

37. Oppose banning all coordinates, support banning "picking a single point to represent something as a whole". This vote has been canvassed by Rschen7754. Bulwersator (talk) 19:51, 17 January 2012 (UTC)

    Please read WP:CANVASS; it's clear that you haven't. --Rschen7754 19:54, 17 January 2012 (UTC)

38. Comment There's a perception at Wikipedia:WikiProject Geographical coordinates that you are prosposing the removal of co-ordinates from all wikipedia articles, including those unrelated to roads. I believe this discussion to be limited to road articles only - so please correct me if I'm wrong. Furthermore, while the current debate revolves around roads, routes, ways etc that can't be represented unambiguously by a single point, surely there'd be occasion in a road-related article where you may want to talk about a single feature on a road (or next to a road) where a point would describe that quite adequately? Socrates2008 (Talk) 22:13, 17 January 2012 (UTC)

    This is limited to road articles only. Tagishsimon was exaggerating. Furthermore, I support the addition of coordinates to articles such as East Los Angeles Interchange, where the article is about one particular interchange and where the above arguments don't apply. --Rschen7754 22:17, 17 January 2012 (UTC)

    Ditto what Rschen said. I also would support the use of coordinates in prose or in the exit table if the long degree-minute-second numbers were omitted in place of something less obtrusive. - ʄɭoʏɗiaɲ ^τ _¢ 23:07, 17 January 2012 (UTC)

39. Strongly oppose. Ridiculous proposal and why is called "original research"? — RHaworth (talk · contribs) 23:57, 17 January 2012 (UTC)

    This vote has been canvassed: [8] --Rschen7754 00:26, 18 January 2012 (UTC)

40. Oppose: Geographical coordinates are useful, and even if only one or two (endpoints, or a single point on a ringroad) are shown for a road it gives a user the chance to locate the road on a map. PamD 00:23, 18 January 2012 (UTC)
41. Oppose as an overreaction. While it's hard to express a long road by a single coordinate, so it might make sense to refrain from giving one coordinate as "the" coordinate of the road, there is value to giving coordinates of significant places on a road such as endpoints and major junctions. *Dan T.* (talk) 04:44, 18 January 2012 (UTC)
42. Oppose - just because we're not sure of the best way to do this doesn't mean we should never try. --SarekOfVulcan (talk) 15:40, 19 January 2012 (UTC)

    But if we continue to use the inaccurate system, we are not only misdirecting readers but also letting complacency take the day. Not allowing this method forces the community to invent a new method that does work. - ʄɭoʏɗiaɲ ^τ _¢ 21:55, 19 January 2012 (UTC)

Proposal 2: limited use of coordinates

At no time should there be more than 10 coordinates, marked in the junction list. These would be the most major junctions and features of the road. This provides the maximum benefit for the minimum amount of cost possible.

Coordinates should also be in a more inconspicuous method than using {{coord}}. There should not be a separate, full-size column for them. The numbers should not be visible, but the links should still work. --Rschen7754 02:58, 26 December 2011 (UTC)

Discussion of Proposal 2

1. Support as first choice. as proposer. --Rschen7754 02:58, 26 December 2011 (UTC)

   Neutral. This seems completely arbitrary. What constitutes a major junction or feature? Also, I don't like the assertion made in the opening and in this section that coordinates have to be placed in the route's junction list. –Fredddie™ 05:21, 26 December 2011 (UTC)

   "Major junction" would need to be discussed, of course. If there's more than 2-3 coordinates, the junction list would be a logical place; I suppose it could be placed in an infobox, if we really had to. And yes, it's arbitrary, but then so are a lot of other things (such as the 10 jct limit in the infobox). --Rschen7754 05:26, 26 December 2011 (UTC)

   I wasn't really active when the 10-junction infobox rule (for WP:USRD) was put into place, so I had no part in that discussion. I wouldn't be against reviewing it; but that's not why we're here. I was thinking if any article had pictures along the route, that would be the place to put {{coord}}. –Fredddie™ 05:43, 26 December 2011 (UTC)

2. Lean support in principle. I like the idea that not everything would be tagged with coordinates, but the details need to be more robust than listed above. –Fredddie™ 20:33, 28 December 2011 (UTC)
3. Oppose: doesn't account for title coordinate usage. The 10-jct limit in the infobox addresses the very real concern of keeping that portion of the infobox a summary of the full junction list in the body of the article without producing an infobox that is as long or longer than the article. This proposal limits the content on the basis of cost which doesn't address very real issues in obtaining the underlying data. Imzadi 1979 → 08:12, 26 December 2011 (UTC)

   This also limits the content on the basis of clutter: hundreds of coordinates result in almost unusable data. --Rschen7754 08:16, 26 December 2011 (UTC)

   The clutter can be solved, not by limiting the data, but rather by suppressing the display of the numbers. Done right, {{GeoGroupTemplate}} could still collect the various points, even if the numerical data isn't displayed to the reader in the table. The globe icon in {{coord}} could still popup the mini-atlas. The only thing lost would be links to the geohack page, unless the link were shortened somehow. Imzadi 1979 → 08:41, 26 December 2011 (UTC)

   Yes, but having hundreds of coordinates on a resulting map is unusable - for an example, look at the Highway Browser on Cmap. --Rschen7754 08:43, 26 December 2011 (UTC)

   Who is proposing to put hundreds of coordinates on our articles? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:07, 28 December 2011 (UTC)

   You're the one pushing for no limits whatsoever on the number of coordinates in an article. This would lead to every coordinate on articles like Interstate 5 in California being tagged. --Rschen7754 04:34, 29 December 2011 (UTC)

   So, no-one, then. And you misrepresent me; and make WP:CRYSTAL statements with no evidence. My position is, and always had been, that we already have means to deal with such extreme edge cases without needing to put hard numeric limits into the MoS. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:21, 29 December 2011 (UTC)

4. Sorry, have to Oppose. Some highways may have more than 10-15 "important" junctions, and choosing those is subjectively deeming them more significant than other interchanges. In some cases its easy to say "ok, the freeway to freeway junctions are more important than the junctions with local streets", but in others the line is not so clear cut. I don't think a number can just be chosen and applied to such a varying subject matter... There's too much editor opinion involved. - ʄɭoʏɗiaɲ ^τ _¢ 13:50, 26 December 2011 (UTC)
5. Comment: I don't think this should be a fixed limit of 10 as roads have quite a variation in length and some may need more than to cover things properly where as other may only need one or two. Better to have some sort of guideline rather than a fixed maximum. -- WOSlinker (talk) 17:51, 26 December 2011 (UTC)
6. Oppose - Too subjective in selecting points. This can lead to endless edit wars. Dough4872 18:18, 26 December 2011 (UTC)
7. Oppose -- I like this idea in theory; I'm just concerned about the practical implementation. The WP:USRD project already has a similar specification for 10 most major junctions in the infobox, and this has been problematic to determine what are the 10 most major junctions. I see this as being even more problematic. — Preceding unsigned comment added by Moabdave (talk • contribs) 03:19, 27 December 2011
8. Support - Everything in Wikipedia is subjective. If we place a limit of ten sets of coordinates, then the sensible editor will aim for five sets, giving leeway for more shoudl that particular road demand it. Martinvl (talk) 21:24, 27 December 2011 (UTC)
9. Oppose While roads are notable, points on that road, including intersections, are very rarely notable. Attaching coordinates to those points is too subjective and ascribes them improper importance. If a junction is notable, it will have its own article that can have coordinates; examples include major named interchanges.  VC  01:25, 4 January 2012 (UTC)
10. Weak Support. If it becomes desirable to have coordinates in the articles, it should not be every single junction but a representative sampling of them. Details would need to be fleshed out better. In this context, a finite number or coords may not be the optimal solution, but rather a selection of major junctions and other points which show changes in route direction and other aids to give the reader a more complete picture of where the route goes. -- LJ ↗ 07:18, 4 January 2012 (UTC)
11. Support in general I disagree with the idea of an artificial limit on the number of locators, but otherwise I agree that, as long as they are not added in an ugly or intrusive manner, anyone who wishes to take upon themselves the task of adding locators for the items in a route chart should be allowed to do so, and this would be a useful service for Wikipedia users. (The *main* locators given for the road should be the endpoints.) Dadge (talk) 12:18, 5 January 2012 (UTC)

    Note: I'm not advocating this as minimum policy for roads articles - since it would be way too much work - only that it be allowed. Locators for the endpoints is an adequate minimum policy. Dadge (talk) 12:26, 5 January 2012 (UTC)

12. Partial support. Giving a manageable number of coords where they would be useful dulce et decorum est. Dropping a hint to authors and users not to get carried away when putting the dots real-close-together might be helpful, but not many editors should struggle with the idea that you might want to add more coords for Route 66 than for Kerkstraat, Tweebuffelsfontein. So much as mentioning a fixed maximum such as ten is simply putting temptation in the Wikilawyers' way IMO. JonRichfield (talk) 15:38, 14 January 2012 (UTC)
13. Oppose:Arbitrary limit based purely on the fact hominids have ten fingers. Massively inadequate for a road such as the Via Domitia (presently a stub) that passed through two Roman provinces. In two thousand years there have been a few changes that need to be documented including rivers changing their course. Rules must fit all cases- this one doesn't.--ClemRutter (talk) 15:23, 17 January 2012 (UTC)
14. Oppose: unduly restrictive instruction creep. Jheald (talk) 15:44, 17 January 2012 (UTC)
15. Oppose: Whilst too many co-ordinates would be bad, limiting to 10 could be just as bad. So in effect, you would allow a 100m cul-de-sac to have coords every few steps, but the Pan-American Highway would have fewer coords than countries through which it passes. If this proposal were to limit the number of co-ordinates to length/x where x were a sensible number, then I would not be so opposed. A blanket 10 is just daft. Bazonka (talk) 17:21, 17 January 2012 (UTC)
16. Weak oppose: Better than the first proposal, but I don't like arbitrary limitations like this. There should be the number of coordinates that is reasonable for a given road. A 2000-mile highway might have more significant places than this limit. *Dan T.* (talk) 04:48, 18 January 2012 (UTC)

Proposal 3: Start and end points of highway only

The only coordinates (if any) on a highway article should be the two termini of the highway. Should the highway have multiple termini, because it is non-contiguous, or under-construction, or never completed along the planned path, then only the two extreme points of the highway should be listed. 76.65.128.132 (talk) 06:50, 26 December 2011 (UTC)

Discussion of Proposal 3

1. Support as second choice. --Rschen7754 07:13, 26 December 2011 (UTC)
2. Oppose: doesn't account for title coordinate usage. This proposal also fails to address roads without termini like M-185 (Michigan highway) or Interstate 275 (Ohio–Indiana–Kentucky). Some highways just don't have physical termini. Imzadi 1979 → 08:12, 26 December 2011 (UTC)

   That's why it says "if any". If there is no endpoint, there are no coordinates to add (of course, you might want to add the geographic center of the ringroad, but that's not too useful) 76.65.128.132 (talk) 21:22, 27 December 2011 (UTC)

3. Support: When mentioned within the main article text. Where a road has mulitple start/end points all should be mentioned. Orbital roads should not have start/end point coords mentioned as there is no start/end points. -- WOSlinker (talk) 12:49, 26 December 2011 (UTC)
4. Neutral - It is possible to use two coordinates with Google Maps to create a Get Directions route, where the other elements are predictable and not encoded into some Google serial number in the URL. If the geohack system could be expanded upon to make use of this, it is an avenue we could explore to create a route on mapping services, rather than a point. However, this proposal fails to address the major issue of title coordinates, and isn't something that the current system supports. In addition, segmented and ring roads that have more or less than two terminii present a formidable challenge to this idea. - ʄɭoʏɗiaɲ ^τ _¢ 16:42, 26 December 2011 (UTC)

   The issue with using a "Get Directions" feature is that it tends to favor certain types of road over others. In the case of Oklahoma State Highway 152, which mostly parallels Interstate 40, Google Maps is apt to give the routing between the two termini as getting on I-40 at the earliest available opportunity and only leaving I-40 when the terminus is near. —Scott5114↗ [EXACT CHANGE ONLY] 23:11, 27 December 2011 (UTC)

5. Oppose - Does not give complete picture of road, also have issue with beltways. Dough4872 18:18, 26 December 2011 (UTC)
6. Oppose, misleading for articles like Oklahoma State Highway 10. Given two coordinates one naturally would assume the road directly connects them, but in the case of OK-10, which is L-shaped, nothing could be further from the truth. —Scott5114↗ [EXACT CHANGE ONLY] 00:05, 27 December 2011 (UTC)

   What if there was a corollary for major 90-degree turns like OK-10 has? –Fredddie™ 04:13, 27 December 2011 (UTC)

   That might work for OK-10 in particular, but it would have to be some kind of "points of major curves" or something to handle stuff like Kansas Turnpike, which would need vertexes at Oklahoma, Wichita, Emporia, Topeka, and Kansas City. Even then determining where to place the vertexes would be difficult and pretty much OR. —Scott5114↗ [EXACT CHANGE ONLY] 12:58, 27 December 2011 (UTC)

7. Oppose - my example of Highway 1 (Israel) is a case which would make the coordinates proposed here useless. Even just the Juersulam-Tel Aviv Highway portion of it needs at least 4 points (near Jerusalem, near Latrun, Ben Shemen Interchange and Kibutz Galuyot Interchange in Tel Aviv. Add a couple points (at least) to represent the part east of Jerusalem - and you need at least 6 points, not just 2 (or even 3, if you go by Fredddie's suggestion and include Latrun). עוד מישהו Od Mishehu 10:26, 27 December 2011 (UTC)

   That article has a table listing interchanges; showing the start (0km) and end (94km) points. Regardless, it would indeed be better to include in that table additional coordinates for other key locations. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:38, 27 December 2011 (UTC)

8. Comment Just because it's possible to find a few examples where it defintately doesn't make sense to have a start & end coordinates doesn't make this a stupid idea. The vast majority of roads do have a single start and end point. -- WOSlinker (talk) 11:07, 27 December 2011 (UTC)

   You are absolutely right (although I can think of examples in Oklahoma with three and four endpoints!), but I think that there are a lot of situations (especially in mountainous terrain) where the road doesn't necessarily follow the straightest line from A to B, instead meandering around a bit. How many, I cannot say, I can only present the examples that I know of. Oklahoma State Highway 10, presented above, is a particularly egregious example of that, but there are plenty of lesser ones out there. Presented with two points, a reader will tend to logically infer that the road does indeed go from A to B, so it's a little misleading on our part to put the two end points out there and just call it good. —Scott5114↗ [EXACT CHANGE ONLY] 13:06, 27 December 2011 (UTC)

   There is the saying "as the crow flies" which usually indicates that roads do not go from A-to-B in a straight line. This seemed obvious to me, when I proposed this, but I can see where assuming the average reader might think that roads run ramrod straight might result in a problematic situation, but then again, what is "straight"? Following a great circle, or a straight line on whatever kind of projection the map is using? 76.65.128.132 (talk) 21:22, 27 December 2011 (UTC)

   I don't think that many people that are not too well versed in geography are aware of the concept of great circles. Most people would, given two coordinates, mentally draw a straight line "as the crow flies" in between them based on whatever projection the map uses and assume that the road generally follows that line, maybe deviating a little to avoid things like lakes and streams, but roughly following the line. It's simple, it makes sense, it doesn't take too much thought, and it's dead wrong. —Scott5114↗ [EXACT CHANGE ONLY] 22:52, 27 December 2011 (UTC)

9. Support - Second choice. The purpose of such coordinates is to help readers find the road in question on a map. In the case of beltways or ring roads, why not just quote the coordinate on Junction 1, kilometre zero etc? Martinvl (talk) 21:27, 27 December 2011 (UTC)
10. Oppose While termini are important and objective, two sets of coordinates would give undue weight to the termini when in fact intermediate parts of the route may be more important.  VC  01:25, 4 January 2012 (UTC)
11. Oppose. Termini are important, but should not be the only sets of coords provided as that would give undue weight to the termini. This proposal also does not adequately address discontinuous highway sections or beltway and loop routes. -- LJ ↗ 07:18, 4 January 2012 (UTC)

    I do think the proposal should be modified to allow for the locators of all endpoints to be given. I don't get this "undue weight to the termini" objection though. The locators are only there to locate, they are not there to assign importance. They are a tool to help the Wikipedia user to find the road. If you provide a non-endpoint as the location of the road, the question arises of why that point was chosen. It is at least obvious why the endpoints would be chosen. Dadge (talk) 11:53, 5 January 2012 (UTC)

    Maybe "undue weight" is not the right term. See Scott5114's explanation above about the straight-line inference. There are many routes that supplying only the endpoints of the route is not a good representation of where the route goes, especially in routes that span an entire state. There's also the problem of supplying the "endpoints" of a loop highway. -- LJ ↗ 06:34, 6 January 2012 (UTC)

    I say it again: providing locators for the endpoints of a road is only to help readers to find the road. It is not, nor is it intended to be, a "representation" of anything, least of all the route of the road. As far as ringroads are concerned, many highways authorities do define a certain point as the start/end of the ring. If not, a single point can be chosen, perhaps where there is a major junction. Dadge (talk) 22:49, 9 January 2012 (UTC)

12. Support in general It's a good idea to limit the number of locators supplied for any given geographical item. For example, the entry for a city only needs one locator and is only given one locator. One is too few for a road since it is impossible to choose one representative point, but two is enough. (Except in the case of non-continuous roads, where the locators of all the end points should be given.) Having said all that, if there is a chart for a road, canal or railway line, there is no reason why locators should not optionally be given for all the features shown on the chart that do not have their own articles, so long as they are discrete. The Tame Valley Canal article shows how it should NOT be done. Dadge (talk) 11:42, 5 January 2012 (UTC)
13. Partial support. Where the object referred to is such that wherever you hit it, you can see the rest, one coord should do. If not, two should be a good default; a minimum if you like. Let's daringly assume that anyone literate enough to use our material could guess that they refer to start-finish or similarly convenient locations. Where there are special considerations, such as on N-S trans-Himalayan Yak route 7, by all means consider permitting a third. Or fourth if you are feeling daring... JonRichfield (talk) 15:48, 14 January 2012 (UTC)
14. Support - In the case of ring roads (or near ring roads), the first coordinate should be the start of the road and the second the point (or junction) furthest from the nominal start. Alternatively the two points, rather than being the start and end points should be the two points (or junctions) on the road that are most removed from each other. Martinvl (talk) 12:50, 17 January 2012 (UTC)
15. Oppose. Someone here has a very limit vision of what a road article is about- maybe it is regional or just limited experience in writing content. Termini are important and all of them should be manadatory in the infobox, but they do not help the reader to understand the structure of a two thousand year road, where was the flood where was the outbreak of Black Death the point that was first MacAdamised, even on a modern structure where is the peage, where was that horrendous junction that was refigured after the coach tragedy. If an editor chooses to put this in their prose or a table to improve the articles quality this should not be deleted.--ClemRutter (talk) 15:35, 17 January 2012 (UTC)
16. Oppose. What exactly is supposed to be the problem with exporting more complete and more informative KML-interpretable information? Jheald (talk) 15:47, 17 January 2012 (UTC)
17. Weak conditional support: I could live with this, but it should not be limited to 2 end points where the road has more. Wikipedia should show oddities, not hide them. Bazonka (talk) 17:24, 17 January 2012 (UTC)

Proposal 4: Route Table

A table should be create, that can be set to hidden/collapsed at the start, that shows all points of interest along the route.

• At least start and end points are shown.
  • Possibly others such as highest and lowest points.
• Additional points of interest can be added, using simple template, as individual users feel are appropriate.
  • Some road will not need only a few points other a large number.
  • If enough points are added the route will be clear on calling {{GeoGroupTemplate}} map.
  • Suggest variant of {{PoI}} maybe with reduced text size for co-ordinates.
• Route table could be used for other features such as hiking routes, rivers, canals and rail-roads.
  • See route list and feature table at Tame Valley Canal, as possible starting point for ideas.
  • Example of how co-ordinates can show route (this is using categories on article rather than table) here. — Preceding unsigned comment added by Traveler100 (talk • contribs)

Discussion of Proposal 4

1. Oppose. No upper limit on the number of coordinates that can be tagged. Interstate 5 in California could wind up with every junction tagged. Also, (especially in California) editors tend to add way too many unnecessary details in the junction list (such as control cities) and tend to edit war over stupid crud like that. I can see coordinates becoming like that too. Not a fan of this. --Rschen7754 08:12, 26 December 2011 (UTC)

   I can see page clutter being an issue but if there is a junction/route list what exactly is the problem with having many coordinates on a page?--Traveler100 (talk) 09:04, 26 December 2011 (UTC)

   As it stands, the coord template outputs the degrees, minutes and seconds of latitude and longitude. Those blue numbers would be placed into those tables amongst the other data. TMI.

   The other issue is that for big exit lists, using that many templates can actually break the article, as there is an upper limit to how many templates can be on a particular page. - ʄɭoʏɗiaɲ ^τ _¢

   Any such inappropriate use can be addressed in article talk pages; as at present. We don't need to prohibit the use of coordinates to account for such reacto ad adbsurum edge-cases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:18, 26 December 2011 (UTC)

   Sure we do. If every article can't have them, because the coord system does not work well with convoluted linear features, then no road articles should have them. Fix the tool so that edge cases are no longer edge cases, and work just as well as every other case. This is the inherent failure of picking a single point, and basing our entire geolocationing/mapping service system on that illogical thought that everything on the planet can be pinpointed to one set of coordinates. - ʄɭoʏɗiaɲ ^τ _¢ 18:09, 27 December 2011 (UTC)

   None of the vague assertions in you post have any substance. And every physical feature on the planet can be displayed on a map which is centred on a single set of coordinates and of suitable dimensions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:17, 28 December 2011 (UTC)

   "None of the vague assertions in you post have any substance." - how so? --Rschen7754 04:39, 29 December 2011 (UTC)

2. Oppose: the proposal duplicates the "road junction lists" defined in MOS:RJL. "Points of interest", without a source to back that interest, is not a neutral point of view by interjecting Wikipedian opinion into the selection of entries in the table. Imzadi 1979 → 08:16, 26 December 2011 (UTC)

   Yes; we phased out "points of interest" sections years ago. --Rschen7754 08:19, 26 December 2011 (UTC)

   Yes, and at least in the US, we limit our junction/exit lists to the intersections shown on the official state maps, providing a basis in reliable sources for the limit on the information listed in the table. Imzadi 1979 → 08:53, 26 December 2011 (UTC)

3. Oppose - Too clunky to add another table to the article, also have subjectivity issue with what points should be represented. Dough4872 18:18, 26 December 2011 (UTC)
4. Comment - I could be persuaded to support this idea, however, I would need to see a better example than Tame Valley Canal, that article is the epitome of what concerns me about adding coordinates to articles on linear features. Dave (talk) 03:25, 27 December 2011 (UTC)
5. Oppose - There is no need to add another table to the article. Martinvl (talk) 21:35, 27 December 2011 (UTC)
6. Oppose. Duplicates WP:RJL. –Fredddie™ 17:27, 28 December 2011 (UTC)
7. Comment No need for a separate table; just add a column; and extra rows if needed, to the junction-list table. An example of this was in [9] but as removed by the American highways lobby. No explanation of how this supposedly harmed the encyclopedia, or why it was not useful to our readers, was given. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:41, 28 December 2011 (UTC)

   WP:There is no cabal. - ʄɭoʏɗiaɲ ^τ _¢ 17:30, 29 December 2011 (UTC)

8. Oppose If a point of interest is notable, it will have its own article with its own set of coordinates. There is no need to put the coordinates in the article about the linear feature.  VC  01:25, 4 January 2012 (UTC)
9. Oppose. Duplicates the junction list...or adds to the table, however you want to look at it. In any case, points of interest is getting subjective. -- LJ ↗ 07:18, 4 January 2012 (UTC)
10. Support as best so far Generally reasonable and sounds harmless, especially if hidden tables are acceptable. As long as readers are not troubled with excessive list clutter, who cares if some compulsional nut gets a rush of blood to the brain and enters a coordinates for each cobblestone? If he really goes too far, then wasn't there some process called err... editing? Opposers seem to hate the idea of a table, or another table, or another column, but as long as the use and layout are clear, functional, and preferably hide-able, why should that matter? No one is forcing anyone to add any particular coords. If the author sees the info as reasonable to add, and some users feel like using it, that is the acid test; in good faith it is not for us to say them nay. JonRichfield (talk) 16:04, 14 January 2012 (UTC)
11. Limited Support. Collapsible lists are extremely useful and could be added to a mandatory infobox, but imposing a item on editors who don't like to use them just generates bad feeling. It should remain an aspiration and over enthusiasm is a nice problem to have --ClemRutter (talk) 15:43, 17 January 2012 (UTC)
12. Support per WP:NOTPAPER. Presenting the co-ords in a collapsible list is a good idea as it will not overwhelm the uninterested. Bazonka (talk) 17:28, 17 January 2012 (UTC)

Proposal 5: Status Quo

The current MoS section, WP:RJL and WP:LINEAR already reflect the schism between those who oppose and those who support the use of coordinates. Both are carefully-reached compromises, allowing for per-article discussion an consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 26 December 2011 (UTC)

Discussion of Proposal 5

1. Oppose, clearly after almost 5 months of you showing up at every corner to slap your coord fever on us means that the status quo is not a carefully managed balancing act nor any sort of compromise. - ʄɭoʏɗiaɲ ^τ _¢ 13:40, 26 December 2011 (UTC)
2. Support, would maybe make the tables a little easier to edit. Like the idea of coords as reference noted, could make the list of reference list of coordinates in a small font and/or in a collapsed table.--Traveler100 (talk) 15:38, 26 December 2011 (UTC)
3. Oppose. Finally, you admit that coordinates are not mandatory in highway articles, as you have claimed several times over at FAC. But still, oppose, because you'll keep fighting for their inclusion. This has resulted in the last 6 months of fighting. Time to settle this once and for all. Also, provides the potential for over 10,000 talk page disputes regarding tagging. --Rschen7754 16:37, 26 December 2011 (UTC)

   Please provide evidence of me saying that "coordinates are mandatory in highway articles", or strike through your dishonest statement. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:11, 26 December 2011 (UTC)

   Your opposal of 2 road FACs because they did not have coordinates, and your trying to persuade the delegates that coordinates are required. --Rschen7754 03:40, 27 December 2011 (UTC)

   So, no evidence of me saying that coordinates are mandatory. Please now strike through your dishonest statement. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:09, 27 December 2011 (UTC)

   I don't really see how Rschen is being unreasonable (or dishonest) here. Opposing a FAC because of the lack of coordinates definitely implies that you feel that coordinates are essential for an article to be considered "our best work". If it were not mandatory, it wouldn't be big of enough of an issue to merit an oppose. —Scott5114↗ [EXACT CHANGE ONLY] 13:18, 27 December 2011 (UTC)

   Considering coordinates essential for an article to be considered "our best work", which I do, is not the same as asserting that they are mandatory. Very few, if any, of the FAC criteria are "mandatory in highway articles". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:34, 27 December 2011 (UTC)

   My comment still stands. Especially considering that you've just declared that "very few, if nay, of the FAC criteria are 'mandatory in highway articles.'" I consider WP:NPOV and WP:V to be mandatory in highway articles, and in every Wikipedia article, in fact. --Rschen7754 04:24, 29 December 2011 (UTC)

   "My comment still stands" - then, clearly, and in the absence of any evidence of me saying that "coordinates are mandatory in highway articles", you're lying. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:14, 29 December 2011 (UTC)

4. Oppose: we're trying to settle, as a community, a question that has caused issues and pages of deadlocked discussion by a smaller group of people. The status quo is untenable, and it will be as long as the debate rages. The legitimate lack of coordinates is a Sword of Damocles some are trying to hang over our heads at various review forums. The community needs to decide by positive discussion whether or not these data needs to be include, period. Passive silence-based "consensus" that they might be included isn't an option anymore. Imzadi 1979 → 17:08, 26 December 2011 (UTC)

   P.S. WP:LINEAR contains five options, the last of which is "no coordinates", and it's still a draft guideline from a WikiProject that hasn't left the draft stage after three years. Imzadi 1979 → 17:10, 26 December 2011 (UTC)

5. Oppose - Status quo will lead to continuous fighting of whether or not article should have coordinates. Dough4872 18:18, 26 December 2011 (UTC)
6. Oppose. Doesn't address the issues with applying coordinates to linear features. —Scott5114↗ [EXACT CHANGE ONLY] 23:14, 27 December 2011 (UTC)
7. Oppose. The status quo is indeed untenable. We will here again in 6 months. –Fredddie™ 17:18, 28 December 2011 (UTC)
8. Oppose We are here to figure out a solution to all of the headaches and fighting caused by this issue. To choose the status quo is to admit that we can do no better than the highly flawed status we have now. We can do much better than that.  VC  01:25, 4 January 2012 (UTC)
9. Oppose. If the status quo was an optimal solution, this RfC would likely not have been started. The debates about coordinates on road articles which have been going on in various forums for a while now need to be decided, and this proposal does nothing to make that happen. -- LJ ↗ 07:18, 4 January 2012 (UTC)
10. Support conditionally I would have given full support, except that what looks like a good solution to me seems to rake up a great deal of history unknown to me, but that I hesitate to dig up. I would have thought that leaving it to the authors and editors to settle matters amicably would do nicely, but I hardly dare ask anyone to explain where the apparent schools of opposing lawyers/liberals got their respective compulsions from. JonRichfield (talk) 16:11, 14 January 2012 (UTC)
11. Support conditionally this remains messy, and does not give the clear message I would like to see. If we could get a clear statement, that it is an aspiration to see all articles clearly co-ordinated, then I would happily abandon the status quo, but in the meantime a solution where I can add them to articles that are deplete, is the best we will get. I will add too that while editors believe that it benefits the debate to say you showing up at every corner to slap your coord fever the status quo will be under attack.--ClemRutter (talk) 15:56, 17 January 2012 (UTC)

Proposal 6: Strengthen use of coordinates in MoS

The relevant MoS pages and other guidelines should be revised to further encourage the use of coordinates. Every article about a highway should have a single set of title coordinates, describing the bounding circle which will display the full road on our mapping page, and locate it in the nearby view of our mobile app, and other services.

Road junction lists should have a coordinates column, with an instance of {{Coord}} on each row. Such coordinates are encyclopedic data and of use and interest to our readers; and should therefore be displayed visibly. Other specific points mentioned in the article should also have their coordinates thus included.

Editors with an antipathy to coordinates are reminded that they can disable the display of coordinates in their local CSS. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 26 December 2011 (UTC)

Discussion of Proposal 6

1. Strong Oppose - A bounding circle (which doesn't show up) does not help locate a line on a map that potentially mislabels roads (ie US highways being labelled as Quebec Autoroutes). It is far too general to pinpoint a feature on the map. Further, it eliminates the usefullness of precise latitude and longitude. Second - Latitude and longitude proponents are reminded that the latitude and longitude shows up AT THE TOP OF THE GEOHACK PAGE! Why does it need to clutter the article up with a geolocationing system that is not used when driving on the road (hence why EVERY SINGLE navigational GPS on the planet uses navteq, and why you don't enter the coordinates of your destination - because they aren't useful when driving)? - ʄɭoʏɗiaɲ ^τ _¢ 14:00, 26 December 2011 (UTC)

   Of course a bounding circle (a point with a defined radius) helps to locate a feature on a map; it governs what map is displayed; again, until you understand how these things work, please refrain from passing comment on what you wrongly suppose to be their failings. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:22, 26 December 2011 (UTC)

   Can you provide a demonstration of one of these bounding circles? I might be more convinced if I saw this concept in action. I do not think bounding circles by themselves will be an acceptable solution, but they could be helpful in moving toward a solution.  VC  18:08, 26 December 2011 (UTC)

   Click on any instance of {{Coord}}, then (for example) the OpenStreetMap link. The map you see is centred on the specified coordinates, and its size is simply that of the bounding circle. Just like every 2-dimensional map. A bounding circle is simply an area centred on a point (as defined by the coordinates), with a given radius. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 28 December 2011 (UTC)

2. Strong oppose per my comments elsewhere on this RFC. --Rschen7754 16:33, 26 December 2011 (UTC)
3. Oppose - The last thing the overlong and overintrusive Manual Of Style needs is a requirement for "a single set of title coordinates, describing the bounding circle which will display the full road on our mapping page..." Carrite (talk) 16:56, 26 December 2011 (UTC)

   This need add only a line or less to the length of the current MoS. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:22, 26 December 2011 (UTC)

4. Strong oppose: per my other comments and Carrite above me. MOS:COORDS already specifies how to format coordinates, if they are added. There is no requirement to add that content, which is what this RfC is about. Imzadi 1979 → 16:58, 26 December 2011 (UTC)
5. Strong oppose - Roads are linear objects and cannot be easily represented by coordinates. Dough4872 18:18, 26 December 2011 (UTC)

   "Roads… cannot be easily represented by coordinates" Please substantiate that opinions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 27 December 2011 (UTC)

   Coordinates are useful to identify an object at a single point, such as a town or building. A road does not exist at just a single point, it is best represented as a line and therefore has an infinite amount of coordinates that can be used to represent the location of the road. Dough4872 01:40, 28 December 2011 (UTC)

Can you trace the route of SH-9? (answer)

6. Oppose, in the case of articles like Oklahoma State Highway 3 the bounding circle will be the size of an entire state. Useless. —Scott5114↗ [EXACT CHANGE ONLY] 00:02, 27 December 2011 (UTC)

We already add - by common consensus - coordinates for states, and countries. As described above, they centre the map which is displayed to users, and which features the entire subject, whatever it is. Also, you're asking us to decide how to treat all cases based on an edge-case. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 27 December 2011 (UTC)

This is hardly an edge case; in addition to border-to-border routes, of which Oklahoma (and most states!) has several (Oklahoma State Highway 9, Oklahoma State Highway 51, Oklahoma State Highway 34, Oklahoma State Highway 99, et al) we have an entire class of articles, called state-detail articles, that cover sections of interstate or US route per state—from the point it enters a state to the point it exits. See Interstate 10 in Arizona, Interstate 70 in Kansas, Interstate 80 in Nebraska, U.S. Route 62 in Oklahoma, U.S. Route 50 in Nevada, U.S. Route 20 in New York. There are hundreds more examples. I can provide you with a complete list if desired. Any solution to the coordinate question must handle these features elegantly, which the bounding circle solution does not. All of these examples of an extremely common situation would be at the zoom level of an entire state, which would be useless for the purposes of identifying the feature. It would be like hanging the map at the end of a hallway and trying to read it from the other end of the hall. —Scott5114↗ [EXACT CHANGE ONLY] 12:54, 27 December 2011 (UTC)

Then how would you suggest we include coordinates for such articles? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:44, 28 December 2011 (UTC)

Ignoring the fact that you're begging the question that I want to include coords in such articles, see Proposal 9. —Scott5114↗ [EXACT CHANGE ONLY] 05:54, 29 December 2011 (UTC)

7. Oppose I see this as creating a lot of clutter in a section that is already accused of being overly visually obstructive. Dave (talk) 03:16, 27 December 2011 (UTC)

   Accused by whom? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 27 December 2011 (UTC)

8. Oppose - many highways can't be represented by a single point - see my example of Highway 1 (Israel) above. עוד מישהו Od Mishehu 10:32, 27 December 2011 (UTC)

   And many more can. baby:bathwater. We deal with such exceptions as and when they arise, not by prohibiting less unusual uses. Furthermore, you're opposing a suggestion which includes tables of coordinates, based on your views on a single set of coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 27 December 2011 (UTC)

9. Oppose per Scott5114. –Fredddie™ 17:21, 28 December 2011 (UTC)
10. Oppose per Scott. I'm afraid that the case he highlights is not an edge case, but is in fact a quite-common test case that the coordinate system proposed in WP:LINEAR can't handle adequately. I am also strongly opposed to that system being elevated to be part of the Manual of Style as part of MOS:COORDS. FWIW, I don't edit road articles, I stumbled into this discussion via WP:CENT, so you can argue that this RFC in fact creates a non-local consensus. Titoxd^{(?!? - cool stuff)} 19:48, 31 December 2011 (UTC)
11. Oppose The impetus to use coordinates for linear objects should not be strengthened when it has been demonstrated that use of coordinates for linear objects is highly flawed.  VC  01:25, 4 January 2012 (UTC)
12. Oppose. The single-point title coordinates do not adequately represent and display an entire linear feature, even with the "bounding circle" set. Additionally, a set of coords on each row of the junction list is bordering on overkill. -- LJ ↗ 07:18, 4 January 2012 (UTC)
13. Oppose. The "bounding circle" concept does not adequately define the limits of the road, as the circle actually contains more land that is not the road than is the road. oknazevad (talk) 07:24, 7 January 2012 (UTC)
14. Oppose categorically for reasons already adequately given by others. Bounding circles (even bounding ellipses) simply are not realistic for the application, and more elaborate bounding conventions simply would be too complex either to use or for modal users to follow. Say I: one set of coords default. Two where two will usefully locate an extended feature. More where required for special purposes.JonRichfield (talk) 16:18, 14 January 2012 (UTC)

Proposal 7: Minimalistic entry in existing junction table

I think the best idea it to use a minimalistic link to coordinates (i.e. displays only as "_coord" or similar). Then the coordinates can be inserted into the existing junctions table. I support the general idea of coordinates, my concern is the potential for clutter. By using a minimalistic icon (or superscript text, or similar) someone can add the coordinates of every junction if desired, without adding too much clutter.

Discussion of Proposal 7

1. Support as nominator Dave (talk) 03:30, 27 December 2011 (UTC)
2. Oppose no upper limit on tagging; see above. Allowing the option of tagging every junction will result in this becoming mandatory at places like FAC. --Rschen7754 03:34, 27 December 2011 (UTC)

   To clarify, I do support the proposal in terms of how coordinates should be displayed. But the sentence "By using a minimalistic icon (or superscript text, or similar) someone can add the coordinates of every junction if desired, without adding too much clutter." led me to oppose. --Rschen7754 05:14, 29 December 2011 (UTC)

3. Oppose - Still doesn't address subjectivity of which roads should be selected, no source for coordinates. Dough4872 04:36, 27 December 2011 (UTC)
4. Support in principle. Should coordinates be allowable in the end, this is how they should be displayed. Use of <ref group=coord>{{coord}}</ref> in concert with {{reflist|group=coord}} and {{GeoGroupTemplate}} has been successful at doing just this. –Fredddie™ 17:43, 28 December 2011 (UTC)
5. Oppose - encyclopedic data such as coordinates should be displayed for our readers to see and use. Also, multiple links all using the same link text, as proposed, hampers accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:25, 29 December 2011 (UTC)
6. Oppose Either every junction will have coordinates or the ones that do will be a subjective matter.  VC  01:25, 4 January 2012 (UTC)
7. Weak Support. Combine my comments for proposal 2 above with the minimalistic coordinate display treatment of this proposal, and it gets some support from me. I do agree with Andy in that each coordinate link would probably need to be distinguishable in some way to aid readers. -- LJ ↗ 07:18, 4 January 2012 (UTC)
8. Weak support seems more or less OK to me. JonRichfield (talk) 16:20, 14 January 2012 (UTC)
9. Weak support: this would work, and would not overwhelm the uninterested. Bazonka (talk) 17:31, 17 January 2012 (UTC)

Proposal 8: (Live and let live)

Let people add coordinates if they want to, but if they don't want to, that's cool too, and they don't have to have them to get any sort of higher certification (GA, A, FA) for their articles. If someone wants to go around and add them to all ten thousand articles in some standardized way as a personal project, well, dandy. —Scott5114↗ [EXACT CHANGE ONLY] 13:21, 27 December 2011 (UTC)

Discussion of Proposal 8

• What about people like me who removes coordinates from road articles when spotted? This is essentially the status quo with a promise to keep our distances, and doesn't seem workable after this much time and quarrelling. - ʄɭoʏɗiaɲ ^τ _¢ 15:16, 27 December 2011 (UTC)
  • As you've been told elsewhere, such behaviour is disruptive; and you should desist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 27 December 2011 (UTC)
    • I have not, and I will not - ʄɭoʏɗiaɲ ^τ

_¢ 18:01, 27 December 2011 (UTC)

• • • • Hey Maaannn! I admire your line in bragging about your disruptive powers! Zis iss a choke, ja? The very idea makes me feel a need to take a shower. JonRichfield (talk) 16:33, 14 January 2012 (UTC)
• Oppose basically same as status quo option. --Rschen7754 16:01, 27 December 2011 (UTC)
• comment Duplicates option 5. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 27 December 2011 (UTC)
• Oppose: duplicates proposal 5. Imzadi 1979 → 20:24, 27 December 2011 (UTC)
• Oppose - Making this optional will lead to edit wars and possible issues at GAN, FAC, etc. Dough4872 23:02, 27 December 2011 (UTC)
• Oppose Similar to Proposal 5, this one is setting us up for continued strife. The only way this could possibly work is if the decision whether coordinates are mandatory to be used, optional to be used, prohibited, or somewhere else on the spectrum is devolved to the project level. This has its own potential set of problems, though.  VC  01:25, 4 January 2012 (UTC)
• Oppose. Duplicates proposal 5. -- LJ ↗ 07:18, 4 January 2012 (UTC)
• Support. There are some times when you would want to have different solutions. Imposing a one-size-fits-all mandate will disturb the wikinature and bring about unbalance and discord. Beware! Selery (talk) 08:00, 5 January 2012 (UTC)
  • That could be used to argue against almost any sort of style guideline on Wikipedia. --Rschen7754 08:02, 5 January 2012 (UTC)
    • And successfully, too. E.g. BC/BCE. Selery (talk) 10:59, 5 January 2012 (UTC)
      • Except that the status quo has been untenable, which is why this RfC was opened, to arrive at a solution to the on-going disputes. Imzadi 1979 → 11:19, 5 January 2012 (UTC)
        • I'm not persuaded that the occasional disagreement isn't a fair price to pay for the flexibility to take different approaches according to the particular situation instead of imposing one-size-fits-all hammer to every problem, nails and otherwise. Selery (talk) 16:41, 6 January 2012 (UTC)
          • This hasn't been "occasional", its been consistent since at least August. Nearly 6 months. The problem is the current one-size-fits-all {{Coord}} template, which by its very nature is designed for points, not lines. - ʄɭoʏɗiaɲ ^τ _¢ 17:55, 6 January 2012 (UTC)
            • I take this Proposal 8 to mean that if people want to add something more appropriate for paths than points, that would be fine too, but it shouldn't be mandatory for GA or FA etc. Selery (talk) 22:56, 9 January 2012 (UTC)
• Support conditionally. I would support it directly, on the assumption that any run-of-the-mill editor would combine sufficient constructive flexibility and cooperative spirit to render such a system generally acceptable, but I am given pause by some of the foregoing, proudly outspoken commitments to obstruction, pollution and destruction. Obviously I was too naive by far. My stomach hurts... JonRichfield (talk) 16:33, 14 January 2012 (UTC)
• Strongly support. Why do we need rules for when coordinates may be added? — RHaworth (talk · contribs) 23:57, 17 January 2012 (UTC)

Proposal 9: Shapefiles

Maybe we're going about this the wrong way. What would everyone think about attaching a polyline shapefile to articles that could be downloaded and used in any software that supports them? This would support at least 70 million coordinates per feature, not lead to any clutter beyond one link, faithfully represent the feature, and major features would able to be labeled via the attribute table. The shapefile specification is well known so it would be supported by many tools, and it would be trivial for editors to rip the coordinate data from already freely available shapefiles (in fact, the same shapefiles we use to create the maps in the articles!). It is less parsable than a single set of coordinates, but then with as many coordinates as would be needed to accurately represent the course of a major road, you would run into parsing problems with tons of {{coord}}s anyway. A microformat could be used to tag the shapefile link as containing geographical data so it would be machine-discoverable. Humans, too, could import the shapefile to their own GIS projects and render them against satellite imagery or in any projection we choose; our data could be used to augment other free maps. (Note! See the reply to comment #2 below for a possible way that Geohack could handle this.) —Scott5114↗ [EXACT CHANGE ONLY] 05:51, 29 December 2011 (UTC)

Discussion of Proposal 9

1. Support. This is so far the only proposal for including coordinate data that has been presented so far that meets all of my concerns. —Scott5114↗ [EXACT CHANGE ONLY] 05:51, 29 December 2011 (UTC)
2. Comment I think we would need a talk with the technical people to see if this is possible. --Rschen7754 06:04, 29 December 2011 (UTC)

   It is technically possible (using tools present on a standard Linux install, which presumably the toolserver or wherever Geohack is hosted would have already) but would take a little coding. I envision it as the modified Geohack downloading the shapefile ZIP from the server, parsing the coords from it, and then presenting tools using the coords as Geohack does presently. Yes, it would take some programming work, but shit, someone wanted to put in the effort to write the current Geohack, didn't they? —Scott5114↗ [EXACT CHANGE ONLY] 06:10, 29 December 2011 (UTC)

   Provisional support depending on if we could get it working. --Rschen7754 01:31, 30 December 2011 (UTC)

   Holy crap this is a good idea. How would the server get the shapefile? Take the shapefiles you can download from the Iowa DOT website for instance, all of the roads in the state are in one shapefile. If I take the time to create individual shapefiles for each route from the original, would that be OR? That being said, I'd love to see it in practice, which may be a while. –Fredddie™ 06:36, 29 December 2011 (UTC)

   I don't see how this would be any more OR than using that shapefile to make a PNG map. Assuming you had a free data source, my idea would be, when making a map, to also copy the points that would become the red line into a new shapefile. There the points could be given annotations in the attribute table in some standard way, then zipped (since a shapefile consists of three separate files) and uploaded to Commons. The article would have a template inserted to associate that ZIP file with the article, and a link to Geohack or whatever service is created to handle it. Clicking that link would cause the new Geohack to download, unzip, and parse the file on demand, and then after that is done present the user with the same sorts of tools Geohack does now.—Scott5114↗ [EXACT CHANGE ONLY] 08:19, 29 December 2011 (UTC)

3. Support. If I wasn't clear enough, I fully support this proposal. –Fredddie™ 01:19, 30 December 2011 (UTC)
4. No harm in doing this (though it duplicates what others, including OpenStreetMap, are doing), but only in addition to displaying coordinates, not as an alternative to it. Shapefiles are neither human- nor machine- readable in the same way that our coordinates are. There is no microformat suitable to "tag the shapefile link as containing geographical data". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:24, 29 December 2011 (UTC)

   I don't really see why the fact that it's different is necessarily bad. I know inconsistency is to be avoided, but we're dealing with a fundamentally linear object here, we should have a linear solution, not a point-based one. Similar situations is what makes consistency possible, and I think the problems we've illustrated with all of the proposals above illustrate why the situations are different. Regarding the microformat, can we not just tag the shapefile link with a <span class="geo"> or would that violate the Geo specification? What about doing something like <span class="geo" href="http://...">? What options does Geo support? —Scott5114↗ [EXACT CHANGE ONLY] 12:55, 29 December 2011 (UTC)

   A sequence of coordinates, such as that in the M23 table given as an example above, is linear, not point-based. Tagging a link with <span class="geo" href="http://..."> would only work if the displayed link text was in the format of a single set of coordinates, such as "52.123456;1-.987654". Also, the method you propose would not work (as does the current title coordinates method) with those external services, linked to from {{GeoTemplate}}, which require a single set of coordinates on which to centre their map or search. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:24, 29 December 2011 (UTC)

   Which currently require. Things can be reprogrammed and IMPROVED instead of "nope, has to be this way, only this way, and nothing but this way". Sorry, but clearly the consensus is weighted against your 'must have coords' viewpoint, so maybe you should sit down and try to compromise instead of trying to bulldoze through everyone. - ʄɭoʏɗiaɲ ^τ _¢ 17:15, 29 December 2011 (UTC)

5. Comment. Can a shapefile be machine-parsed to produce a representative point that can be used as title coordinates and calculate a bounding circle for the route based on that representative point and the point in the shapefile that is furthest from the representative point? Ideally, there would be a single set of coordinates at the top of an article, as is the case for many point-subject articles; and a path based on the shapefile that could be viewed by clicking on the coordinates at the top of the article to go to geohack, then selecting the desired mapping service.  VC  15:38, 29 December 2011 (UTC)

   I don't believe it is possible to accurately represent a linear feature as a single point. This proposal is designed to avoid having to do so. —Scott5114↗ [EXACT CHANGE ONLY] 22:42, 29 December 2011 (UTC)

   I understand the opposition to explicitly representing a linear feature as a single point, as in title coordinates. However, what if the set of title coordinates is a supplement to a true linear representation derived from a shapefile? What if the title cooordinates are not broadcast in an article but are only used behind the scenes to produce a Wikipedia link, somewhat analogous to a route marker on a physical map, in addition to a path in a mapping application? I am being theoretical here because we do not know yet if this shapefile idea is practical.  VC  00:12, 30 December 2011 (UTC)

   Ah, I see what you're saying. I assume it would be possible to take the first point and the last point and average them to create some sort of middle point that could be used for centering maps and creating bounding circles, but isn't broadcast as the One True Coordinate for the feature. I'm not really too good at math but I'm sure there's some function or formula for calculating the "most extreme" of a set of points. —Scott5114↗ [EXACT CHANGE ONLY] 01:11, 30 December 2011 (UTC)

   It's possible. The main question to ask is whether this representative point should lie along the path, or if it is merely the centroid of a point cloud. (The centroid is nice for centring a map; a point on the path might be some kind of midpoint, but I'm not sure that it's necessarily a meaningful location.) Additionally, are there any additional considerations due to not every point cloud being created equal? (Low density, for example.) TheFeds 20:51, 31 December 2011 (UTC)

   Using the centroid of a point cloud might work, but the representative point would need to lie along the path. After all, it would not make sense for the route marker to not be placed on the route path in the absence of a connecting arrow. It may actually be better if the representative point is not a meaningful location, because meaningful locations, such as a city, an interchange, a historical site, or a bridge, might already have a marker and coordinates. A non-meaningful location puts the emphasis on the route and not on the non-route nature of the location.  VC  04:14, 5 January 2012 (UTC)

6. Comment - While this seems better than any of the other proposals besides the one that bans coordinates, I don't see the average reader finding value in downloading the shapefiles. Dough4872 18:31, 29 December 2011 (UTC)

   The average reader wouldn't have to do so; they would simply click a link and Geohack would do all the work behind the scenes. See my reply to Fredddie above. —Scott5114↗ [EXACT CHANGE ONLY] 22:42, 29 December 2011 (UTC)

   Support - I think this idea could work to represent the coordinates of a road. Dough4872 01:39, 30 December 2011 (UTC)

7. Support. This is the only system that makes any sort of sense for paths. Do get in touch with GeoHack developers to see how this could be accomplished. Titoxd^{(?!? - cool stuff)} 19:51, 31 December 2011 (UTC)
8. Support as a supplement irrespective of the main RfC decision about whether to expand/reduce/maintain the use of co-ordinates. (I was thinking of proposing the same thing, but Scott committed it to electrons first!) Eventually we'll need to have a discussion about what constitutes a reliable source for the purposes of plotting a road, but I suspect data from most jurisdictions' own transportation departments will be sufficient and available. We'll also need to discuss what file format(s) to offer. Support as an alternative to co-ordinates, provided that this information will be adequately available to users without special software outside their browsers. (For example, do we have a good UI that allows them to visualize the shapefile and extract the co-ordinate information that would otherwise be in the article text/infobox?) Comment: this is not to say I'm opposed to using co-ordinates to identify particular features, with good reason; this is merely a better way to characterize an entire road geographically. TheFeds 20:42, 31 December 2011 (UTC)
9. Support This is a thinking-outside-of-the-box solution. The problem of representing a linear object should have a linear solution, not a point solution.  VC  01:25, 4 January 2012 (UTC)
10. Support—if this can be made to work. Imzadi 1979 → 01:32, 4 January 2012 (UTC)
11. This is a very interesting proposal. I like the thought of still using the GeoHack but actually produce a linear feature on a map. If the idea can be made to work, it has my strong support. -- LJ ↗ 07:18, 4 January 2012 (UTC)
12. Support an initiative to develop this - It is the only accurate way to properly geolocate a linear feature (by the way, this feature would be amazing for rails and rivers, also commonly mapped out by local governments in shapefiles); show the whole route as a line, doing away with points entirely. - ʄɭoʏɗiaɲ ^τ _¢ 17:34, 4 January 2012 (UTC)

    Not just that, we could show the entire city and not just the city center. –Fredddie™ 18:26, 4 January 2012 (UTC)

13. Conditional Support If this shapefile can be made to integrate with the existing geohack tools to support a layer in google maps (or similar), I would wholeheartedly support this. If this can be done this would be better than my own proposal above. Dave (talk) 21:12, 4 January 2012 (UTC)
14. Conditional support If we can get it to work, this would likely solve many of the issues. oknazevad (talk) 16:49, 7 January 2012 (UTC)
15. Support strongly. Now yer torkin! If it is a Linux standard, it should be feasible to adopt, adapt, even perhaps largely to borrow. It sounds versatile and visually supportive too. Should be good for more than just highways and rivers. Worth waiting for if necessary. In cases where a single- or few- coordinate set would do, it could be optional, or possibly the feature could be implemented with the simplest cases as options to avoid scaring off folks who don't need the full set of bells and whistles. JonRichfield (talk) 16:43, 14 January 2012 (UTC)
16. Support --99of9 (talk) 13:42, 17 January 2012 (UTC)
17. Support As a medium term goal- thought should take place on how this data can be input and referenced using standard WGS, so it can continue to be written displayed in standard dd.dddd, dd mm.mmm and dd mm ss formats. In the mean time we should aspire to put end and median point data to every road, and a collapsible table with significant points should be included in the infobox. In the short term all articles missing this should be tagged for attention. A css fix, maybe white font on white should be published so users who have expressed contrary opinions can white it out on there own screens. --ClemRutter (talk) 17:00, 17 January 2012 (UTC)

    {{Coord}} is our method for the entry and display of WGS 84 coordinates; and I have pointed out already that {{Coord}} includes a facility (see its documentation) for those who do not wish to see coordinates, to hide them. Those opposing coordinates here are not content to simply do that; they wish to deprive all our readers of their benefits. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:29, 17 January 2012 (UTC)

    Is this a new feature in {{Coord}}? I ask because seem to recall vehement opposition from you, Andy, to hiding coordinates at all. So, as you can hopefully understand, it seems odd that you, of all people, would point out this feature. –Fredddie™ 17:46, 17 January 2012 (UTC)

    Not at all; you're confusing the forced hiding of coordinates for everyone (depriving all our readers of their benefits; which would be dumb), and you hiding them for your account (which still dumb, but up to you). The facility for the latter has been in the template from the beginning. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:06, 17 January 2012 (UTC)

18. Support in addition to another option: Nothing wrong with this, but not everyone has the wherewithal to use shapefiles. But everyone can click on a normal co-ordinate pair and use Geohack though. Bazonka (talk) 17:36, 17 January 2012 (UTC)

    Through Geohack, the shapefile would render the line over whichever map is requested, much like you can choose what map will show the coordinates. Users would have the option to download the shapefile if they so choose. –Fredddie™ 17:46, 17 January 2012 (UTC)

    Not all maps have that facility; not everything linked to from GeoHack is a map. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:06, 17 January 2012 (UTC)

    OK, so it's more powerful that I thought; but even so, some users would just prefer the speed and simplicity of clicking on a co-ordinate pair. Bazonka (talk) 18:16, 17 January 2012 (UTC)

    Bazonka, I was replying to Fredddie, not you. Your point is valid. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:57, 17 January 2012 (UTC)

    Everyone can also click on the word "coords" to open up geohack, instead of blundering them with a potentially limitless number of degrees, minutes and seconds that serve no purpose on the article itself. Geohack shows the longitude and latitude, and that is enough. - ʄɭoʏɗiaɲ ^τ _¢ 19:04, 17 January 2012 (UTC)

    We could also hide the length of the road behind a link saying "length", or the date of opening or places passed though, likewise; but we don't, because - like its features' coordinates - they're facts about the subject which are of use or interest to our readers. And because hidden data which is wrong is less likely to be noticed and corrected. I have no idea what is meant by "to blunder" someone. We get that you don't want to see coordinates; but as I explain just above that's within your gift; it doesn't mean that you should remove them from view for those who wish to see them on the page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:31, 17 January 2012 (UTC)

    I fail to see the correlation between the length, a single unlinked number, and the display of DMS coordinate pairs, which link to a page that repeat that information as well as providing the visual interface that our users desire... The display of repetitive number sets that vary only by decimal places is not helpful or informative in this context. Blunder, barrage, overburden, fill too much damn space with blue numbers with no context to their purpose. Take you pick. - ʄɭoʏɗiaɲ ^τ _¢ 21:37, 17 January 2012 (UTC)

19. Support per Scott5114. - Presidentman talk · contribs Random Picture of the Day (Talkback) 21:05, 17 January 2012 (UTC)
20. Support I agree that the current coordinates system may be impractical for roads, but coordinates do add a value. If we can supply coordinates in a sensible format with this, why not? It might also work for other non-linear features such as rivers. Excirial ^{(Contact me,Contribs)} 23:55, 17 January 2012 (UTC)

    Addendum: My comment in below seems to be a variation / extension of this suggestion now that i think about it. Perhaps some parts of it would be useful to consider as well in addition to this proposal. Excirial ^{(Contact me,Contribs)} 19:50, 19 January 2012 (UTC)

Proposal 10: Coordinate clutter

This proposal is not intended to be complete; it's supposed to be more or less a statement.

California State Route 282 has very few rows in its junction table. It may be feasible to tag every row in the junction table with a coordinate.

Interstate 10 in Texas has 396 exits. It should not have a coordinate tag for every row in the junction column for several reasons:

• Currently, we have to hardcode some elements of the junction table because the MediaWiki software has a hard limit on how many templates can be on a page. {{Coord}} 396 times won't help at all.
• {{GeoGroupTemplate}} - "Map of first 200 coordinates from Bing". Sucks if you prefer Bing over Google Maps, because you'll only be getting the western half of the route. (And I keep hearing more and more editors complaining about Google Maps because of inaccuracies).
• Does each ramp get a geotag, even if they're 1/8 of a mile apart or less? Is this helpful at all?
• The FHWA is required to add exits for local access as the only road into an area, even if the exit is rarely used at all.
• It will take hours for an editor to add such tags to an article, and it is highly unlikely that a reader will care enough to want to find the coordinates of where a particular exit is on a map. Even if all 3289 readers of Interstate 10 in Texas in December 2011 wanted to look at one exit's coordinates, and each clickthrough is distributed evenly (in practice, they wouldn't be), that would be 8.3 views per month per coord tag. And that's ridiculous; not all readers want the coordinates; I'd venture a guess that no more than 25% would want them (overestimating). So that goes down to about 2 views a month.
  • The clickthroughs wouldn't be distributed evenly. I think we'd find that the 10-15 most major junctions would get 75% of the clicks. So we just tag those, and only lose 2 views a month, or 0.5 views a month, depending on the percentage you're using from above.
  • Keep in mind that this is the main highway in Texas; it being an Interstate really helps its popularity, and here's some stats on a different highway: Interstate 90 in Montana. Viewed 860 times in December 2011. 116 junctions. That's 7.4 views per month per coord tag assuming equal distribution and 100% clickthrough. Which is quite optimistic, considering a) Montana is very sparsely populated (it had some of the last 2-lane stretches of the Interstate system) and b) it's thus one of the least well traveled Interstates ([10]).
  • Some highway articles only get 46 views (though granted, less junctions); even my beloved FA California State Route 78 only gets 956.
• Sea of blue clutter, if not done properly.
• People with screen readers beware.
• Readers can get a good sense of where the road goes from ~10-20 coordinates; the extra detail isn't too helpful.
• Sometimes the placement of coordinates on junctions makes the resulting route more inaccurate than if the coordinates were placed in more geometrically strategic locations.
• We have our own map in the infobox, compiled from GIS data. And it's right there at the top of the article. No scrolling, no click.
• Notability; is a road junction's coordinates that noteworthy? For a major junction, yes. Otherwise, no.
• When you have hundreds of tags on a map, they all tend to overlap each other and are impossible to click on; you can't even tell which tag is which or even see the route under them until you zoom in by a lot.
• A shapefile can provide this level of detail and even more for much less work.
• Counterargument: But we shouldn't prevent every row from being tagged because if the road editors don't want to do it, someone else will!!!
  • Rebuttal: Not really. There are over 10,000 highway articles in the US alone. Lots of work. Also, at least in the US, Ontario, and Croatia, we like to take our articles to GA and FA... so the coordinates will become a "de facto" requirement and the editor will be forced to add coordinates there. At WP:USRD, we have 11.9 times the percentage of GA/FA articles in the English Wikipedia overall.
• Counterargument: But this means banning all coordinates from road articles!
  • Rebuttal: No, it does not.
• Counterargument: But this means removing people's work from articles that already have coords in every row!
  • Rebuttal: Yes, and it's unfortunate when this happens. But Wikipedia is for the reader, not editor; And also, it would be more work to add the coordinates for consistency purposes than it would be taking out the extraneous ones. Furthermore, less than 0.1 % of all USRD articles have coordinates for every junction, and we have roughly 2/3 of all the highway articles. And at least 2/3 of the remaining third have no road junction list at all.
• Counterargument: But it is our duty as Wikipedia to provide this info!!!
  • Rebuttal: . We're not an atlas or gazeteer; we're an encyclopedia.
• Counterargument: WP:NOTPAPER!
  • Rebuttal: WP:NOT an indiscriminate collection of information.
• Counterargument: Okay, so 5-10 clickthroughs for coordinates; net positive.
  • Cost-benefit analysis. Is it worth the hours of work for such a small gain? It's a net loss.
• Counterargument: Wikipedia is not for the editor; it's for the reader.
  • Correct; but, that doesn't mean compromise everything; for example, notability.

Discussion of Proposal 10

1. Support as proposer. --Rschen7754 11:56, 19 January 2012 (UTC)

• Actually, according to Wikipedia:Five Pillars we are a gazetteer. You remember the five pillars, right? --Tagishsimon (talk) 21:34, 19 January 2012 (UTC)

• Still no. Contains elements of gazetteer != is a gazetteer. Large distinction. --Rschen7754 21:58, 19 January 2012 (UTC)

• Bit difficult being anything like a gazetteer absent links to a map. A point you have not grasped, even though I did give you a pointer to the gazetteer page. --Tagishsimon (talk) 22:03, 19 January 2012 (UTC)

• We do have a map in our articles; also, a link to OSM or a shapefile would suffice. Plus, you have yet to substantiate your assertion that gazetteers must have coordinates. --Rschen7754 22:09, 19 January 2012 (UTC)

• You need to explain why it is a good thing that I cannot look up the road on the map of my choice, not the cruddy image you deign to be a map. In substantiation of my assertion, a gazetteer, per the definition on wikipedia, is a geographical directory ... used in conjunction with a map or a full atlas. Coords are the de facto means in wikipedia of putting an article or element in and article in conjunction with maps and atlases. The burden is on you to explain why it is that highways should get a dispensation to use other than the standard in seeking to achieve its gazetteer function, given that we're well able to point to otherwise completely unobjectionable examples of the use of coords on highway articles. --Tagishsimon (talk) 22:19, 19 January 2012 (UTC)

• Even if your points are true (which they aren't) how would this not be resolved with a shapefile? --Rschen7754 22:21, 19 January 2012 (UTC)

• You don't actually explain anywhere in your proposal, that I can see, what a shapefile is and how it serves us. You rant on for thirty or so lines, and then say ""A shapefile can provide this level of detail and even more for much less work" and, err, that's it. Is it a Shapefile? Can I use it with google maps, bing and acme maps? You do actually need to explain what you're talking about before soliciting comments on it. --Tagishsimon (talk) 22:50, 19 January 2012 (UTC)

• Can you use {{GeoGroupTemplate}} with acme maps? Where is this highway article where there were no objections to coordinates being added? Was it one of the articles where you shoehorned them in amongst discussions on WT:RJL? - ʄɭoʏɗiaɲ ^τ _¢ 23:00, 19 January 2012 (UTC)

• No. But you can use each of the individual coords with acme, as well you know. Could we not do the pissy stuff, please. Mine is a simple request for Rschen to explain what he or she is proposing. I'm disinclined to give you a list of UK articles with tables of coords in their RJL, since your record is one of deleting them on sight. --Tagishsimon (talk) 23:18, 19 January 2012 (UTC)

• What's your response to the other points, by the way? Also, I figured that Proposal 9 explained the shapefile concept enough. If not, please ask questions. --Rschen7754 23:21, 19 January 2012 (UTC)

Proposal 11: (name of proposal)

Discussion of Proposal 11

Overall discussion

• Comments: something not addressed by proposals 2, 3, and 4 is the usage of coordinates in the title space. This is an issue that will need to be decided, unless we went with something along the lines of proposal 1. The {{coord}} template can be used two ways: to define title coordinates, which is the single point associated with the article subject, and to list the coordinates in the body of the article, or in the body of a table. Title coordinates are quite problematic, IMHO, because roads don't exist in single locations. They're even worse on segmented roads. What segment gets the "honor" of containing the title point? What about a highway that is a full circle beltway, orbital, or ring road? A ring road doesn't have discrete termini, although for mileposting and similar applications, one junction is typically defined as the zero milepost.
  Title coordinates can't be located on a junction though. If I tag the article about a hypothetical Highway 1 with title coordinates located at its junction with Highway 2, to which of the two roads that meet at that intersection am I referring? Google Maps, and other mapping services, would link to the HIghway 1 article over the location of the junction. A reader looking at the map, if it doesn't label the roadways for them, could be confused at which road is the subject.
  As I explained in my support of the first proposal, the government agencies that maintain the roads don't publish official sets of waypoints for their highways. They may publish Geographic Information Systems (GIS) frameworks for cartographic purposes, but GIS defines roads as lines, not points. If the DOT treats them as lines and not points, neither should we. Imzadi 1979 → 08:37, 26 December 2011 (UTC)

IMO, for the proposals that do not address what to do in the title space, that can be presumed to be a separate issue. In, my opinion, there is no point to putting co-ordinates in the title space for linear features. Dave (talk) 03:28, 27 December 2011 (UTC)

I agree with Dave, there's no point in using titlespace coordinates for almost all roads. (I suppose you could use the geographic average centerpoint, or the mileage centerpoint... but that's not too useful) The system in use on Wikipedia only supports one set of coordinates. (I do see the proposal to make the coordinates solution used on Wikipedia to support more than one set of coordinates... not holding my breath that that won't break other people's tools) 76.65.128.132 (talk) 21:25, 27 December 2011 (UTC)

• Comment: Despite warning against canvassing, Rschen7754 is referring elsewhere to this as an RfC on "the potential use of coordinates in highway articles" (my emphasis), ignoring, as does the RfC itself, that many articles on roads already have coordinates; and that their use is explicitly provided for in our Manual of style. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:13, 26 December 2011 (UTC)

There is no canvassing in stating that this RfC determines their potential (ie future) use. If the community opposes them, they can always be removed from those few articles. We aren't compiling a summary of the past, we're picking a path for the future. - ʄɭoʏɗiaɲ ^τ _¢ 14:05, 26 December 2011 (UTC)

Exactly. I'm just trying to remain neutral. As you can see above, I actually support the limited use of coordinates, rather than not using them at all. So if "potential use" was canvassing... I'd be canvassing against myself. --Rschen7754 16:32, 26 December 2011 (UTC)

• Comment: There are two different issues to discuss here.

• What things should/shouldn't have coordinates against them in the article?
  • Start/End points
  • Points of interest
  • Junctions
  • Other things
• Where should the coordinates be placed within the article?
  • In the title
  • In the infobox
  • In the body text
  • In junction lists

Might be better to have a number of smaller focussed proposals rather than trying to write on proposal that covers everything and then picking a few of the proposals rather that just trying to get everything in one.

For example:

• Should there be Coordinates in the title?
  • No
  • Yes, just a single point to represent the average location
  • Yes, start & end points (execpt for orbital roads)

Then list out the options for Infoboxes, Junction Lists, and within the article text. -- WOSlinker (talk) 13:07, 26 December 2011 (UTC)

• • A sensible approach, in general, but note that the title parameter only allows for a single set of coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:14, 26 December 2011 (UTC)
    • Nothing is forbidden in the world of coding. I'm sure this could be changed to support the endless list of linear features we cover with more informative and less subjective data. - ʄɭoʏɗiaɲ ^τ _¢ 17:00, 26 December 2011 (UTC)
    • Its purpose is to display a single set of coordinates, for reuse by many tools and partners. It's not broken, so there's nothing (per your edit summary) to fix. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:07, 26 December 2011 (UTC)
      • Then its purpose isn't suitable for things that don't exist at a single set of coordinates. - ʄɭoʏɗiaɲ ^τ _¢ 17:13, 26 December 2011 (UTC)
        • Poppycock. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:22, 26 December 2011 (UTC)
          • Could easily make a template that showed two coordinates, but at present they would need to be individual links to click on rather than clicking on them both as a set. -- WOSlinker (talk) 18:05, 26 December 2011 (UTC)
            • We could indeed, but that wouldn't work for the various tools that make use of those coordinates; and may well break some of them. (I have previously suggested putting a fixed string in that location, as a work-around t=for this issue.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:13, 26 December 2011 (UTC)
              • It is possible to Bing & Google maps with 2 coords -- WOSlinker (talk) 11:20, 27 December 2011 (UTC)
                • http://maps.google.com/maps?q=44.112,-87.913+to+43.112,-87.913
                • http://www.bing.com/maps/?q=44.112,-87.913+to+43.112,-87.913
                  • Now here's one more step that could make this a completely viable option: Can you create waypoints inbetween using more coordinates? If a route can be outputted instead of a set of coordinates, that would be something useful to link in the title. - ʄɭoʏɗiaɲ ^τ _¢ 15:13, 27 December 2011 (UTC)
                    • It's not practicable to put an entire route (and routes are sets of coordinates) into the title position. As I've suggested previously, the way to do that is to put the coordinates into a section of the article (like the junction list) and put a link akin to {{GeoGroupTemplate}} in the title position. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:41, 27 December 2011 (UTC)
                      • Poppycock! You just don't want to improve the tool that only works for one application. - ʄɭoʏɗiaɲ ^τ _¢ 18:00, 27 December 2011 (UTC)
                        • Please do not attempt to speak for me; you are singularly lacking the wit or wisdom to do so. I, on the other hand, as the creator of that template, am already aware that it already works for several applications. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:30, 28 December 2011 (UTC)
                          • Just not this one... - ʄɭoʏɗiaɲ ^τ _¢ 17:33, 29 December 2011 (UTC)
                  • The problem one sees in this example is that the line drawn does not conform to a single road. Mangoe (talk) 21:59, 27 December 2011 (UTC)

• Support a la Ustinov

In his book "Ustinov's Diplomats", the UK delegate in effect says for a Yes' vote: "Her Majesty's government, while not saying aye to the motion, none the less do not say nay; this should in no wise be taken as an abstention..." I reckon that where there is a practical use for a coordinate in the title, and where that need cannot be equally well filled by giving the same info in the article, then by all means. I cannot offhand think of an example though; in general I am inclined to say that it should not be encouraged as an option when it cannot be shown to be really necessary or at least particularly helpful. JonRichfield (talk) 17:18, 14 January 2012 (UTC)

Numerical data

Does anyone who supports the use of coordinates have any actual numerical data available showing that the coordinates are used in any appreciable degree by readers? How many hits does the Geohack page get per day? If it turns out that only a couple dozen readers use coordinate data then it's not worth our time to even bother with them. (I know if I were a reader I would find no use for them because I cannot relate them to the real world—I have no idea what my current coordinates are as I sit here—so instead I'd be using the maps included in the article).—Scott5114↗ [EXACT CHANGE ONLY] 00:12, 27 December 2011 (UTC)

Given your final sentence, the irony that a prime purpose of {{coord}} is to enable users to click through to a map is not lost. Last time I asked - Template_talk:GeoTemplate#Stats_for_the_use_of_GeoTemplate I was told that 26k users, but the respondent was less than clear about the time period. I presume that was for a 24 hour period. The case was also made that Geohack is only one of a number of resources made available by {{coord}}. Clicking on the globe icon brings up a small map; I have no idea on the hits for that. And coords are used to place wikipedia icons in products such as Google Maps. Again, I know not whether much use is made of the wikipedia layer in maps of the ilk of Google or Bing. --Tagishsimon (talk) 00:50, 27 December 2011 (UTC)

Hmm. 26k is a lot, but I'm not sure how that compares to Wikipedia's general user load. Do you know if it was unique users or just straight hits (i.e. if one person/IP clicked 5 coords, would that count 5 times or just once)? I would like some more specific data if you could find any, since a big part of the coordinate question in my mind is whether the great investment of editorial effort that would have to be spent looking up these coords would even have any benefit to our users. Regarding my personal tendencies, I would be unlikely to click a coord link if the article already contained a map of the type that our articles already do because that would already answer my question of "Where is this feature located?". (Plus I'm probably the laziest editor around, clicking links is way too much effort for me. :P) I might be more likely to try it if it didn't have a map (supposing I was cognizant of the fact that I knew the link led to the Geohack page with maps, which I'm sure a good amount of users don't realize inherently—though an informal survey of a couple non-Wikipedians taken just now shows they tend to guess that it leads to Google Maps), but with the way our workflow tends to go in the roads projects, by the time an article would have gotten to the state that coordinates would have been added, a map would already be present. —Scott5114↗ [EXACT CHANGE ONLY] 02:55, 27 December 2011 (UTC)

And that's just dandy if you like the officially sanctioned map. Heaven forfend that we would want to give our users a choice in the matter. --Tagishsimon (talk) 03:02, 27 December 2011 (UTC)

Ours are accurate, which is more than can be said for Google Maps. :P —Scott5114↗ [EXACT CHANGE ONLY] 03:23, 27 December 2011 (UTC)

Google maps is one option. There are many others, including OpenStreetMap; and services ranging from nearby Flickr photos to weather forecasts and sunset times. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:16, 27 December 2011 (UTC)

Many of our articles do not include maps. Where such maps are shown they are not, unlike the output of {{Coord}} machine readable, and so are of no use to our mobile app, or other such tools. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:16, 27 December 2011 (UTC)

Many more of our articles do not include coordinates. It would take less effort to finish the mapping than to implement the coords. Unless I'm missing something {{Coord}} is no more machine readable than any other wiki code; it looks like it'd be a pain in the ass to write a parser for. —Scott5114↗ [EXACT CHANGE ONLY] 12:45, 27 December 2011 (UTC)

You're missing something. Please see {{Coord}}'s documentation for details. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:26, 27 December 2011 (UTC)

Already read it before posting that. Can you point it out for me? —Scott5114↗ [EXACT CHANGE ONLY] 22:46, 27 December 2011 (UTC)

Apologies; since I last visited, someone has removed some of the detail; but the template emits a Geo microformat). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:13, 27 December 2011 (UTC)

Quite all right, it's easy for pages to change out from under you like that :) Pretty neat trick, didn't know coord could do that. —Scott5114↗ [EXACT CHANGE ONLY] 03:54, 28 December 2011 (UTC)

• Question: What is a bounding circle? It's been mentioned a dozen-or-so times now, and not once has it been explained for those of us who don't know what it is. –Fredddie™ 17:46, 28 December 2011 (UTC)
  • Please see the documentation of {{Coord}}; specifically the dim attribute. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:23, 28 December 2011 (UTC)
    • Theoretically, if we were able to supply a set of coordinates for the starting and ending points of a road, and then use that for the title coordinates, we could use the coordinates to set the dimensions of the bounding circle for us. –Fredddie™ 18:58, 28 December 2011 (UTC)

Proposal for Geo members

According to this page, it is possible to create a "Get Directions" line which follows the road using as many coordinates as you want with the "daddr=" parameter and separating each coordinate with "+to:". Make coords work with this concept, and you've got a perfect platform for a single link showing you the entire road correctly and informatively. - ʄɭoʏɗiaɲ ^τ _¢ 14:19, 28 December 2011 (UTC)

Addressed in my comment below, time-stamped "17:35, 28 December 2011 (UTC)". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 28 December 2011 (UTC)

I would imagine it would be difficult to calculate statistics on this given that there are infinite combinations of coordinates, but are there numbers that say which services get the most traffic from the Geohack page? There are services that are shaded "most popular", could that change dynamically or did someone shade those for ease of finding? –Fredddie™ 20:29, 28 December 2011 (UTC)

There was some work done on this a while ago; you'd need to scan {{GeoTemplate}}'s talk-page archives; or ask there. The shading is not dynamic, but (AIUI) based on that work. Bear in mind that some services are location specific (UK only, or whatever). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:04, 28 December 2011 (UTC)

Request

Request for someone who supports coordinates Could you please select any road article that does not already have coordinates and give it title coordinates? Please list the article here and tell us how you selected the point you did and how you format the map that is eventually linked through Geohack. I think this exercise would bring some clarity of the process to a few of the editors on this page. Note, I cannot guarantee that once the coords are added that they will remain; however, I will not personally remove any added coordinates. –Fredddie™ 04:30, 27 December 2011 (UTC)

I have added a title coordinate to Bundesautobahn 61 and put some (but not all) coordinates on the junction list to show how you could add a list without too much extra clutter on the page. --Traveler100 (talk) 12:26, 27 December 2011 (UTC)

• I picked the start of the Autobahn where junction number 1 is, i.e. the North in this case. Personally I think the two most extreme points should be in the title.
  • Question - would there be any issue with adding two title coordinate templates to a page?
• Coordinate list is hidden and the small reference notes only work as links if the table is expanded.
• Have shown with degree minutes seconds and degree decimal formats in the list. Need to decide which looks better.

The title coordinates are on a train track, and at the very northernmost point of the autobahn... - ʄɭoʏɗiaɲ ^τ _¢ 15:23, 27 December 2011 (UTC)

The intention was to create an example, the point of wiki is for someone to start an article an other to improve on the content. --Traveler100 (talk) 16:23, 27 December 2011 (UTC)

Changed title point to mid(ish) point and added end of route coordinate reference into info box.

That's not a great example; the table violates WP:RJL. --Rschen7754 16:04, 27 December 2011 (UTC)

Could you improve the format so that it fits the guideline better. I think it would be useful to find a consensus by building and example. --Traveler100 (talk) 16:23, 27 December 2011 (UTC)

[ec] How so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:24, 27 December 2011 (UTC)

Perhaps a better question to ask is... how does it follow RJL? That would produce a shorter list. --Rschen7754 16:44, 27 December 2011 (UTC)

You're the one making the assertion; please substantiate it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 27 December 2011 (UTC)

On an iphone here; I'll let one of my colleagues get it. --Rschen7754 19:58, 27 December 2011 (UTC)

Looks like it's still up to you to do so (with reference to coordinates, if applicable, please)... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:45 am, Today (UTC−5)

Look inside the collapse box. --Rschen7754 23:15, 29 December 2011 (UTC)

Thank you. So, no issue with the coordinates, then. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:17, 30 December 2011 (UTC)

Hey maybe a few more of these eureka moments and you'll convince him to support your ideas... Oh wait - That's not how it works... stuff like this actually makes people resist you. - ʄɭoʏɗiaɲ ^τ _¢ 16:02, 30 December 2011 (UTC)

Discussion of WP:RJL compliance with no relevance to this RfC

I don't even know where to begin... It violates every part of WP:RJL, from the first sentence to the last. It also violates MOS:ICONS by having meaningless icons in a column which are meant to purvey some information to the reader not otherwise contained in text, MOS:TABLES by having no table headers and no legend, and WP:ACCESSIBILITY for both those reasons. Andy, these are the type of issues User:Tagishsimon has raised at WT:RJL#Table format: headings which you have supported; I don't see why you need this spelled out to you. - ʄɭoʏɗiaɲ τ ¢ 20:20, 27 December 2011 (UTC) "It violates every part of WP:RJL, from the first sentence to the last" That's not an answer; and as a statement is false. Your other points don't appear to relate to coordinates per se. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 27 December 2011 (UTC) Adding a header would make sense but I am unsure why the icons seem meaningless. Maybe it is a regional thing, anyone who drives in Europe would recognise the service and fuel station symbols and the interchange and exit symbols appear (at least to a European eyes) clear. If I did not also dive in the USA frequently I think I would have problems with some of the road symbols used on US articles. Take for example M-25 (Michigan highway), what are those black squares with white diamond in them or the blue and red shields (only making a point here, I know but many people will not)? On the Autobahn table if you click the icon you get a page with an explanation of the symbols. Although I do think a keys at the bottom of the table would be useful in both cases; remember most readers will not be aware of all the guideline pages that people have been quoting here.--Traveler100 (talk) 21:04, 27 December 2011 (UTC) Taking your reference to M-25, the "black squares with white diamond[s] in them" also have their explanatory text link next to them. In other words, the M-142 diamond marker has "M-142" next to it, and the text in the article already has introduced the abbreviation convention I-94=Interstate 94. Even so, if you hover the cursor over the abbreviated links, the full article name pops up. (M-25, etc isn't an abbreviation, of course.) The problem with many of the foreign uses of junction lists that will need to be resolved that the US and most of Canada has resolved is to make the marker a graphic with its text equivalent next to it, so the reader can gain the meaning either by the graphic or the the text. Your article doesn't explain the meaning of those icons at all in the article in anyway, meaning a reader unfamiliar with them has to leave the article to gain that understanding. Even our color coding is explained three ways in the M-25 article: the text notes, the color key at the bottom and popup/mouse-over text legends. Another issue is that when using stylized text for the links is that if the article is a redlink, it appears the same way as any others, and you lose the visual cue that the text is a link. Which is why WP:COLOR says: "Links should clearly be identifiable as a link to our readers." But all of that is an issue for compliance with MOS:RJL and other MOS sections. Imzadi 1979 → 21:52, 27 December 2011 (UTC) Please do not make the mistake others are making and make this personal or start to own articles. Please do not use phrase like your article, I picked this page as it did not have coordinates and an example , as requested above. In fact I have contributed to M-25 as much as A 61 in the past. And be careful about the use of the word foreign, it depends where you are sitting and I have always see Wikipedia organised by language not country. --Traveler100 (talk) 23:01, 27 December 2011 (UTC) I see a number of criticisms of examples and proposals but little constructive solutions. Could others maybe enhance the A 61 article in the direction of a good example, trying to take into account various peoples views listed here? --Traveler100 (talk) 23:05, 27 December 2011 (UTC) I would love to help work on the A61 article. –Fredddie™ 23:13, 27 December 2011 (UTC) I've been asked to provide specific guidance as to how Bundesautobahn 61 is not RJL-compliant. It is not RJL compliant or MOS compliant. "Geographic columns should be used to orient the location of a junction along the path of the roadway. " - where are they? "Mile or km: The measured location of the junction. If no source is available, and the road uses a distance-based exit numbering system, then this column may be left out in favor of the exit number column." - a source is available, Google Maps. Also, what the heck are the parentheses doing? What do they mean? "Notes: Any additional notes about the interchange or terminus, such as the design of an interchange, special circumstances such as missing ramps, concurrency termini, opening date, or additional locations that do not merit inclusion in "Destinations"." - the notes about the interchanges should go in this column, which isn't present. "To comply with MOS:ACCESS, and promote accessibility on the part of our readers who use assistive technology like screen readers, tables or the templates used to create tables should use: !scope=col|<column name> as the code to create column headers." - where's the column headers? What the heck do the icons mean? One shouldn't have to click on it to find out what it means. Accessibility violation. "Directional junctions should be formatted in the following pattern: "(route marker) (link to road article) (direction)"" - not done here "They should always appear at the beginning of the line, per Wikipedia:Manual of Style/Icons#Do not use icons in general article prose: "Icons should not be used in the article body...This breaks up the continuity of the text, distracting the reader." Use of marker images should be limited to the Destinations column(s) only." - so what are the icons doing at the end of the line? "There are two methods for displaying concurrencies. A simple note may be placed in the notes column for the interchanges where the concurrency begins and ends, or a multi-column row can be used to mark the termini of the concurrency. Ideally, this multi-column row should span the Destinations and Notes columns, allowing the milepost and exit number to appear to the left." - that clearly isn't done here. Why do the exit numbers suddenly jump? What does (incl.) mean? Also, the pictorial icons are pure decoration. Violates WP:MOSICON. {{legendRJL}} - "This conversion key is required on all tables unless both miles and kilometers are listed on the table." Where is that? Violations of WP:MOSITALICS here too. The whole entire purpose of WP:RJL is to standardize the appearance of all road junction tables across the site. RJL carries as much weight as the rest of the MOS, as it is a part of the MOS. It is to be followed as much as the rest of the MOS is followed. If anyone has a problem with this, they are welcome to start a RFC attempting to invalidate the guideline; if they're bold, they can send it to MFD. --Rschen7754 23:15, 29 December 2011 (UTC) In the interest of disclosure, BAB 61's junction list uses Category:Autobahn_infobox_templates. The German Wikipedia uses the same templates to create a collapsible junction list table in the infobox. –Fredddie™ 01:00, 30 December 2011 (UTC)

Question to Traveler100: How did you decide the title coordinates? –Fredddie™ 23:12, 27 December 2011 (UTC)

Using the coordinates of the two end points I opened in Google Map and looked roughly where the middle was. I initially though of a major interchange but decide that could confuse someone looking a this for the first time. There is however a major feature nearby (namely the viaduct) and took the co-ordinates from that article. Pigsonthewing then improved the coord entry by adding the dim entry. This I think is what is basically needed. If I come across an article about a linear object (road, cananl, path, ..) all I need is to get to the right part of the world in Google or Bing so that I can brows the route. It does not need to be anything mega exact. But this is quicker and easier than finding an article link on the page, going to that page and then clicking on its coordinates, or going to bing/google maps, typing in a location and trying to work out which of the many options is the correct one. --Traveler100 (talk) 08:11, 28 December 2011 (UTC)

What about when there is just a link in the External link section to Google Maps, with the route highlighted? - ʄɭoʏɗiaɲ ^τ _¢ 13:56, 28 December 2011 (UTC)

Yes that would be a good solution but when ever I have tried to link directly to Google Maps in an article it has been deleted. --Traveler100 (talk) 16:07, 28 December 2011 (UTC)

Per policy, I believe. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:35, 28 December 2011 (UTC)

Really?! Where does it say this? I ask because it seems odd that external links to Google Maps are verboten, while references using {{Google maps}} are fine. –Fredddie™ 17:42, 28 December 2011 (UTC)

WP:ELNO. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:20, 28 December 2011 (UTC)

Guideline, not policy, but that was exactly what I needed. Thanks. –Fredddie™ 18:50, 28 December 2011 (UTC)

Nothing there says no Google Maps. The closest thing, applied liberally, perhaps could (and I'm sure that is what Andy is leaning towards), but it clearly states "Links to sites already linked through Wikipedia sourcing tools". Unfortunately Wikipedia sourcing tools cannot produce a route line, so this is acceptable as an external link which "contain[s] further research that is accurate and on-topic, information that could not be added to the article for reasons such as copyright or amount of detail, or other meaningful, relevant content that is not suitable for inclusion in an article for reasons unrelated to its accuracy." - ʄɭoʏɗiaɲ ^τ _¢ 17:22, 29 December 2011 (UTC)

You've poured scorn on Google Maps, above, and doing as you now suggest would deprive our readers of easy links to other mapping an geolocation-relevant services; and would fail to emit the coordinates as machine-readable metadata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:35, 28 December 2011 (UTC)

Why can't it emit machine-readable and not human readable (ie hidden) metadata? Also, I've just chosen Google Maps as it is the number one online map service provider (at least according to Guinness)... I'm sure other providers have different methods to produce directions from A to B to C or could be requested to add the capability. - ʄɭoʏɗiaɲ ^τ _¢ 19:40, 28 December 2011 (UTC)

Wikipedia:SOPA initiative

In the event that a full blackout of the site occurs this Wednesday, the time that the RFC will be open will be extended by the time the site is locked from editing. I can't guarantee the RFC template will remain though as that's bot controlled. --Rschen7754 08:57, 16 January 2012 (UTC)

I'm extending the close date by one day as the site will be blacked out. --Rschen7754 03:08, 17 January 2012 (UTC)

Potential canvassing issue

Earlier today (January 17), Tagishsimon (talk · contribs) posted a link on approximately 100 editors' talk pages under the heading "Proposal to shut down WP Geographic Coordinates & ban coordinates on wikipedia articles". (See [11] for one example of these identical postings.) The link posted on each talk page was to Wikipedia talk:WikiProject Geographical coordinates#Proposal for the closure of this project, which contains non-neutral commentary urging project members to participate in this RfC. (The project had been notified of this RfC, in a neutral fashion, on December 26.) I'm posting this here because of the instructions at the head of the RfC that state "Please make sure that any crossposting to users, WikiProjects, and project noticeboards remains neutral and in compliance with WP:CANVASS. ... Any violations of this will be noted to the closing administrator." Imzadi 1979 → 15:23, 17 January 2012 (UTC)

Hi, I was canvased' in this way and I am shocked that what looks like two or three powerfull advocates for a counter intuitive argument seem to be trying to undo useful work and prevent others from presenting what the vast user base would seem sensible, ie a map giving the roads general location on it. I am glad I was canvassed, I am not a part of this project but they want toimpose on me and my Wikipedia a destructive new rule. Thought a discussion in an obscure corner of the system. Cosnahang (talk) 23:44, 19 January 2012 (UTC)

Continuation of discussion

(Replying to Excirial's comment above down here for clarity and so that people can actually read it) Yes, I think that tagging one coordinate for each road is a very bad idea. I also think that tagging every single road junction in a long list is also a bad idea. I think somewhere in between would be a worthwhile compromise. That's what I was trying to get at with P2, but people grabbed onto the arbitrary 10-15 limit and opposed. --Rschen7754 19:11, 19 January 2012 (UTC)

I don't think that visually storing coordinates right in the article body would be a good move, at least not with the current system. We would either get an overload of templates in this case, and even if we used another way to visually represent this data it would still leave us with a mess of coordinates in the article body - and i believe that would leave the article about as maintainable as any article with a huge wikitable with all the syntax you can squish into it. If we are going to do this it would have to be both reliable (Limiting ourselves on the amount of coordinates we use only hurts accuracy), and easy to use (Using a high amount of coordinates in the body makes things unreadable). Of course objective 1 seems to conflict with 2, so that would require alternatives.

As for that matter, have you ever played around with tracing paper, which you can overlay on something else to trace its content? What if we could create another layer over the wikiminiatlas map we use in article's already, that would allow people to draw onto it like tracing paper? That way we could trace lines by sketching them directly on the map, removing the necessity to search a boatload of individual coordinates for mapping. The widget itself could handle data storage, retrieval and display, which in turn would allow for much more complex data storage then templates could since we don't have to worry about template readability. At the same time we wouldn't have to deal with an article that is cluttered with coordinates and therefor would be completely unreadable.

This method would at first be incompatible with all the geohack atlases, but if we would remove coordinate templates otherwise we wouldn't give them any data otherwise, and we might just as well combine both methods we currently use, if this would be warranted. If we kept this system open it could - over time - grow large enough for other sites to support it. I have no idea if this is technically feasible with the current infrastructure, but perhaps it could be done with some effort. Excirial ^{(Contact me,Contribs)} 19:37, 19 January 2012 (UTC)

Look at proposal number 9 at WT:HWY - is this similar to what you've suggested? --Rschen7754 19:48, 19 January 2012 (UTC)

Yes, i just figured that it seems to be a variation of the proposal i was already supporting so i amended my previous comment with a pointer here for consideration (Copy and paste large pieces of text is generally not a good idea, after all). I think that the proposal is quite similar, and that my own writeup just seems to deal with the matter of practical implementation of it on Wikipedia, such as using the wikiminiatlas to create polygon files, and using it to load and store these data file in an unobtrusive way without the need for user intervention. I do not have extensive knowledge on Shapefiles, but i think the basic idea is more or less identical otherwise. Guess i just deemed it such a good idea that it stuck in the back of my mind, and sneaked to the front while i was writing the above text. :) Excirial ^{(Contact me,Contribs)} 19:57, 19 January 2012 (UTC)

(ec) Hmm, I see you've noticed it already... my bad. Proposal 9 is the most optimal and most supported solution at this point; the problem is that it involves elements beyond our control. So it seems that the question is what to do in the meantime, or if this isn't implementable. --Rschen7754 19:58, 19 January 2012 (UTC)

Meta:WikiMiniAtlas seems to state it is an open plugin developed by mediawiki itself. Searching on the mediawiki wiki it seems that user:dschwen is the one who made it (Or is at least knowledgeable of the topic, par this code review). It might be a good idea to contact him and ask his opinion on the feasibility of proposal 9 (He is active on en and commons), and it might equally be a good idea to ask for some opinions in either the wikimedia-tech IRC channel, or or the wikiteck-l mailing list, assuming that this proposal is the one that gains consensus, as it seems to be doing so at the moment.

If the change would be feasible and would be planned sometime in the future, it would leave us with the question what we should do with the current coordinates in the meantime. Personally i would propose leaving them in the article, or perhaps we could comment them out. Having a "starting point" as to where to work from should be convenient when using this feature. Actually leaving them in as is might be slightly advantageous, since it would keep them listed in the category of article's that already has some form of coordinates (Pending a future system). Excirial ^{(Contact me,Contribs)} 20:18, 19 January 2012 (UTC)

(edit conflict) I just had a look at the Mediawiki trunk, and i thought I'd share my findings. The plugin itself was developed back in 2007, and has not really been altered ever since, The only large contributer indeed being dschwen. The rest of the edits to the code are mainly maintenance for it. The tool itself seems to be split in a javascript front-end (Reading article coords, displaying the map et cetera), and a C++ backend which is used to generate the map tiles (I guess it simply splits a large map into smaller parts). I presume that, to get the proposal working, there would have to be some mechanism to create, upload and store the shape files, along with some routine that would make the data available to the javascript frontend which would take care of drawing it on the map (I guess it would need another layer on top of the loaded map parts to draw on though). My gamble is that this would be technically possible, but i am not the person to ask about c++, javascript and mediawiki integration. Excirial ^{(Contact me,Contribs)} 20:51, 19 January 2012 (UTC)

And we have a bit of a dichotomy here in terms of the highway articles: < 0.5% of the U.S. articles have coordinates. So it seems to me worthless to add them or mandate adding them in, if we're just going to ax the whole thing and replace it with a better system. However, I'd say a good 50% of the UK articles have them, if not more. --Rschen7754 20:33, 19 January 2012 (UTC)

"< 0.5% of the U.S. articles have coordinates. So it seems to me worthless to add them" There is no logic whatsoever, and no precedence on Wikipedia, in that comment. As for your repetition of your mandatory FUD, nobody is trying to make you or any other editor add coordinates. Just back off when others wish to. signing unsigned comment for User:Pigsonthewing by user:Excirial

(edit conflict) General consensus seems to be that we need to change the way we deal with linear features - the supports in proposal one seem to remark the flawed representation of geo coordinates, while the opposes seem to remark that coordinates are useful, so i think we can summarize that coordinates are useful if we can present them in a meaningful way. Perhaps we could just discourage adding coordinates to highways for the time being, seeing that this would be futile if the system would be replaced? Even if we could not replace the system it might be more worthwhile to tag other article's first; The backlog is large enough, and other coordinates might add more value to an article. Excirial ^{(Contact me,Contribs)} 20:51, 19 January 2012 (UTC)

(ec) If we're going to add them just to remove them, it is worthless, yes. "As for your repetition of your mandatory FUD, nobody is trying to make you or any other editor add coordinates." I could point to a few FACs that would disprove this. --Rschen7754 20:53, 19 January 2012 (UTC)

You could not; just as you failed the last time you tried to do so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:59, 19 January 2012 (UTC)

Because you wouldn't admit what you had done, as others repeatedly told you. --Rschen7754 21:04, 19 January 2012 (UTC)

You were lying then; and you're lying now. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:55, 19 January 2012 (UTC)

Either you are lying or I am lying. I'll post the FACs here and let others be the judge: Wikipedia:Featured article candidates/U.S. Route 2 in Michigan/archive1 Wikipedia:Featured article candidates/M-185 (Michigan highway)/archive1 --Rschen7754 22:18, 19 January 2012 (UTC)

"if we can present them in a meaningful way" - Please tell us what is not meaningful about the coordinates on, for example, M5 motorway (note that Rschen7754 says that this is "unworkable")?

"Perhaps we could just discourage adding coordinates to highways for the time being" - No. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:56, 19 January 2012 (UTC)

A large 1000 pixel table is in my eyes not the most optimal method of displaying a road - the wikiminimap just shows dots, and you have to click multiple geolocations to get an idea of the roads approximate whereabouts. It would be more convenient to have a visual representation of the exact same data the table has. For example, a map with a drawn road and "points of interest" (The junctions) that would show the table's row data for that junction once you hover over it. It would contain the exact same data, in a more convenient format.

On a similar matter i like to note that most of your comments are rather combative towards other ideas, without offering any suggestions of their own. If you believe the current situation is the ideal situation which doesn't require change that is fine of course, but without a "no, because" there is little i can do with a comment. And to be entirely fair - if all that is added is a "no" i generally don't care about a comment either since it holds no value discussion-wise. Excirial ^{(Contact me,Contribs)} 21:15, 19 January 2012 (UTC)

Given the complexity a road could have and the number of points, would having this info in a file, trx, gpx or whatever format, and putting that on commons just like where images are kept, would that potentially be a way. Opening this file with a mapping site could display the route. DubhEire (talk) 20:55, 19 January 2012 (UTC)

While you could in theory do that, it would not be an argument for removing coordinates from articles like M5 motorway or prohibiting their addition to others. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:01, 19 January 2012 (UTC)

Because...? --Rschen7754 21:04, 19 January 2012 (UTC)

Because...? (Echo!). Also see my comment somewhat higher up on how we could perhaps incorporate the same data the table holds in the wikiminimap. Excirial ^{(Contact me,Contribs)} 21:18, 19 January 2012 (UTC)

Because it wouldn't provide the same service to our readers, nor the same functionality. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:55, 19 January 2012 (UTC)

You've got to define your terms here; what do you mean by "functionality"? Vague assertions won't cut it here. --Rschen7754 22:12, 19 January 2012 (UTC)

If the suggested shapefile from proposal 9 is indeed some form of standard, we could just use it ourselves (For the in-wiki) map, while also giving a download link to the source file so that people could download it as well. Since i presume the file needs to be saved and loaded per-article anyway it may actually be as easy as adding a link to save it. Excirial ^{(Contact me,Contribs)} 21:23, 19 January 2012 (UTC)

Does anyone have any examples to go with the proposals? Does it take into account easy or hard to build/put together/edit? Browser and maps compatibilty is brought out in the discussions, but the other thing is, I find it hard to see examples of articles that have coords other than the M11 motorway one. So, this M11 is interesting, but it does mean I have to click out 2 pages to view each one, which is very tedious. So how does one view them all on one map and possibly with the information that is from the article? Shows me that this article has taken the coords yes, but doesn't reach the full potential that geotagging could bring and the level of information one could get. Looking at the original template, there is some attempt to bring this together with grouping and I see the example of List of rapids of the Columbia River. So this shows that the problem persists not just for highways, but to rivers, borders and any other linear thing. If you let you imagination think beyond this again, and think large historic sites, you get another way of using geo coords grouped to show the intersting spots around the site, e.g. Pompeii.

Just a flow of thought. I was trying to find where the problem was and see if what is currently there is useable. The current guide lines does say that coords can be used for roads. And grouping has limits. Hopefully, I'm a lot clearer now.

My own conclusion is that coords will not be the best solution, but it can give basic geo location, i.e. start, middle, end of road. Enhanced with GeoGroup it can be better, showing each junction, or major junctions. But when you are reading an article and what to view it on a map, what does either of these really bring? If there is a chance to move to the next level of geo tagging, I'm all for it. In the meantime, let's think about the reader and keep it simple. DubhEire (talk) 22:46, 19 January 2012 (UTC)

Unfortunately, we can't get a shapefile working at this time because it would require technology we don't have right now. I can take a look and see if I can find an article with (at least to me) an appropriate amount of coords and in a decent style. --Rschen7754 23:23, 19 January 2012 (UTC)

Template:shc

One of the developments in my early experimentations with coords (my personal issue is the repetitive string of blue linked numbers that add little to the article itself when they can be obtained on the geohack page for the minority that prefer that method of geolocation) was a template that simply displays a globe icon that links to a geohack page identically to {{coord}}, but without the latitude and longitude following that globe icon. Personally I feel the globe icon is not intuitive (for both {{shc}} as well as its current use with {{coord}}), but that a better icon would make the purpose clear. I would not object to another column in the exit list where editors could feel free to add coordinates, subject to whatever limitations on upper limit there are. As far as I am aware, there were several other editors who supported the concept of this template and so moving forward I'd imagine would support trying to develop this further. - ʄɭoʏɗiaɲ ^τ _¢ 19:25, 19 January 2012 (UTC)

{{shc}} has significant accessibility problems, it should not be in us anywhere on Wikipedia. I have no care if the globe icon is removed from {{coord}}; but note that logged-in users can disable it in their personal settings. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:50, 19 January 2012 (UTC)

I said improve it, not use it as is. If you actually read what I said, you'd have seen that; but, you saw the potential of not using {{coord}} and grabbed onto that. - ʄɭoʏɗiaɲ ^τ _¢ 21:49, 19 January 2012 (UTC)

possible SVG proposal

I don't know but perhaps taking the map and drawning the road route using SVG onto the map and just producing the coordinate that the person arbitrarily picks to start the svg plot from might work ? EdwardLane (talk) 14:12, 27 December 2011 (UTC)

Well, that has the difficulties of 1) being arbitrary and 2) SVG mapping is difficult right now because the only free GIS software out there (Quantum GIS) doesn't really produce very good SVG output. —Scott5114↗ [EXACT CHANGE ONLY] 14:54, 27 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)