Jump to content

Wikipedia talk:WikiProject Highways/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6→Archive 10

RFC on coordinates in highway articles

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The consensus of this RfC is section 9 to use shapefile software to illustrate the the area of highway mentioned in the article. Although I did not find that the canvassing to be detrimental to the RfC, I did find it disruptive to this RfC and do not support the use of such methods (since around 130 talkpages were canvassed in the sweep on the 17th). -- DQ (ʞlɐʇ) 18:39, 4 February 2012 (UTC)
Closing admins notes + section continued below. -- DQ (ʞlɐʇ) 15:50, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.
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

This statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 18:39, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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 editsreview 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 {{GR|1}} 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?[1] 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)
    {{Coord}} is currently an accessibility violation for its unintuitive icon that brings up a map. Bazonka, as I've stated before, the coord data would not be gone, it is still available at the geohack page, right at the top, when you choose which mapping service to display. - ʄɭoʏɗiaɲ τ ¢ 14:54, 20 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. SpencerT♦C 13:05, 17 January 2012 (UTC)
    This vote has been canvassed: [2] --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: [3] --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: [4] --Rschen7754 19:27, 17 January 2012 (UTC)
    I don't know if I am expected to respond -but as it is Saturday. There was a technique in local government where officers would respond to a request for public consultation- by holding one in a village hall 30km from the city away from a bus route- on a weekday when everyone was working, and widely advertise it house to house in village 20km away. Obviously the result was meaningless, but it remained on the books and blocked any further progress on the project. If anyone else tried to advertise the meeting it was regarded as canvassing. Wasn't it Douglas Adams who announce a consultation on the destruction of the earth on one library notice board on an uninhabited planet on a unnamed star in Ursa Major? --ClemRutter (talk) 12:34, 21 January 2012 (UTC)
    Notice was given to WP:Wikiproject Geographic coordinates, and notice was posted on WP:CENT. It is a textbook case of vote-stacking to solicit specific editors with an inflammatory notice on their talk pages that directly or indirectly tells them to participate in a RfC. There was no attempt to obfuscate the existence of the RfC; on the contrary, all of the directly affected WikiProjects were notified. In the end, it is for the closing admin to weigh the impact of Tagishsimon's actions to spam the notice to 100 editor's talk pages on the results of this RfC. Imzadi 1979 → 13:28, 21 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. SilverserenC 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: [5] --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: [6] --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: [7] --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)
  43. oppose see Pam above and others. I want a clear map in the article but I also want the facility to go to google earth and trace it out, see the location etc. also remember it goes the other way as Wikipedia articles are visible on google earth. Cosnahang (talk) 23:53, 19 January 2012 (UTC) PS I was 'canvased' ( see below) but wasn't everyone alerted to any discussion in some way?
    • Maybe this is totally going over my head, but I think there is a clear difference between "We request your comments on a discussion going on about a topic you are interested in at Location X" and "Oh my god! They are going to destroy our project and ban everything! If you know what is good for you, get over to Location X right now and stop this existential threat! Not later today, you lazy fool, right now! Yes, this means you! Do it, or I will beat you up!"  VC  13:13, 20 January 2012 (UTC)
  44. Oppose. Sorry, but this is a bad proposal. The use of No original research wreaks of a wikilawyering attempt. You are doing no service to the readers with this little crusade against coordinates. I understand that not everybody likes them from an aesthetical point of view, but they are useful. We have tools and infrastructure to process and display coordinates, and they are helpful. --Dschwen 20:35, 20 January 2012 (UTC)
    Not for a 1000 mile highway though, as they are falsely representing it or cherry picking specific points along it for inclusion. You are picking a single leaf from the tree, as the original research argument was one of many. - ʄɭoʏɗiaɲ τ ¢ 20:37, 20 January 2012 (UTC)
    Well, you other points are all pretty much rubbish as well. Consistency, nonsense, should we have deleted Wikipedia a few years back when we didn't have an article on every subject? Lack of reliable source, nonsense, there are plenty of sources, calling them unreliable doesnt mak it true. If OSM is "unreliable" so is Wikipedia. Is satellite data unreliable? What about driving the road with a GPS. Your point are all weak at best and fabricated. --Dschwen 21:37, 20 January 2012 (UTC)
    Actually, an article can't use user-generated content as a source. You can't cite the French Wikipedia article on Paris for a fact listed in the English Wikipedia, which is why you can't cite OSM as a source for information. Policy requires us to use reliable sources, and other wikis are excluded from that definition, by policy. Driving a road with a GPS fails policy because it's not verifiable to a published source; we don't allow a wikipedian to personally measure any data on his or her own. The data used in any article must come from a published source. Imzadi 1979 → 13:35, 21 January 2012 (UTC)
  45. Support I often find myself scratching my head when trying to figure out what coords to use on roads. TiMike (talk) 03:32, 21 January 2012 (UTC)
    And because you don't understand it nobody should add coordinates? *Scratches head* --Dschwen 19:56, 23 January 2012 (UTC)
  46. oppose --Guerillero | My Talk 19:53, 23 January 2012 (UTC)
  47. Oppose because there needs to be transition. A support of this would suggest the removal of coords from all articles once passed. I think the solution is to use common sense in the meantime until a more suitable way is found for the future. DubhEire (talk) 21:38, 23 January 2012 (UTC)
  48. Support a point is not a line. Roads are not straight lines, so even two points wouldn't cover it (point-to-Point). Marking the central point of a road is silly and not very encyclopedic as it doesn't really offer much to readers. Haljackey (talk) 07:12, 26 January 2012 (UTC)

Proposal 2: limited use of coordinates

This statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 17:56, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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)
  17. Oppose: Arbitrary limit for no good reason. --Tagishsimon (talk) 02:43, 20 January 2012 (UTC)
  18. Oppose. What is the point of this limit? Other than a shallow it looks ugly? What is that cost to you? Why do you feel the need for such an invasive proposal that restricts the useful work that other people are doing for our readers? This is bordering on absurdity! --Dschwen 20:37, 20 January 2012 (UTC)

Proposal 3: Start and end points of highway only

This statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 17:59, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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)
    I agree that additional data shouldn't be deleted, but the basic idea of giving locators for the endpoints, as a starting point for the description of a road, seems to make sense. Dadge (talk) 15:07, 20 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)
  18. Oppose proposal, support start & end in infobox: Start and end in infobox should not be the only way. Coords in a road junction list yield useful functionality through {{GeoGroup}}. NO good reason to lose that functionality. --Tagishsimon (talk) 02:45, 20 January 2012 (UTC)
  19. Oppose. Agree with Tagishsimon. Again a useless restriction that is taking away value from our readers. --Dschwen 20:38, 20 January 2012 (UTC)
  20. Oppose. TiMike (talk) 03:38, 21 January 2012 (UTC)
  21. Oppose Roads are not straight lines, so even two points wouldn't cover it (point-to-Point). Haljackey (talk) 07:15, 26 January 2012 (UTC)

Proposal 4: Route Table

This statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 18:02, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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 [8] 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)
  13. Weak Support with caveats Having read the proposal two or three times, I'm not exactly sure my understanding is as the OPs. To the extent that it's talking about coordinates in road junction lists, that seems a good thing. I'd happily collapse RJLs by default. I don't think I'd go out of my way to try to hide (collapse sideways) a coord column, even assuming that can be done. I'd want to see a coord for each row on the basis that if there is a feature deserving of being noted in the table then it warrants a coord. --Tagishsimon (talk) 02:52, 20 January 2012 (UTC)
  14. Oppose. While this sounds like a good comprominse it is actually a step in the wrong direction. Now you are duplicating data, you are taking the coordinates out of context. This is making coordinates and the articles less useful for the reader. Now, if we had the code to collapse a column in a table then we might have a solution! --Dschwen 20:40, 20 January 2012 (UTC)
  15. Oppose. TiMike (talk) 03:40, 21 January 2012 (UTC)
  16. Weak Oppose I do see the interest in marking specific points, but I think it will add unneeded bulk to articles that very few readers will actually use. Haljackey (talk) 07:17, 26 January 2012 (UTC)

Proposal 5: Status Quo

This statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 18:12, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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)
  12. Comment It would be ideal to end the wrangling, and so I kinda hope this is not the outcome. Clearly, as a partisan, this is a better outcome than, for instance Proposal 1. What I would wish for is a less prescriptive approach all round. I think we should offer / support / tolerate a number of different approaches, including single mid-point coords in the title line, start & end coords in infoboxes, coords in RJLs. No one or pair of these excludes the others. None are so wrong that they should be hunted down and removed, as currently they are. --Tagishsimon (talk) 02:58, 20 January 2012 (UTC)
  13. Neutral. The current situation is apparently not satisfactory. If we could keep the status quo minus the fighting and bickering it would be ok. I don't get it, some people put in a lot of effort to enrich articles with useful information and some people are fighting to destroy that work for no good reason. --Dschwen 20:43, 20 January 2012 (UTC)
  14. Oppose Something needs to change, simple as that. Haljackey (talk) 07:19, 26 January 2012 (UTC)

Proposal 6: Strengthen use of coordinates in MoS

This statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 18:14, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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)
  2. 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)
    3. 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)
  3. 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)
  4. 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)
  5. Oppose per Scott5114. –Fredddie™ 17:21, 28 December 2011 (UTC)
  6. 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)
  7. 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)
  8. 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)
  9. 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)
  10. 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)
  11. Support with comments In exactly the same way that WP:RJL is part of the MoS, it would be ideal if advice for geo-coording highways had the same status and really really really odd if after months of this haggling and an RfC we didn't get that outcome. I would want to MoS to offer the three options of title coord, start & end coord in infobox, and coords in RJL and leave it to a case by case basis as to which are used. --Tagishsimon (talk) 03:09, 20 January 2012 (UTC)
  12. Support. Some of the comments here sound like they are from another planet. Sorry, I don't mean that in a derogatory way, but there are clearly worlds between us. As a geospatial data enthusiast this sounds like a good idea to me. The concept of a bounding circle and its purpose are apparently not clear to everyone here. Why would it be useless if it were an entire state? Guys, the world extends beyond state boundaries, even beyond country boundaries ;-). You will never see the bounding circle on the map, it only determines the zoom. What you would see are points of interes on the road (endpoints, junctions, etc.), which of course will make the trace of the road very apparent. Just take a look at M11 motorway and open the WikiMiniAtlas. All junctions are shown as blue dots, indicating the extent and position of the entire road. --Dschwen 20:49, 20 January 2012 (UTC)
  13. Oppose If the route was perfectly straight I could possibly see encyclopedic value to this proposal, but that just isn't so in the real world. They aren't transit lines. Haljackey (talk) 07:21, 26 January 2012 (UTC)

Proposal 7: Minimalistic entry in existing junction table

This statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 18:39, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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)
  10. Weak support: Better option than no / arbitrary partial lists of cords, worse option than plain old {{coord}}. Should be one of three options though, with coords in infoboxes and title coords supported. --Tagishsimon (talk) 03:12, 20 January 2012 (UTC) --
  11. Neutral. Icon is a crap idea, minimal text is ok. I could make the WikiMiniAtlas icon appear on hovering only to make it even more minimalistic. But the coordinates should be in the table. Reflist is a bad solution. --Dschwen 20:51, 20 January 2012 (UTC)
  12. Support. For the meantime until we have a better way, long highways that have significant junctions should only have coords or preferably GeoGroup Coords for major junctions. DubhEire (talk) 21:44, 23 January 2012 (UTC)
  13. Neutral On the fence with this one. While I see the use of marking these, I do feel that they will just bulk up the articles with information only few will use. Haljackey (talk) 07:23, 26 January 2012 (UTC)

Proposal 8: (Live and let live)

Good Ignore all rules spirit, but this statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 18:21, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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

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

