This is an archive of past discussions about Template:Coord. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
It's standard on commons, I believe only my parser actually reads the extra information. Many of these values are need better overlaying image directly on the Google Earth, but might have some other users. Here are some the of extra values that could be included:
dim: for the general dimension/diameter in meters (now supported by GeoHack)
elevation: (also alt: for the height presumably above mean sea level, intended as as a coord3d
heading: the general direction of the object or direction of a picture.
Many the tilt and roll will be include for photographs...
Just passing by, and I saw this paragraph. You talk about elevation: as being a height above mean sea level. I think I read some where that mean sea level in Dover UK is +38m using WGS84. At any rate it needs to be thought through. --ClemRutter (talk) 08:38, 2 October 2009 (UTC)
Before parameters like elevation: and heading: are "supported", they need to be documented. Feet or metres? And what datum? Otherwise confusion is created. --Stepheng3 (talk) 03:43, 20 October 2009 (UTC)
After we get the undefined parm issues settled, I'd like to make three improvements to the error handling in {{coord}}:
Strengthen the range checking on input parms. Currently, the maintenance category is invoked unless min<60 and sec<60. I'd also like to invoke it for min<0, sec<0, latd>90, latd<-90, longd<-180, and longd>=360. While Dispenser provides tools that can detect these errors, I believe they work off daily dumps, which delays the visibility of problems and fixes. Now that I'm a seasonsed {{coord}} hacker (ouch! :) I should have no trouble implementing these checks.
Make {{Coord/input/ERROR}} to invoke the maintenance category, for articles at least. This would mean one less place to look for coord maintenance work.
Insert some bold, red error text whenever the maintenance category is invoked. That way when there are dozens of {{coord}}s on a page, it'll be easy to find the one with the problem. And perhaps the errors will become conspicuous enough that non-project editors will notice them and fix them!
I've implemented #1 and #3 in the {{Coord}} sandbox and expanded Template:Coord/testcases to test all range checks. I changed the longd<-180 test to longd<=-360 to be symmetrical. Feedback and additional testing would be most welcome. If this gets installed, the new template ({{Coord/input/error2}}) I created should get full-protected. --Stepheng3 (talk) 01:43, 16 October 2009 (UTC)
After augmenting Template:Coord/testcases some more, I think I've adequately tested this change. The next steps would be:
Well, that was exciting. I seem to have hit a gusher of errors of the form {{Coord|latd|longd|source=geograph.co.uk|region:GB_type:landmark|display=title}}. Until the pressure subsides, I'm going to put off the final edit to {{Coord/input/ERROR}} to address improvement #2. --Stepheng3 (talk) 21:10, 16 October 2009 (UTC)
The excitement has wound down, and the sandbox version of {{Coord/input/ERROR}} is tested and ready to roll. Time to:
Order, a few people had got in the habit of using the template contrary to the documentation--a matter that ought to get discussed here, I think.
I'm unsure why "source" was made a coordinate parameter instead of a template parameter. If it were a template parameter, the template could use it generate footnotes and stuff. It would still be bot-readable, just not accessible to the mapping tools. Since I don't see any reason why mapping tools need source info, I think there's a good argument for changing the "source:" info to "source=".
According to Template:Coord/doc, {{Coord}} is supposed to display a blue globe () for each set of coordinates. This is broken in many skins, but it usually works with Chick, Monobook, Simple, or Vector. The fact that it doesn't always work, even with these skins, is demonstrated below.
OK, it makes sense to hide the blue globe for off-Earth coordinates. (There probably won't be a WikiMiniAtlas of the Moon any time soon.) However, the fact the the blue globe is hidden for all subsequent coordinates (in my browsers, at least) has got to be a bug. I've seen this both with IE8 and Opera 9.64 and with all four of the skins that usually display the blue globe. Does anyone know what's going on here? --Stepheng3 (talk) 03:24, 19 October 2009 (UTC)
I tried to report the bug, but I can't sign up for the bug ticket system of the toolserver atm. So I have reported the error in the IRC channel, and if I see Dschwen himself around, I'll tell him. —TheDJ (talk • contribs) 10:50, 19 October 2009 (UTC)
Is there a reason why Ganymede is not documented as a legal value for the globe: parameter? Despite being capitalized differently from the other values, it gets a lot of use and doesn't seem to be breaking anything. --Stepheng3 (talk) 23:30, 16 October 2009 (UTC)
You're testing GeoHack's support for globe:. There maybe other parsers which aren't so tolerant of the casing, we need to decide (or I'll decide) if we should be capitalizing the planet names since they are proper names or leave them all lowercase for easier typing. The ghel parser support 36 globes in our solar system (planets+some moons). The supported planets in GeoHack only limited by subpages people have created (list) and the willingness of to documenting the coordinate system and finding services. — Dispenser06:22, 19 October 2009 (UTC)
You're right, Dispenser. I didn't test any parsers besides GeoHack. Is there a list of bots and tools that interact with Coord somewhere? If not, perhaps there should be. Even if I can't test them all, it would be nice to know what all we could potentially break when we make changes to {{Coord}}.
As far as case-sensitivity is concerned, I think the parameter should be insensitive. This project has a history of using all lowercase, but English convention is to capitalize the names of celestial bodies. As long as the IAU is on the case, it's not likely {{coord}} will ever need to distinguish two heavenly bodies with the same name. --Stepheng3 (talk) 16:23, 19 October 2009 (UTC)
No, other than the typical datum (link to Geography of Mars) that each body uses. It would also be nice if you added more major moons. As for the casing, most applications just need to know how to filter those values out. I would suggest restricting the values to all lowercase (preferred) and initial capitalization. — Dispenser03:25, 22 October 2009 (UTC)
I documented the three additional globes that GeoHack supports and, in the process, learned more than I wanted to know about how longitude is defined for other worlds. Suffice to say that the IAU has coordinates systems set up for 51 natural satellites.
I converted a bunch Thursday night looking at the Gas Giants' moons. I'm using the following list in my database: ENUM( 'Mercury', 'Venus', 'Earth', 'Moon', 'Mars', 'Phobos', 'Deimos', 'Ceres', 'Ganymede', 'Callisto', 'Io', 'Europa', 'Mimas', 'Enceladus', 'Tethys', 'Dione', 'Rhea', 'Titan', 'Hyperion', 'Iapetus', 'Phoebe', 'Miranda', 'Ariel', 'Umbriel', 'Titania', 'Oberon', 'Triton', 'Pluto'). Hopefully, I wont be needing to add more in the near future. — Dispenser22:35, 24 October 2009 (UTC)
Pop-up map text labels
The rendering of text labels on the map that pops up when you click on the blue globe is pretty buggy. Text is often illegible either because of clipping, overlapping or lack of colour contrast with the background. Guess everyone already knows this, right? —Preceding unsigned comment added by 86.138.41.250 (talk) 01:54, 24 October 2009 (UTC)
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?
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)
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
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)
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? Orderinchaos19: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)
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...
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?
— .`^) Paine Ellsworthdiss`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
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<sup>‡</sup>" code line in the box on the India page. There is no close paren, however if the <sup>‡</sup>" 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!
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.
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!
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)
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? HoverfishTalk17: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? HoverfishTalk18:18, 15 November 2009 (UTC)
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)
Currently the javascript for the WikiMiniAtlas is loaded on every page view, no matter if a page has coordinates or not. I intend to make it so it only loads when needed. See discussion at MediaWiki talk:Common.js#WikiMiniAtlas.
If this change is implemented, I would request that an optional parameter can be passed to {{coord}} to suppress the CSS id in certain cases that enables the WikiMiniAtlas, per the preceeding discussion topic. Shereth17:33, 15 January 2010 (UTC)
I see what you mean, but this is different. Even if the id is 100 times on a page the code in MediaWiki:Common.js will only run once and load the WikiMiniAtlas javascript once. So suppressing the id doesn't help with the problem you describe in the above section, unless you suppress it for all instances of {{coord}} on the page.
I would actually like to see less horizontal integration. WMA is optional, it's the admins haven't gotten to making an opt-out gadget. — Dispenser18:09, 15 January 2010 (UTC)
Dispenser: An opt out gadget would only help the small number of users who are logged in, and know we have gadgets, and understand that opting out from WikiMiniAtlas could make their page loads faster. The group of such users is probably about the same as the group of users that have discussed this on this page and in some other places. So an opt out gadget isn't the solution.
We could define an id alla disable-wma, that WMA will getElementId and when present not run WMA on those pages. It could be added with a {{disable wma}} or something. And then additionally add a 10second execution timeout in the script. I'll look at making such suggestions later today. —TheDJ (talk • contribs) 19:43, 18 January 2010 (UTC)
The problem I started this section with is that the WikiMiniAtlas code is loaded on all pages, including all articles and all pages in other namespaces, in spite that the vast majority of pages don't use any coordinates. Creating {{disable wma}} would not help against that, since we can't really add {{disable wma}} to most of the 61,821,078 pages here...
Over at MediaWiki talk:Common.js#WikiMiniAtlas I have suggested a simple way to instead make the WikiMiniAtlas code only load on pages that have coordinates.
Hmm, still a bad request? Damn. The toolserver admins changed some things around. Well, to be fair, I got a warning, but have been too busy lately to adapt the WMA. I thought I fixed it already. I'll check it out again. --Dschwen 02:48, 26 January 2010 (UTC) P.S.: Looks like a major thing, will get to it tomorrow. --Dschwen02:56, 26 January 2010 (UTC)
For some few weeks at least now, most of the topographical maps have stopped working for Hawaiian islands (except Oahu and Kauai at low resolutions). For example, try 20°48′N156°20′W / 20.800°N 156.333°W / 20.800; -156.333 (Maui) and select any of the topo sites. It used to work. This might not be anything with this template, but perhaps someone here might know if this is a feature or a bug, who to contact, etc. Thanks for any suggestions. W Nowicki (talk) 23:58, 30 January 2010 (UTC)
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? Shereth16: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)
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. Shereth18: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. Shereth19: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. --Dschwen19: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. Shereth19: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). --Dschwen19: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. Shereth19: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. --Dschwen19: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. Shereth19: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. --Dschwen20: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. --Dschwen20: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)
(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. Shereth20: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. --Dschwen20: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? Shereth20: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. --Dschwen20: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).
This is almost certainly Internet Explorer's horrible string performance, the page loads in about 14 seconds with a bunch of other scripts in Firefox on a decade old machine. — Dispenser15:16, 1 January 2010 (UTC)
I use a very old computer (700 MHz Celeron bought in spring 2001). And I use Firefox 2 since I can not run Firefox 3 on my operating system. (I don't have the money to buy a new computer.)
I have blocked the loading of meta:MediaWiki:Wikiminiatlas.js in my AdBlock Plus plugin. I have done several test runs, and when the WikiMiniAtlas is not blocked some articles take several seconds more to load. If it is even slower in Internet Explorer, then ouch. So Dschwen, please do any optimisations you can.
And as far as I can see all coordinates here at the English Wikipedia are added by using the {{coord}} template. So it should be possible to add some option to the template that when set tells WikiMiniAtlas to not do operations on it. WikiMiniAtlas probably need some code change to understand that setting.
I see that WikiMiniAtlas has the setting "var wma_settings = { onlyTitle: true }". I can use that to make a small template or an option in {{coord}}, that when placed on a page adds a special id. And I can add code in MediaWiki:Common.js that triggers on that id and then adds "onlyTitle: true". Thus making WikiMiniAtlas only work on the title on that page. But it would be better if Dschwen supplied us with a method to disable it for just some coordinates on a page.
I have previously suggested a cut down version of the {{Coord}} template or the retaining of the older depreciated templates specifically for pages that have a large number of instances of the template on them. But this was ignored and we were rail roaded into using this complex template with all of its problems. Can I suggest that we have a cut down version of the template for use on pages with many calls or that the {{Coord}} template be simplified by getting rid of some of the many options that are available. Keith D (talk) 01:09, 19 January 2010 (UTC)
What editors would like to do is click on the Bing or Google maps link and see them plotted on a map, or maybe click one set of coordinates and see it on google maps. We'd also like to be able to add a photo in less than 30 seconds. I don't think anybody wants to click on one of the little blue globes and get that funky little map that comes up. Can't those maps just be deleted, thrown away, stamped underfoot, and gotten rid of? Smallbones (talk) 03:04, 19 January 2010 (UTC)
No. 58 seconds on first load, then I clicked a bluelink for one of the place names, reached a shortish page of slightly more than 2 screens (at 1280x1024 in Firefox using Monobook with default font size) and on completion of that load, hit "back" immediately. It took 15 secs to return despite being cached. --Redrose64 (talk) 10:15, 19 January 2010 (UTC)
I added a 5 second timeout to the script (refresh cache to see it in effect). Incidentally the Pennsylvania bridge list is processed in <5sec in Google Chrome. No significant delay. --Dschwen15:32, 19 January 2010 (UTC)
P.S.: I'm thinking of making the script post a small message to the head of the page with a link to resume processing of coordinates. But it'd have to be unintrusive enough. --Dschwen15:36, 19 January 2010 (UTC)
Indeed. It's crazy that we are forcing every instance of this template to create a complex link (with javascript parsing that many editors here have complained is making pages unusable for editors or even readers). At present, there is no easy way for editors or users to opt out from the gadget per transclusion, per page or per user (unless users hack their javascript code):
Per transclusion: It can't be difficult to create a per-transclusion opt-out; a minor change to the javascript with an additional parameter for the template.
Per page: It shouldn't be very difficult to create a per-page opt-out as well (not instead); perhaps a custom magic word that adds some metadata which the javascript can use to prevent the WMA code from loading.
Per user: The user settings interface is no doubt harder to change; though it is notable that other gadgets can easily be disabled through Special:Preferences.
Of all the things that Wikipedia should deny any control over, WikiMiniAtlas activation is not one of them. At present, coordinate lists must either be untagged or be unusable. One size does not fit all.
Can we at least remedy two out of these three glaring omissions?
You should get some perspective here. Since the beginning of the discussion in this section I vastly improved the performance of the coordinate parser script. Calling Mountain peaks of North America unusable is way off. It takes 2 seconds on my machine for the page to come up (5 year old machine, single processor 2GHz, Firefox 3.6). You are suggesting to deny control to users. Forcing an inconsistent and unexpected behavior is bad interface design. --Dschwen12:33, 7 March 2010 (UTC)
I'm grateful for your work on this. But Mountain peaks of North America took 50 seconds to load and render here (IE8/XP, a notoriously slow browser but one too widely used to be ignored). And that was with the new timeout kicking in after 69 geolinks, leaving 81 geolinks without WMA despite the unacceptable delay. Whether WMA is always loaded or never loaded, users are denied a choice; the commenters here are just wanting some flexibility.
Editors must use their judgement to produce articles accessible to a broad range of readers. But developers must offer editors options to address all reasonable scenarios.
WMA is good enough to thrive on its merits without insisting on it being applied to every geolink on every page read by every user regardless of the judgement of individual editors and readers. Your work is appreciated but it is counterproductive to be overprotective.
Unless we can produce much faster benchmarks on all major platforms (including IE!), a workaround is required.
Ha ha, I know, but it is my baby! ;-). Anyhow. I'll do some benchmarking with IE8 in the coming days, but this looks seriously screwed up. Now on my 7 year old laptop with a 900Mhz Pentium-M and Google Chrome the page display in 2 Seconds with all coordinates processed. It does not strike ma as a good idea to punish users with reasonable browsers with a degraded experience just because one browser cannot get its act together. I'm seriously thinking of putting in a browser detection and just ad the blue globe for the main coordinate for IE users. Had I done this before I would have been spared this long discussion... --Dschwen15:38, 7 March 2010 (UTC)
Well that page uses a lot of elements that are very slow. First of all there are a LOT of references. As any FA editor can tell you, citations templates take LONG to render. Then this page uses another very complicated template, {{coord}}. Then it uses sortable tables (slow on IE). and it uses WMA of course. conclusion, total mayhem everywhere. Even for me that page takes 49 seconds to retrieve (note not render, NO, you have to wait 49 seconds before the server is done PRODUCING the page for you.) The page source says: "<!-- Served by srv195 in 49.224 secs. -->". This effect can only be fixed by making the page less complex. Use simpler reference and citation system, and probably using a non-complex version of coord. —TheDJ (talk • contribs) 16:03, 7 March 2010 (UTC)
But you should get almost always a cached version. Mine says Served by srv183 in 0.068 secs. and as I said it just takes 2 seconds on a crappy old laptop to get it completely rendered. So I really have a hard time understanding why other people have to suffer that badly. --Dschwen16:08, 7 March 2010 (UTC)
54 secs to load, including <!-- Served by srv203 in 49.154 secs. -->. Firefox 3.0.18, Windows XP, Monobook. --Redrose64 (talk) 16:28, 7 March 2010 (UTC)
Lately I've spent a lot of time normalizing type: parameters. I suspect one of the reasons why people use undefined typecodes like type:hamlet and type:place is that the documentation (at Wikipedia:WikiProject Geographical coordinates/type:) doesn't provide as much clarity and guidance as it might, particularly concerning type:landmark, which seems to be the catch-all.
I plan to edit the documentation to address issues I see. However, I'm bringing up my plans for discussion here in case they prove controversial.
For type:city, the lower limit is unclear. I propose including "hamlets, suburbs, subdivisions, neighborhoods, other human settlements including unincorporated and/or abandoned ones". Otherwise these might get lumped with type:landmark.
For type:airport, include "airbases".
For type:mountain, include "hills, submerged reefs, seamounts".
For type:waterbody, include "waterfalls".
For type:river, include "arroyos, brooks, streams including intermittent ones".
For type:event, include "earthquakes, festivals, shipwrecks".
For type:railwaystation, include "(railway) maintenance areas".
Broaden type:landmark from "buildings of special interest" to "buildings that are neither schools nor railway stations".
For type:landmark, enumerate miscellaneous artificial structures including "antennas, bridges, castles, cemeteries, dams, factories, intersections, lighthouses, mines, museums, monuments, power plants, ranches, roads, rocket launch sites, shopping malls, stadiums, theatres"
For type:landmark, enumerate miscellaneous natural features including "caves, geologic faults, headlands, valleys".
In a few cases I'm unsure which type: applies best...
A. Should craters and calderas be coded as type:landmark or type:mountain?
B. Should individual trees be coded as type:landmark or type:forest?
C. Should archeological sites be coded as type:landmark even if they were once cities? I'm tempted to say "yes".
D. I'm unsure how to code fourth-level administrative divisions, such as civil parishes of England. I'm tempted to lump them with "adm3rd" or "city".
E. How should we code non-administrative regions: biomes, extraterrestrial regios, and informal regions such as the Rust Belt? I tend to use type:landmark and override the default scale using a dim: parameter.
Calderas are volcanic in origin, so should be treated similarly: you don't mention volcanoes, but I'm guessing that they go with mountains. Craters may be volcanic (treat as volcano), or meteorite (landmark, imho). --Redrose64 (talk) 21:52, 17 January 2010 (UTC)
I'm don't see how it would be any less ambiguous, though it would probably be more intuitive for most people. It would also be longer. --Stepheng3 (talk) 00:12, 20 February 2010 (UTC)
I haven't seen any objection to adding type:settlement, so I'd like to proceed with this. I'll talk to User:Dispenser about getting this synonym added to GeoHacks, and then proceed with documenting the change. --Stepheng3 (talk) 16:40, 8 March 2010 (UTC)
I oppose this for two reasons: 1) settlement vs. city is redundant if you specify the population. 2) the type parameter is not a competitor for our category system. Keep it simple! --Dschwen17:08, 8 March 2010 (UTC)
I'm sympathetic with the desire to keep the system simple, to the extent that "simple" implies easy-to-use. To me, the English word "city" implies a lot more than just a certain number of residents, it implies local governance, defined borders, etc. I think that may be part of the reason why many editors are reluctant to code type:city (with or without population) for villages, Census-designated places, and so forth.
In an ideal world, all settlements would've been coded as type:settlement(pop) from the beginning. Perhaps (after a transitional period) we could make type:settlement(pop) the standard and eliminate type:city(pop) completely. Would you support that plan, Dschwen? --Stepheng3 (talk) 06:52, 9 March 2010 (UTC)
In England and Wales (possibly Scotland and Northern Ireland as well), a settlement may choose for itself whether to describe itself as "town", "village" or "hamlet"; but the term "city" is reserved, and such an honour is not awarded lightly, see City status in the United Kingdom. --Redrose64 (talk) 12:04, 9 March 2010 (UTC)
The type parameter is in no way intended or designed to bestow any honors on the places pointed to by the coordinates. Just think of it as a simple non-memonic tag. Would renaming it to settlement be clearer? Probably. But the improvement is so marginal (and probably far outweighed by the inconvenience of more typing and an increase in typos) in the big picture, that I do not think it is worth the effort. Sometimes the appropriate resolution is just to "suck it up" and get on with it ;-). There are many more important problems to solve. --Dschwen15:32, 9 March 2010 (UTC)
Really not worth arguing about. The problem is that a city in the UK is not a settlement- it is an honour. (Gross simplification- yes). But, the idea of labelling a town with a parameter called city just cannot be done because it isn't one- so one would just leave it out. Settlement- could be used- though it is far too long- it is the only word that encompasses hamlets, villages, towns and conglomerations.--ClemRutter (talk) 19:57, 9 March 2010 (UTC)
This isn't just a UK issue. I live in California, and I grind my teeth a little every time I code "type:city" on a settlement (anywhere in the world, but especially in region:US-CA) that isn't a city in the strict sense of the word. But I fear it may be too late for major changes to the type system, entrenched as it is.--Stepheng3 (talk) 19:50, 11 March 2010 (UTC)
Hi,
As far as I understand, Template:coord is the accepted way of adding coordinates to Wikipedia. I have however just discovered Template:Oscoor, which appears to do a parallel job, and seems to be unable to integrate with Template:GeoGroupTemplate (see List of Hewitts and Nuttalls in England), and may not have microformats, nor allow geo-indexing by search engines (e.g. google).
They have different purposes. {{coord}} is for use when you have a latitude and longitude on a globe. {{oscoor}} is for when you have a British or Irish National Grid Reference on a map (transverse Mercator projection). Further, {{oscoor}} should not be used alone, but should be called via any of several wrappers such as {{gbmapping}}. --Redrose64 (talk) 16:17, 23 February 2010 (UTC)
I would have thought that all types of coordinates (UTM, etc) should be piped through a {{coord}} template via some coordinate conversion so that external systems know about them, so there is one place for microformat code, and one place linking to the GeoHack page.
That's been suggested before. If I recall, it was considered too much effort, trouble, and confusion for the benefit. —EncMstr (talk) 19:37, 23 February 2010 (UTC)
Would it be worthwhile to include the conversion script in the GeoHack collection? (i.e. copy the script without integrating) — Dispenser22:11, 11 March 2010 (UTC)
Syntax for region parameter
Many mountains are located on international borders. So region codes for two countries are appropriate. For example a mountain on the US Canadian border should use US and CA. Is there a meaningful syntax for this case. I have noticed that some editors have used region:US/CA but this is not a documented syntax. –droll[chat]22:05, 9 March 2010 (UTC)
The slash syntax could be useful if it were supported by tools. GeoHack, for example, currently uses the country portion (first two characters) of the region code to emphasize links to regional mapping resources. If GeoHack were hacked to emphasize links for more than one region at a time, I would support this additional syntax. Similarly, if the WikiMiniAtlas or {{GeoGroupTemplate}} had some use for country codes, it might be worth extending the syntax in this way. Until that time, the only benefit I envisage would be compatibility with other Wikipedias such as dewiki. In my opinion, that's not enough motivation to change.--Stepheng3 (talk) 19:29, 11 March 2010 (UTC)
Well, it is not much of a change here, rather than just deciding on a syntax. I'd prefer that to the status quo where nobody knows what format to use and people start making up their own formats. --Dschwen 19:38, 11 March 2010 (UTC) P.S.: I had been thinking how to use the region code in WikiMiniAtlas. But never came up with a good idea. I'd happily listen to suggestions how it can be used. --Dschwen19:39, 11 March 2010 (UTC)
Bottom link proposal for Template:Infobox mountains
It has been proposed at Template talk:Infobox mountain that the template use the coord | notes = parameter to display a link in the title line to a bottom note. This would be for ever page that uses the template. I don't like the idea and I'm wondering if those who watch this template have any thoughts. –droll[chat]07:36, 17 March 2010 (UTC)
type:state
I think it's time to get rid of type:state, which is currently used in only about 250 coordinates. The documentation says it's for specifying coordinates of a "Former country or administrative unit of country, undefined level", but I think it would be better to tag these as type:country, type:adm1st, and so on, so as to provide better scale hints to GeoHack. If there's no objection, I'll retag these coordinates and update the template documentation. --Stepheng3 (talk) 05:53, 20 April 2010 (UTC)
Hidden feature in coord
I stumbled into this yesterday. I think this is a great feature and plan to use it. If I put text after the scale parameter, it will show up before and part the coord image e.g.
I've been programming for over 40 years and I've never heard unintended hidden feature. I hope you don't mind me using your phrase in future computer related meetings. GloverEpp (talk) 00:16, 30 April 2010 (UTC)
It's because we don't {{urlencode:}} or {{fullurl:}} parameters before creating a links, until recently neither method would produce satisfactory results. I've been working on the latter method at tswiki:GeoHack#Nice URLs and can now recommend its use. — Dispenser19:23, 30 April 2010 (UTC)
Globe icon
Do we really need the globe? There are a lot of infoboxes that use {{coord}} as a nested template and I at least find it quite disturbing to see the globe interrupt the table structure of the final box output. And when one uses display=title, these boxes will leave the Coordinates field blank but still show the parameter name. De728631 (talk) 17:51, 31 March 2010 (UTC)
If there are infoboxes that show a parameter name with display=title, you might take that up with the infobox maintainers. As for pitting WMA against aesthetics, that's a debate I'd prefer to watch from a safe distance.--Stepheng3 (talk) 18:00, 31 March 2010 (UTC)
Hmm, what I totally missed here is the function of the globe button, ie the interactive map tool. Maybe an option could be included to disable this feature for use with infoboxes that show a location map anyway? If there's no map shown in the article then the popup map is certainly useful though. De728631 (talk) 06:45, 1 April 2010 (UTC)
I am visiting this page as a casual reader of the article Mary_Celeste. In section 3 (Discovery of the Mary Celeste), the "coord" template inserts this unpleasant hieroglyph in the middle of the text. It breaks ease of reading, so much that I left the article to complain here. I am not interested in template design, this is only the testimony of somebody _reading_ an article, but I strongly feed something should be done ; inserting a blue small disc in the middle of a sentence is a real disgrace. French Tourist (talk) 16:41, 2 May 2010 (UTC)
Hmmm. I could also make it appear when hovering the coordinates only. That would be even less obstrusive. Let me see if I can come up with an alternative. --Dschwen18:12, 2 May 2010 (UTC)
trying to use this code gives error
I tried copying this code to this page, but it seems to always give an unrecognized character error there. Would someone here be able to troubleshoot that? --209.34.235.6 (talk) 19:25, 6 May 2010 (UTC)
Hi GloverEpp, I was using it on this site Danzig and it continues to give unrecognized character errors every time I use it. I'm just not sure how to troubleshoot that. Could it be an issue with using a certain monobook.css file perhaps? --209.34.235.6 (talk) 18:03, 10 May 2010 (UTC)
The page has other errors, perhaps if they are fixed, this one will fix itself. Another possibility is that there is something else wrong and it is showing itself as a coord problem, when in fact it is something else. You might consider building the page from scratch under a test name to see if the error reappears. GloverEpp (talk) 19:40, 10 May 2010 (UTC)
Road junction lists
I had this goofy idea in my head, but I still thought that I would run it by some people here. There have been requests made at various times to add geographic coordinates to the junction lists at the bottom of articles on highways. M6 motorway does this by using footnotes; Montana Highway 16 by including a column of them with {{coord}} in it for each junction it its very non-standard list. What I'm picturing is something similar to {{coord}}, but without the full display of the linked coordinates. Maybe it would display just the globe icon. It could be inserted into the distance or exit number column of a list in an article like U.S. Route 41 in Michigan. The data would be there and accessible, but streamlined for display purposes. Thoughts? Imzadi1979→00:53, 10 May 2010 (UTC)
I'm not sure what you envision here. One easy thing to do in articles that contain multiple coordinates would be to add {{kml}}, which provides links to maps showing all the coordinates in the article. --Stepheng3 (talk) 05:12, 10 May 2010 (UTC)
I'd like a way to add the coordinates to the articles in the tables, but suppress the display of the linked coordinates. Some way display a smaller link inline in the table. I like the output of {{kml}}, but the junction table at the bottom of the US 41 article already has enough data in it. Since kml needs the coordinates added to the article some place, I need a way to add them without cluttering the table. Imzadi1979→08:34, 10 May 2010 (UTC)
I have looked at several pages with coord and so far, they are all having issues w/ Geohack. (Or, is it just me?) GloverEpp (talk) 13:19, 13 May 2010 (UTC)
Is there something similar like mountains for other landscapes like deserts, peninsula or larger regions? -- Tobias_dahinden 13:07, 2 June 2010 (UTC) —Preceding unsigned comment added by 130.75.51.124 (talk)
No, these can all be tagged as "type:landmark", with the scale overridden by dim: or scale: as necessary. I'm unsure why certain landforms (including mountains, passes, and glaciers) get special treatment, but that's how things seem to be at present. --Stepheng3 (talk) 20:19, 2 June 2010 (UTC)
I agree. But this will lead to problems because people start tag the coordinates with expressions like 'valley'. A similar problem is 'railwaystation'. People start to tag other buildings, e.g. there are about 500 coordinates with type 'church'. —Preceding unsigned comment added by 130.75.51.124 (talk) 10:38, 3 June 2010 (UTC)
Over the past months, I've cleaned up the enwiki mainspace such that there are no coordinates tagged with type:valley, type:church, type:building, or any other non-standard type. See the daily report. Where are those 500 coordinates you refer to? --Stepheng3 (talk) 15:27, 3 June 2010 (UTC)
The number is related to the Wikipeida-World-Gazetteer of Kolossos. Most of the churches are from the Swedish and Norwegian Wikipedia - the English Wikipedia seems to be correct. The problem is, that the coordinate parameter type should be consistent for any Wikipedia. -- Tobias_dahinden 09:40, 4 June 2010 (UTC) —Preceding unsigned comment added by 130.75.51.124 (talk)
I agree that consistency is desirable, given the practice of bot-copying coords between wikis.
I see two paths. If we're satisfied with the existing types, then we should nag our nowiki and svwiki colleagues to clean up their wikis. On the other hand, if we find a consensus to support new Coord types, then we should get GeoHack to support them. Without GeoHack support, type:church will (by default) give a map scale of 1:300,000--not very helpful.
As for myself, having twice supported new Coord types and been ignored, I've come to the conclusion that the type system, haphazard as it seems, is more-or-less set in stone. If I were to campaign for a new type, type:church would not be it. Recoding all the church Coords in enwiki strikes me as a major undertaking for miniscule benefit. --Stepheng3 (talk) 16:53, 4 June 2010 (UTC)
Error checking
After seeing this, it got me thinking that we could potentially set up some sort of a check for some of the more basic errors in specifying the region, source, type, ... passed to the coord template. One very basic check is to look for < and [ in the field using say {{str find}}. This could be one of the checks that throws an error exception. This wouldn't find all such errors, but doing that may create too much server load. Here is some code that finds wikilinks and html tags in a field:
{{#ifexpr: {{str find|{{{region-iso|}}}|[}} < 0 | Good | Bad}}
and
{{#ifexpr: {{str find|{{{region-iso|}}}|<}} < 0 | Good | Bad }}
This test could go in {{Coord/link}} or upstream in the top level template with the other error exceptions. It would be really nice if we could check the validity of the region field, but I am afraid that would take far more work. Comments? Plastikspork―Œ(talk)15:19, 15 April 2010 (UTC)
I'm interested in this idea. However, region-iso= is not a {{Coord}} parameter, so that check would have to be performed at a higher level template (in this case {{Infobox mountain}}). Unless you know how to parse the coordinate parameters, that is, in which case I'd like to see a prototype.
The use of {{{region-iso}}} was just a dummy value to give an idea of what I was talking about. Basically, I believe that none of the unnamed parameters in this template should contain wikilinks, flag templates, or html code. Plastikspork―Œ(talk)18:36, 15 April 2010 (UTC)
You're correct on that score. Again, checking is much easier at the Infobox level. If you have an implementation of checking code at the {{Coord}} level, I'd love to see it. --Stepheng3 (talk) 18:45, 15 April 2010 (UTC)
The following should work, so long as there aren't more than 50 characters in the sum of the fields. Otherwise, one could break them up into multiple checks. Additional fields could be added as well. Plastikspork―Œ(talk)18:50, 15 April 2010 (UTC)
{{#ifexpr: {{str find|{{{1|}}}{{{2|}}}{{{3|}}}{{{4|}}}{{{5|}}}{{{6|}}}{{{7|}}}{{{8|}}}{{{9|}}}{{{10|}}}|[}} < 0 | Good | Bad}}
{{#ifexpr: {{str find|{{{1|}}}{{{2|}}}{{{3|}}}{{{4|}}}{{{5|}}}{{{6|}}}{{{7|}}}{{{8|}}}{{{9|}}}{{{10|}}}|<}} < 0 | Good | Bad}}
One idea I had last night would be to check for {{Coord}} transclusions where the degrees latitude (or the degrees longitude) is empty or blank or non-numeric. That would be a very lightweight error check and might catch some interesting errors. Another idea would be to check for undefined values of the display= parameter.--Stepheng3 (talk) 16:48, 15 April 2010 (UTC)
String manipulation templates are very expensive, I really don't think we should be using them in this heavily used template. Many of the other checks mentioned are already performed by the ghel parser and I intend to help automate Stepheng3 high level with geosearch.py. As for invalid input with the display=, I've added namespace support for to my redlink prefix index tool to identify all cases. — Dispenser04:33, 16 April 2010 (UTC)
I took a look at {{str find}} and I have to admit it's going to be expensive. I don't know at what point an error check becomes too expensive, but I trust Dispenser on this one. The latd/longd check, however, would be inexpensive to implement and might catch some interesting errors.
The disadvantage of external tools like geosearch.py and redlinks.py is that only a handful of editors use them, so most editors never learn from their mistakes. Bold red error messages provide immediate feedback to editors when they abuse the template (or before even, if they use preview mode).
This brings me to a question that's been bugging me for weeks. When's geosearch.py going to be operational again? --Stepheng3 (talk) 05:16, 16 April 2010 (UTC)
For the minutes and seconds parameters anything that does not make sense mathematically to MediaWiki will cause it to throw big red error messages. Testing blank values is harder, but the following code may do the trick:
{{#ifexpr:((0{{{2|-1}}}+1) and not (0{{{6|-1}}}+1)) or (not (0{{{2|-1}}}+1) and (0{{{6|-1}}}+1)) != 0|Empty warning}}
Of course with every additional step it takes longer and longer to render a page w:List of craters on Mars: A-L has 534 points and takes 47 seconds to render. On geosearch.py its going to optional once I write tools to handle the errors that have surfaced regarding geohack URL missing this template. — Dispenser07:05, 16 April 2010 (UTC)
Dispenser, I'm not sure what you mean by "going to optional".
Yes, I figured that this might be a bit expensive. This {{#ifeq:{{padleft:|1|{{{foo|}}}}}|<|Bad|Good}} and this {{#ifeq:{{padleft:|1|{{{foo|}}}}}|[|Bad|Good}} aren't as expensive, and catch some cases, but probably would be better to just to other individual templates that call this one. For example, this works for the region example:
By the way, I am aware of the problem with the Mars Craters page. I had to split it after running into the problem of exceeding the total number of templates on a page limit. I think it could be split again due to the size. Although, it is a good test case for illustrating a point. Plastikspork―Œ(talk)17:06, 16 April 2010 (UTC)
I did a quick test, loading List of craters on Mars: A-L then seeing how it takes for the page to reload after a purge. The results were surprising: 120 seconds with {{Coord/sandbox}} (no error checks) but only 105 seconds with {{Coord}}. Either the time is very sensitive to load or caching effects or else I screwed up. Please run your own tests and let me know what you find. --Stepheng3 (talk) 02:29, 17 April 2010 (UTC)
Strange. It could be that the name of the new template is longer, and takes longer to parse? Perhaps it would be better to check say "sandbox1" vs. "sandbox2" so there is no difference in page length. Just a thought, however it does seem to indicate that these checks aren't having much of an impact. Plastikspork―Œ(talk)22:40, 17 April 2010 (UTC)
Were you looking at the HTML comment at the end <!-- Served by srv207 in 43.015 secs. -->. There's also inital caching delay. I ran the tests a few times and it seems the one without the check is about 2 seconds faster (40.366 vs 42.386) but this is rather negligible across 500 especially when comparing to {{coor d}} which can renders 2000+ coordinates in 20 seconds. — Dispenser04:34, 19 April 2010 (UTC)
I'd been timing the purges with a wristwatch. When I use the "Served by" comment in the HTML, I got results that seem consistent with yours: 5%-7% longer service delays with the checks enabled. --Stepheng3 (talk) 21:44, 22 April 2010 (UTC)
Getting back to the original problem. Since these users don't look at the HTML output, big red error messages are going to do nothing. So we need a way of detecting these broken URLs. Instead of use the expensive parser functions, I propose that we append & to the end of the coordinate URLs and use geosearch.py with [^&]$. — Dispenser04:34, 19 April 2010 (UTC)
I'm unsure what you mean by looking at the HTML; I think a lot of editors preview their changes and/or look at the page displayed after they edit, so if the padleft tests throw up error messages, that should help. I assume that any error message will also cause the article to show up in the maintenance category, so specialists like me can efficiently find and fix problems that ordinary editors miss or can't fix themselves. Even without padleft tests, I would expect that characters like "<" and "[" in GeoHack URLs could be easily found using geosearch.py. I don't see why flagging URLs with would improve the situation. Could you explain your proposal in more detail? --Stepheng3 (talk) 05:04, 19 April 2010 (UTC)
After looking into this, I realized that the padleft tests can only work at the Infobox level, where the region: parameter might already be isolated. I tried using an #rpos test, but it seems that Extension:StringFunctions is not enabled on enwiki. Then I tried using {{Str find}} but this introduced so many transclusions that the testcases exceeded the template include size; I was unable to get the speed test to render at all with those tests. So I've given up on checking for illegal characters in {{Coord}}. I do want to add other checks, however.--Stepheng3 (talk) 22:55, 22 April 2010 (UTC)
I added checks for missing latitude and longitude to the sandbox and added corresponding cases to the testcases. I also strengthened and added format info to existing error messages, improved readability, and removed redundant {{pp-template}}s. The performance cost of all these changes (measured on the speedtest, relative to the live {{Coord}}) is about 2.5%. --Stepheng3 (talk) 02:51, 23 April 2010 (UTC)
Right, we have to be careful about transcluding more templates within this template due to the limit. I'm fine with a 2.5% performance penalty if it makes things more robust. Plastikspork―Œ(talk)13:35, 23 April 2010 (UTC)
I had to experiment to find a way to add the checks without breaking List of craters on Mars: A-L. The fact that I succeeded does not guarantee that the change won't break some other long list of coordinates.
In the long run, I expect that the empty lat/long checks will prove more useful than others I've added in the past. I'd consent to trimming some of the other tests in order to keep these new ones. --Stepheng3 (talk) 16:10, 23 April 2010 (UTC)
I thought it was quite obvious that some users just don't preview and just look at changes, but I digress. MediaWiki will not form URLs with (space) (newline) [ ] < > " characters, as soon as it encounters one of those characters it will treat the rest as the title (gets tricky with '' and '''). If we have a known marker at the end the URL, it wont be included if the mentioned truncation happens. We then can then search for URLs missing this marker indicating something was lost. There's also the {{urlencode:}} function (can now produce underscores) but hasn't been thoroughly debugged yet, it may double escape input and escapes everything that isn't 0-9A-Za-z:._. — Dispenser19:06, 30 April 2010 (UTC)
Ah. When you wrote "these users" I assumed you were generalizing about editors who introduce erroneous {{Coord}}s. I agree it seems likely that 'some' of them don't preview. But I believe many of them do. End of digression.
I think the changes I made in the sandbox are ready to go live. (See my 02:51, 23 April 2010 above for summary.) If there are concerns, please raise them ASAP. If not, I plan to editrequest this weekend.--Stepheng3 (talk) 05:54, 5 May 2010 (UTC)
Kootenay River after a problem edit to Template:Coord I have reverted your edit [1] because it caused major formatting errors on a lot of articles using {{Geobox}}. The screenshot of Kootenay River shows the article in Firefox right after I had purged it and a second before reverting your edit. A second after reverting I purged Kootenay River again and it looked normal with no error messages and no extending too far to the left. I became aware of the problem after investigating Wikipedia:Help desk#Geobox River. I'm not a template expert and don't know how to make the desired changes to {{Coord}} without breaking things. PrimeHunter (talk) 23:48, 9 May 2010 (UTC)
In the |1={{{1|}}}| form, any leading or trailing spaces are stripped from parameter 1 before it's passed on; but in the |{{{1|}}}| form they're not. This is significant when you start substituting the actual values used into the subtemplates, and you find that {{Geobox2 coor}} inserts a space prior to the latitude degrees before sending this into {{coord}}. You can check this by using the subtemplate {{coord/input/dms}} directly. The code
Thanks, Redrose. That's very enlightening. However, since I want {{Coord}} to be as robust as possible, I'd prefer fixing it here instead of (or in addition to) in {{Geobox2 coor}}. I'll code something up in the sandbox later this week. --Stepheng3 (talk) 00:07, 8 June 2010 (UTC)
Okay, I've applied the fix to the sandbox and tested it on the testcases. If there's no objection in the next few days, I'll request that it be promoted to the live template. --Stepheng3 (talk) 03:08, 17 June 2010 (UTC)
) for each set of coordinates. This is broken in many skins, but it usually works with Chick, Monobook, Simple, or Vector. The fact that it doesn't always work, even with these skins, is demonstrated below.
Done. The only page which shows up in Category:Coord template needing repair is Template:Coord/testcases.
Resolved
