Template talk:Coord

Template:Coord/input/dm

To add the same check for minutes >=60 as in Template:Coord/input/dms, I'd like to make the following change [1]. -- User:Docu

References for {{coord}}

Is there a general way to give a reference for a display=title coordinate? For an inline coordinate, it seems straightforward: {{coord|...|display=inline,title}}<ref>...</ref>

I see no way to translate that for display=title. The "source" parameter doesn't seem to do nearly as much as a <ref> can. Am I just being anal retentive? Gregbaker (talk) 05:31, 8 July 2009 (UTC)

You are not being retentive (at least on this question). The matter has been discussed before, but has only got as far as your observations, which are that source: is not as good as a <ref>. Having played with it just now, I note that you can squeeze a <ref> into a {{coord}}, but the reference number is shown in a rather odd place, between the globe and the coordinate. Actually, it looks kinda okay at the top of the page, but not so good inline; whereas your suggestion of putting the ref outside the template works for inline coords. Can it be beyond coords CSS to sort the issue out?

Example:[1] 51°51′51″N 31°21′11″E

The <ref> in {{coord}} does seem a little awkward. I'd suggest the following workarounds (in order of preference):

1. For inline {{coord}}, use <ref> after the tag (e.g. {{coord|...|display=inline,title}}<ref>...</ref>)
2. If the source is simple/obvious enough, use source. (e.g. Finding the address in Google Earth becomes "source:googleearth")
3. If there is (or can be) a passage of text mentioning the location, slap the reference on it. (e.g. "...is located west of Foo Island<ref>...</ref>.")
4. If all else fails, put a "Location" section on the article's talk page and say your piece there.

Gregbaker (talk) 07:20, 26 July 2009 (UTC)

Please could we have a reference parameter into which we can put our citations (in the usual formats) which displays as a normal inline reference? Railwayfan2005 (talk) 21:30, 10 August 2009 (UTC)

Just dropping in out of the blue I would say that this just adds complexity to an already complex template. Standard practice has always been to add the citation after the template. I know there is a problem when the coordinates only appear in the title line. I don't think the title line the place for and inline citation. I concur with Gregbaker. –droll [chat] 17:01, 24 August 2009 (UTC)

I haven't done much template programming, but I would think that the complexity could be managed. I agree there's a difficulty when the coords appear only in the title. The tendency in that case is to use the source: parameter rather than a footnote citation, but that's not quite satisfactory. For one thing, it can cause the article to appear to be sourceless. I think that normal inline references in {{Coord}} would be a good addition. --Stepheng3 (talk) 00:04, 6 September 2009 (UTC)

Agreed. Geographic coordinates are the sort of thing I see copied to a zillion travel industry web sites advertising "landmarks near XXX", which makes it really hard to verify locations; the top 20 google hits (because all of those sites play search engine optimization tricks) all have copies of the wikipedia information. It would be extremely helpful to be able to cite an actual source. Particularly for things like the archaeological site I'm updating (Dos Pilas) that aren't even visible on satellite view. (In my case, the source is The Dynastic Sequence of Dos Pilas, Guatemala.) 97.103.4.238 (talk) 03:20, 2 October 2009 (UTC)

For reasons relating to EU database copyrights limiting what can be used as a source is a very bad idea. Generaly it's not a good idea to encourage people to draw large numbers of coordiates from a single source.©Geni 13:13, 17 October 2009 (UTC)

I don't think there's any intention of limiting what can be used as a source for coordinates, merely to limit what codes get put into the "source:" parameter. According to the documentation, the parameter is mainly intended for bots, which don't want the kind of detailed citations encouraged by Wikipedia:Citing sources.

How about we add an optional "note=" template parameter? This would be used to display arbitrary wikitext after the coordintes, both inline and in titles. One could then code things like

{{coord|67.5|22.5|note=<ref>_Encylopedia Galactica_, page 14:322</ref>|display=title}}

without worrying about whether the citation text contained blanks, colons, or underscores. The "source:" parameter could then be left to the bots and toolserver hackers. --Stepheng3 (talk) 03:03, 19 October 2009 (UTC)

I've added a notes= parameter to the sandbox version of the template. If someone with administrative powers would copy {{Coord/sandbox}} to {{Coord}}, I'll take care of updating the template documentation. --Stepheng3 (talk) 17:45, 5 November 2009 (UTC)

Done. Orderinchaos 19:39, 5 November 2009 (UTC)

