Template talk:Coord/Archive 10

Latest comment: 10 years ago by Trappist the monk in topic Hiding the coordinates?
Archive 5 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 14

Bug in microformat for non-terrestrial coordinates

There is a bug (or bugs) in this template's emitted microformat for non-terrestrial coordinates. For example, the HTML markup for the infobox on Curiosity rover includes (line breaks added for readability):

<code>
<span style="display:none">
? / 
<span class="geo">-4.6; 137.2</span>
</span>
</code>

Firstly the "? /" appears extraneous; if so, and they can be disposed of, it may be possible to apply style="display:none" to the span with class="geo"

More importatly, the |globe= parameter is not being passed; the HTML should be something like:

<code>
<span style="display:none">
? / 
<span class="geo">
<span class="latitude">-4.6</span>; 
<span class="longitude">137.2</span>; 
<span class="body">mars</span>
</span>
</span>
</code>

per http://microformats.org/wiki/geo-extension-nonWGS84

Fixing this may require attention to the CSS described in Template:Coord#Per-user display customization. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:11, 9 February 2012 (UTC)

Region

Many existing Hong Kong articles are tagged with CN. But a separate code HK exist for the territory. Is it possible to clean this up by a bot? 218.250.159.25 (talk) 19:44, 10 February 2012 (UTC)

Enhance coord

Is there scope to enhance the coord template to include a url to an article and a picture. This is for use with the GeoGroup template so when viewing grouped coords on a map, one can see not just the name, but also see a picture and have a link to the article. There is a difference between grouped points that belong to the article and those that have wikilinks to other articles. The pictures would come from commons.

In my thinking we would have to modify coord to add this but I'm not sure on any impact that might have to anything else that relies on the data in the coord template from an article.

Then the GeoGroup template would need to be altered to use this data if available rather than use the link directly to the source article of the point.

Thanks in advance for any help. DubhEire (talk) 10:26, 18 February 2012 (UTC)

Display in Google Maps/Earth etc - redirects

Re: User_talk:Mddkpp#Magna_Park.2C_Milton_Keynes and User_talk:John_Maynard_Friedman#Magna_Park - there appears to be an issue with content with "coord : display=title" used in a redirects (similar to the principle of categorising redirects I suppose) not appearing.

Additionally I have several examples were having a coord with "display=inline" being parsed and displayed by google maps etc makes sense..

Is there anyway to do this? or is it entirely in google's hands.. Is there an accepted 'kludge' that can be used - maybe somesort of non-displaying template or use of subpages?? ThanksMddkpp (talk) 18:07, 23 February 2012 (UTC)

Discussion at WT:MOSICON regarding this template

I started a discussion at WT:MOSICON regarding the use of this template in prose as it pertains to WP:MOSICON. Your input is appreciated. Thanks. –Fredddie 00:20, 27 February 2012 (UTC)

"A" HTML tag closed early

In text browsers one can see only part of the coordinates are linked.

Coordinates: 24°10′54″N 120°51′58″E / 24.18170479°N
____________ ____________

Why don't you have a good look at where you close your "A" HTML tag!!

Jidanni (talk) 05:35, 27 February 2012 (UTC)

Overprinting

On my user page I use your template.

As we hit CTRL+++++ in our browser, other words overprint it.

Please use proper HTML.

Seen in Mozilla/5.0 (X11; Linux i686; rv:12.0a2) Gecko/20120224 Firefox/12.0a2 Iceweasel/12.0a2

Jidanni (talk) 05:31, 27 February 2012 (UTC)

For those who don't speak Microsoft Windows, that means that the overlapping occurs when the user increases the font size of everything on the page by 5 "bigger" steps. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 18:17, 8 March 2012 (UTC)

Make icon display optional

This template is causing endless bickering because of its forcing an icon into running prose, against MOS:ICONS. This only ever makes sense when the template is used at top right corner of the page, and this "feature" needs to be tied to such placement. If it's used inline, it can't insert a graphical icon like that. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 17:50, 8 March 2012 (UTC)

