This template does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Microformats Coord is part of, or of interest to, WikiProject Microformats, which encourages the deployment of microformats in Wikipedia, and documents them in the article space. If you would like to participate, visit the project page.MicroformatsWikipedia:WikiProject MicroformatsTemplate:WikiProject MicroformatsMicroformats articles Geographical coordinates Coord is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Wikipedia. If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.Geographical coordinatesWikipedia:WikiProject Geographical coordinatesTemplate:WikiProject Geographical coordinatesGeographical coordinates articles Geography This template is within the scope of WikiProject Geography, a collaborative effort to improve the coverage of geography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.GeographyWikipedia:WikiProject GeographyTemplate:WikiProject Geographygeography articles WikiProject Geography To-do list: Here are some tasks awaiting attention: Article requests : See Requested articles/Social sciences/Geography, cities, regions and named places and Missing articles about Locations Assess : Tag related article talk pages with {{WikiProject Geography}}. To help assess the quality and importance of geography articles, please see: Unassessed geography articles and Unknown-importance geography articles. Cleanup : See Geography articles needing attention Deletion sorting : Listed at Geographic related deletion discussions Geographical coordinates : See Articles missing geocoordinate data by country Infobox : See Geography articles needing infoboxes Map : See Wikipedia requested maps Notability : See Geography articles with topics of unclear notability Photo : See Wikipedia requested photographs of places Stubs : See Geography stubs

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 14

This page has archives. Sections older than 60 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

I've used this template for the first timehere, and the globe icon does not appear to the left for some reason. I got a popup with a similar icon and the words 'WikiMapAtlas' if I hover the cursor over it, but that's it. I'm using Chrome on Windows 7, but I don't think it's a rendering problem, because the globe icon shows up in all of the examples in the documentation for this template. Any thoughts? CanadianJudoka (talk) 06:11, 27 September 2012 (UTC)[reply]

I don't think it's a problem in your code; I believe that the globe icon only appears for coordinates positioned upper right and also those contained in tables. For coordinates in running text, the globe icon is suppressed. --Redrose64 (talk) 12:32, 27 September 2012 (UTC)[reply]

Okay. What's the reasoning for that? I feel like the globe icon is an important visual cue for what the numbers mean, and makes it easier to understand that clicking on the globe will give you a popup map instead of taking you to a different page. CanadianJudoka (talk) 15:31, 27 September 2012 (UTC)[reply]

Judging by threads higher up this page; in the archives; at meta:Talk:WikiMiniAtlas; and meta:MediaWiki talk:Wikiminiatlas.js, this is intended behaviour, and has been for years. I'll drop a note to Dschwen (talk · contribs) who is most likely to know the reasoning. --Redrose64 (talk) 16:16, 27 September 2012 (UTC)[reply]

Hey guys, yeah, it is "intended" behavior. Some people got their panties twisted because a flashy colorful icon in running text is a big no no. It like totally distracts the reader.. and stuff ;-). The Manual of style says so, even though the globe is not a decorative icon but a widget to interact with. The WMA icon should show up when you hover the coordinates with the mouse pointer (i see you already noticed that). Anyhow, bottom line is that the users who are most vocal dictate stuff like that. --Dschwen 17:44, 27 September 2012 (UTC)[reply]

Thanks for your response. Where should I suggest (i.e. be vocal) that this would be a useful exception to the 'inline pictures' rule? A bunch of seemingly random numbers without a visual cue to provide context doesn't pass the 'grandmother test'. ;) CanadianJudoka (talk) 18:03, 27 September 2012 (UTC)[reply]

Well, I honestly don't know. You could raise that point at WP:MOS/ICONS or at the Village Pump, I guess. --Dschwen 20:10, 27 September 2012 (UTC)[reply]

LOL... In before matter of factly response about pointless numbers. - Floydian ^τ _¢ 21:23, 27 September 2012 (UTC)[reply]

I don't really understand your message, Floydian, but maybe you misunderstood me. I didn't say that the numbers are pointless. My point was that their meaning will not be obvious to some people, and the globe icon may help to intuitively communicate that meaning. CanadianJudoka (talk) 21:28, 27 September 2012 (UTC)[reply]