I've deployed it at Hamersley, Western Australia, in order to get rid of an otherwise unnecessary external link. One question, would this hinder services like Google Maps which lift coords from us en masse every so often, or can it accommodate the extra superscript text? Orderinchaos 19:45, 5 November 2009 (UTC)

Thanks for your help, Order. As for how this affects Google Maps, that would depend on how they do the lifting. If (as seems likely) they parse microformats from the HTML, then they should be fine, since the <sup> tag appears outside of the microformat <span>s -- if you know what I mean. --Stepheng3 (talk) 23:46, 5 November 2009 (UTC)

Ah cool - thanks for that. Orderinchaos 01:47, 6 November 2009 (UTC)

Mapping services

[Moved to Template talk: GeoTemplate#Mapping services. The map links are in that template]

Weirdological symbol in the India article

I've been working on the Infobox Country template on the India page, and I noticed that the coordinates of New Delhi in the Infobox have a little weird symbol combination that looks like this...

‡)28°34'N 77°12'E

I've checked a few other articles that use Infobox country, and they appear okay. So far, I see this little " ^‡) " symbol only in the India article and across all nine skins in my IE7. Anybody else see this? and what do you suppose is causing it? I can't find anything in the code for this template nor the Infobox template that might cause this, and the box on the page itself appears to be free of this symbol. If it's coming from outside, then why is it only affecting one particular article's Infobox?
 —  ^{.`</sup>^) Paine Ellsworth<sup>diss`cuss} (^^`.  11:17, 27 October 2009 (UTC)

Using the "View page source" option (it's Ctrl-U in Firefox 3.0) reveals within the anchor linked text the presence of

<sup>‡</sup>)

which renders as

^‡)

The anchor link itself is to "http://stable.toolserver.org/geohack/geohack.php?pagename=India&params=28_34_N_77_12_E_type:country(3,287,240" so it looks like the closing parenthesis is supposed to be part of that. The double dagger, I'm not sure yet. Further investigation is warranted: but it's clear to me that it's a template bug, and not something produced by toolserver. --Redrose64 (talk) 11:46, 27 October 2009 (UTC)

This is a source for the population number. The population number is used in the geohack link, and the source breaks this usage. —TheDJ (talk • contribs) 11:49, 27 October 2009 (UTC)

(out). I found it. It was on the "area_km2=3,287,240^‡" code line in the box on the India page. There is no close paren, however if the ^‡" is removed, the weirdological symbol vanishes, including the close paren. To me, this appears to be a high-falutin' vandalism, but I'm not experienced enough to know for certain.

• PS. Make that two "oops", TDJ <g> So it wasn't a vandalism, it was a footnote symbol that was in the wrong place. Ain't life grand? --- You're probably not amazed at the way that got into the coordinates link, but believe me, I'm totally astounded!

 —  ^{.`</sup>^) Paine Ellsworth<sup>diss`cuss} (^^`.  12:09, 27 October 2009 (UTC)

• • Well they are not supposed to be used in those coordinates. I reported this error of the Infobox Country here: Template_talk:Infobox_Country#Broken_capital_coordinates —TheDJ (talk • contribs) 13:08, 27 October 2009 (UTC)

Great! Thank you very much, TDJ! Now if we can just get those gurus to add lats and longs to the coordinates. The degrees and mins just don't always get close enough when one tries to nail down a city map point.

 —  ^{.`</sup>^) Paine Ellsworth<sup>diss`cuss} (^^`.  13:19, 27 October 2009 (UTC)

To get extra precision without using seconds of arc, you may supply decimal fractions for the latm and longm parameters. --Stepheng3 (talk) 16:50, 27 October 2009 (UTC)

Thank you very much, Stepheng3! That worked very well in the India article. I still favor dms over dec, though, and would prefer the simple changes to the Infobox country template described here. Best of good fortune to you!

 —  ^{.`</sup>^) Paine Ellsworth<sup>diss`cuss} (^^`.  21:22, 27 October 2009 (UTC)

standardizing source= to source:

Last month I added a check to {{Coord}} such that articles which use "source=" (instead of "source:") would get a bold red error message and a maintenance category. After this turned up a large number of nonstandard template uses, the check was removed. In order to start standardizing these uses, I'd like to add a slightly different check, which would invoke the maintenance category but not display a message. Are there any concerns or objections to adding this check? My next step will be to standardize existing uses of {{Coord}} (in articles), and when that's done, I'd like to re-enable the error message. --Stepheng3 (talk) 19:37, 11 November 2009 (UTC)

{{Editprotected}}