That is just plain wrong. The feature makes sens in prose text as well. It is not a decorative icon, but a functional widget. Clicking the button opens a little map. This is useful for all coordinates, not just an arbitrary subset (title coordinates). You can switch off the icon by putting this
var wma_settings =
{
 flowTextTooltips : true
}
in your vector.js file. I presented that method on the MOS page, but did not get feedback on whether it would be a better default behavior. So just quit the "bickering" and give your opinion. The "blatantly obvious" statement that you left in the MOS discussion was a bit unqualified. You seemed not to have understood neither the propose nor the origin of the "icon". It has nothing to to with this template. --Dschwen 18:08, 8 March 2012 (UTC)
This isn't about whether logged-in users can do geeky things with Javascript, it's about not having icons appear in the middle of prose, for all users. I'm not bickering, I'm reporting that this is widely viewed as problematic and a solution needs to be found. I detect a notable degree of anger, irritation and impatience in your response. This strongly suggests you are tired of this debate. Which strongly suggests it is one that is brought by various people, many times, all over the place, from MOS pages (I can attest to that - it's come up more than once at both WP:MOS and WT:MOSICONS), to this talk page (its archives bear this out) to the talk pages of many articles and wikprojects (I know I've seen it before in "Talk:" space, and it is an open discussion at WT:MILHIST right now, for example), and the issue just won't go away. This in turn strongly suggests a lot of people disagree with using this and other templates (even if they don't start a new thread about it every day) to insert goofy icons in the middle of sentences, and rather than make a case for doing so, you'd rather be dismissive and pretend that no one disagrees with you. I don't think anyone cares where the icon comes from; this is the web, and it's a simple matter to code things differently so that there's a non-graphical version of this widget. Even the fact that the icon is functional doesn't mean necessarily that this functionality has be including in the inline version anyway, even if it's not done graphically. (The fact that a feature is possible to implement doesn't mean that it must be implemented in every possible context; this is utterly elementary human interface common sense.) — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 18:56, 8 March 2012 (UTC)
And by the way, even if the "bickering" is endless, it occurs at a very low frequency. It is basically only half a handful of very vocal people that mention it once every two years. The few million other users don't seem to have a problem with it. --Dschwen 18:11, 8 March 2012 (UTC)
Just because you like to pretend no one disagrees with you doesn't mean no one disagrees with you. The entire MOS:ICONS guideline, with hundreds of editors, has evolved precisely too prevent the use of iconic graphics in running prose as well as purely decorative use of iconic graphics in tables and lists. The fact that the average reader doesn't get involved in disputes about templates and features, or even know how to, doesn't mean they don't find it jarring to have an icon pop up in the middle of a phrase in an article. Surely you know this. So, quit being reflexively hostile, and maybe instead suggest a solution to the image. "Lead, follow or get out of the way". — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 18:56, 8 March 2012 (UTC)
In any case the globe icon isn't generated by this template, any of its subtemplates, or by CSS styling within those templates. The MediaWiki parser detects the use of the URL for the geohack page on toolserver, and forces the icon in. You can test that theory by adding a direct coordinate link without using templates or any of the <span>...</span> tags like this. --Redrose64 (talk) 19:46, 8 March 2012 (UTC)
That's right. See also Template talk:Coord/Archive 5. De728631 (talk) 20:27, 8 March 2012 (UTC)
No, I'm afraid that is not quite right. It is not the parser, it is a piece of Javascript. Guys, please read what is written above. I give an example on how to deactivate the icon in prose text (and replace it with a non obstrusve tooltip). If that is what people want, I can simply make that setting the default. --Dschwen 20:34, 8 March 2012 (UTC)
Please note prior and ongoing discussion at Wikipedia talk:Manual of Style/Icons#Does Template:Coord violate MOSICON when used in prose?, where a solution has already been proposed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:37, 8 March 2012 (UTC)
WP:MULTI ignored yet again. --Redrose64 (talk) 21:09, 8 March 2012 (UTC)
A little less finger wagging, please. The same topic came up more or less independently on multiple talk pages. --Dschwen 21:27, 8 March 2012 (UTC)

Replacement for icon in inline usage

How about a parameter, e.g. |map=, such that {{coord|22|54|30|S|43|14|37|W}} would output something like 22°54′30″S 43°14′37″W / 22.90833°S 43.24361°W / -22.90833; -43.24361[map] where "map" is a link that pop up the same WikiMiniAtlas as the icon-widget does in non-inline display? And have {{coord|22|54|30|S|43|14|37|W}} do what just {{coord|22|54|30|S|43|14|37|W}} used to? Or something like that. There are cases where inline usage may be desired to have the icon-widget, like in non-articles, and tables and such.

The WikiMiniAtlas should autodectect coordinates in tables and still add the icon there. The popup should only appear in flow text. Let me know if there are cases where this autodetection does not work. --Dschwen 02:37, 17 March 2012 (UTC)
Haven't seen any. Didn't know about the table auto-detection. Is there a way to override it? And a way to override the the flow autodetection? Like, one might have something table-like that is actually not a table, perhaps a short list, and want the table-style display with icons, or have running prose that happens to be in a table cell and not want the icon. Maybe too complicated to bother with. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 03:47, 17 March 2012 (UTC)
No not yet, but I'd be happy to work on that once it becomes a concrete issue. I wasn't a big fan of these customizations mainly because I think predictability is important in a UI. --Dschwen 04:28, 17 March 2012 (UTC)

Give some air

Hello,

The template gives this :

57°18′22.5″N 4°27′32.7″W

This is too much stuck. Please give some air. Respect usage, geographical convention, and the Wikipedia Manual of Style. Please replace this with that, with non-breaking spaces :

57° 18′ 22.5″ N 4° 27′ 32.7″ W

Thanks.

--Nnemo (talk) 00:08, 19 March 2012 (UTC)

  • Support. I think that's a good idea, the string can be read much better with spaces inserted. De728631 (talk) 00:49, 19 March 2012 (UTC)
  • Comment This was brought up at Template talk:Coord/Archive 8#readability of dm and dms formats (′W, etc.) where my suggestion to use thin non-breaking speces was not taken up. Note that the "beta" referred to in that thread is what we now know as the Vector skin; but subsequent changes mean that Vector and MonoBook now use the same font styling for title coords. --Redrose64 (talk) 11:53, 19 March 2012 (UTC)
  • There are external tools which read off these values (see Template:Coord#Caveats). We would need to check that this won't break them. Looking at [1], they may (I don't know) read off the contents of <span class="latitude"> and <span class="longitude">, in which case I don't know if an extra space (say, after the degree symbol) might break something. Can anyone check how these values are normally parsed, and if this would cause a problem? Tra (Talk) 20:13, 20 March 2012 (UTC)
    • In this case, I would rather say : they would want to check that this won't break them. --Nnemo (talk) 01:05, 22 March 2012 (UTC)

Other project problem

I have installed this template on a off wiki project and have a display problem which I'm stumped, the template displays on the left side of the page instead of the right above the infobox here any ideas ? Mlpearc (powwow) 17:51, 8 April 2012 (UTC)

Your wiki lacks at least one template. If you edit the page, and look at the stuff below the "Save page" buttons etc. there is a list of templates. One of these, Template:Precision/tz, is a redlink. --Redrose64 (talk) 22:39, 9 April 2012 (UTC)
Thank you, how embarrassing I know this stuff this is a rookie overlook :P thanx for the wake up   Mlpearc (powwow) 21:56, 10 April 2012 (UTC)

new interwiki

Hi! This page Hungary name: Sablon:Koord!

Thank you! --B.Zsolt (talk) 20:37, 19 April 2012 (UTC)

  Done, see here --Redrose64 (talk) 20:59, 19 April 2012 (UTC)

Tooltip problem in Firefox/Mac

  Resolved
 – Fixed on the Firefox end, apparently.

The problem reported here affects Firefox 11 on Mac OS X 10.7; does not affect Safari or Chrome on the same OS. Didn't test further.

The mouseover pop-up "tooltip" with the WikiMiniAtlas icon widget isn't working properly when the {{coord}} isn't at the beginning of the line (or list item or whatever). The tooltip appears where it would if the template were at the beginning of the line.item, but is too far away to be moused to and clicked. Test cases:

22°54′30″S 43°14′37″W / 22.90833°S 43.24361°W / -22.90833; -43.24361

works fine, as does this one:

22°54′30″S 43°14′37″W / 22.90833°S 43.24361°W / -22.90833; -43.24361

But this one:

Lorem ipsum dolor sit amet consectetur adipisicing elit sed do eiusmod tempor incididunt ut labore 22°54′30″S 43°14′37″W / 22.90833°S 43.24361°W / -22.90833; -43.24361

has an unusable tooltip at most window widths (it will work if by chance the prose wraps such that the template is near the left edge of the page).

SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 01:33, 17 March 2012 (UTC)

This is no longer happening under Firefox 12. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 00:09, 3 May 2012 (UTC)
Uhgh, sorry I did not see this section at all, but I'm glad it is resolved. Maybe it should be advertised a bit more to drop me a line on my talk page when WMA-related problems occur. --Dschwen 01:14, 3 May 2012 (UTC)

Where is a river?

Is there a consensus or agreed convention about where to identify the location coordinates for a river? At its source? Midway along its course? At its mouth? Or just any old place? — O'Dea (talk) 13:33, 6 May 2012 (UTC)

Yes, there is a consensus. In the infobox source and mouth are tagged, as far as I know. You can take a look at {{AttachedKML}} if you want to add the entire course of the river. --Dschwen 13:52, 6 May 2012 (UTC)
Thank you, but if I don't know the course of the river which which to make a KML file because the river runs underground during parts of its course, and if I don't know how to make a KML file, anyway, so I will be using a COORD template, then, is there a consensus or agreed convention about where to identify the location coordinates for a river, if I will only be identifying one part of the river? After all, the COORD template does have a RIVER parameter so I am inquiring about its agreed conventonal usage. If I am to use COORD with RIVER enabled, then which part of the river do I stab the location marker into? — O'Dea (talk) 16:22, 6 May 2012 (UTC)
See Wikipedia:WikiProject Geographical coordinates/Linear; you can also use multiple instances of {{Coord}}, one at each key feature, as on, for example, River Tame, West Midlands. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:26, 6 May 2012 (UTC)
If only one point is used, it is the location of the mouth. —EncMstr (talk) 19:16, 6 May 2012 (UTC)

Request that {{Coord/prec dec}} be edited

With the deployment of 1.20wmf2 it has become evident that many articles exceed the expansion depth limit. See this. I have requested an edit to {{Infobox coord}} and that will, marginally, reduce the expansion depth in many articles. Replacing {{Coord/prec dec}} with the modified version in that template's sandbox will reduce the expansion depth a bit more. Test cases are heredroll [chat] 06:36, 8 May 2012 (UTC)

On that page, you say ". I had to remove some error checking to reduce the expansion depth. This is far form ideal.". Does anyone have a fix for this or do we have to live with it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:29, 8 May 2012 (UTC)
  Done -- WOSlinker (talk) 22:44, 8 May 2012 (UTC)
Does anyone know when the Lua support for templates is supposed to arrive? --Dschwen 23:39, 8 May 2012 (UTC)
Thanks for the edit.
I'm not an insider but "it will be early 2013 by the time of rollout to WMF sites", according to mw:Lua scripting/status. I bet there will be some limit on recursion and the level of nesting allowed. –droll [chat] 01:05, 9 May 2012 (UTC)

"WikiMiniAtlas"

E.g.: 81°18′N 110°48′W / 81.3°N 110.8°W / 81.3; -110.8

Using Win 7 / IE9. When I place the mouse over this link I get two little pop-ups. One is in the usual IE mouseover text style and says "Maps, aerial photos, and other data for this location". The other is in a slightly different style and has a little globe icon followed by the text "WikiMiniAtlas". The first pop-up overlays the second, partly obscuring it. The visual impression is that you might be able to click on the little globe icon (especially since it seems to include a small arrow, suggesting that if you click it then something will happen). However, I am unable to click on it because when I move the cursor to do so the icon disappears. I am unclear what "WikiMiniAtlas" is, or how it differs, if at all, from the "GeoHack" page that you get to when you click the main link, which seems to be what is described by the "Maps, aerial photos, and other data for this location" text. If there is no difference then I suggest that the "WikiMiniAtlas" popup is just removed because it's visually confusing. If there is a difference then maybe something is not working in IE that works in other browsers? 86.181.172.218 (talk) 20:48, 25 May 2012 (UTC)

Wiki Mini Atlas is a surprisingly versatile inline mapping tool. If you can trick IE sufficiently to click on the globe icon, you will see all kinds of great things: maps, options, size comparisons, etc.
Alas, IE is not the most conforming-to-expectations of browsers. Any reason you cannot use a standards-compliant browser like Firefox? —EncMstr (talk) 21:23, 25 May 2012 (UTC)
Any reason why the feature doesn't work in a browser used by more than 30% of users? What happens in other browsers? How do you click on the globe icon? Does it not disappear when you move the mouse towards it? 86.181.172.218 (talk) 21:45, 25 May 2012 (UTC)
OK, now I have got it to work. If I am very quick I can get the mouse to the icon and click it before it disappears. However, it is difficult and non-intuitive. Why does the pop-up disappear so quickly? 86.181.172.218 (talk) 21:54, 25 May 2012 (UTC)
 
Rendering on Firefox 12 on Linux Fedora 16
You'll have to ask Microsoft why they do things the way they do. (Good luck getting an answer.)
I have included a piece of a screenshot showing what happens with Firefox on Linux. The title popup did not capture, but it was positioned below and to the right of the WikiMiniAtlas text, enough out of the way to be useful, but not confusingly disconnected either. —EncMstr (talk) 23:13, 25 May 2012 (UTC)
Thanks. It would be nice to get it working more sensibly in IE. Please excuse me, because I do not wish to be rude to you or anyone else here, but I am rather tired of people holding their hands up in horror when I mention using IE, like I'm some kind of child molester or something. All browsers have their idiosyncracies, and we should not ignore the one that, still, is probably used by more people than any other. 86.181.172.218 (talk) 00:13, 26 May 2012 (UTC)
See the first thread on this page... problems with WikiMiniAtlas can be directed at the talk page of Dschwen (talk · contribs). --Redrose64 (talk) 10:14, 26 May 2012 (UTC)

type:landmark off Earth

I just removed type:landmark from Thor (volcano) and Tirawa (crater) to get them off Earth. I assume there is actually an error in the coord template.  Randall Bart   Talk  18:15, 22 June 2012 (UTC)

I don't see how removing type:landmark from these {{Coord}} templates changes anything. Please explain in more detail why you believe this was the right thing to do. Best regards, —Stepheng3 (talk) 23:24, 22 June 2012 (UTC)

These two items were showing up on Earth. Clicking the link took you to a map of Earth, and Google Maps was flagging their locations. It appears that Globe was (still is?) ignored when Landmark was used, so I removed landmark to put those items on their proper globes.

But I really need to know where do we discuss Google maps problems?  Randall Bart   Talk  00:32, 7 August 2012 (UTC)

Edit request on 10:53, 1 July 2012 (UTC)

  Unresolved

The <font> HTML element is deprecated. <font color="red"> must be changed to <span style="color:red"> and </font> to </span>. jfd34 (talk) 10:53, 1 July 2012 (UTC)

I support the change. —Stepheng3 (talk) 16:31, 1 July 2012 (UTC)
Why isn't it at Template:coord/input/error? Would <span class="errormsg"> be better since it's detected by #iferror:? — Dispenser 19:59, 1 July 2012 (UTC)
Answer: to reduce the potential confusion with Template:coord/input/ERROR. —Stepheng3 (talk) 21:13, 4 July 2012 (UTC)
The same change must be made to Template:coord/input/ERROR as well. jfd34 (talk) 09:53, 5 July 2012 (UTC)

Rather than hand-coding HTML here, does using {{error}} work here? If so I'll sync. Chris Cunningham (user:thumperward) (talk) 11:24, 10 July 2012 (UTC)

Disabling for now pending feedback. We need to discuss the best markup to use here. Chris Cunningham (user:thumperward) (talk) 11:43, 22 July 2012 (UTC)
I would advise against using {{error}}. Coord already contains too many nested templates thta put quite a strain on the parser and limit the number of emplates that can be used on a page. --Dschwen 14:47, 22 July 2012 (UTC)

Do we have a decision on how to deal with this? I think we're all agreed that <font color="red"> must go. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:06, 7 August 2012 (UTC)

Unsourced Coordinates

Could the template be amended so that 'unsourced' co-ordinates are categorised into a maintenance categeory? Sfan00 IMG (talk) 12:19, 4 July 2012 (UTC)

That is going to be huge. Not every set of coordinates is given by direct use of {{coord}}; many instances come from the |latitude=|longitude= parameters (or equivalent) found in many infoboxes - these often construct a {{coord}} with region: and type: (sometimes scale: or dim:), but rarely is source: specified. I guess this is because dim:, region:, scale: and type: can be seen to have a direct effect on the maps offered, whereas source: has no visible effect. --Redrose64 (talk) 14:07, 4 July 2012 (UTC)
Well can it at least be updated in respect of the direct transclusions then? Sfan00 IMG (talk) 14:43, 4 July 2012 (UTC)
How would we tell the difference? --Redrose64 (talk) 16:10, 4 July 2012 (UTC)
OK. I still think unsourced geo-data needs to be flagged in some way Sfan00 IMG (talk) 16:32, 4 July 2012 (UTC)
Why do you want them flagged? Coordinates are easy to verify and seldom contentious. —Stepheng3 (talk) 20:26, 4 July 2012 (UTC)
I agree with Stepheng3, flagging unsourced coordinates by default would be overkill. De728631 (talk) 20:58, 4 July 2012 (UTC)
They should be flagged, because other data on Wikipedia requires citations. I don't see why Geodata should be exempt. Sfan00 IMG (talk) 21:42, 4 July 2012 (UTC)
Surely they are directly verifiable? That is, you click them, pick a mapping service and click that, and check that the spot indicated shows the feature concerned. If it doesn't, try a different mapping service. --Redrose64 (talk) 22:14, 4 July 2012 (UTC)
They maybe directly verifiable, but they still need to be cited. Also some mapping providers gat annoyed when they aren't attributed somehow. The other concern is that without the sourcing it's impossible to know what in terms of co-oridinate GeoData has come from 'free' sources, what has come from 'Propiatery' sources, and whats been made up.

Adding a source field to all coordinates will help remove that issue. 23:27, 4 July 2012 (UTC) — Preceding unsigned comment added by Sfan00 IMG (talkcontribs)

It might be possible to create a nightly report on instances of the {{Coord}} template which lack the "source:" and/or "notes=" parameters. Would that satisfy the perceived need? —Stepheng3 (talk) 02:28, 5 July 2012 (UTC)
Yes, The idea is here is to encourage people to 'find' the data, I also think WP:NOR needs a revision to allow people to physically get co-ordinates from GPS/Galileio etc.. themseleves. Sfan00 IMG (talk) 08:02, 5 July 2012 (UTC)
I recall previous debate about the admissibility (or otherwise) of coords obtained from GPS or from mapreading. Wikipedia:Templates for discussion/Log/2011 November 22#Template:Infobox ukcave; Template talk:Infobox cave#Merge from Template:Infobox ukcave; Template talk:Infobox cave#location_ref. --Redrose64 (talk) 13:37, 5 July 2012 (UTC)
I see that with this bot edit, coords were added sourced to "enwiki", presumably English Wikipedia; but no indication of just where in enwiki that was. Sourcing content to English Wikipedia surely goes against WP:CIRCULAR? --Redrose64 (talk) 11:20, 8 July 2012 (UTC)
I believe "source:" was intended to prevent circularity, not provide verifiability. For verifiability, use "notes=". —Stepheng3 (talk) 14:22, 8 July 2012 (UTC)
Previous consensus has been that coordinates are generally self-verifying and do not need a cited source. I think you need to demonstrate a general agreement to the contrary, if you can (I'd be opposed), before making template and documentation changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:12, 14 July 2012 (UTC)
Well, it seems consensus is that coordinates don't need to be routinely sourced, which makes it harder to determine what's come from Google/Bing/OSM etc... Sfan00 IMG (talk) 17:20, 14 July 2012 (UTC)
I think you were right the first time. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:28, 14 July 2012 (UTC)

Google Maps

Where do we discuss the way that these articles show up on Google Maps?  Randall Bart   Talk  00:50, 7 August 2012 (UTC)

Try WT:GEO. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:04, 7 August 2012 (UTC)
Or call Google ;-) --Dschwen 02:11, 8 August 2012 (UTC)

Globe icon

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)

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)
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)
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)
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)
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)
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)
LOL... In before matter of factly response about pointless numbers. - Floydian τ ¢ 21:23, 27 September 2012 (UTC)
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)

