Wikipedia talk:WikiProject Highways/Archive 4

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7

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)

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

Proposal 2: limited use of coordinates

Proposal 3: Start and end points of highway only

Proposal 4: Route Table

Proposal 5: Status Quo

Proposal 6: Strengthen use of coordinates in MoS

Proposal 7: Minimalistic entry in existing junction table

Proposal 8: (Live and let live)

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.  V 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.  V 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.  V 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.  V 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

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

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)
  • Comment: Despite warning against canvassing, Rschen7754 is referring elsewhere to this as an RfC on "the potential use of coordinates in highway articles" (my emphasis), ignoring, as does the RfC itself, that many articles on roads already have coordinates; and that their use is explicitly provided for in our Manual of style. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:13, 26 December 2011 (UTC)
There is no canvassing in stating that this RfC determines their potential (ie future) use. If the community opposes them, they can always be removed from those few articles. We aren't compiling a summary of the past, we're picking a path for the future. - ʄɭoʏɗiaɲ τ ¢ 14:05, 26 December 2011 (UTC)
Exactly. I'm just trying to remain neutral. As you can see above, I actually support the limited use of coordinates, rather than not using them at all. So if "potential use" was canvassing... I'd be canvassing against myself. --Rschen7754 16:32, 26 December 2011 (UTC)
  • Comment: There are two different issues to discuss here.
  • What things should/shouldn't have coordinates against them in the article?
    • Start/End points
    • Points of interest
    • Junctions
    • Other things
  • Where should the coordinates be placed within the article?
    • In the title
    • In the infobox
    • In the body text
    • In junction lists
Might be better to have a number of smaller focussed proposals rather than trying to write on proposal that covers everything and then picking a few of the proposals rather that just trying to get everything in one.
For example:
  • Should there be Coordinates in the title?
    • No
    • Yes, just a single point to represent the average location
    • Yes, start & end points (execpt for orbital roads)
Then list out the options for Infoboxes, Junction Lists, and within the article text. -- WOSlinker (talk) 13:07, 26 December 2011 (UTC)
    • A sensible approach, in general, but note that the title parameter only allows for a single set of coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:14, 26 December 2011 (UTC)
      • Nothing is forbidden in the world of coding. I'm sure this could be changed to support the endless list of linear features we cover with more informative and less subjective data. - ʄɭoʏɗiaɲ τ ¢ 17:00, 26 December 2011 (UTC)
      • Its purpose is to display a single set of coordinates, for reuse by many tools and partners. It's not broken, so there's nothing (per your edit summary) to fix. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:07, 26 December 2011 (UTC)
        • Then its purpose isn't suitable for things that don't exist at a single set of coordinates. - ʄɭoʏɗiaɲ τ ¢ 17:13, 26 December 2011 (UTC)
          • Poppycock. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:22, 26 December 2011 (UTC)
            • Could easily make a template that showed two coordinates, but at present they would need to be individual links to click on rather than clicking on them both as a set. -- WOSlinker (talk) 18:05, 26 December 2011 (UTC)
              • We could indeed, but that wouldn't work for the various tools that make use of those coordinates; and may well break some of them. (I have previously suggested putting a fixed string in that location, as a work-around t=for this issue.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:13, 26 December 2011 (UTC)
                • It is possible to Bing & Google maps with 2 coords -- WOSlinker (talk) 11:20, 27 December 2011 (UTC)
                  • http://maps.google.com/maps?q=44.112,-87.913+to+43.112,-87.913
                  • http://www.bing.com/maps/?q=44.112,-87.913+to+43.112,-87.913
                    • Now here's one more step that could make this a completely viable option: Can you create waypoints inbetween using more coordinates? If a route can be outputted instead of a set of coordinates, that would be something useful to link in the title. - ʄɭoʏɗiaɲ τ ¢ 15:13, 27 December 2011 (UTC)
                      • It's not practicable to put an entire route (and routes are sets of coordinates) into the title position. As I've suggested previously, the way to do that is to put the coordinates into a section of the article (like the junction list) and put a link akin to {{GeoGroupTemplate}} in the title position. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:41, 27 December 2011 (UTC)
                        • Poppycock! You just don't want to improve the tool that only works for one application. - ʄɭoʏɗiaɲ τ ¢ 18:00, 27 December 2011 (UTC)
                          • Please do not attempt to speak for me; you are singularly lacking the wit or wisdom to do so. I, on the other hand, as the creator of that template, am already aware that it already works for several applications. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:30, 28 December 2011 (UTC)
                    • The problem one sees in this example is that the line drawn does not conform to a single road. Mangoe (talk) 21:59, 27 December 2011 (UTC)


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

Numerical data

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

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 above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

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)