There being no objections, I've implemented the check in Template:Coord/sandbox and tested it. Could someone with admin powers please copy the template to Template:Coord? --Stepheng3 (talk) 03:11, 15 November 2009 (UTC)

 Done. The only page which shows up in Category:Coord template needing repair is Template:Coord/testcases.

—WWoods (talk) 07:55, 15 November 2009 (UTC)

Thanks. With categories populated by templates, there's often a long lag, so I'll want to wait a few days. --Stepheng3 (talk) 17:42, 15 November 2009 (UTC)

Okay, it's been very quiet for a few days, so I think it's time to roll out the error message. Could someone with admin powers please copy Template:Coord/sandbox to Template:Coord? --Stepheng3 (talk) 05:14, 18 November 2009 (UTC)

Done. Orderinchaos 17:13, 18 November 2009 (UTC)

Thanks, Order. For reasons I don't understand, the change has revealed a few old Coord errors; I'll take care of them. --Stepheng3 (talk) 00:30, 19 November 2009 (UTC)

Firefox compatibility

Whereas in IE Opera and other browsers the template appears directly under the page title line, in Firefox it stays at a steady distance under the top tabs' line. In the case of long titles, it superimposes on the title letters. Any cure for this? Hoverfish Talk 17:15, 15 November 2009 (UTC)

I've just compared Firefox 3.0 to IE7; both show the coords on the right-hand end of the line which begins "From Wikipedia, the free encyclopedia", just below the horizontal rule which is beneath the page title. This is in Monobook for both. Are you (a) using Firefox 3.5 or (b) a different skin? --Redrose64 (talk) 17:59, 15 November 2009 (UTC)

This is mad. Firefox 3.0 and IE7 have just both changed their behaviour for me; the coords now show above the aforementioned horizontal rule. --Redrose64 (talk) 18:06, 15 November 2009 (UTC)

Hmm. Yes, in the last half an hour Safari (for windows), IE8, Chrome, Opera have also changed as you say and only Flock has it still the old way. Could it be that the Meta-techs are moving things around? Hoverfish Talk 18:18, 15 November 2009 (UTC)

I have Firefox 3.5.5 and Monobook BTW... Oh, and Flock just jumped with the other browsers. Hoverfish Talk 18:28, 15 November 2009 (UTC)

readability of dm and dms formats (′W, etc.)

I've been noticing how coordinates in dm and dms formats can be very difficult to read--at least with my browser/skin combination (Monobook/Opera 10.01). This is especially a problem in the title position, due to the small font used. An extreme example is dm-format title coordinates in the northern and/or eastern hemispheres, where the stroke (′) after the minutes of latitude disappears completely into the N, and/or the stroke after the minutes of longitude disappears completely into the E. When the stroke appears immediately before an S or W, it merges with the letter and easy to miss unless you know what to look for. Even the normal font used in inline coordinates has problems with ′W. There are similar problems in dms format with the ′ merging into certain digits and the second stroke of the double stoke (″) merging with a following glyph.

Are others experiencing these problems? If so, I see a various possible solutions: (1) increase the font size (2) switch to a different font family (3) add a space after each stroke and double stroke Each of these solutions might be applied to all coordinates or only to title coordinates. --Stepheng3 (talk) 06:03, 20 November 2009 (UTC)

Looks OK to me. It varies, mainly according to what the next character is. Most of the articles that I am involved with have the lat/long entered in decimal form (almost always by other editors), so I'm kind of used to seeing that format. But being a "pounds, shillings and ounces" sort of person, I prefer to see dms rather than decimal deg. As stated in previous section: Firefox 3.0, Monobook. However, see no problem in slight padding - is there a half-width version of   that could be used? --Redrose64 (talk) 10:52, 20 November 2009 (UTC)

One possibility would be to insert a thin space ( ) or narrow no-break space ( ). In my browser, however, these don't look different from an  .

I checked Monobook in IE8, and the vanishing stroke issue seems much less severe there, so perhaps the issue is specific to Opera.--Stepheng3 (talk) 23:53, 20 November 2009 (UTC)

Switching to Beta seems to help a lot, so that's what I've decided to do. --Stepheng3 (talk) 00:03, 21 November 2009 (UTC)

WikiMiniAtlas override?