Consensus collapsed for readability. -- DQ (ʞlɐʇ) 18:39, 4 February 2012 (UTC)
  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)
    What benefits? What readers? Do you have any evidence of either? I want them hidden to the readers of the article I've written unless they have specified to override that and display coordinate no matter what, as they clutter the display of actually useful and informative information in the context of the article. - ʄɭoʏɗiaɲ τ ¢ 21:02, 22 January 2012 (UTC)
    "I want them hidden to the readers of the article I've written" You give every indication of not understanding what Wikipedia is about. Please try to understand WP:5P; especially WP:OWN. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:39, 22 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)
  21. Conditional Support as a student sitting in intermediate GIS. Just remember that .shp files are an ESRI proprietary format and are extremely complex. A shape file uses an interlocking group of 3-8 individual files. I would recommend that we utilize file geodatabases because they are easier to download/transfer and are less proprietary. --Guerillero | My Talk 19:18, 23 January 2012 (UTC)
    Maybe your curriculum hasn't gotten to KML files yet ;-)... But those would be a good alternative. I imagine nobody actually had .shp files in mind when they commented in this proposal (correct me if I'm wrong). --Dschwen 20:01, 23 January 2012 (UTC)
    pfff....Google earth was day one lesson one :-) KMLs would be a great option that skipped my mind. It is the preferred format of the Open Geospatial Consortium and is creatable in any text editor. It is actually easier to create them via text then to use ArcMap or GRASS to make them. The only reason I jumped to geodatabases is because I spent the previous hour reviewing why shapefiles are evil in class. --Guerillero | My Talk 23:01, 23 January 2012 (UTC)
    I, for one, was thinking exactly of .shp files. I think that goes for anyone from the roads projects who have made maps, but I'm not 100% sure on that. If there is an easier way, we're all ears. :) –Fredddie™ 23:34, 23 January 2012 (UTC)
  22. Support but I'm not 100 percent convinced that shapefiles are the way to go. The GeoPolygon looks interesting, but I think the future should be something that is not so complicated to create/edit that it precludes so many editors. DubhEire (talk) 21:40, 23 January 2012 (UTC)
  23. Unconditional support - Just before getting down to this section, I was actually thinking to myself how ideal something like this would be as a solution. I wasn't too sure what all it would entail on the technical level, but we've got a very good starting point outlined here.   — C M B J   04:49, 24 January 2012 (UTC)
  24. Support Seems fine to me. Haljackey (talk) 07:28, 26 January 2012 (UTC)
  25. Support as supplement only. A shapefile would be an excellent addition to a linear feature article. However it does not support a key user requirement for me, which is to click through to a map and see that bit of the road I'm interested in. I'm interested in Junction 48 of the A1(M), for instance. I want a way in which I can click through and be drawn to Junction 48 of the A1(M). I don't particularly want to be shown the whole of the A1(M) and left to figure out where J48 is. Right now I get the impression that the shapefile solution is seen mostly as an effective way of sweeping all this coordinate nonsense away into a single tidy link. A single tidy link does not deliver to the class of user that has an interest in being directed to a specific node - a junction, most probably - of a road. In my imagination, interest in a specific junction will tend to be one of the more prevalent use modes: I'm going to Nottingham and want to look at a map of the Nottingham junction. A shapefile is a poor solution for this use case. Wikipedia should be about admitting to and providing solutions for credible use cases, and on its own, the shapefile does not do this.
    Providing information is what we're here to do, of course, but is this really a use case most people would even consider using Wikipedia for? I would wager a rather grand sum of cash that pretty much anyone that wanted to look for a map of a particular junction would simply go directly to their favorite mapping service and just search for "junction 48 nottingham" (and if that didn't work just search for "nottingham" and find j48 manually) and never even think to go to Wikipedia for that sort of information. I mean, if they're going to end up on Google Maps (Bing) eventually anyway, why not just cut out the middleman and use the search feature there? Again, "all the world's information" is our billing, but WP:NOT exists for a reason. —Scott5114↗ [EXACT CHANGE ONLY] 21:37, 26 January 2012 (UTC)
    Consider, for example, the scenario where a reader is told something about a junction (or service station, bridge, or other feature) and thinks "I wonder which one that is - I need to see it on a map". Also, not every map (some people don't use Google maps) makes each junction or other feature searchable by name/ number. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:47, 26 January 2012 (UTC)
    I'm a user of that use case. I tend to doubt I'm the only one amongst our millions of users. I hazard the proposition that there are three classes of users w.r.t. maps linked from roads: those with no interest at all; those interested in seeing the whole road a la shapefile; and those interested is a specific point on the road. I don't think it takes to much good will to wish to support that third camp. --Tagishsimon (talk) 21:57, 26 January 2012 (UTC)
    Well, Proposal 7 would go some way to support that and the outcome of that proposal was Support. So it would appear that there is some scope there to have coords for junctions. But looking at the voting, it was not strongly supported for some reason. DubhEire (talk) 22:45, 26 January 2012 (UTC)
    It doesn't take much good will, no. However, how can we support the users that want to do that without filling tables that are already criticized for being an overload of data with even more - that being the DMS coordinates. The DMS coordinates are not necessary to accomplish what you want to do; a link to geohack where users can choose their preferred mapping service should suffice. - ʄɭoʏɗiaɲ τ ¢ 22:52, 26 January 2012 (UTC)
    Yep. I don't think the DMS adds anything to this List of National Monuments in County Dublin, but if it could be shortened to something less intrusive, but equally clickable, it would be much more presentable. The GeoGroup at the top of the page gives me a great way of looking at everything on a map. Now if I could use a definied KML I could put a link back to the actual article and perhaps the photo for each tag on the map rather than it just being a basic point one the map linked back to the one original article. Take a look what someone did here Megalithic Ireland I'm hoping there are further uses to these discussions. Then I can go about the Irish rivers and roads. DubhEire (talk) 23:14, 26 January 2012 (UTC)

Proposal 10: Coordinate clutter

This statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 15:18, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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 ([9]).
    • 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.
      • Yeas really! What kind of argument is this? Volunteers have already created an encyclopedia with millions of entries, and you are saying a measly 10000 articles are unsurmountable? Ridiculous. --Dschwen 21:06, 20 January 2012 (UTC)
  • 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: [citation needed]. 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.
  • 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)
  • 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)
  • 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)
  • 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)
  • Sorry, I was reading from bottom to top; hadn't looked at 9. So I'd be right in thinking that it's ownly any use if I have a GIS system to put it into. Umm. I don't think I do. I want to be able to click on a link or two and wind up at google or bing or acme. Do we really have time and space for me to respond to each of the points in your proposal? Is there really any point? I can give a sincere and probably differing opinion for many of the 25 or so main bullet points. Suffice to say for this proposal, I'd love a shapefile, even though I don't have a GIS, because I'm confident that other users will have GIS and will find it useful. But I cannot support a shapefile as a substitute for coords in the article. But since it's you, I'll respond to each & every point below.
  • Okay, thanks, I've now grokked that. What about this use case: I want to see a particular junction I happen to be interested in, on a map. I'm understanding the shapefile to be all points which'll highlight the whole road (which is great). But will it highlight the junction I'm interested in. (i.e. I'm wanting to use the coord function not the geogrouptemplate function.) I continue to support having a shapefile, but I have yet to give up on the coords. I'm open to convincing. --Tagishsimon (talk) 00:31, 20 January 2012 (UTC)
tagish simon comments on Rschen's other points, at Rschen's request
  • 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.
    • Hard cases make bad law. I'm not ducking the fact that there may well be a fatal problem with 400 coords in an article, I just don't happen offhand to know the limit. But most of our articles are not of that length. I'm well in favour of other arrangements for the more lengthy lists, including (what I think is one of your favoured approaches) selectively coording them. But I would select only when there is a hard technical constraint.
  • {{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).
    • Yup, the Bing limit is not good, but it is out of our control; and each of the individual coords remains useful. I don't keep hearing more and more people complaining about google map inaccuracies - at least not with respect to the validity of its coord handling. I"ve only heard one remark recently on the geocoord project talk page which suggested that google was thought to be more reliable than others. Give me facts; I'm not buying uncited assertions from you.
      • No, it's the maps themselves that are wrong. I can provide examples of errors, but I assume you don't want that. Plus whatever happened to wanting to locate a route on any sort of map you want? Tagging every junction will get you the western half only on Bing! --Rschen7754 00:41, 20 January 2012 (UTC)
  • No, it'll also allow me to pick out each junction on a one by one basis. I've already agreed that the geogroup would fail.
  • Does each ramp get a geotag, even if they're 1/8 of a mile apart or less? Is this helpful at all?
  • No, it's in scope. I'm saying that the decision is not whether a junction gets a coord, but whether the junction is or is not in the list. If it is, it gets a coord. This works for, I submit, the vast majority of articles. I grant, and grant again, that the 300 & 400+ articles are concern. Just as you want to emphasise the problems with the very large articles, I want to emphasise the lack of problems with what I claim to be the much larger set of not-large-enough-to-be-a-problem articles. That it is the vastly larger set is based on my supposition, btw.
  • 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.
  • Then why are they in the table. You get the pattern as I see it: is it is in, it gets a tag. I'm favouring a two state solution: in with a tag, or not in. You a three state solution in which you add the option 'in without a tag'. That just makes tables look ragged.
Not if the coordinate footing is unobtrusive, and doesn't take up a separate column. In M62 motorway, you barely notice that the coordinates are only for certain exits. --Rschen7754 07:52, 20 January 2012 (UTC)
  • 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.
  • We have hours. We've done about 715,000 coords so far, and we're not tired.
  • I'll take your word on the figures. Multiple two views per month per coord tag times number of coord tags times number of article (as it were) and if that figure does not lead to less than hundreds of thousands of satisfied people per annum, I'll eat a chocolate bar I have handy for the occasion.
  • But are the sets disjoint? That's another assumption that I made that will fall apart quickly. And you can't multiply two views per month; the reason I gave the other examples was to show that not every highway article is as popular as I-10 TX. 2 views a month is a maximum, not an average. --Rschen7754 00:41, 20 January 2012 (UTC)
    • 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.
  • You should start by explaining the need to lose these coord tags. But I agree with clickthroughs will be lumpy, yes.
    • 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]).
  • Coords certainly are not of use to most users, most of the time. But the numbers of articles & junctions & users & days means inevitably that we end up satisfying a very great many people. That's a good thing, yes?
  • Try to have only a single stab at figures. If you disagree with yourself, go basck and edit the first set of figures. In all other respects, continue to see my comments above.
  • As above
  • Sea of blue clutter, if not done properly.
  • One person's clutter...do it properly. I have no objection to a tabular list of coords.
  • It dissociates the coord from the context. It's not a good user interface. If I want to see the map for Junction 25, it is more easy by far to click on a coord found on the same row as it is to have to find map 12. I've played on the District line, and it is a poor way of doing things. Besides, it adds to the length of the article for no good reason.
  • People with screen readers beware.
  • I'd like to do more digging here. I'd have thought contemporary screenreaders would provide means by which users can skip cells, columns or rows in tables, but I don't have one to hand. Equally, beware anyone with a screenreader going through the existing 396 row, n column table, non?
  • Readers can get a good sense of where the road goes from ~10-20 coordinates; the extra detail isn't too helpful.
  • Value judgement. IIRC, M25's geogrouptemplate view is crap just now that it's been cut down from all to a very few. I'll assert that extra detail may not be too helpful, but may be helpful, and conversely, is not unhelpful.
  • That only has one. Which isn't good. I'll save you the trouble and point to M62 motorway; I think that's a good and responsible solution; just enough info without clutter in the article or on the map. (Not necessarily talking about the style here; just the number of tags and where they are.) --Rschen7754 07:52, 20 January 2012 (UTC)
  • Sometimes the placement of coordinates on junctions makes the resulting route more inaccurate than if the coordinates were placed in more geometrically strategic locations.
  • I'll bite. How does it do this.
  • 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.
  • I don't like your map. It does not do what I want it to do.
  • Notability; is a road junction's coordinates that noteworthy? For a major junction, yes. Otherwise, no.
  • When why is the junction in the RJL. Meanwhile for UK roads, I can point to publications which provide separate detail of each and every UK motorway junction, which to me signifies notability in the normal WP:N WP:RS WP:V kind of a way.
  • Nope. You can't raise the issue, read a rebuttal and then decide the topic you introduced is out of scope. Well, you can, but you probably shoudn't.
  • 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.
  • I guess it depends on what the starting zoom is. Even with sparse coording, you can still get this if you select the right zoom.
  • Yup. I do appreciate that, now, more than I have appreciated it before. But I'd like to see, empirically, how bad (or not) the output looks in google or bing. And I'd keep in mind that it would continue to be useful when you zoom in, whereas the sparse version would get to a level of zoom at which the markers disappear, sooner than an example with a complete set of markers. So it's somewhat horses for courses.
  • You can get a vague sense of what it would look like by going to the Highway Browser at Cmap. To me, it's super annoying as the exit numbers tell me nothing, and don't zoom to the spot, either. --Rschen7754 08:09, 20 January 2012 (UTC)
  • 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.
  • Realistically, the number of articles you submit to GA and FA is small enough that they could be knocked off fairly quickly by geocoders as they pop up. I don't underestimate the backlog work; you have about 660 or so articles at GA or above. There is a lot of work to add coords to these. But far from insurmountable, especially if you embrace the geocoord project. Is this at the heart of your concerns - that you'll lose all your FAs & GAs? Is that more important that providing content that your maths, above, suggests many users will make use of?
  • You've seen my argument in a couple of FA discussions. You know I think that an absence of coords is not the best that we can do, and on that basis we should not feature. If a shapefile became the agreed standard then guess what: I would expect each article to have a complete shapefile to quality for FA. I think the marginal rate of submission to GA & FA is well within the capability of interested parties to coord. There really are a lot of people on wikipedia who add coords and I really do think that a system of asking for help in adding coords for CA & FA submissions could be implemented and is likely to get a good response, much in the way the copywrite guild does for copywriting. Obviously this is speculation, but really: do not underestimate the number of coords which can be provided by wikipedians; especially RJL coords, which tend to be very easy to find.
  • Counterargument: But this means banning all coordinates from road articles!
    • Rebuttal: No, it does not.
  • Good. As I think I said elsewhere, happy to have shapefiles, but not as substitues.
  • 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.
  • And I think you;ve established that there is a subset of readers who will click on the links if they are there. That suggests you concede there is demand from some editors for coords. So if wikipedia is for the reader, why is the solution to fail to give the reader what she wants? It would be easier to remove all stubs from wikipedia than get the to FA. What sort of an argument is that?
  • Counterargument: But it is our duty as Wikipedia to provide this info!!!
    • Rebuttal: [citation needed]. We're not an atlas or gazeteer; we're an encyclopedia.
  • As notes, we are a gazetteer. But you're still in denial a bout what it means to be a gazetteer
  • Counterargument: WP:NOTPAPER!
    • Rebuttal: WP:NOT an indiscriminate collection of information.
  • A tabulated list of coords in an RJL is the very model of a discriminate collection of information. (This presupposes you have a clue that the words indicriminate and discriminate mean.)
  • Counterargument: Okay, so 5-10 clickthroughs for coordinates; net positive.
  • We're not asking you to do the work. We're asking you not to stop us doing the work. FFS.
  • Counterargument: Wikipedia is not for the editor; it's for the reader.
    • Correct; but, that doesn't mean compromise everything; for example, notability.
  • Dealt with above. If it is not notable, why is it in the RJL
  • A shapefile is essentially analogous to an XML file in that its database. It's made of many many coordinates, and so theoretically it could be possible to isolate an individual coordinate from the group. The big benefit here is not cluttering the article with coordinates while still supplying access to them. - ʄɭoʏɗiaɲ τ ¢ 01:45, 20 January 2012 (UTC)
  • If we can get something which is functionally equivalent (or better, but not worse) than coords & geogroup, then I'm totally persuadable and most likely to give that my support. I'm not wedded to the current implementation. You and I don't agree on the question of whether coords are or are not clutter; but equally I'm not sure I see an absolute necessity for the coord to be displayed in DMS or decimal on the table row. I can see arguments for such placement. I'm not persuaded by clutter arguments against. But I'm probably not going to go to the wall defending them. Whilst we're here, a quick steer: does proposal 10 vary in a material way from proposal 9? It's very nice hanging out here, but it does feel like shapefile proposals have forked for reasons I'm unsure of. --Tagishsimon (talk) 02:39, 20 January 2012 (UTC)
  • "This proposal is not intended to be complete; it's supposed to be more or less a statement." Basically, this is a statement against the tagging of all the junctions on large junction lists. The actual solution could be selective tagging; it could be shapefiles; it could be no tagging. P10 doesn't say. --Rschen7754 08:02, 20 January 2012 (UTC)

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