Default map mode

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)

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)

Coord#globe:G

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)

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

Globe icon not showing

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 (talkcontribs) 04:03, 27 October 2012 (UTC)

It was disabled with this edit. The reason is in the edit summary. --Redrose64 (talk) 13:56, 27 October 2012 (UTC)
OK, thanks for the info. –– Anonymouse321 (talkcontribs) 15:18, 27 October 2012 (UTC)
It looks like the globe icon is back. –– Anonymouse321 (talkcontribs) 04:28, 28 October 2012 (UTC)
That would be this edit then. --Redrose64 (talk) 13:13, 28 October 2012 (UTC)

display parameter

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)

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)
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)
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)
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)
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)
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)
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)

Improved error detection

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)

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)
Thanks. I can see I've got quite a few coord templates to remove..... PaleCloudedWhite (talk) 03:39, 7 December 2012 (UTC)
See also Wikipedia talk:WikiProject Geographical coordinates/Archive 27#GeoData extension. --Redrose64 (talk) 13:40, 7 December 2012 (UTC)
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)
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)
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)
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)
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)
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)
(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)
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)
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)
(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)
@ 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)

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)

Make it bigger

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)

  Not done: 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)
Too right. The last two edits shoved the job queue through the roof. --Redrose64 (talk) 14:56, 17 December 2012 (UTC)