Is there a way to specify the default WikiMiniAtlas map mode for a given coordinate? Compare for example 5°53′11″N 62°07′50″W / 5.8864002°N 62.1304322°W / 5.8864002; -62.1304322 (Aparamán Tepui) (coordinates for a Venezeulan tepui) in Full basemap and Satellite views. mgiganteus1 (talk) 00:53, 13 October 2012 (UTC)[reply]

Anyone? If not possible currently I think it would be a useful feature to have (see example above, where Full basemap isn't helpful at chosen scale). mgiganteus1 (talk) 01:27, 20 October 2012 (UTC)[reply]

I saw the coordinates at the top of Cydonia (region of Mars) and wondered how earth coordinates played into the image on Mars. It turns out that the parameter Template:Coord#globe:G was being used to specify Mars coordinates. Right now, the top coordinates in the Cydonia article appear as "Coordinates: 40°44′N 9°28′W / 40.74°N 9.46°W" with the globe parameter reading "globe:mars". If possible, please edit the template to change display based on the |globe= parameter. If the globe parameter is blank or is for earth, there should be no display change. If the |globe= parameter is filled in with, for example, Mars, then the display should appear as "Mars Coordinates: 40°44′N 9°28′W / 40.74°N 9.46°W" rather than merely "Coordinates: 40°44′N 9°28′W / 40.74°N 9.46°W". Thanks. -- Uzma Gamal (talk) 04:02, 21 October 2012 (UTC)[reply]

What benefits would this bring? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:04, 21 October 2012 (UTC)[reply]

What happened to the globe icon that used to appear to the left of the coordinates? I can't find it on any coordinate in any article. I don't know when it disappeared, but maybe in the last day or so. Looking at the history, the last change to the template was made in June 2010. Any ideas? Anonymouse321 (talk • contribs) 04:03, 27 October 2012 (UTC)[reply]

It was disabled with this edit. The reason is in the edit summary. --Redrose64 (talk) 13:56, 27 October 2012 (UTC)[reply]

OK, thanks for the info. –– Anonymouse321 (talk • contribs) 15:18, 27 October 2012 (UTC)[reply]

It looks like the globe icon is back. –– Anonymouse321 (talk • contribs) 04:28, 28 October 2012 (UTC)[reply]

That would be this edit then. --Redrose64 (talk) 13:13, 28 October 2012 (UTC)[reply]

The use of "title" as an option in the display parameter seems a poor choice. Firstly the coords are not displayed in the title but at the top. The use of "title" in the documentation is misleading as it appears to ask for the substitution of the article's title at this point which breaks the template without any explanation. I suggest that "top" would be a more accurate and less misleading option name and more consistent with what the documentation describes as the effect of the option. Kerry (talk) 13:51, 3 November 2012 (UTC)[reply]

Actually the template does not know at what position the coordinates are displayed, that is determined by the stylesheet. I thought the title argument associates the coordinates with the article title, semantically. But then again display as a parametername would be a bit inconsistent. --Dschwen 14:42, 3 November 2012 (UTC)[reply]

I've tweaked the documentation in an attempt to clarify the semantics of this parameter. It wouldn't be difficult to change the template to accept "top" as a display= parameter value. If you abbreviate "top" as "t", you may find the semantics easier to remember. ;) Cheers, —Stepheng3 (talk) 18:48, 3 November 2012 (UTC)[reply]

After reading Kerry's request for help at the Teahouse, I came here to make this very proposal. The only problem with disabling "title" is that it would break tons of old revisions of pages. What if we had two options ("title" and "top") that did exactly the same thing, and what if we changed "title" to "top" in all of our examples? That way, we'd not affect old page revisions, but we'd also make it a lot simpler. Nyttend (talk) 01:13, 9 November 2012 (UTC)[reply]

That's what I'm suggesting. It's a simple change; I can probably do it myself. —Stepheng3 (talk) 01:33, 9 November 2012 (UTC)[reply]