This statement is not found to be a consensus of the community at this time. -- DQ (ʞlɐʇ) 18:39, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

Whatever else we agree or do not agree on, could we agree that having a start and end coordinate in an infobox is an acceptable thing to have. Not a mandatory thing. Merely a thing that we will tolerate. See, for example, A20 road (England).

The template uses from, to terminology. I've seen the argument made that start and end coords will mislead users into thinking the road is a straight line. That holds no water for me; I cannot conceive of a person clever enough to be able to understand what a coordinate is but stupid enough to think showing start and end coords means the connecting road is straight. --Tagishsimon (talk) 03:32, 20 January 2012 (UTC)

Discussion of Proposal 11

  1. Support as proposer
  2. Support - equal preference with number 3 Why not? I could even go with mandating it, but I can only speak for myself there. --Rschen7754 07:37, 20 January 2012 (UTC)
    Footnote: We would need some way to deal with oddball cases, such as noncontinuous routes and loops. I'd suggest tagging all terminii in the first one, and tagging the zero milepost for the second. --Rschen7754 08:04, 20 January 2012 (UTC)
  3. Support. If it means progress, I'm all for it. Oppose. I had a change of heart over coordinates in the infobox. I think they're useful and I can't wait until there is a solution that all of us like, but I don't see the usefulness of putting them in the infobox. Yes, I'm aware coordinates are placed in the infoboxes of lots of articles (WP:OTHERSTUFFEXISTS), I don't feel it's the right thing to do here. After we close up here, I am going to make a request on one of the templates discussed here. Afterwards, I'll feel comfortable discussing my plans with others. –Fredddie™ 07:06, 26 January 2012 (UTC)
  4. Question, what's the difference between this and proposal 3? I see these as being the same thing. For the record, I'm ok with this, but it's not an ideal solution. There will be many highways listed where using google maps (or whatever) to plot a route between the coordinates will give a routing that does not involve the highway in question. Several such examples are listed in proposal 3, another one not listed there, and a current FA, would be Utah State Route 128. Dave (talk) 08:34, 20 January 2012 (UTC)
    There's one difference: this is optional. --Rschen7754 08:39, 20 January 2012 (UTC)
    Answer. This relates solely to infoboxes, it provides a primary coordinate bringing the infobox upto date. It does not proscribe or prescribe the use of further co-ordinates elsewhere in the article. Putting this in as an aspiration will, allow restless editors to cruise through the backlog doing a bit of restful tagging after they have finished correcting spelling mistakes and grammatical errors in the 3,850,600 pages elsewhere.;-) --ClemRutter (talk) 11:02, 20 January 2012 (UTC)
    I do also agree that the coords shouldn't be used to provide a route, because that would be highly inaccurate. --Rschen7754 18:06, 20 January 2012 (UTC)
  5. Support. If it means progress, I'm all for it but would like to see a principal_coord and principle_coord_caption that could be interpreted by humans as whatever but to make it simpler for database linking.--ClemRutter (talk) 11:02, 20 January 2012 (UTC)
  6. Support only if the degrees minutes and seconds are not displayed in the infobox. A word or two description which links to geohack (ie start point, end point)is more suitable and more focused on the aim. The geohack page would show the latitude and longitude. There are also issues when it comes to roads with discontinuous sections and orbital (ring) roads with no verifiable mile 0 or similar concept. - ʄɭoʏɗiaɲ τ ¢ 14:58, 20 January 2012 (UTC)
  7. Support. Well this should go without even saying. But it should not prevent us from putting in more coordinates either. --Dschwen 21:08, 20 January 2012 (UTC)
  8. Oppose - I do not see the value of selecting only the termini for coordinates, as it does not provide a complete picture of the road. I still think no coordinates is the best idea. Dough4872 03:58, 21 January 2012 (UTC)
    That makes no sense. --Dschwen 05:05, 21 January 2012 (UTC)
    The termini only show the endpoints and not the curvature of the road. In addition, there is also an issue for beltways which have no terminus. Also, adding the coordinates to the infobox will make it look cluttered. Dough4872 05:15, 21 January 2012 (UTC)
    That makes even less sense. Curvature of the road is irrelevant, I imagine that beltway is term meaning ringroad- several ways have already been suggested that are acceptable. As for cluttered- suitable use of the if clause in the template design prevents that- Some articles requiring infoboxes will only display three bits of information- the name - the coordinates and a location map! --ClemRutter (talk) 13:09, 21 January 2012 (UTC)
  9. Weak neutral tending towards oppose (now how's that for a wishy-washy vote?) If this could be implemented in a visually unobtrusive way, maybe, but I'm still not convinced that the amount of time that I would have to spend looking the coordinates up would be justified by the number of people who actually care. —Scott5114↗ [EXACT CHANGE ONLY] 04:36, 21 January 2012 (UTC)
    Please don't oppose based on the premise that you have to add and/or maintain the coordinates. There are people more than willing to to the hard work here. All you guys are doing here is debating whether their work should be destroyed and suppressed in the future. --Dschwen 05:05, 21 January 2012 (UTC)
    You seem to have had a very different experience on Wikipedia than I have. I am used to being the only person that substantially edits any of the articles in my area of interest. —Scott5114↗ [EXACT CHANGE ONLY] 05:41, 21 January 2012 (UTC)
    It can get pretty lonely at times! I wouldn't dare to edit one of your articles unless I had been requested- you get a reputation as being the expert and suffer. But geotagging is different, if you have the right setup on your computer, and the target articles are well written you can mod a batch of infoboxes at about 30 an hour, so giving help is not too onerous.--ClemRutter (talk) 12:58, 21 January 2012 (UTC)
    Oppose. Upon further thought this would be unnecessary if, as expected, Proposal 9 is found to have consensus. If, for some reason, someone needs just the termini, they could open the linked coordinate file and extract the first and last point. The vast majority of coordinate requests would most likely be seeking the information "where is this road?" and therefore providing both is not necessary. —Scott5114↗ [EXACT CHANGE ONLY] 20:50, 26 January 2012 (UTC)
  10. Support as I think this should just be the minimum requirement for a road if it is just a simple road. DubhEire (talk) 21:46, 23 January 2012 (UTC)
  11. Weak Support If this is done, it should be very simple. Haljackey (talk) 07:30, 26 January 2012 (UTC)
  12. Weak Support This approach would work in many cases, but it does not effectively address the issue of roads that are forked, circular or have more than one section. Also some roads do not even approximate a straight line, so a more thorough approach is preferred. Bazonka (talk) 08:24, 26 January 2012 (UTC)
  13. Oppose because this proposal does not seem to be that much different from Proposal 3.  VC  22:37, 26 January 2012 (UTC)

Overall discussion

As the section title says, overall discussion, collapse for readability. -- DQ (ʞlɐʇ) 15:56, 4 February 2012 (UTC)
  • 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)
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)


  • 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

Request for information. Collapse for readability. -- DQ (ʞlɐʇ) 15:52, 4 February 2012 (UTC)

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)
The WikiMiniAtlas gets about 20000 hits per day. Of course that is not much in relation the entire Wikipedia (as someone mentioned above). But that is besides the point! 20000 users each day are certainly better than nothing. --Dschwen 21:16, 20 January 2012 (UTC)
  • Comments: Why I would like coordinates in an article. For example: I am in Michigan with some time on my hands, so go to Category:Wikipedia requested photographs in Michigan and click on the Map of all coordinates link. From this I see what is in the area where I am or even plan a road trip for the day; take my camera and clear up some of those requests. I see there is a Category:Wikipedia requested photographs of roads in Michigan with 137 requests. I could probably clear up some of these but not knowing the state to the extent of all the road numbers it is not easy to work out which ones I could get to easily. I do not need anything complex but at lease see which ones are in the south east or the north west of the state would help work out which one to look at. --Traveler100 (talk) 21:34, 22 January 2012 (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 and comments. Collapse for readability. -- DQ (ʞlɐʇ) 15:53, 4 February 2012 (UTC)

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)

possible SVG proposal

Not a feasible option at this point in time. -- DQ (ʞlɐʇ) 15:28, 4 February 2012 (UTC)
The following discussion has been closed. Please do not modify it.

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)
Sorry, but this is a pretty ill-informed proposal. It will result in non formatted, non machine readable, and non reusable data. This is very 90ies. Nowadays we like to have semantic markup. --Dschwen 02:33, 21 January 2012 (UTC)
I can think of four other free and open source GIS programs that are widely used --Guerillero | My Talk 19:19, 23 January 2012 (UTC)
You are not getting the point! SVG is not a geodata format. This would be only marginally better than using PNG maps. The number of opensource GIS programs is pretty much irrelevant. --Dschwen 19:52, 23 January 2012 (UTC)