It has come to my attention that there are some list articles such as this one that employ numerous calls to this template. These articles are suffering from long (over 20 seconds) load times and high CPU loads on some medium powered machines, leading to concern that they might be inaccessible on older machines. This template was identified as the culprit, and further testing by myself has revealed the real culprit to be the implementation of the javascript WikiMiniAtlas with each call to this template. I slogged through the code on this template and its subtemplates and it appears that the WikiMiniAtlas feature is hard-coded into the template and there is no way to disable it. If there is a way to disable it, that should be made more clear in the documentation so that these kinds of lists can do away with the WikiMiniAtlas feature and eliminate the long load times; if not, can an optional parameter be added to optionally disable this feature? Shereth 16:31, 29 December 2009 (UTC)

It's not possible to disable it. The script runs, whenever coordinates links are present. It probably could be made more efficient however. Contact User:Dschwen, who is the developer. —TheDJ (talk • contribs) 18:17, 29 December 2009 (UTC)

Actually testing the page in question. The problem is not the script, it is the complexity of the page. The coord template is a VERY complex template, because it needs to recognize so many forms of the coordinates. The sourcecode of the page shows:

<!-- Served by srv146 in 17.527 secs. -->
<!-- 
NewPP limit report
Preprocessor node count: 112588/1000000
Post-expand include size: 737005/2048000 bytes
Template argument size: 271536/2048000 bytes
Expensive parser function count: 0/500
-->

So that means that the page is simply very complex and taking a long time to render (unless you are an IP user, because then you get a cached version). In the future this will be solved mostly by the new geo parserfunction of the Maps extension, which will help us do away with all the existing 'hacks'. The delay of the WMA script is minor compared to the delay of the parsing/rendering of the page. Solution is to avoid using {{coord}} or use a simpler version of it (Not sure we have it). —TheDJ (talk • contribs) 18:27, 29 December 2009 (UTC)

And {{dts}} is a complex template call as well. —TheDJ (talk • contribs) 18:33, 29 December 2009 (UTC)

Running a test version of the page with a "hacked" version of the coord template (it was actually a hacked version of the coord/link template) that removed all of the error checking, switches, calls to other templates etc. still resulted in extremely slow load times until I removed the span elements that create the WikiMiniAtlas maps, at which point the load times for that particular page went from 28 seconds to 2 seconds. I'm pretty sure that they are still the culprit. I suppose a hacked version of coord may be necessary for these kinds of lists until a more elegant solution is found. Thanks for your reply. Shereth 18:38, 29 December 2009 (UTC)

What kind of computer and browser do you use? On my computer (Core2Duo 2Gh) the maximum execution time of the script on that page is 2secs (maximum) according to the WebKit inspector of Safari 4. All other delays are delays at the mediawiki side. —TheDJ (talk • contribs) 19:02, 29 December 2009 (UTC)

(edit conflict) At work (where I am currently) I am running IE7 on a dual core Pentium 3GHz machine with 2GB RAM - I do not have access to details about precisely what the hardware setup is. I do note that much of the delay does seem to be client-side as there is a significant spike in CPU usage when loading the page, which also leads me to suspect the Javascript mini-atlas. On my home system I experience a shorter delay but still more than what I would expect. By comparison, another fairly large page with a lot of template calls List of United States cities by population takes 3 seconds to load from my current computer. You may also be interested in some test runs by another user here. Shereth 19:30, 29 December 2009 (UTC)

Did it ever occur to you that the rendering engine in your browser might need a few of those CPU cycles? As for the list article, unfortunately you are comparing apples and orange glowing giant stars. The coord template cannot be compared to the simple stuff in List of United States cities by population. --Dschwen 19:36, 29 December 2009 (UTC)

I'm not trying to be critical of the WMA in the least - not trying to fault it in any way - but I do not believe it was written with these kinds of lists in mind, where it would be implemented 100+ times in a single page? As I noted previously, I used a test version of the coord template and selectively removed different elements of it and tested load times of a copy of this page in my userspace. The load times were consistently 28-29 seconds regardless of which elements I removed until I removed the spans containing the WMA impelmentation, at which point load times dropped to 2-3 seconds. The only conclusion I can come to is that the slow load times are related to the WMA. Shereth 19:41, 29 December 2009 (UTC)

Happened to stumble across this posting. However accurate the profiling may be (maybe it is time to upgrade the browser). meta:Wikiminiatlas explains how to either deactivate the WMA completely, or have it only attach maps to the one single set of "title" coordinates on each page. Both should yield significant JS execution time reductions (note that in current browsers JS execution time still is negligable compared to the rest of the page load time). --Dschwen 19:25, 29 December 2009 (UTC)

Is there any way to implement these on a by-page basis? It isn't a problem I am experiencing per se but has been noted previously by the NRHP wikiproject. The concern isn't my own load times (as long as they might be) but the load times experienced by users on slower machines who may find these particular pages inaccessible. Shereth 19:33, 29 December 2009 (UTC)