With {{Coord}} used on nearly a million articles (far more than most other templates), I think it would be needlessly confusing to introduce a new parameter value that simply duplicates the existing one. Since the standard position with display=title is for the coordinates to appear somewhere near the title, that's reasonably intuitive. And the title will always be somewhere near the top, so display=top is not much more intuitive. But most importantly, there are hundreds of thousands of articles already using display=title, and tens of thousands of editors familiar with the display options. New and old editors would both be confused if they see the documentation advising them to do something that differs from what they see in existing articles, or if they see other editors making changes which differ from the established usage. Also, the documentation would either become even longer if it mitigated confusion by describing both options; or it would exacerbate confusion if it omitted the old option. So I see no net benefit in making such a minor change with such a high impact.

If you are concerned that editors are mistakenly inserting title text instead of the word "title", a better solution would be to improve the documentation; and maybe add a hidden error tracking category for invalid cases. But I haven't noticed this to be a significant problem.

— Richardguk (talk) 01:58, 9 November 2012 (UTC)[reply]

You raise valid concerns, Richard. However, since we already support display=it, display=title,inline, and display=t in addition to the standard display=inline, display=inline,title, and display=title settings, I'm not quite convinced that the confusion engendered by adding two more settings would outweigh the benefits. —Stepheng3 (talk) 02:08, 9 November 2012 (UTC)[reply]

Thanks for the considered response. Though there is already some flexibility, at least the various permutations and abbreviations of inline and/or title are more intuitive than an entirely new synonym for the latter. For example, I can immediately guess on seeing title,inline, inline,title and ti that they are intended to do the same thing in relation to coordinate display. But it is not so clearly self-evident that top and title are meant to be equivalent. The practical effect is that editors would be more likely to turn to the documentation in puzzlement, or that other editors would needlessly amend articles from one form to the other in the mistaken belief that the old (or new) synonym were somehow preferable. So I still think it is better to keep it obvious that there is no semantic difference, by sticking with the current more limited range. — Richardguk (talk) 17:52, 10 November 2012 (UTC)[reply]

What has happened to the coord template? On all UK settlement articles that I have previously added an infobox to (e.g. Sydling St Nicholas, Litton Cheney), the wording "{{#coordinates:}}: cannot have more than one primary tag per page" now appears in bold red text somewhere within the article. ? PaleCloudedWhite (talk) 02:17, 7 December 2012 (UTC)[reply]