Wikipedia:SOPA initiative

Blackout Extends RfC by a day, collapse for readability. -- DQ (ʞlɐʇ) 15:28, 4 February 2012 (UTC)

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

Notes on canvassing, to be noted in my close, collapse for readability. -- DQ (ʞlɐʇ) 15:28, 4 February 2012 (UTC)

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

Comments on methods and tagging one coordinate per road, collapse for readability. -- DQ (ʞlɐʇ) 15:43, 4 February 2012 (UTC)

(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)
Here I am. The plugin in the svn repo is not what is driving the WMA. The code has been and is being actively developed. --Dschwen 21:18, 20 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)
You will find my positive suggestions and contributions (including but not only the instigation of {{Coord}}, its optional display features, its metadata, arranging its use by Google, and our draft guidelines on geotagging linear features) in the history oh this and other pages. Forgive me if I don't repeat them all, every time a bunch of editors start another fork of their lame, tired and facile objections.
Also, I don't see anything in your comment, in response to my question about the workability of the coordinates M5 motorway. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:45, 22 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)
I believe Wiktionary has a definition. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:41, 22 January 2012 (UTC)
Well of course it does, but that's not helpful. To be specific, what is "same functionality"? What is the functionality that would be lost? --Rschen7754 10:03, 26 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

Per TfD template was a no keep, collapse for readability. -- DQ (ʞlɐʇ) 15:28, 4 February 2012 (UTC)

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 use 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)
Oh, I read what you said (though I did miss that "they can be obtained on the geohack page" is false for more than one set of coordinates). I repeat: "it should not be in use anywhere on Wikipedia". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:16, 22 January 2012 (UTC)
Well, unfortunately your opinion wasn't backed by consensus. I'd like to see an opinion from an editor that isn't on an unending crusade to bring down anything that isn't the status quo. - ʄɭoʏɗiaɲ τ ¢ 02:09, 22 January 2012 (UTC)

This RFC

Administrative notes, comments, and concerns on this RfC. A proposal to split Collapse for readability. -- DQ (ʞlɐʇ) 15:48, 4 February 2012 (UTC)

Having thought about this a great deal, I think we are trying to achieve too much in one RFC. In order to move forward, I think we should break this into 3 separate RFCs as follows.

  1. As per Proposal 1. Should cords be in a road article
  2. If we have a yes to proposal 1, then what guidelines should we use with the current templates. I think proposals 2 to 8 cover off the same thing. Most articles are straight-forward to deal with, for example 95%. Leaving 5% to be figured out what the best approach should be. We must bear in mind that there are technical limitations.
  3. What is the ideal future? There have been plenty of ideas given, so we could get a better way in a month, 6 months, 1 year?

DubhEire (talk) 23:13, 20 January 2012 (UTC)

I think its being approached in the wrong way by everyone involved (myself included). We all support being able to geolocate a road. The disagreements come in two forms: The method of displaying that on the article (be it coords or not, and how they are displayed, where, etc), and the amount of geolocating data that should be available (ie, tagging everything (shapefile is included here), just junctions (coord template), start and end points, middle, etc) / how to choose that amount fairly without bias. - ʄɭoʏɗiaɲ τ ¢ 01:55, 21 January 2012 (UTC)
This car-wreck of an RfC is going nowhere, and will never lead to a sensible decision. I think that it should be closed (with a No Consensus decision), and then we open a simpler, more focused RFC, along the lines of that suggested by DubhEire. I think we should skip his/her first question though as this will clearly never end in a No decision - at best a No Consensus, which is useless. Bazonka (talk) 09:45, 21 January 2012 (UTC)
I'm glad we can agree that what Tagishsimon did wrecked this RfC by giving people a false and negative impression before they even read the proposals, because it certainly wasn't a train wreck 3 days ago. - ʄɭoʏɗiaɲ τ ¢ 15:26, 21 January 2012 (UTC)
Come on kid I wouldn't take that last thought to RfC. If you intending to run an RfC in future, just advertise it fully om the correct page. Now how about thinking about how you can service the community as a whole by implementing Proposal 11 where you said.
Support only if the degrees minutes and seconds are not displayed in the infobox. A word or two description which links to geohack (ie start point, end point)is more suitable and more focused on the aim. The geohack page would show the latitude and longitude. There are also issues when it comes to roads with discontinuous sections and orbital (ring) roads with no verifiable mile 0 or similar concept.
Not having 60 fingers I see no difficulty in making the default display dd.dddd and leaving it to users Javascript to fiddle with it if they want something different. I am supremely relaxed to working to 10m accuracy so 4dp digit references are fine.--ClemRutter (talk) 17:56, 21 January 2012 (UTC)
Well, Tagishsimon mostly made himself look like a bit of an ass. It took a little looking for me to then find this RFC. If you want to call his action "canvassing" then you've got your head up your "wahzoo". But you've made it abundantly clear that you'd rather discuss this in your closed off article-owning clique, than get the input of the people who actually do the heavy lifting work on the coordinate front. --Dschwen 18:14, 21 January 2012 (UTC)
Consensus on WP:ANI is that that was canvassing. Secondly, this RFC was advertised on many pages, including the coordinates project's talk page. --Rschen7754 22:27, 21 January 2012 (UTC)
Can you be more specific with your link- I can't see it. Don't bother to look- it is totally irrelevant that you know more legal worm holes than I do. I am sure you are right that a link was once made coordinates project's talk page it was just too obscure to notice before it was highlighted. But on more important matters, in your comment on proposal 11 you said:
Support - equal preference with number 3 Why not? I could even go with mandating it, but I can only speak for myself there. --Rschen7754 07:37, 20 January 2012
We can square the circle later, but as a priority could you discuss with your wikigroup how and where you would like to appear in the infobox. I have stated that I would like 4 parameters. coord_start, coord_end coord_principal and coord_principal_caption. The principal co ordinate would always be coord_start unless coord_principal_caption existed when coord_principal would be would become the principle coordinate (appearing in title and be available for bots). This leaves the minimalists with an option for endpoint tagging and in other contexts (and in derived templates) another point. Personally I agree with you, that two points should be mandatory but not being a member of your group I wouldn´t inflame the debate further by suggesting it.--ClemRutter (talk) 23:27, 21 January 2012 (UTC)
As has been said, we don't really need a separate parameter for the coordinates since we can just put it in the terminus field with the terminus that is already there. --Rschen7754 00:08, 22 January 2012 (UTC)
Separate fields make data more easily parsable not least by maintenance bots. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:30, 22 January 2012 (UTC)
I'm not really picky on this, but having written parsers before, it wouldn't be much extra work. --Rschen7754 01:01, 22 January 2012 (UTC)
Once again, Rschen7754's claims and reality are miles apart. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:30, 22 January 2012 (UTC)
All the uninvolved admins that have posted have disapproved of his actions, and Tagishsimon was warned several times [12]. --Rschen7754 00:45, 22 January 2012 (UTC)
Which is not evidence for what you falsely claimed above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:52, 23 January 2012 (UTC)

I was away for a bit. Sorry for not being more involved. Anyway, all of you have generated some pretty interesting statistics. It has been a very interesting RFC. Shall I put some stats here as it may help come to a useful conclusion? Or should I hold off? I can send them to you Rschen7754. Anyway, I should also put down my own support/oppose. DubhEire (talk) 19:15, 23 January 2012 (UTC)

What sort of stats? --Rschen7754 05:20, 24 January 2012 (UTC)
Well, I find it curious that of the 21 who support proposal 1, 57% (12) have not supported any other proposal. Similarily, of the 25 who oppose proposal 1, 52% (13) have not supported another proposal either. So that means out of the 53 users involved, only 28 have supported another proposal. There are 7 users who neither support/oppose proposal 1. I'll leave it at that for the moment. DubhEire (talk) 10:09, 24 January 2012 (UTC)
Thanks. I mean, there could be many causes of this, but I don't feel it appropriate to voice my thoughts at the moment. --Rschen7754 10:32, 24 January 2012 (UTC)
Yeah, I'm refraining from putting any opinion around it too. Best wait until after the end time. DubhEire (talk) 10:38, 24 January 2012 (UTC)

Extending the RFC

Administrative notes of RfC, collapse for readability. -- DQ (ʞlɐʇ) 15:28, 4 February 2012 (UTC)

The RFC seems to still be going, and discussion still seems to be taking place. However, it is "scheduled" to end next week. There is no "minimum" or "maximum" length of a RFC as per WP:RFC; it's "tradition" that it's 30 days. The only thing limiting this discussion to 31 days (as extended with everything else during the blackout) is my statement at the top when setting up the RFC. I'm open to extending it, but I'd like to get the okay from others before I do that. --Rschen7754 02:03, 21 January 2012 (UTC)