Precision

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

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)

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)
(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 [2]. I'll see if it can be applied here.  An optimist on the run! 20:16, 17 December 2012 (UTC)
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)
I think I've fixed it.  An optimist on the run! 20:27, 17 December 2012 (UTC)
Indeed it appears so. Thank you! siafu (talk) 20:35, 17 December 2012 (UTC)
... and it's sent the job queue soaring --Redrose64 (talk) 22:28, 17 December 2012 (UTC)
The fix may also have caused or exposed a new bug. —Stepheng3 (talk) 06:32, 18 December 2012 (UTC)

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)

  Done. Probably sending the queue sky-high again, but who cares? If they don't like it, they should have given us more warning or the software change. Or any at all.  An optimist on the run! 07:08, 18 December 2012 (UTC)

Found that the /dm1 and /dms1 code paths also have the same problem. Applied the same fix. Can an admin please copy User:Hike395/dm1 to {{coord/dec2dms/dm1}} and copy User:Hike395/dms1 to {{coord/dec2dms/dms1}}? The test cases are the last 4 rows at User:Hike395/sandbox. Thank you. —hike395 (talk) 07:19, 18 December 2012 (UTC)

I am going to temporarily retract my edit request. After looking over the dm and dm1 code, I think that the code is simply wrong. I will attempt a fix of at least these two code paths, and then re-request the edit request. —hike395 (talk) 08:04, 18 December 2012 (UTC)