Sure there is. You can do that yourself in your monobook JS. Just query the page title and set the WMA options accordingly. But two things: 1) there is no problem that needs to be fixed. 2) per page settings a a bad idea (TM) as they introduce unexpected behaviour. --Dschwen 19:39, 29 December 2009 (UTC)

You are missing the point - this isn't a personal complaint, as in "I am upset this page is taking so long". It is an issue that had been noted prior to my own observation of the slow load times in these lists (here). I'm not sure how you get the idea that there isn't a problem when multiple users have noted that there is an issue. Shereth 19:44, 29 December 2009 (UTC)

Sure, there is an issue, but it has to do with the complex template logic and the use of old/obsolete browsers. Anyhow, see my comment below. --Dschwen 20:14, 29 December 2009 (UTC)

(edit conflict) Ok, that sounded a bit arrogant ;-). I could do two things: a) introduce an option to limit the number of coordinates that are decorated with a map (if you set it to let's say 20 you'd be fine for most articles and the big lists would not need that much processing time). b) change the way the WMA is added to the coordinates. The main problem I suspect in your browser are the DOM insertions for every little blue globe. I experimented with drop down menues on the links. --Dschwen 20:12, 29 December 2009 (UTC)

Another approach, closer to what Shereth asked for, would be to add a named option to {{Coord}} that would disable the section of {{Coord/link}} that's causing the performance hit. I'd be happy to prototype this.--Stepheng3 (talk) 20:18, 29 December 2009 (UTC)

Yes, that's what I originally imagined :) Shereth 20:23, 29 December 2009 (UTC)

How would that help? --Dschwen 20:23, 29 December 2009 (UTC)

(edit conflict) I don't doubt that the real problem is local to this machine and not the WMA. That's really the core of my point, though. At work I am using sub-optimal hardware and experiencing loading issues on these lists, and my concern is for the numerous other users who must access Wikipedia from sub-optimal setups; it is at its core a usability issue, as we want as many of our articles to be accessible to as many people as possible. As an experiment I modified my monobook.js to disable WMA and found the list in question now loads in 2-3 seconds, as most other articles do. I certainly don't want to legislate any kind of restrictions to WMA itself to accomodate this little issue, as I supsect there aren't too many lists that use {{tl:coord}} dozens and dozens of times. That's why originally I was considering an option in coord, or perhaps a version of it written for repeated use in lists like this, that would not all the WMA extension. Shereth 20:23, 29 December 2009 (UTC)

Guys, there seems to be a slight misunderstanding. WMA is not specific to the coordinate template. WMA looks for links in the rendered page that look like coordinates. Whether they are generated by coord or not does not matter. Fumbling around with coord is not feasable, unless you want to turn off the generation of geo hack links, which would unlink the coordinates and make them plain text. Any kind of solution will have to be implemented in teh WMA code in some way. --Dschwen 20:27, 29 December 2009 (UTC)

I see what you are saying now, but I think that might actually make it simpler to solve the problem. Would there be any possible way to add an optional flag to the template, something like |WMA=no that would insert something like style="nowma" to the link, and then instruct WMA to skip these ones? Shereth 20:33, 29 December 2009 (UTC)

Yikes! I had no idea it worked that way, but it explains the behavior I see for intense pages like List of shoals of Oregon. Maybe an experiment with WMA not messing with the DOM at all and instead be linked from coord? —EncMstr (talk) 20:38, 29 December 2009 (UTC)

Well, as I said, I could just attach an event handler to the links, which would not perform any visible dom changes that would need a redraw. That might help too. I'll overlook the yikes ;-). The way it is done now (which predates the introduction of coord by the way) is a nice encapsulation of the functionality, rather than having tons of templates and JS depend on each other. --Dschwen 20:49, 29 December 2009 (UTC)

• I just came here to make exactly the same observation that pages with very many "coord" templates are very slow to load. I don't know anything about the technicalities, but it would be nice to get it fixed if possible. 86.134.55.200 (talk) 03:45, 31 December 2009 (UTC).
  • Can I amend my "nice to get it fixed" comment above? I've just been trying to work on Research stations of Antarctica and it's completely unusable. I guess it's bearable if you just want to load the page once, to consult it, but if you're trying to do any editing work then forget it. So, rather than being "nice", I think it definitely needs fixing asap, even if the "fix" is just some sort of a "cut-down" version for use in long lists. 81.129.128.90 (talk) 14:16, 1 January 2010 (UTC).