I don't know. I think it might be useful to end the RFC as scheduled so as to allow us to clear our heads and decide where we're going to go next. —Scott5114↗ [EXACT CHANGE ONLY] 05:48, 21 January 2012 (UTC)
No point waiting. It'll almost certainly be a No Consensus closure, and another few days isn't going to change that. See my comment in the thread above. Bazonka (talk) 09:47, 21 January 2012 (UTC)
I disagree. There's significant consensus to at least look into P9. Also, there is significant consensus against the status quo. --Rschen7754 09:56, 21 January 2012 (UTC)
P9 (shapefiles) should be an add-on to the main article structure, and we are still utterly undecided on how that should be. I agree that there is a consensus against the status quo, but agreeing that we don't like where we are now is hardly a plan for the future. Bazonka (talk) 10:01, 21 January 2012 (UTC)
It's pretty clear that, aside from the hardcore {{coord}} pushers, most people would support this replacing the coordinate system with something that is much better presented, much more functional, much more accurate/reliable and much less abrupt in the articles. - ʄɭoʏɗiaɲ τ ¢ 15:20, 21 January 2012 (UTC)
Shapefiles would not be more functional. They would add another barrier to editing and would replace simple templates with established functionalities and a big supporting community by hunks of cryptic data that is inaccessible to even more people than the coord template. --Dschwen 18:17, 21 January 2012 (UTC)
No more so than an image adds cryptic data to a text only article. There are plenty of open source GIS editors that can view the shapefiles and allow you to edit the parameters, which are coordinates. There is no established consensus for most linear features, so it's time to come up with some solutions. - ʄɭoʏɗiaɲ τ ¢ 18:28, 21 January 2012 (UTC)
Bazonka, could it be that we haven't decided how coords and shapefiles should work together because we don't know how shapefiles will work at all? We can speculate all we want, but until it works, we should be all be advocating that it needs to work. Dschwen, it sounds like you're saying "I don't want to because it's going to be hard to do." –Fredddie™ 19:04, 21 January 2012 (UTC)
With all due respect, I'm getting nothing but WP:IDONTLIKEIT from the highway community. The underlying point here is we think it looks ugly. The rest are just fabricated non-issues. If you think my point boils down to IDONTLIKEIT then I might not have made myself clear. Analogy: we don't upload images of text either, we use wikitext. And there is currently no technical way of properly handling shapefiles. Would you want to embed them in the wikitext? How? Those are complicated XML files! Would you want to upload them on commons? How? There is no infrastructure in mediawiki to embed them. I have dealt with shapefiles a while ago for a map overlay project on commons. I thought they were the way to go. Believe me I have spent a great deal of time on these issues. The highway people have not. This may seem harsh, but you guys have no clue about the technical underpinnings of the whole geocoding stuff. And that is ok, that is why we have a geocoding project with plenty of motivated people doing their jobs. All we ask is that you let us do what we do. I'm not opening crazy RFCs on how highway articles are supposed to look either. I realize it is good to talk and not ignore each other completely, but this has escalated to a level where it is just disruptive and hurting all our productivity. --Dschwen 20:14, 21 January 2012 (UTC)
Not "We think it looks ugly", its more like "we think it overwhelms the text with masses of blue linked numbers which serve little to aid reader understanding". If coords are to be used as the method of tagging highways and other convoluted linear features, then there has to be a better way of presenting them on the article. "There is no infrastructure in mediawiki to embed them." - So then why not work towards making that possible? There are plenty of open source GIS programs, there are even some that can do it online. User:Egil developed the current Geohack system by the looks of it, and [13] shows that there are different systems in place. What is needed is a person who both knows GIS data and how to program in scripting languages. A shapefile could be laid over the miniatlas to become a scrollable map of a route. - ʄɭoʏɗiaɲ τ ¢ 20:56, 21 January 2012 (UTC)
Well, yeah, of course I will program such overlay functionality once a means for using shapefiles exists. And yes "everything can be programmed", but you seem to have little idea about what it takes to do so. It is near impossible to add innovative functionality into Mediawiki and onto Wikimedia servers. That is why there are so many Javascript and toolserver kludges. Here you are, a tiny special interest group, that just goes and demands an addition to the mediawiki codebase that has proven to be not feasible for at least the last 4 years. Dream on. But this is not going to happen. Full stop. Also, where would the shape files go? And where would you suddenly get sources that you could call "reliable"? I thought those didn't exist in your world. You keep talking about opensource GIS programs, fine, but still this would make geocoding orders of magnitude more complicated. We have a system that works for now. Sure, let's keep an open mind about improving on it, but make it an evolutionary change. Do not burn down the current efforts completely before even undertaking the monumental task of "next generation" geocoding. --Dschwen 22:14, 21 January 2012 (UTC)
(edit conflict)I will say Floydian's views on how coordinates are displayed do not necessarily represent my own. The problem I see, Dschwen, is that the Geocoords project seem to feel the current Geohack system is "good enough". In my line of work, I'm told every day to not accept "good enough" – always strive to do better. To me, the shapefile idea is a leap past "good enough" and if you're not willing to help get it in motion, please don't be an obstructionist. This, too, may seem harsh, but I get annoyed when the discussion keeps coming back to the current being "good enough". It's not. –Fredddie™ 22:28, 21 January 2012 (UTC)
How about you f***ing read my comments before you utter this obstructionist shit. Uhm, yes, this might seem a bit harsh. I get annoyed when this discussion boils down to scrap all coordinates right now because we a pipe dream about how things may be better. Oh, yeah, but we don't actually have a darn clue how it is supposed to work. And let's not forget to insult people who coded their asses off to make the current system happen, and are still investing time in maintaining and improving it, and have just indicated they'd support and work on a better solution, as obstructionist. What the hell Freddie?! --Dschwen 22:35, 21 January 2012 (UTC)
Look, I respect what you have done, and I wish I could say I could do what you do, but I can't. The optimal goal for all of us is to get something written and added to MediaWiki. Am I right here? Assuming I haven't burned the bridge, you, Dschwen, would be willing to do some of the coding work, right? But if it's damn near impossible to get anything good added into MediaWiki, what's the point of trying? It seems self-defeating and it creates mixed messages.