I believe that I have fixed /dm and /dm1. The existing template does not round correctly --- it turns 2'28" into 3'. The change to the mod function also broke the existing template.

It turns out that the parameters to these templates are always positive, which makes fixing the rounding relatively easy. The only subtle thing is in the /dm1 template, making sure that there is always one digit after the minutes decimal place, and that the minutes are always zero padded to have 2 digits before the decimal place.

Everything is tested at User:Hike395/sandbox. Other editors should feel free to look at the code. /dms1 will have to wait for another day. Admin: please copy User:Hike395/dm to {{coord/dec2dms/dm}}, and copy User:Hike395/dm1 to {{coord/dec2dms/dm1}}. Thanks! —hike395 (talk) 09:19, 18 December 2012 (UTC)

Both   Done. Thanks for finding a solution to this.  An optimist on the run! 13:08, 18 December 2012 (UTC)
Thanks for figuring this all out. Followup should include augmenting the test cases at Template:Coord/testcases. —Stepheng3 (talk) 17:45, 18 December 2012 (UTC)

title coordinates not tagged as primary

In response to this issue, I've coded a two-line fix in the sandbox. If someone would review the fix for correctness and completeness, I'd appreciate it. —Stepheng3 (talk) 00:30, 24 December 2012 (UTC)

Yes, the two sets of aliases (one for inline,title the other for title) are now tested consistently. --Redrose64 (talk) 11:20, 24 December 2012 (UTC)
Some admin please copy the sandbox to the live template. —Stepheng3 (talk) 22:58, 24 December 2012 (UTC)
  DoneMr. Stradivarius (have a chat) 08:44, 25 December 2012 (UTC)
Thank you! —Stepheng3 (talk) 08:59, 25 December 2012 (UTC)

Placement of coordinates

There is a discussion at Wikipedia talk:WikiProject Trains#Coordinates in infoboxes arising from a user deleting coordinates from infoboxes. AFAIK it is normal to put the coords of the article subject in the infobox if there is one and it has that feature so as to display both in the infobox and the title. And if there is no infobox, it is the norm to place the "coord" template above the list of categories, but force it to display in the title. Could we insert a sentence or two to the effect that this is the preferred practice (unless exceptionally there is a good reason not to) in the article documentation to make it clear? --Bermicourt (talk) 07:27, 18 January 2013 (UTC)

Fine with me to document common practice as the norm. One advantage of putting coordinates in an infobox (when the box has separate fields for latitude and longitude) is that this enables the infobox to display a location map. One exceptional case when I would put a {{Coord}} template above the infobox or above the References section would be when I wish to cite a reference for the coordinates. —Stepheng3 (talk) 15:44, 18 January 2013 (UTC)
Agree --- this is truly common practice. Many infoboxes have parameters to allow referencing of coordinates, so hopefully Stepheng3's exception is rare. —hike395 (talk) 17:42, 18 January 2013 (UTC)

Documentation change request

In the documentation for this template, in the discussion of the region parameter, is a little table listing examples of some region codes; title is "Examples of ISO 3166-1 alpha-2 codes:" I think the links to the countries in this table should link to the ISO 3166-2 pages rather than to the countries. Having a link to Brazil, for example, is pretty much useless here. The user does not want to read about Brazil, but about the ISO codes. Here is way the items should link:

•••Life of Riley (TC) 02:08, 20 January 2013 (UTC)

It's in Wikipedia:WikiProject Geographical coordinates/region:. How about this?
--Redrose64 (talk) 14:47, 20 January 2013 (UTC)

In this context, why do we need links at all? If we must have them, then:

  • AQ Antarctica

would be a better format. We should give fewer examples, also. I've boldly done that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:34, 20 January 2013 (UTC)

  • Concur with Andy. That would seem to be the best format. •••Life of Riley (TC) 18:01, 20 January 2013 (UTC)

Help Request

W.Punjabi wikipedia is relatively a new wikipedia. We at our Wikipedia: W.Punjabi WIkipedia.org [3] want to use coordiantion system. Help is requested from experienced users to help us. Or tell us where we can find it. Help should be in detailed and step by step form for easy understanding of application. My first poor try can be seen in the lower portion of this page infobox [4]. Please reply here on this page.--Khalid Mahmood (talk) 12:47, 5 February 2013 (UTC)

font-size of #coordinates from 85 % to 92%

See MediaWiki talk:Vector.css#font-size of #coordinates from 85 % to 92%. —Ruud 09:41, 16 February 2013 (UTC)

Template:Coor d