When coordinates are specified with latitude and longitude in an infobox, such as in {{Infobox UK place}}, you should not include them again with {{Coord}}. The new {{#coordinates}} function displays an error message where coordinates are specified more than once in the same article, but it has never been intended that coordinates should be specified more than once. To fix this, simply check that the infobox coordinates are specified correctly and remove the coord template completely. The infobox should display the coordinates in the usual way. — Richardguk (talk) 02:35, 7 December 2012 (UTC)[reply]

Thanks. I can see I've got quite a few coord templates to remove..... PaleCloudedWhite (talk) 03:39, 7 December 2012 (UTC)[reply]

See also Wikipedia talk:WikiProject Geographical coordinates/Archive 27#GeoData extension. --Redrose64 (talk) 13:40, 7 December 2012 (UTC)[reply]

Can I suggest these changes are rolled back. The first principles of an edit- is do no harm. Complex infobox templates viz {{Infobox mill building}} have be written based on the de-facto Coord behaviour- and these have held together reliably for years. Now this bug/malfuction/improvement has devastated hundreds of articles and countless templates. ALL 54 members of Category:Textile mills owned by the Lancashire Cotton Corporation are broken. but it has never been intended that coordinates should be specified more than once. is just rewriting history. Roll back, analyse, discuss and then improve please.--ClemRutter (talk) 10:46, 7 December 2012 (UTC)[reply]

The problem on pages using {{Infobox mill building}} is nothing to do with coordinates being specified more than once - for which the error message would be {{#coordinates:}}: cannot have more than one primary tag per page. The actual error message is {{#coordinates:}}: invalid longitude. It's displayed twice on pages like Ainsworth Mill, Breightmet because the coordinates are displayed twice - once in title, once in the infobox, because there are two instance of {{coord}} - one with |display=title the other with |display=inline. Exactly the same message would be shown if instead of two {{coord}} there were just one, which specified |display=inline,title, but the error would then be displayed only once.

The error {{#coordinates:}}: invalid longitude is displayed because {{Infobox mill building}} feeds bad values into {{coord}}. The infobox accepts only two coordinate values, so a point west of Greenwich must be specified as e.g. |latitude=53.5784|longitude=-2.3710. This in itself is perfectly acceptable, but these are then put into {{coord}} with the hemispheres explicitly given as N and E respectively, i.e. {{coord|53.5784|N|-2.3710|E|type:landmark}} which yields 53.5784°N -2.3710°E / 53.5784°N 2.3710°W / 53.5784; -2.3710 Coordinates: longitude degrees < 0 with hemisphere flag
{{#coordinates:}}: invalid longitude. If the hemispheres were simply omitted from the {{coord}}, which is what I suggested first off, this would have become {{coord|53.5784|-2.3710|type:landmark}} which yields 53°34′42″N 2°22′16″W / 53.5784°N 2.3710°W / 53.5784; -2.3710.

The change to {{coord}} has served to highlight a problem which was already inherent to {{Infobox mill building}}, although not obvious unless you looked at the displayed coordinates and saw the negative value associated with East. --Redrose64 (talk) 13:40, 7 December 2012 (UTC)[reply]

Exactly. {{Infobox mill building}} takes exactly the same data that is processed correctly by {{TMtr}} so as to allow an article to develop from a list. (I hadn't noticed the - XX.XXXX E reference that has been there since at least 2009- to much mathematical training! ) but I is certainly wrong that a production version of {{coord}} does not handle a situation of double negative and render correctly rather than throw an error message- or default to blank. If sand boxing the error message is of course correct. User:Redrose64 solution is correct. --ClemRutter (talk) 16:20, 7 December 2012 (UTC)[reply]

Machine handling of double negation is easy but don't forget we're ultimately doing everything for humans, and humans don't need to see what they see now - misleading coordinates like 53.5784°N -2.3710°E. It was perfectly understandable during the extension's development that some existing pages will start displaying error messages, however I'm yet to see a page where GeoData has detected a problem while in fact there's none. Speaking of duplicate title coordinates, even if they match exactly and don't overlap funnily like this, there's no guarantee whatsoever that this will remain to be the case in all situations and for every user agent. So fixing template invocations is always better. Max Semenik (talk) 21:57, 8 December 2012 (UTC)[reply]

I'm wondering is it possible to adjust the new function so that the red error message is always displayed at the bottom of the page, rather than wherever the coord template sits, as is happening at the moment? There must be thousands of articles currently displaying the error message, so it looks like they're not all going to be corrected quickly, yet in the meantime the readers are confronted by rather jarring red text, often right at the top of the page. PaleCloudedWhite (talk) 22:06, 8 December 2012 (UTC)[reply]

Not thousands, just 300, though not all pages with coordinates have been refreshed yet, we're approximately in the middle of this process. And a lot of these pages aren't even in article space. Moving the error message is possible, however it will make identifying and fixing the issue harder, especially in cases like this. Max Semenik (talk) 22:34, 8 December 2012 (UTC)[reply]

(e/c) I think that category is misleading regarding the nature/extent of the problem, perhaps because it only contains pages with malformed coordinates, which doesn't seem to cover duplicated coordinates, which also results in red error text. Here for example is a page (one of dozens in the county of Dorset, UK, that I've been correcting) that has the red error text, but isn't on the category list. PaleCloudedWhite (talk) 22:51, 8 December 2012 (UTC)[reply]

Mmm, the category name can be improved indeed, it is doable with MediaWiki:geodata-broken-tags-category, no developer intervention needed. As of pages with error messages but no tracking category, anonymous editors shouldn't see error messages in them in most cases, as they see a cached version of the page that gets purged only when page is edited or refreshed by job queue - in both cases tracking category also gets added. Max Semenik (talk) 23:05, 8 December 2012 (UTC)[reply]

I don't understand your last sentence about anonymous editors; can you translate for someone who isn't used to dealing with jargon terms like "cached version" and "refreshed by job queue"? I wasn't concerned about editors, but readers. The page that I highlighted above has red error text displayed in it, which all readers can see, yet I couldn't see it on the category, so how will any editors know such articles need fixing, save by stumbling on them by accident? PaleCloudedWhite (talk) 23:15, 8 December 2012 (UTC)[reply]

(edit conflict) CAT:COORD definitely does include pages with two or more sets of coords, because that's how I found and fixed these (and dozens of others).

The job queue is described at Help:Job queue. Briefly, if a category is added because of a change to a template (or parser function), not as a result of a direct edit to the page, the category page is not updated instantly, it's spread over a period of time. That delay in updating is due to the job queue, and until it completes, there may be cases where a cat shows at the bottom of an article, but the article isn't visible on the cat page. If a template change results in a cat being removed, the opposite may happen - the cat disappears from the article page, but the article is still listed on the cat page. --Redrose64 (talk) 23:49, 8 December 2012 (UTC)[reply]

@ MaxSem, PaleCloudedWhite: The job queue has spiralled out of control over the past 2 weeks, which explains the many affected articles which are not yet showing up at Category:Pages with malformed coordinate tags. I have raised this at WT:GEO. — Richardguk (talk) 23:43, 8 December 2012 (UTC)[reply]

Please note discussion at Wikipedia talk:WikiProject Geographical coordinates#GeoData deployed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:46, 8 December 2012 (UTC)[reply]

This is a great feature and it should be visible. I propose increasing the size of the icon and text. Mono 02:09, 17 December 2012 (UTC)[reply]

 Not done for now: please establish a consensus for this alteration before using the {{Edit protected}} template. Maybe you could try starting an RfC and advertising it at the relevant WikiProjects? We need to make sure the consensus for this change is strong as the template is so widely used. — Mr. Stradivarius ^{(have a chat)} 10:09, 17 December 2012 (UTC)[reply]

Too right. The last two edits shoved the job queue through the roof. --Redrose64 (talk) 14:56, 17 December 2012 (UTC)[reply]

A parameter to limit the final display precision would be quite useful. Consider the difference between these two coordinate displays from Mount Ararat:

• {{coord|39.6553|N|44.8034|E }} == 39°39′19″N 44°48′12″E / 39.6553°N 44.8034°E / 39.6553; 44.8034
• {{coord|39.6553|N|44.8034|E|format=dms}} == 39°39′19″N 44°48′12″E / 39.6553°N 44.8034°E / 39.6553; 44.8034

While the dms conversion is fine, in principle, it seems to have problems with repeating decimals. Some way to truncate the result to, say, 3-4 digits post-decimal should be more than sufficient without cluttering up the page with sequences of numbers that will cause readers' eyes to glaze over. siafu (talk) 19:41, 17 December 2012 (UTC)[reply]

The dms conversion is not fine in principle - decimals should only be shown on the least significant component, which in this case is the seconds - both the degrees and the minutes should be integers. It should display as 39°39'19.08"N 44°48'12.24"E, or 39°39'19"N 44°48'12"E if rounding to whole seconds. --Redrose64 (talk) 20:14, 17 December 2012 (UTC)[reply]

(e/c) It used to display correctly, however there's been a change to the way that the Wiki software deals with non-integer division. The problem arose on Commons the other day, but there was a simple fix there [1]. I'll see if it can be applied here.  An optimist on the run! 20:16, 17 December 2012 (UTC)[reply]

FYI, I meant "fine in principle" in that I have no real problem with displaying coords in dms format (even though it's not used in many professional settings), not that it's "fine" in that it's doing the conversion properly. siafu (talk) 20:19, 17 December 2012 (UTC)[reply]

I think I've fixed it.  An optimist on the run! 20:27, 17 December 2012 (UTC)[reply]

Indeed it appears so. Thank you! siafu (talk) 20:35, 17 December 2012 (UTC)[reply]

... and it's sent the job queue soaring --Redrose64 (talk) 22:28, 17 December 2012 (UTC)[reply]

The fix may also have caused or exposed a new bug. —Stepheng3 (talk) 06:32, 18 December 2012 (UTC)[reply]

The fix is fine. It's just that the /dm code path has not been fixed yet. Can an admin please copy User:Hike395/dm to {{coord/dec2dms/dm}}? The test cases are shown at the second and third rows of User:Hike395/sandbox. I am not familiar with how to test proposed changes to subtemplates of {{coord}} --- if I need to create a different test cases, please let me know. —hike395 (talk) 06:53, 18 December 2012 (UTC)[reply]