As far as the obstructionist comment goes, it was not specifically directed at you, Dscwhen, so I apologize for getting you worked up. We have all been discussing this ad nauseum for over six months. There is a "cycle of no" from the coordinates project that keeps directing the discussion back to the current method of geotagging. If even an idea comes up from the roads project, it is summarily rejected with a rationale of (I'm paraphrasing here) "It has to be this way (the current method of geotagging) and no other way." Those are the obstructionists. –Fredddie™ 23:13, 21 January 2012 (UTC)

Ha, no, bridge not burned. I apologize for my worked up comment. Yes, I'd be happy to help where I can. What I ask in turn is that current geocoding is not disrupted while we try to come up whit an improved solution. --Dschwen 23:19, 21 January 2012 (UTC)

I don't necessarily think the interest in Prop 9 indicates that using shapefiles in particular are what the highway editors want. On the contrary, it seems to me that what myself and my fellow highway editors are interested in is a method of fully expressing a road as a linear feature, while also not overwhelming the article with hundreds of coordinate links (since the coord data would be in a separate linked file). Shapefiles are one possible answer to this question, and one that we particularly like because we are used to dealing with them to generate the maps that appear in our infoboxes, and would mesh well with our present workflow (i.e. we just have to export the shapefile after we render the map and upload it). If another proposal could be devised that treats roads as linear features and doesn't require dozens of coordinate links strewn across the page, and yet is simpler to implement than the shapefile proposal, I think it would merit serious consideration. The problem is, nobody seems to have had such an idea yet. —Scott5114↗ [EXACT CHANGE ONLY] 02:09, 22 January 2012 (UTC)

Is there a way that maybe the wikiminiatlas could be built into another template? I'm picturing replacing the map in the infobox with something interactive. Then the reader could zoom, pan and all of that good stuff within the current article and not have to leave the article to another website (where they might be distracted and not come back). Of course, it would be great if that map has the road, river, train line, etc highlighted. Imzadi 1979 → 02:26, 22 January 2012 (UTC)
This would rewquire javascript. But to open the wikiminiatlas you don't leave the page, it pops open on the current page. You only need to leave the page to get to the geohack. The coordinate data (shapefile, if you want) could be deposited on a subpage such as /coords. The WMA could query that page, parse it and display the contained data. This could be implemented now (as opposed to uploading shape files on commons). But subpages are somewhat frowned upon here. --Dschwen 04:29, 22 January 2012 (UTC)
The rules can always be changed. If we can all agree on something (I like this idea as a replacement for coords in the junction list or title) then there are enough people here to get behind setting a new precedent. - ʄɭoʏɗiaɲ τ ¢ 05:01, 22 January 2012 (UTC)
Dschwen, what sort of data would you need? A list of coordinates that draws a line or polygon? Give us an example of what you would need and I imagine you'll have 10 of us giving you something to test out. –Fredddie™ 05:16, 22 January 2012 (UTC)
The sort of data is a good question. Should we use entire shapefiles (difficult to parse and edit on-wiki) or a homebrew format (easier to parse and edit, but potentially less powerful and harder to use off-wiki). I will start laying some groundwork, such as the plotting routines for 1D, 2D data in the WikiMiniAtlas, so that I'll be ready for anything that comes up. I can just use some dummy data to work on that. But this discussion could benefit from more input as the result may have wider reaching consequences. --Dschwen 15:16, 22 January 2012 (UTC)
Someone upthread mentioned KML, which on a cursory examination might be exactly what we need. Easily parsable, easily editable. I'm running a bit short on time, but if QGIS has a KML export feature/plugin, that will probably seal the deal for the roads people. —Scott5114↗ [EXACT CHANGE ONLY] 05:36, 24 January 2012 (UTC)
It does indeed! As does ArcGIS. - ʄɭoʏɗiaɲ τ ¢ 15:05, 24 January 2012 (UTC)
After looking into XML parsing a bit more I came to realize that it would actually be dead simple for me to parse a KML file for display on the WikiMiniAtlas (the display part is not quite that simple, but doable). --Dschwen 15:24, 24 January 2012 (UTC)
It's my understanding that true subpages aren't possible in main (article) space. However, if we could convince the powers that be to allow KML files in file space (here, Commons, or both), how hard would it be for a template to assume that the shape data for M-185 (Michigan highway) is at File:M-185 (Michigan highway).kml, and parse it accordingly? I'm assuming that it wouldn't be very hard at all. Imzadi 1979 → 15:48, 24 January 2012 (UTC)
Probably not too hard. I'll have to check if there will be any cross-domain access issues for getting the files from upload.wikimedia.org (but it would probably go through Special:Filepath in any case). --Dschwen 18:15, 24 January 2012 (UTC)

Of course, KML is far too specialised and intricate for many of our editors to created by hand, so we'd need a template into which they can paste coordinates and metadata, and which, when used in multiple, can be used to generate the KML. Oh, wait, {{Coord}} already does that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 25 January 2012 (UTC)

I don't really see how KML is "intricate". It is just XML. (And a piece of cake compared to SVG, another XML application which many people in the roads project have written by hand.) Considering that so many things generate KML in particular (someone left me a link on my talk page where one can easily use OSM to generate KML files), including programs (ArcGIS, QGIS, and Google Earth, which from my memories of it is user-friendly enough that someone in elementary school could use it) nobody will really need to be hand-hacking KML files. Thus, there is not really a need for {{coord}} at all. In fact, I would wager that creating a KML from one of those programs and uploading that would be much easier than looking up a bunch of coordinates and pasting them into {{coord}}. —Scott5114↗ [EXACT CHANGE ONLY] 12:54, 25 January 2012 (UTC)

Anyway, I'm not extending the RFC per comments above. I will ask that the non-proposal sections be left open though so discussion can continue. --Rschen7754 21:38, 22 January 2012 (UTC)

One possibility is to rewrite the road junction lists as template with various options - "RJL", "KML" etc. The output will depend on the option chosen. There will be one template per road, much as the railway and canal groups do (for example, follow the links for the Basingstoke Canal. This will allow RJL to be displayed in Wikipedia without coordinates, while the Geocoords group can have coordinates in their preferred format. The template will of course be agnostic as to whether it is holding RJL or KML data. Any comments? Martinvl (talk) 12:58, 25 January 2012 (UTC)
In the case of the United States, the RJLs are already templates: {{jcttop}}, {{jctint}}, etc. I am not sure how compatible this structure is with your idea. However what we're thinking of with the KML thing is something a bit grander in scale—there will be coords for not just major junctions, but for each point along the route such that an accurate trace of the road is obtained. Basically, think of an SVG representation of the route; convert that to use geographic coordinates, and that's what the KML idea is. —Scott5114↗ [EXACT CHANGE ONLY] 13:06, 25 January 2012 (UTC)
I was thinking of something like this:
  1. Create a template "M25 (United Kingdom) Route Data" that could take parameters "RJL" or "KML". Potnetially it could take other paramters that would be passed on to other templates.
  2. It would reference one template "jctuktop"
  3. It would reference 31 templates "jctukin" that would contain junction and coordinate information. This template would produced different output, depending on whether the first template received a "RJL" or a "KML" parameter.
  4. It would reference 100 templates "jctukin" that would contain only coordinate information (junction information would be blank). This template would produce output it the "KML" parameter was set, otherwise it would produce no output.
  5. It would referencec one "jctukbot" template whose behaviour would depend on whther the "RJL" or the "KML" parameter was declared.
Please note that the UK road junction lists are different to the US ones. Martinvl (talk) 13:35, 25 January 2012 (UTC)
RJL appearance is a discussion for another day, Martin. :) I agree with you in principle about collecting geolocation data with templates, but new things are in the works and we should see how they work before we get in too deep. –Fredddie™ 18:00, 25 January 2012 (UTC)

Coordinates and OR

Surprisingly, perhaps, the proponent's enquiries elsewhere on coordinates and OR have not been reported by him here. See:

Is using a GPS receiver to find coordinates original research? and Coordinates and original research. While the original questions were framed in terms of GPS, the answers also touch upon the use of coordinates obtained from maps. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:07, 26 January 2012 (UTC)

There are still over 20+ editors that disagree, listed above. Consensus can change. - ʄɭoʏɗiaɲ τ ¢ 13:30, 26 January 2012 (UTC)

Closure of RFC

I've put in a request to get this RFC closed at WP:AN/RFC; unfortunately, it seems that we're at the bottom of a backlog, so it could be a few days. --Rschen7754 07:14, 26 January 2012 (UTC)

Ok. Does that still mean that the cut off time was 01:25, 26 January 2012? DubhEire (talk) 11:36, 26 January 2012 (UTC)
I think people can keep posting until the RFC closes. --Rschen7754 18:14, 26 January 2012 (UTC)

Another reason to include coordinates

Wikipedia now has a mobile app (for Android and iPhone). v1.1, currently in alpha for Android, allows users to tap any instance of {{Coord}}, and then be shown a map with five pins, linking to, respectively, the five nearest geotagged articles. This allows, for example, a reader planning a trip, to view the article on the highway they will be travelling on, select the coordinates for the junction at which they will leave, and then see what other points of interest are in the vicinity. Even without this feature, coordinates on articles are being used by version 1.0 around 27 thousand times a day, since its launch last month. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:51, 2 February 2012 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Moving forward on Proposal 9

Since Proposal 9 is another proposal with near unanimous support, I think we should likewise take a look at how to move forward with making it happen in the real world. Here are some of the questions that I think need to be agreed on:

  1. What sort of format are we looking at for the coordinates? Proposal 9 itself mentioned "shapefiles", but KML seems to do the same job, and much easier, too. Does anyone really object to using KML over actual shapefiles?
  2. Assuming KML is used, is there any way we could place the KML on a wikipage, perhaps a subpage of the talk page? Would this present unwarranted parsing difficulties?
  3. If we cannot put the KML on a wiki page, who do we need to convince to allow us to upload KMLs/shapefiles to Commons or the English Wikipedia?
  4. How will the link to the coordinate file be presented in the article? Will it be visible in the rendered output? Can it be tagged in some consistent way so that reusers of data can consistently find it? (Perhaps a class or id parameter in the HTML, somewhat akin to the way microformats are specified?) Would it be feasible to allow the file to be named anything (i.e., must it always be named <article title>.kml)?
  5. How can this be tied into GeoHack? How will the GeoHack link, if any, be presented in the article?
  6. Likewise, how can this be tied into the WikiMiniAtlas? How can we use the WikiMiniAtlas to enhance our articles?
  7. Who do we need to talk to in order to get the ball rolling on the necessary coding?
  8. Do the technical people need anything from us? Can we help them in any way to make implementation as smooth as possible on their end?

I think that about does it. If there are any questions that need to be addressed besides those, now is the time to get them ironed out. —Scott5114↗ [EXACT CHANGE ONLY] 21:05, 26 January 2012 (UTC)

The more I'm looking into it The more I'm getting convinced that the data duplication that results from uploading shape files (not mentioning issues with proper licensing) are a bad thing (tm). I suggest focussing on a way to refer to OpenStreetMap ways. This is not completely trivial, but reduces redundant efforts. --Dschwen 23:29, 26 January 2012 (UTC)
Could the resultant file be dynamic from data in hidden or not on the page/template? Could it even be stored via the toolserver rather than commons thus reducing the effort required to maintain? I know you probably can't answer straight away. Do you have an example of a KML (for example) that has a route following a road and some points on it. Must find/make one for curiosity. DubhEire (talk) 00:03, 27 January 2012 (UTC)
Sorry, but wouldn't it be fair to say that the complexity here is the route information, i.e. not all roads are perfectly straight. Bringing in other points of interest would make it more of a challenge also. DubhEire (talk) 00:27, 27 January 2012 (UTC)
I don't think licensing is really an issue here. The roads projects already use shapefiles for creating raster maps; we are always careful to use free data sources. Freely licensed shapefiles are not all that hard to find; many state governments release their stuff as PD, as do some universities. What data is being duplicated? As for OSM ways, I don't really think that is necessarily a good idea, considering ways do not necessarily correspond to any given numbered route, and I'd hate to have to impose on them by saying "we need this way split over on Wikipedia even if you don't have any reason to split it". Furthermore, I personally would like to avoid getting entangled in OSM any more than I have to; I don't understand their community or how their tagging is supposed to work and it seems really inconsistent (i.e. the suburb I live in is tagged completely differently than the main city 20 miles away, the same road classifications mean different things between the two cities, etc). I don't think it is really reasonable to ask editors here to learn an entirely new set of cultural norms and editing procedures if they should want to add geographic data to their articles. —Scott5114↗ [EXACT CHANGE ONLY] 15:19, 27 January 2012 (UTC)
A shapefile is a standardized presentation of GIS data, which is measured by surveying. They can't be copyrighted, as there is no presentation, just measurements. - ʄɭoʏɗiaɲ τ ¢ 15:36, 27 January 2012 (UTC)
You should be careful with statements like that. Databases enjoy special protection. --Dschwen 15:43, 27 January 2012 (UTC)
Feist v. Rural: the raw data can not be protected by copyright in the US. Imzadi 1979 → 15:45, 27 January 2012 (UTC)
Scott, how OSM tags their ways is not an issue to us. We would not have to meddle with their tagging or their splitting of ways. It just boils down to formulating a query that obtains a certain set of nodes and lines. Such a query could do the splitting as well. We'd get raw data, not their road classifications. And such a query would still be smaller than painting your own road or copying it. It could fit into a template. --Dschwen 15:49, 27 January 2012 (UTC)
How would this work in practice? Say, if I need only half of a way, because the route I am interested in leaves midway through a way? —Scott5114↗ [EXACT CHANGE ONLY] 22:01, 27 January 2012 (UTC)
Give me an example for a problematic route and I will build you a query. --Dschwen 20:12, 28 January 2012 (UTC)
Sooo... this discussion is already dead again? I guess the candle that burns twice as bright burns twice as fast... --Dschwen 16:55, 1 February 2012 (UTC)
Like it. Point well made. I've been busy as I am sure you have too. I would still like to make an example so let's define what that should be in abscence of anything else. Are you looking to build a query on the toolserver to do this? I was thinking of manufacturing one by hand and then layer in anything else. Do you have an idea youself what steps must be taken? I am not that familiar with how things work on the toolserver, but I am willing to try. DubhEire (talk) 17:03, 1 February 2012 (UTC)
There is query to map (which I worked on as well a long time ago). It is abit outdated, so i might have to create a new version or construct an SQL-query on the database by hand. But this should get us started. All I need are examples for problematic ways. You must understand that my knowledge of the highway business is limited, so I may have an oversimplified idea of what is necessary to get highways out of the database in a manner that will please the pros. --Dschwen 17:22, 1 February 2012 (UTC)
I see how it works. It's too bad that, for the most part, the routes I care about have not been plotted on OSM. –Fredddie™ 18:46, 1 February 2012 (UTC)
Really?! What kind of routes are that? --Dschwen 22:44, 1 February 2012 (UTC)
I should clarify. The routes I care about don't have an OSM relation, which are made up of ways. A few roads articles have OSM relations tagged using {{Osmrelation}}. That's what I meant, sorry. –Fredddie™ 23:25, 1 February 2012 (UTC)
But you don't need osm relations, tags on the ways can be sufficient to query the data. --Dschwen 05:03, 2 February 2012 (UTC)
OK, I guess I need a picture drawn. Let's use Iowa Highway 415 as an example, since I was looking at it in OSM earlier today. It's shown on the map as IA 415. As a bonus, it's not a simple straight-line highway. –Fredddie™ 05:11, 2 February 2012 (UTC)
Good, I'll look into that. I'm moving today and won't have reliable internet access for a few days. But I'll be back! --Dschwen 13:25, 2 February 2012 (UTC)

Visualization pending (this is all I can quickly do from a hotel lobby: 

osm_mapnik=> select name from planet_roads where ref='IA 415';
          name            
---------------------------
West Bridge Road
Northwest Polk City Drive
Northwest Polk City Drive
Northwest 35th Street
Northwest 35th Street
Northwest 35th Street
Northwest 78th Avenue
Northwest 78th Avenue
Northwest 78th Avenue
Northwest 78th Avenue
Southwest Oralabor Road
Southwest Oralabor Road
Southwest Oralabor Road
Southwest Oralabor Road
Southwest Oralabor Road
Southwest State Street
Southwest State Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 112th Street
State Highway 415
State Highway 415
State Highway 415
Mile Long Bridge
(31 rows)

Does this look right to you? --Dschwen 02:43, 3 February 2012 (UTC)

After I realized it wasn't a serial list of ways, yes it does. –Fredddie™ 04:24, 3 February 2012 (UTC)
A couple questions:
  • I notice a "where ref='IA 415'" on there. Is this an attribute on OSM that we are using to snag just a part of a way or just a variable to aid in processing on our end? If it is the former, how would we proceed if this tag is missing on OSM?
  • What will happen if the data is changed on OSM? Will we have to alter the query on our end too?

The missing data question is most important to me, as there are situations that we cover on Wikipedia that OSM would not have tagged; unsigned highways, for example. An instance of this is Interstate 444, which is a snippet of freeway in downtown Tulsa. Because of all the highway designations that converge here, I-444 signs are left off the road, but it is officially on the Interstate rolls and therefore we cover it with its own article. However, since knowing the road is I-444 is useless for actual navigation on the ground, OSM does not have any sort of I-444 tags at all; they mark it the same way it's marked on the ground, as portions of US-412 and US-75. Another case I am concerned about is rural areas where perhaps the data has not been tagged or processed at all since initial import from TIGER (i.e. it is simply tagged as whatever the Census Bureau tagged it with) due to lack of interest in that area by OSM editors (it happens on this wiki, I'm sure it happens there too). —Scott5114↗ [EXACT CHANGE ONLY] 18:43, 3 February 2012 (UTC)

ref is an osm attribute. And a way is really a way-segment. An OSM way is always a uniform piece of road, as I understand it. So there really never should be a case of needing to get part of a way. Of course we can kill this discussion with a bunch of unlikely ifs. Can te data change on OSM? Yes, but I would cache the query results, and cache clearing could be made in a way that the nre result is previewed and checked first, so that the query could be adapted. Might there be some exotic roads where the tags are still missing? Maybe, but I'd rather cover 95% of all use cases with a clean and rather simple solution, than continue discussing about a suboptimal solution. A suggestion: get an OSM account and add the tags onto the data yourself, you'll be doing the world a service at the same time ;-). Anyhow, I will need a few days to settle in at my new place, but I already played around with querying the actual coordinate data and plotting it in the browser (this is a lot of fun!). --Dschwen 14:24, 4 February 2012 (UTC)
Ways are always uniform pieces of road, but a route doesn't always follow them. Consider the very common and not at all exotic instance of a concurrency. This is a segment of road with two different designations following it, i.e. both Interstate 44 and State Highway 3. This will, in my experience, usually be tagged in OSM as just the more important designation, in this case, I-44 (makes sense for OSM's users, it's what most people will be interested in). In any event, if you were trying to get a route trace for OK-3, you're going to miss out on those extensive concurrent sections (the first 304 miles of OK-3 is concurrent with another road, and it's only independent for 40 miles or so before it joins up with something else) because they won't be tagged as SH-3, they'll be tagged as whatever the more important road is.
As I said before, though, I consider it unreasonable to have to require editors to have to edit data over there, learn their conventions for tagging, etc. Personally I have enough going on here on Wikipedia to have to worry about falling down a whole new rabbit hole of butting heads with OSM editors for reasons that do not matter to them. (Why should they care if I need so and so tagged in this or that way for Wikipedia's queries? It doesn't benefit OSM any.) I, and probably most of the other roads editors, would much rather prefer to be able to hand tune the data to meet Wikipedia's needs without having to step on someone else's grass. Before we spend too much time chasing the OSM thing, can we stop and investigate the KML option more thoroughly as well? I don't really see why we've abandoned the idea of uploaded KML files other than a vague "data duplication" explanation (which I don't think holds much water, frankly; what we'd be doing with the data is somewhat different than what OSM is doing—it's a subtle difference, yes, but a difference).—Scott5114↗ [EXACT CHANGE ONLY] 15:00, 4 February 2012 (UTC)
Feel free to chase the KML dream. I won't actively push for it. It makes no sense to me to reject the notion of collaborating with OSM to improve the tagging for everyone's benefit. I will look into the road concurrency thing, I don't see why OSM would not be interested in properly tagging those ways. It actually does not make sense for OSM users to tag only with one designation. Just think about routing applications. Saying those correction would be another rabbit hole and you wouldn't want to force users to edit on another project seems a bit absurd, considering the alternative of using complex external software to prepare the data. --Dschwen 15:55, 4 February 2012 (UTC)
You mean complex software like Google Earth, where you make a path and export to kml? - ʄɭoʏɗiaɲ τ ¢ 16:28, 4 February 2012 (UTC)
That will most certainly give you a ridiculously low quality file, unless you spend a lot of time... ...duplicating the efforts that were already made elsewhere. Not invented here syndrome. --Dschwen 17:05, 4 February 2012 (UTC)
Dschwen, we already use GIS software and high-quality, freely-licensed GIS data in the creation of our maps. It's not terribly complex for us to select the red line that has just been created for the purpose of a map and export it to a KML. We teach new editors that are interested in the mapping aspects of the project how to use QGIS whenever they ask. We have tutorials written. We have the infrastructure for this ready on our end; don't worry about the complexity there. —Scott5114↗ [EXACT CHANGE ONLY] 17:18, 4 February 2012 (UTC)
Road concurrency is taken care of at the highway level at least in OSM (see I 57; I 70 near Effingham, IL). However this turns out, I'll be happy to add overlay support to the WikiMiniAtlas. --Dschwen 17:06, 4 February 2012 (UTC)
I was trying to use the Query to Map method of retrieving OSM data for river liffey or N11 in Ireland. I'm not sure if I am querying it correctly. I tried Way:name=Liffey ;Node:river=* What do I put the bounding box as? I tried -5,52.-6,53 . I also tried Way:name=N11 ;Node:highway . Also tried leaving bits out too. Just trying to understand this approach a bit better. Thanks. DubhEire (talk) 11:24, 18 February 2012 (UTC)
That particular tool is just broken. Above I gave an example for how to manually query the database. However the OSM querying approach was shot down, so I did not pursue that avenue any further. --Dschwen 02:26, 19 February 2012 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Highways/Archive_4&oldid=1148048783"