{{Coor d}} is finally unused in article space. Like the other former coordinates templates, it should now be redirected to {{Coord}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:14, 7 March 2013 (UTC)

{{Editprotected}} added (the relevant talk page already redirects here). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:50, 11 March 2013 (UTC)
  DoneMr. Stradivarius ♪ talk ♪ 14:10, 11 March 2013 (UTC)
Thank you. This ends a conversion process that I initiated in 2007! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:53, 11 March 2013 (UTC)

Lua replacement

We are getting closer to the point of being able to replace the current template {{coord}} with the Lua based version in {{coord/sandbox}}. My benchmarking suggests that the replacement will takes us from around 14 Coord calls per second to around 45 Coord calls per second. Much of the lag that is left actually seems to be associated with the #coordinates parser function which stores location information in the database, as the formatting part of the Lua Coord calls runs very, very fast.

There are some minor variations in the Lua version from the current version.

  1. The Lua code maintains trailing zeros on decimal expansions when necessary to reach the requested precision, the current template will drop these.
  2. The Lua code is more verbose in generating error messages.
  3. The Lua code traps all formatting errors to Category:Pages with malformed coordinate tags rather than just some errors.

Template:Coord/testcases shows examples of both working results and error messages shown on malformed results. Module_talk:Coordinates/tests also shows example of the current template output and the current Lua draft. Dragons flight (talk) 19:23, 5 March 2013 (UTC)

A very useful side effect of the switch to Lua is that more than 400 instances of {{coord}} can now appear successfully on one page. Years ago, I had split List of canals in Oregon—with a total of 661 coordinates—into two articles to get around the template expansion limitation. I have remerged the articles. It mostly works, though sometimes there is a server timeout. However, it has yet to fail to display all the coordinates—before it would display the first 300-some coordinates and then blank the rest out. A job well done! Thanks, —EncMstr (talk) 00:56, 11 March 2013 (UTC)
I measure 57 seconds -- I wouldn't really count that as "mostly working". If you also use the Lua version of {{convert}} then it only takes 20 seconds, which is somewhat closer to working. -- Tim Starling (talk) 06:11, 14 March 2013 (UTC)
I was not aware there was a Lua version of convert. It does not appear you saved a modified version (why not?), so I'll see if I can figure out how to set up the Lua version of convert. (Looks like an explicit invocation might be called for, like {{#module:convert}}. Am I close?) I, too, am seeing Served by mw1111 in 51.875 secs. as is. What is your threshold for "working"? Ten seconds? —EncMstr (talk) 08:32, 14 March 2013 (UTC)
Lua convert is not yet installed because it is still being developed and won't cover all cases that {{convert}} does. It might be functional enough for certain pages, but I'd generally suggest waiting until they get it finished. Dragons flight (talk) 15:39, 14 March 2013 (UTC)

Formats

It would be of huge benefit to us translators if the new template could also cope with coordinates presented in the format dd/mm/ss/NS and dd/mm/ss/EW for latitude and longitude parameters. This would greatly simplify process for importing infoboxes, since lat and long are often in that format and the result is we waste lots of time manually converting dms to decimal on a calculator and then changing the data in the infoboxes. --Bermicourt (talk) 17:41, 6 March 2013 (UTC)

{{Coord}} can already handle DMS values. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:11, 7 March 2013 (UTC)
But not the slashes. Dewiki uses slashes, but enwiki found it too difficult to parse. —Stepheng3 (talk) 17:13, 7 March 2013 (UTC)
Can you show some exact examples of what you mean, i.e. is that {{coord| 15/24/32/N | 18/59/02/W }} or {{coord| 15/24/32 | N | 18/59/02 | W }} or what? Obviously, the standard format {{coord| 15 | 24 | 32 | N | 18 | 59 | 02 | W }} = 15°24′32″N 18°59′02″W / 15.40889°N 18.98389°W / 15.40889; -18.98389, already works, so I'm not sure why one would need to get out a calculator. A link to relevant examples on dewiki might also help. Dragons flight (talk) 17:39, 7 March 2013 (UTC)
de:Brandenburger Tor#Einzelnachweise contains the line
{{Coordinate |NS=52/30/59/N |EW=13/22/40/E |type=landmark |region=DE-BE}}
Our own {{coordinate}} template takes similar input and converts it; {{Coordinate|NS=52/30/59/N|EW=13/22/40/E|type=landmark}} displays as 52°30′59″N 13°22′40″E / 52.51639°N 13.37778°E / 52.51639; 13.37778. I'm sure we discussed this very matter two or three years back. --Redrose64 (talk) 19:13, 7 March 2013 (UTC)
Just found Template talk:Coord/Archive 9#Reading imported coord formats; there may have been others. --Redrose64 (talk) 19:15, 7 March 2013 (UTC)
@Dragon's flight. The most common problem I come across is copying an infobox from German wiki when I'm translating the article. Typically the infobox parameters look like: |BREITENGRAD=47/09/46/N and |LÄNGENGRAD=13/23/38/E for the lat and long coords respectively. These are usually only recognised by the various templates that handle such situations if the coords are manually converted to decimal. I've tried sorting this out but my template skills aren't up to it! For a recent article I translated, see de:Weißeck for the German original and Weißeck for the English wiki version where I've had to convert the coords. It's not too big a deal for one infobox, but I've already translated over 3,000 articles and it gets tedious when a fix would handle it automatically.
@Redrose64. Yes, you're right, I did raise it before. It was suggested I use {{coordinate}}, but I couldn't see how to get it to work and gave up I'm afraid. Sorry. --Bermicourt (talk) 15:25, 11 March 2013 (UTC)

Leading zeroes

Hi! Shouldn't minutes and seconds have leading zeroes if they are less than 10? For instance, I guess it should be 10°02′04″N 10°01′05″W instead of 10°2′4″N 10°1′5″W --DixonD (talk) 21:47, 21 March 2013 (UTC)

Up until now, that's been at the editor's discretion. See archived discussion at Wikipedia talk:WikiProject Geographical coordinates/Archive_28#Leading_zeroes. Why do you believe there should be leading zeroes in the minutes and seconds? —Stepheng3 (talk) 23:53, 21 March 2013 (UTC)
Is "0000000012 per dozen" more correct than "12 per dozen"? Since most coordinates are for processing by humans or (presumably) smart machines, I expect the more direct, less verbose form would be preferred. As far as I know, only iron dinosaurs running ancient software, often written in COBOL or FORTRAN, prefer leading zeros.
Additionally, using degrees, minutes, and second is quaint: a convention of the old days when paper maps had grids with subdivisions based on those. Most people now use digital maps or GPS devices, etc. For those, it is generally more convenient to input and output those as signed decimal degrees, such as 10.034443,-10.018158 or, if needed to clarify that is a location where the context is ambiguous, 10.034443 N 10.018158 WEncMstr (talk) 06:36, 22 March 2013 (UTC)
I find that quite arch and cavalier - you are saying human beings should be more like machines rather than the other way? I am quite happy with one degree of latitude being 100km, which makes one minute about 1600 metres and one second of arc less than 30 metres. But decimals leave me completely cold, especially with people's obsession with 6 or 8 decimal places. Leading zero too is important, as it is a place-filler, so you know there is nothing missing.
John of Cromer in Philippines (talk) mytime= Mon 22:17, wikitime= 14:17, 15 April 2013 (UTC)

Statistics, Geolocated article

As in the French Wikipedia, I would like to change {{Coord/display/inline,title}} and {{Coord/display/title}} (See http://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le%3ACoord%2Fdisplay%2Finline%2Ctitle&diff=91902006&oldid=91897673).

I would like to add

{{#ifeq: {{NAMESPACE}}| {{ns:0}}|[[Category:Geolocated article]]}}

.

Then in Category:Geolocated article, we can see the number of geolocated articles, as in fr:Catégorie:Article géolocalisé.

How would this be any more useful than the template counting tool?—Stepheng3 (talk) 15:24, 11 April 2013 (UTC)
See the number in http://toolserver.org/~jarry/templatecount/index.php?lang=fr&namespace=10&name=Coord#bottom (255,112 articles) and see the number in fr:Catégorie:Article géolocalisé (253 446 articles). There is a difference ! Why ? Because it's a question of namespace. toolserver count all the page, even the page of namespace user, talk, etc. fr:Catégorie:Article géolocalisé count only the pages in the main namespace
Furthermore, it's important to write this code in {{Coord/display/inline,title}} and {{Coord/display/title}}, and no in {{coord}}. In fact, {{coord}} can be use anywhere in the article. {{Coord/display/inline,title}} and {{Coord/display/title}}, as the name "title" suggest, display the geolocation in the top left-hand corner.
Excuse me for my bad English, but I'm a French contributor. It's hard to write in english !
--Juanes852 (talk) 16:26, 11 April 2013 (UTC)
Since the rewrite of {{coord}} to use Module:Coordinates, the use of subtemplates (including {{Coord/display/inline,title}} and {{Coord/display/title}}) had decreased dramatically. --Redrose64 (talk) 19:48, 11 April 2013 (UTC)
Thank you for replying,
So my idea is not interesting ?
Could you tell me what is the interest of Module:Coordinates ? Maybe we must use it in Wikipedia in French ?
--Juanes852 (talk) 20:37, 11 April 2013 (UTC)
It reduces the time required to generate {{coord}} displays by 75%. Otherwise the results are identical to what the previous template produced. Dragons flight (talk) 20:41, 11 April 2013 (UTC)
We can still create a tracking category for articles with primary coordinates. We'd just need to implement it in Module:Coordinates, not in {{Coord/display/title}}. I don't object to that, though it seems frivolous. Does anyone besides Juanes852 want such a tracking category? —Stepheng3 (talk) 23:23, 11 April 2013 (UTC)
@Dragons flight, thanks for your precisions. I am going to suggeste Module:Coordinates in fr:projet:géolocalisation
In Module:Coordinates, I'm reading : "This module is intended to replace the functionality of {{Coord}} and related templates."
So, when in an article there is Module:Coordinates there isn't {{Coord/display/inline,title}} and {{Coord/display/title}}, and vice versa when there is {{Coord/display/inline,title}} or {{Coord/display/inline,title}} there isn't Module:Coordinates.
So, in three pages ({{Coord/display/inline,title}}, {{Coord/display/inline,title}}, and Module:Coordinates), we must add
{{#ifeq: {{NAMESPACE}}| {{ns:0}}|[[Category:Geolocated article]]}}

.

Be careful, the interest in Category:Geolocated article (or fr:Catégorie:article géolocalisé) is to know the number of Geolocated article ; the interest isn't have a tracking category.
--Juanes852 (talk) 10:10, 15 April 2013 (UTC)
I don't think that anything is actually still using {{Coord/display/inline,title}} and {{Coord/display/title}}. It is true that the "what links here" for Template:Coord/display/inline,title has a list of articles, but if you pick any one of these and WP:NULLEDIT it, it will drop out of the list when next refreshed, which suggests that the job queue hasn't got to these pages yet. --Redrose64 (talk) 11:26, 15 April 2013 (UTC)
Redrose64, thanks for replying, I know. --Juanes852 (talk) 13:36, 15 April 2013 (UTC)

footnotes for title coordinates

The behavior of the notes= parameter with title coordinates has changed recently, and I wonder if this is connected with the recent Lua rewrite.

In the past, the footnote indications for title coordinates appeared in the top right corner of the page, immediately to the right of the title coordinates, which seems to me the most logical place. Now the footnote indications are appearing at the left side of the first or second line below the page title. This separates the indication from the information being annotated.

Articles impacted by the change include Mitchell Creek, Rhododendron Creek, and Goat Rock Beach. —Stepheng3 (talk) 20:45, 13 March 2013 (UTC)

You're right, my bad. This should be fixed now though it will take a while for all the pages to be regenerated. You can check it by purging any of those pages. Dragons flight (talk) 21:39, 13 March 2013 (UTC)
Thanks for the quick fix. It seems to be working. —Stepheng3 (talk) 22:29, 13 March 2013 (UTC)
Instead of footnoting the coordinates, wouldn't it be better to put the reference in the body of the article? It would make it easier to click on if it was. Apteva (talk) 19:17, 11 May 2013 (UTC)

some problem with toolserver/geohack

- can't find page

I tried several different pages

John of Cromer in Philippines (talk) mytime= Sat 12:07, wikitime= 04:07, 13 April 2013 (UTC)

You're not the only one suffering. See Wikipedia talk:WikiProject Geographical coordinates#Toolserver broken?, for instance. —Stepheng3 (talk) 05:51, 13 April 2013 (UTC)
It's a general problem with Toolserver, see WP:VPT#Toolserver is down again. --Redrose64 (talk) 06:26, 13 April 2013 (UTC)
Like all things wiki, I never really know the correct place to report things, but usually I get directed. NB Wikipedia talk:WikiProject Geographical coordinates#Toolserver broken? was 6 days ago John of Cromer in Philippines (talk) mytime= Sat 14:29, wikitime= 06:29, 13 April 2013 (UTC)
There are still problems with this. Going to the toolserver over HTTPS works though, so if someone know how to change the link in the template we should probably do so, at least as a temporary fix. Bjelleklang - talk 07:34, 16 April 2013 (UTC)

Duplicated footnote id

I don't have my head in this template, but it looks like it is rendered twice but displayed once? If a footnote is included in the notes, then the generated HTML id is duplicated, which is wrong. For example, this results in the cite id cite_ref-nmts1_1-1 being generated twice:


Markup Renders as
<ref name=nmts1>xxx</ref>

{{coord|11|13|15|N|123|44|45|E|type:isle_dim:35000_region:PH-07|notes=<br />
geometric centre<ref name=nmts1 />|display=inline}}

{{reflist}}

[1]

11°13′15″N 123°44′45″E / 11.22083°N 123.74583°E / 11.22083; 123.74583
geometric centre[1]

  1. ^ a b xxx

--  Gadget850 (Ed) talk 15:04, 18 April 2013 (UTC)

Putting that through Special:ExpandTemplates yields
<span class="plainlinks nourlexpansion">[//toolserver.org/~geohack/geohack.php?pagename=Special:ExpandTemplates&params=11_13_15_N_123_44_45_E_type:isle_dim:35000_region:PH-07 <span class="geo-default"><span class="geo-dms" title="Maps, aerial photos, and other data for this location"><span class="latitude">11°13′15″N</span> <span class="longitude">123°44′45″E</span></span></span><span class="geo-multi-punct">&#xfeff; / &#xfeff;</span><span class="geo-nondefault"><span class="geo-dec" title="Maps, aerial photos, and other data for this location">11.22083°N 123.74583°E</span><span style="display:none">&#xfeff; / <span class="geo">11.22083; 123.74583</span></span></span>]</span><br />
geometric centre<ref name=nmts1 /><span style="font-size: small;"><span id="coordinates">[[Geographic coordinate system|Coordinates]]: <span class="plainlinks nourlexpansion">[//toolserver.org/~geohack/geohack.php?pagename=Special:ExpandTemplates&params=11_13_15_N_123_44_45_E_type:isle_dim:35000_region:PH-07 <span class="geo-default"><span class="geo-dms" title="Maps, aerial photos, and other data for this location"><span class="latitude">11°13′15″N</span> <span class="longitude">123°44′45″E</span></span></span><span class="geo-multi-punct">&#xfeff; / &#xfeff;</span><span class="geo-nondefault"><span class="geo-dec" title="Maps, aerial photos, and other data for this location">11.22083°N 123.74583°E</span><span style="display:none">&#xfeff; / <span class="geo">11.22083; 123.74583</span></span></span>]</span><br />
geometric centre<ref name=nmts1 /></span></span>
Only one of the HTML elements has an id= attribute; there's a <span id="coordinates"> --Redrose64 (talk) 19:18, 18 April 2013 (UTC)
If you check the original markup, <ref name=nmts1 /> is included once, but shows twice in the ExpandTemplates output. But, ExpandTemplates does not expand Cite references. The rendered HTML is:
<span class="plainlinks nourlexpansion"><a rel="nofollow" class="external text" href="//toolserver.org/~geohack/geohack.php?pagename=Template_talk:Coord&amp;params=11_13_15_N_123_44_45_E_type:isle_dim:35000_region:PH-07"><span class="geo-default"><span class="geo-dms" title="Maps, aerial photos, and other data for this location"><span class="latitude">11°13′15″N</span> <span class="longitude">123°44′45″E</span></span></span><span class="geo-multi-punct"> / </span><span class="geo-nondefault"><span class="geo-dec" title="Maps, aerial photos, and other data for this location">11.22083°N 123.74583°E</span><span style="display:none"> / <span class="geo">11.22083; 123.74583</span></span></span></a></span><br />
geometric centre<sup id="cite_ref-nmts1_1-1" class="reference"><a href="#cite_note-nmts1-1"><span>[</span>1<span>]</span></a></sup><span style="font-size: small;"><span id="coordinates"><a href="/wiki/Geographic_coordinate_system" title="Geographic coordinate system">Coordinates</a>: <span class="plainlinks nourlexpansion"><a rel="nofollow" class="external text" href="//toolserver.org/~geohack/geohack.php?pagename=Template_talk:Coord&amp;params=11_13_15_N_123_44_45_E_type:isle_dim:35000_region:PH-07"><span class="geo-default"><span class="geo-dms" title="Maps, aerial photos, and other data for this location"><span class="latitude">11°13′15″N</span> <span class="longitude">123°44′45″E</span></span></span><span class="geo-multi-punct"> / </span><span class="geo-nondefault"><span class="geo-dec" title="Maps, aerial photos, and other data for this location">11.22083°N 123.74583°E</span><span style="display:none"> / <span class="geo">11.22083; 123.74583</span></span></span></a></span><br />
geometric centre<sup id="cite_ref-nmts1_1-1" class="reference"><a href="#cite_note-nmts1-1"><span>[</span>1<span>]</span></a></sup></span></span></p>
<div class="reflist references-column-width" style="-moz-column-width: close; -webkit-column-width: close; column-width: close; list-style-type: decimal;">
<ol class="references">
<li id="cite_note-nmts1-1"><span class="mw-cite-backlink">^ <a href="#cite_ref-nmts1_1-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-nmts1_1-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text">xxx</span></li>
</ol>

You will find two instances of <sup id="cite_ref-nmts1_1-1" class="reference">. When you invoke a named reference multiple times, the id should increment like:

  • <sup id="cite_ref-nmts1_1-1" class="reference">
  • <sup id="cite_ref-nmts1_1-2" class="reference">
But, that is not happening here. --  Gadget850 (Ed) talk 19:43, 18 April 2013 (UTC)
The behavior is different, but I think this is the same underlying problem as bugzilla:46815, where frame:preprocess leads to inappropriate caching of ref tags. If you know explicitly that one needs to generate a ref tag then one can workaround and render it via frame:extensionTag, but I don't think there is any current solution for the general case of a ref embedded in random text that needs to be parsed. Dragons flight (talk) 20:02, 18 April 2013 (UTC)

Slight Display Error

This

({{Coord|37|1|54|N|27|25|46|E|display=inline,title}})

inserts a break space right before the closing parenthesis (and possibly elsewhere). --91.10.32.201 (talk) 17:00, 19 May 2013 (UTC)

(37°1′54″N 27°25′46″E / 37.03167°N 27.42944°E / 37.03167; 27.42944)
Ignoring the link, that is the same as simply writing out (37°1′54″N 27°25′46″E).
I don't see any extraneous space. Dragons flight (talk) 19:31, 19 May 2013 (UTC)

Nonsense value for the parameter "display" kills the text to be returned

Hallo. I just found a very ugly bug, which isn't caused from this template, but from its module. If you write, thus, parameter "display" has a nonsense value:

{{coord|12|34|12|N|45|33|45|W|display=kato}}

, it returns nothing: . Please, read on Module talk:Coordinates too. Greetings --Tlustulimu (talk) 13:01, 29 June 2013 (UTC)

Good find. Not even an alert categorization. The fix (suggested on the module talk page) looks good. —EncMstr (talk) 14:18, 29 June 2013 (UTC)

A helping hand is needed from he/she who dares

To Whom this may concern, I have been shown time and time again but I can never get the Coord template to work. If someone can kindly fix the info box coordinates on the Museum of Old and New Art article, it would be much appreciated. Wiki ian 12:11, 9 August 2013 (UTC)

What you wanted was
{{Infobox museum
...
| coordinates         = {{coord|42|48|46|S|147|15|40|E}}
...
}}
I've done this now.--Salix (talk): 12:31, 9 August 2013 (UTC)
No, what was wanted was {{coord|42|48|46|S|147|15|40|E|region:AU-TAS_type:landmark|display=inline,title}}; I've done that ;-) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 9 August 2013 (UTC)

Mobile: 'Title' coordinates not showing

There's an issue with coordinates not showing in mobile; please see WP:VPT#Mobile: 'Title' coordinates not showing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:50, 26 August 2013 (UTC)

Hiding the coordinates?

In the article Resolute Desk there is quoted text that includes this:

H.M.S. RESOLUTE forming part of the expedition sent in search of SIR JOHN FRANKLIN IN 1852, was abandoned (74°00′00″N 101°22′01″W / 74°N 101.367°W / 74; -101.367) in latitude 74 degrees 41 minutes N longitude 101 degrees 22 minutes W on 15th May 1854. She was discovered and extricated in September 1855 in latitude 67 degrees N (67°00′N 58°42′W / 67°N 58.7°W / 67; -58.7) by Captain Buddington of the United States Whaler "GEORGE HENRY."

Of course, the original text doesn't have the parenthetical coordinates. I find this to be rather ugly. Is there a way to hide the coordinate link so that the appropriate text has a {{coord}}'s link but displays other text? Perhaps conceptually like this:

[[{{coord|67|N|58.7|W |scale:10000000}}|latitude 67 degrees N]]

Maybe there is a new parameter needed that would facilitate this:

{{coord|67|N|58.7|W |scale:10000000 |text=latitude 67 degrees N}}

Or is this such a rare occurrence that it's not worth bothering about?

Trappist the monk (talk) 13:07, 2 September 2013 (UTC)

Coordinates are useful information so should not be hidden. You can, though, move them to a footnote by applying <ref></ref> tags around them (as I have just done). This technique, though particularly suitable in quoted material, should otherwise be used sparingly. If there are many coordinates, consider moving them to a table. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:09, 2 September 2013 (UTC)
Yeah, that works I suppose, and was a solution I contemplated. I don't think that standard coordinate display is always the best or most useful – certainly no more so than than any other link that gets pipe-text – especially in this case where the displayed text from the quote is the coordinates in a slightly different form.
Trappist the monk (talk) 14:52, 2 September 2013 (UTC)
Why not put this:
H.M.S. RESOLUTE forming part of the expedition sent in search of SIR JOHN FRANKLIN IN 1852, was abandoned at 74°41′N 101°22′W / 74.683°N 101.367°W / 74.683; -101.367 on 15 May 1854.
--Redrose64 (talk) 15:15, 2 September 2013 (UTC)
Because the text in question is quoted text which really ought not be changed.
Trappist the monk (talk) 15:40, 2 September 2013 (UTC)