Template talk:Coord/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Previous discussion

Previously discussed at Template talk:Coor dms/archive001#Geo microformat

Who you callin' human???

Nice template. Nice presentation and linking. Nice docs.

BUT I know of at least one human who prefers to read coordinates in decimal notation. DMS is as archeaic as pounds-shillings-pence or pounds(again?)-ounces-pennyweights or gallons-quarts-ounces(again?)-drams or miles-furlongs-yards-feet-inches or ... (Those are all English aren't they? What would one expect.)

I'm not quite ready for radians, but ... Human readible, indeed!  :-> --Saintrain 02:07, 26 March 2007 (UTC)

Fair point, but we'll never be able to please all of the people all of the time. I, too, prefer to read decimal values - but they're always available by following the link produced by this template. Perhaps on day there will be a user setting in "preferences" as there is for date display. Andy Mabbett 22:46, 26 March 2007 (UTC)

For what it's worth, I also dislike DMS and strongly prefer decimal notation for coordinates. (What's next, a return to Roman numerals?) I am disappointed to see a loss of choice. Why doesn't {{Coord}} have a parameter to select the display format? Great job, otherwise.

I would imagine lots of people will wonder why we cannot display decimal degrees any more, and therefore the documents should explain the reasoning behind removing the feature. We cannot please all the people all the time, but we can be pretty sure that when we remove a feature people are accustomed to using, at least some of them are likely to be displeased, and they may not understand why (in their perception) they are getting screwed. If removing this feature actually benefits everyone, then we should explain the benefits, because the benefits aren't obvious from where I sit. Wikipedia happily tolerates regional variations in English spelling; why would there be a greater need to standardize the display of coordinates, and standardize on the archaic option? --Teratornis 20:31, 3 April 2007 (UTC)

Thank you for your input, Saintrain, Andy, Teratornis. You can now choose to display as decimal (default is whatever the source specifies). I believe this is better than the previous system where you were forced to view it in the format that the source specified. —Quarl ^(talk) 2007-04-04 11:37Z

Maintainability

I believe this template will be difficult to maintain because the meanings of positional parameters change from one "overload" to the next. --Kevinkor2 18:12, 31 March 2007 (UTC)

Please can you explain your concerns in more detail and - if possible - suggest solutions? Thank you. Andy Mabbett 18:31, 31 March 2007 (UTC)

Sorry about that. I was trying to debug {{smallcaps}} and I thought part of the problem was positional arguments with #if. --Kevinkor2 12:55, 6 April 2007 (UTC)

OK, no worries. Thank you. Andy Mabbett 13:24, 6 April 2007 (UTC)

I think we're fine, uses (articles) don't need to be updated, since the template is backwards-compatible. We just need to (re-)redirect {{coor dms}} et al. —Quarl ^(talk) 2007-04-04 11:38Z

Inappropriate precision and Coordinate Display/Conversion

The page Great Barr uses decimal values, to three decimal places: {{tl:coord|52.548|N|1.932|W}} - an accuracy of ~100m. However, the page displays 52°32′52.8″ N 1°55′55.2″ W - accuracy to ~3m. Whatever is doing the calculating (is it this template, or somewhere else?) needs to do some rounding. Andy Mabbett 17:12, 3 April 2007 (UTC)

Thanks, addressed below. —Quarl ^(talk) 2007-04-04 11:41Z

• Why does the coord template assume that all coordinates should be converted to Degrees/Minutes/Seconds? The coor templates allowed users to decide how they wanted to display the coordinates, according to what was appropriate to the article: articles documenting a region may want to just display an integer degree value, with no minutes or seconds displayed, which appears to be impossible with the coord template. --Ozhiker 17:20, 3 April 2007 (UTC)

• • Thanks for the input, but I think you misunderstood the documentation (which I've now clarified). If the coordinate has only d/m precision, it is displayed as d/m. For example: {{coor}} displays only degrees: {{Coor|12|N|34|E}}. This template supports everything the old templates supported. What Andy mentioned above was a different, though related, bug. —Quarl ^(talk) 2007-04-04 11:41Z

Display preferences

In coord, the decimal values are hidden by <span class="geo" style="display:none">; if we also wrap the DMS values in a class, say <span class="geo-dms">, then, by tweaking their local style sheets, users could choose to display or hide either or both. Andy Mabbett 20:36, 3 April 2007 (UTC)

Updates

Okay, I made a lot of changes and I think I addressed all the concerns raised post-deployment:

• The template by default now displays the notation (DMS or decimal) that the source uses, by default. The user can, through monobook.css (instructions on doc page), change that to either
  1. always decimal
  2. always DMS
  3. both (DMS, then decimal in parentheses)
  4. (I guess could also choose to display nothing at all :)
• Works correctly for non-CSS browsers, same as "both" option
• Extra parameters like scale, region, etc., now supported, either like {{coord|...|scale:1000_type:city}} or like {{coord|...|scale=1000|type=city}}
• Precision now works better. It should work for both values input as decimal and displayed as DMS, and vice versa. I had to invent some new templates ({{precision}}) to get tricky cases like 43°39.34′ working. It might not be perfect yet though, if there are any bugs please fix them: {{coor dms2dec}}, {{coor dec2dms}}.
• geo microformat of course still works.
• Still/more backwards-compatible with {{coor dms}} et al, so no need to replace all existing uses.

—Quarl ^(talk) 2007-04-04 11:35Z

Oh yeah, a number of geo-related classes are now defined at MediaWiki:Common.css. You may need to refresh this page: [1]. —Quarl ^(talk) 2007-04-04 11:46Z

Thank you for your amazing work. We'll need to make sure that this suits the wikicode parsers, which, I'm sure, will need to be tweaked accordingly. Replacing, by bot, the existing "coor" uses will make things easier for such parsers (and new parsers) in the future, by reducing the number of permutations to be catered for, and will encourage users to use the new template, if they're learning by copying existing pages. I don't do "barnstars" and the like but I wish I could buy you a beer in R/L! Andy Mabbett 11:46, 4 April 2007 (UTC)

Okay, thanks :) —Quarl ^(talk) 2007-04-04 11:48Z

Now, about {{coor title d}}... ;-) Andy Mabbett 11:54, 4 April 2007 (UTC)

"Still/more backwards-compatible with {{coor dms}} et al, so no need to replace all existing uses." But that means yet more work for anyone who is trying to read our data... also means more templates to maintain.. more confusion for editors, etc. I'll test the changes tonight and make some suggestions. :) But at the end what we need to achieve is something that can reasonably replace the existing uses. Once we're there the actual replacement is utterly trivial. --Gmaxwell 21:12, 4 April 2007 (UTC)

Ah, and as far as coor title d goes.. since we now have working arguments, I really think we should solve that with an extra argument to the template {{coord|...|scale:1000_type:city|display=title}} --Gmaxwell 21:14, 4 April 2007 (UTC)

Very much agreed. Also "coor at d". Perhaps "display=title" should be the default, with "display=inline" added where necessary? (How many "coor d*" currently exist, and how many "coor title d*"?) What about the "Geolinks-*" template family? Thanks for offering to do testing. Andy Mabbett 21:22, 4 April 2007 (UTC)

 Done, see #New_display_parameter —Quarl ^(talk) 2007-04-07 07:12Z

Precision revisted

I think 43°39′ N 79°22.8′ W should be 43°39′ N 79°22′ W (As seen on the template documentation's examples). Andy Mabbett 12:05, 4 April 2007 (UTC)

 Done Fixed, it's now 43°39′ N 79°23′ W —Quarl ^(talk) 2007-04-07 06:40Z

Bug: when displaying both formats

I've just added the CSS to display both formats, to my monobook.css. For Great Barr, I'm now getting 52.548°N 1.932°W (52.548, -1.932), with decimal-degrees, not DMS, in the first part. Same problem with the fourth Toronto example, and Moscow's, on the template documentation. Andy Mabbett 21:14, 4 April 2007 (UTC)

 Done Fixed. —Quarl ^(talk) 2007-04-07 06:25Z

Categories

I think this template should be in the categories "Protected templates" and "Coordinates templates" (as is "coor dms"). Andy Mabbett 21:44, 4 April 2007 (UTC)

 Done —Quarl ^(talk) 2007-04-07 06:15Z

Bug: breaks with many instances

I created a copy of List of impact craters on Earth, at User:Pigsonthewing/scratchpad, using coord. It breaks halfway down the second table. Perhaps the cause is the total number of template calls. I've sub-divided the original page and substituted coord; I'll leave the long, broken version on my user page. Andy Mabbett 14:11, 6 April 2007 (UTC)

• And here's a simpler test-case. Andy Mabbett 16:54, 6 April 2007 (UTC)

 Done Fixed. Thanks for tracking that down. I had to re-architect it using subroutine templates like {{Coord/dms}}, but it pays off a lot in reducing pre-expand size. —Quarl ^(talk) 2007-04-07 06:09Z

Request for a title argument

As long as this template isn't frozen yet, let me ask for another little feature: a title arguments. With lots of inline coordinates (i.e. Ridge Route) external usability of the data would be greatly enhanced. My ideal solution, forget about the display= argument, request a title= for every inline coordinate and put the one coordinate without it in the title. --Dschwen 22:38, 4 April 2007 (UTC)

You refer, I think, to discussion at Wikipedia:Peer review/Ridge Route/archive1. The existence of {{Coor at dms}} suggest that the issue is more complex than you imply here, but it should be possible to include a switch for inline, title-level, or both; as well as one for including your title. Andy Mabbett 01:27, 5 April 2007 (UTC)

I haven't read that discussion, thanks for the link! As for the coor at template family, I think they are fairly pointless and should be deprecated anyways. KISS principle! --Dschwen 07:26, 5 April 2007 (UTC)

Dschwen, the coordinates are part of the text and should be displayed, not hidden. On the occassions that you really don't want to show the coordinate itself, you can just use {{Coor}} instead of {{Coord}}. That template is dead simple since it doesn't need to do any CSS magic nor show a Geo microformat coordinate. —Quarl ^(talk) 2007-04-07 06:18Z

I agree that cords should be visible; and that's also required for a microformat, which should be present. I'd be wary of using {{Coor}}, as we're likely to result bot replacement of all such examples. I think the answer may be to put the coordinates in a separate table. I'll suggest that at the above discussion. Andy Mabbett 08:07, 7 April 2007 (UTC)

Huh? Where did I suggest the coords should be hidden? That must be a slight misunderstanding. --Dschwen 10:10, 11 April 2007 (UTC)

Sorry, I must have misunderstood. Can you clarify, perhaps with an example? —Quarl ^(talk) 2007-04-12 07:49Z

If coordinate data is to be extrated from articles, for example to create the GoogleEarth wikipedia layer, how should articles with tens of coordinates be treated? Should every coordinate marker from the article be labeled with the article title? That wouldn't be very useful, would it? Instead I propose an optional title (or name) argument, which describes the coordinate and allows to create meaningful labels for maps. I.e. in Ridge Route:

Reservoir Summit {{coor d|34.663|N|118.725|W|title=Reservoir Summit}}, also called Reservoir Hill, is 3883 feet (1184 m) above sea level. The Reservoir Summit Café was a popular [[high-class]] restaurant on the east side of 
the road, closed in the late 1920s; the [[foundation]] remains. The summit was named after a now-dry [[reservoir]], 
one of three probably built for the [[concrete]] used in paving the road.<ref>Scott, pp. 43-45, 121-126</ref>

Kelly's Half Way Inn {{coor d|34.683|N|118.729|W|title=Kelly's Half Way Inn}} was roughly halfway between Los Angeles 
and Bakersfield - 62 and 64 mi (100 and 103 km) respectively. Located on a small knoll with a single tree 
on the east side of the road, all that remains is remnants of the foundation.<ref>Scott, pp. 126-130</ref>

The labels created from these tags could be Reservoir Summit (Ridge Route) and Kelly's Half Way Inn (Ridge Route). --Dschwen 11:37, 19 April 2007 (UTC)

Usage

How many pages use coor at? Andy Mabbett 10:32, 6 April 2007 (UTC)

• coor at d: ~150
• coor at dm: ~550
• coor at dms: ~620

Most of them come from the use in infoboxes.--Dschwen 10:45, 6 April 2007 (UTC)

Thank you. How did you do that? It would be good to have counts for coor and coor title, as well, please. Andy Mabbett 11:11, 6 April 2007 (UTC)

• coor: 5,506
• coor d: 26,185
• coor dm: 59,635
• coor dms: 75,427
• coor title d: 18,353
• coor title dm: 39,587
• coor title dms: 27,596

Found using What transcludes here feature in AutoWikiBrowser, takes a while though! Any more of interest? Adambro 19:25, 6 April 2007 (UTC)

No, but that's great, thank you. That's over a quarter-million geo-tagged articles, and a quarter-million potential Geo microformats! Andy Mabbett 19:58, 6 April 2007 (UTC)

Wikicode parsers

How will parsers deal with pages which have more then one {{coord}}? For example, Ridge Route, List of impact craters on Earth. Andy Mabbett 11:41, 6 April 2007 (UTC)

Google Earth mashup

See: Google_Earth#Wikipedia_and_Panoramio_mashup and Google's documentation. Andy Mabbett 13:02, 5 April 2007 (UTC)

So do we know if Google Earth understands coord yet? Amake 07:37, 16 April 2007 (UTC)

No - I've been waiting on Gmaxwell. Andy Mabbett 11:36, 16 April 2007 (UTC)

Could someone also tell the Google people to enable parsing of Infobox templates? Currently GoogleEarth doesn't seem to capture coordinates from them (e.g. Infobox Town). This leads to the somewhat absurd situation that in some cases stubs (suburbs) show up and fully fleshed out articles (main city) don't. 80.129.120.188 21:52, 11 May 2007 (UTC)

Actually according to this site, Google does parse Infobox templates, but only if the coordinate info is labeled with the keywords "coordinates" or "coords". I was encountering the same problem as you with the Template:Infobox City Japan, but we (hopefully) solved it by changing the "coord" keyword to "coords". Unfortunately Google hasn't updated the Wikipedia layer lately, so I don't know if it's actually fixed. Amake 12:29, 23 May 2007 (UTC)

I don't think Google does anything with Infobox templates themselves, they just search the wikitext for coor title d[ms], coor at d[ms] and coor d[ms]. The first two are special because the given coordinate applies to the whole article, which is why we place it at the top as well. A lonely inline coor d[ms] is not important and isn't visualized, unless it's used with a coordinate parameter in an infobox, which in turn makes it apply to the whole article. Note that currently coordinates given with the coord template are not shown at all. Google's updates follow the database dumps, which unfortunately with the English Wikipedia don't happen very ofen. And yes, the Infobox City Japan change looks fine. --Para 23:34, 23 May 2007 (UTC)

Couldn't the information in the infoboxes be entered in the format given by the Manual of Style? I don't see much reason in having to give each number in a separate variable, as the information is mostly static anyway. Perhaps I'm overlooking something? --Para 09:51, 23 May 2007 (UTC)

New display parameter

The new display named parameter adds {{coor title dms}} and {{coor at dms}} functionality. display can be inline (default, same as before), title, and inline,title.

Examples:

{{coord|12|34|N|45|67|W|display=title}}	Replaces {{coor title dm|12|34|N|45|67|W}}
{{coord|12|34|12|N|45|67|45|W|display=inline,title}}	Replaces {{coor at dms|12|34|12|N|45|67|45|W}}
{{coord|10.2|-20.3|display=inline}} or {{coord|10.2|-20.3}}	Replaces {{coor d|10.2|N|-20.3|E}}

—Quarl ^(talk) 2007-04-07 07:09Z

Quarl, thanks again for some superb work! My test page now has 200 working examples. Andy Mabbett 07:21, 7 April 2007 (UTC)

Archive

I've just done a big archive. Some of the material was fairly recent, but superseded by Quarl's latest edits. Andy Mabbett 07:21, 7 April 2007 (UTC)

Bug: Antarctica

Antarctica has an odd use of coor d (example: {{coor d Antarctic|25|W}}), which breaks if changed to coord. Andy Mabbett 08:56, 7 April 2007 (UTC)

Good find. Given that that article wants to hide the latitude when rendered in the article, and secondarily not have to specify 60°S in every template invocation, it'd have to be a separate template. Not sure hiding the 60°S is really necessary, but someone did go to the trouble of making that template... —Quarl ^(talk) 2007-04-08 04:30Z

How does that affect plans to bot convert/ redirect coor d ? Andy Mabbett 08:17, 8 April 2007 (UTC)

Perhaps it needs to be re-written, to output a microformat, with the -60 latitude hidden? Andy Mabbett 11:38, 16 April 2007 (UTC)

Breaking after 240-odd occurrences

Using coord' over 240 times on one page breaks it; however, I think such use is unreasonable and any such pages should be sub-divided. See User:Pigsonthewing/scratchpad for an example with over 1,000 (!) examples - based on List of islands of Western Australia, which I plan to sub-divide later. Andy Mabbett 09:45, 7 April 2007 (UTC)

Wow, that page has 1000 uses? :) I'll see if I can further trim the pre-expand size, but there'll always be a limit. —Quarl ^(talk) 2007-04-08 04:31Z

Okay, I optimized some more, that should help a lot. —Quarl ^(talk) 2007-04-08 05:35Z

Thanks. It now breaks after ~675! Thank you for your latest fixes. Believe it or not, there is some [Wikipedia talk:WikiProject Western Australia#List of islands of Western Australia is too long|resistance to splitting that page]. Andy Mabbett 08:26, 8 April 2007 (UTC)

Now sub-divided. Andy Mabbett 08:22, 12 April 2007 (UTC)

Bug: poor handling of mis-matched lat/long precision

{{coord|36|46|N|118|49|20|W|}} (DM;DMS) gives:

Andy Mabbett 20:46, 7 April 2007 (UTC)

Interesting case. When would one want to use mixed precision, and what behavior would we want? —Quarl ^(talk) 2007-04-08 04:33Z

On the page where I found that, I added a "0 seconds", since that was what I thought was implied. Perhasp a job for the conversion bot? Andy Mabbett 08:17, 8 April 2007 (UTC)

Bug: Spacing

If you go to WWVB, you will see that Template:Coord adds an errant space. Can this be fixed? --  Denelson83  06:25, 8 April 2007 (UTC)

 Done Thanks for the bug report; fixed. (A bug/unwanted-feature in MediaWiki moves leading spaces in <span>s outward. I had to insert some dummy stuff to stop that.) —Quarl ^(talk) 2007-04-08 07:08Z

Suggested improvement

Changing the "display both" output (for example):

32°18′19″S 115°41′28″E (-32.30528, 115.69111)

to:

32°18′19″S 115°41′28″E / -32.30528, 115.69111

would mean that there was one less span in the mark-up (reducing file sizes for long lists of coordinates, some of which have over 200 entries) and would look better when the template is already in brackets, like:

(32°18′19″S 115°41′28″E)

Andy Mabbett 18:51, 8 April 2007 (UTC)

 Done —Quarl ^(talk) 2007-04-12 07:44Z

Thank you. That looks much better. Andy Mabbett 08:22, 12 April 2007 (UTC)

Suggested improvement 2

"display=inline,title" is valid, but not "display=title,inline". Perhaps both should be? Andy Mabbett 21:50, 8 April 2007 (UTC)

 Done —Quarl ^(talk) 2007-04-12 07:46Z

Thank you again! Andy Mabbett 08:22, 12 April 2007 (UTC)

Quick one

Let's say I want it to link to the geohack but I want it to display something else completely, basically like an alternate text tag such as this text. Is there an option currently configured to do that? (I'm guessing it's something I've just missed in the docs but if not, I think it would be really useful.) If this is available, I can change a single major template across to use it which carries with it several thousand Australian articles.

Excellent work has gone into this btw, those geographers amongst us will be most grateful for your hard work and efforts in making the previous mind-boggling array of templates work so much more nicely. Orderinchaos 10:37, 11 April 2007 (UTC)

At the moment, no. Why would you want to hide the coordinates? Andy Mabbett 20:53, 11 April 2007 (UTC)

Comes from one of the templates {{Mapit-AUS-suburbscale}} where the heading is actually the coor currently. I've already been able to flip the title bit across to use this template, but not the heading. Orderinchaos 22:00, 11 April 2007 (UTC)

I'm not sure I follow you - what do you mean by "heading"? Anyway, thank you for using coord. Andy Mabbett 22:10, 11 April 2007 (UTC)

More than happy to - it's more sane and logical than anything that preceded it, and I like consistency. :) On Corrigin, Western Australia for example, the heading is "Maps and aerial photos". The code creating this, from the template, is {{Coor|{{{lat}}}_N_{{{long}}}_E_type:landmark_region:AU|Maps and aerial photos}} - an odd non-standard use admittedly, but yeah. Orderinchaos 05:41, 12 April 2007 (UTC)

Hmmm - there are two lots of coordinates in that article, one (using decimal values) with the display you refer to, the other, (DMS) on the opening paragraph with a display on the title bar. I think that's the way to madness; such metadata should be entered once only. Are there many articles like that ? I think it may be better to rationalise the way they're coded. Anyway, I think your former usage makes sense, only; if the coordinates are displayed in the title bar. Since that seems to be working already, and using coord, I'm not clear what it is you're asking for. Andy Mabbett 08:31, 12 April 2007 (UTC)

There are a few - in retrospect that was not a great example to use as I haven't cleaned it up yet (most of the culprits are older Australian pages). Bruce Rock, Western Australia is a better example - the maps and aerial photos heading links to the same page as the title attributes (keeping in mind they normally would not be on the same screen), but there doesn't seem to be a way to get it to display as "Maps and aerial photos" with coord, it displays the actual coordinates instead. Once we've got this one sorted out it will actually be a lot easier to find the odd ones out, I can do intersection queries with AWB to determine which of our project articles exhibit this problem and clear them out, as we really should only have the title coords at the top. Orderinchaos 20:05, 15 April 2007 (UTC)

On Bruce Rock, I see "Maps and aerial photos" under external links, and the numerical coordinates in the title bar. Is that not what you expect? Or want? Andy Mabbett 20:20, 15 April 2007 (UTC)

Actually, found a better way to explain it. On Template:Coor documentation, it mentions {{Coor|cc|tt}} - it's the tt bit I'm asking about. If there isn't one already, maybe an "alt" tag would cover this, eg "|alt=Maps and aerial photos". (Although I recognise this template doesn't strictly replace coor, in this particular case the use of coor is completely unnecessary as we can make the link using this template) Orderinchaos 06:08, 16 April 2007 (UTC)

Sorry, I still don't understand what you want. Andy Mabbett 13:30, 18 April 2007 (UTC)

I think the desired result here is a single template to give the relevant link to Special:Mapsources as well as the desired microformats, with the ability to make the link text something other than the coordinates themselves. In the examples Orderinchaos gives, the coordinates are in the title bar, the microformat included, with links to the map sources page in the title bar and at the "maps and aerial photos" text - this all being achieved by calling both {{coord}} and {{coor}}, which seems a bit of a waste. Whatever the pros and cons of {{Mapit-AUS-suburbscale}}, this option does sound like it might be a good idea, as it provides a way to include map links and microformats even when including coordinates visible to the reader is plain disruptive. JPD (talk) 14:01, 18 April 2007 (UTC)

So long as the coordinates are displayed once, in the title, it might be a good idea to have a text display in-line (but note that hiding the coordinates in both would be a very bad idea and would invalidate the microformat). Paging Quarl... Andy Mabbett 15:13, 18 April 2007 (UTC)

(reset indent)Well yes, in Orderinchaos' examples, the microformat in some sense belongs with the coords in the title bar, and the heading in external links is just an extra link to the map page. Apart from that, I understand that it is valid to display a the geo-reference in a Geo microformat in some other form (such as OS grid references), which this would allow - I'm not sure how flexibility is valid here. Would an indication that there is a geo-reference in the page, without any details of the actual reference, be enough? There are definitely situations where the visible coordinates are not helpful to the reader. It is fine to say that the microformat is only valid for things that are visible, but this means it is wrong to use the benefits of microformats as a justification for adding coordinates to articles. JPD (talk) 16:30, 18 April 2007 (UTC)

"I understand that it is valid to display a the geo-reference in a Geo microformat in some other form (such as OS grid references), which this would allow" - yes, that's right; since the two are directly convertable, in either direction.

"Would an indication that there is a geo-reference in the page, without any details of the actual reference, be enough?" - No.

Andy Mabbett 11:24, 19 April 2007 (UTC)

add it

please add the interwiki it:Template:Coord --WISo 18:07, 15 April 2007 (UTC)

 Done —Quarl ^(talk) 2007-04-16 01:20Z

Adding hCard wrapper

I've been contemplating different possibilities for "wrapping" the output of coord in an hCard microformat. One would be to have a "scope-page" attribute:

{{coord|53.653|-1.838|type:landmark|display=title|scope=page}}

which included {{pagename}} in the output, hidden by CSS by default.

Another would be a separate hCard template, which called coord if coordinates were present.

Thoughts? Andy Mabbett 13:27, 18 April 2007 (UTC)

Is an hCard really appropriate for every instance of coordinates? If not, suresly a separate template would be most appropriate. JPD (talk) 14:20, 18 April 2007 (UTC)

No, though most do; especially those which apply the subject of an article page. I don't see how your latter point follows from that, though. Andy Mabbett 14:27, 18 April 2007 (UTC)

I'm not sure if I understand completely what it is Andy is contemplating but I'll describe a situation which I believe could be related to this discussion. I've recently added the coord template to Template:Infobox UK station within "fn org" classes. Using the Operator add on for Firefox, this shows up in the drop down "Find with Google Maps" list as {{name}}, e.g. Huddersfield. I think it would be more desirable to use the {{PAGENAME}} variable to display the page name in the list, e.g. Huddersfield railway station. However, the pagename would want to be hidden of course. I think this is what Andy is discussing and would like to find a way to do it. Adambro 14:41, 18 April 2007 (UTC)

That would indeed be good - but hadn't occurred to me! I was thinking, for example, of yoru recent addition of coord to Huddersfield New College, where the extra parameter would have generated an hCard, with the page name as the "fn org" (i.e. name) attribute, not just a Geo. Andy Mabbett 14:49, 18 April 2007 (UTC)

(edit conflict)That could be a good thing to do with {{Infobox UK station}}, but I don't really see why it should be part of this template. As I understand it, what you have done is not so much "added the coord template to Template:Infobox UK station within "fn org" classes", as added both the coord template and "fn org" classes, wrapped in an hCard microformat. As the coords are just part of an hCard (perhaps more relevant than the fact that they don't always belong in one), it seems logical to call coord from an hCard template, rather than incorporate the hCard in the coord template, whether or not {{PAGENAME}} is used. JPD (talk) 15:07, 18 April 2007 (UTC)

Questions and possible errors

I've never used {{coord}} yet, only the deprecated {{coor dms}} et al, but I have been experimenting with it today. I have some questions and also think I've found some errors. First of all, how do you get {{coord}} to display decimal degrees? If I enter a number in decimals, why does it auto-convert to dms? Is there an optional parameter to set so it will display decimals? Yes, I've looked in the documentation, but have not found the answer.

Second, it doesn't even appear to convert properly. I've found three classes of apparent problems:

• Completely wrong, erroneous conversion, may have other errors too
• Wrong precision, failing to use trailing zeroes to detect and display proper amount of precision: dd.dd° should give dd°mm′, and dd.ddd° needs to give dd°mm′ss″
• Missing leading zero, I think dd°mm′ss″ or dd°mm′ notation should always show leading zeroes, e.g. 33°02′07″ or 33°02′.

See these examples:

• {{coord|48.02|N|121.02|W|type:mountain}} displays as 48.02°N 121.02°W / 48.02; -121.02   Completely wrong Fixed, should convert as 48°01′N, 121° 01′W
• {{coord|48.020|N|121.020|W|type:mountain}} displays as 48.020°N 121.020°W / 48.020; -121.020   Completely wrong Fixed, should convert as 48°01′12″N, 121° 01′12″W
• {{coord|48.03|N|121.03|W|type:mountain}} displays as 48.03°N 121.03°W / 48.03; -121.03   Completely wrong Fixed, should convert as 48°02′N, 121° 02′W
• {{coord|48.05|N|121.05|W|type:mountain}} displays as 48.05°N 121.05°W / 48.05; -121.05   Correct conversion, but missing leading zero fixed, should be 48°03′N, 121° 03′W
• {{coord|48.12|N|121.22|W|type:mountain}} displays as 48.12°N 121.22°W / 48.12; -121.22   Correct conversion, but missing leading zero fixed, should be 48°07′N, 121° 13′W
• {{coord|48.120|N|121.220|W|type:mountain}} displays as 48.120°N 121.220°W / 48.120; -121.220   Wrong precision Fixed, should convert as 48°07′12″N, 121° 13′12″W
• {{coord|48.119|N|121.219|W|type:mountain}} displays as 48.119°N 121.219°W / 48.119; -121.219   Correct conversion, but missing leading zero fixed, should be 48°07′08″N, 121° 13′08″W

Thanks for looking into this. --Seattle Skier (See talk tierS) 18:01, 18 April 2007 (UTC)

Edited to add: This template displays very differently in different browsers. I use Mac OS X, and mostly the Safari browser, but occasionally Firefox. I get the following output for my examples above:

Safari:

• {{coord|48.02|N|121.02|W|type:mountain}} displays as 48°N 121°W Completely wrong, should convert as 48°01′N, 121° 01′W
• {{coord|48.020|N|121.020|W|type:mountain}} displays as 48°N 121°W Completely wrong, should convert as 48°01′12″N, 121° 01′12″W
• {{coord|48.03|N|121.03|W|type:mountain}} displays as 48°N 121°W Completely wrong, should convert as 48°02′N, 121° 02′W
• {{coord|48.05|N|121.05|W|type:mountain}} displays as 48°N 121°W Correct conversion, but missing leading zero, should be 48°03′N, 121° 03′W
• {{coord|48.12|N|121.22|W|type:mountain}} displays as 48°7′N 121°13′W Correct conversion, but missing leading zero, should be 48°07′N, 121° 13′W
• {{coord|48.120|N|121.220|W|type:mountain}} displays as 48°7′N 121°13′W Wrong precision and missing leading zero, should convert as 48°07′12″N, 121° 13′12″W
• {{coord|48.119|N|121.219|W|type:mountain}} displays as 48°7′8″N 121°13′8″W Correct conversion, but missing leading zero, should be 48°07′08″N, 121° 13′08″W

Firefox:

• {{coord|48.02|N|121.02|W|type:mountain}} displays as 48°N 121°W / 48.02, -121.02 Completely wrong, should convert as 48°01′N, 121° 01′W
• {{coord|48.020|N|121.020|W|type:mountain}} displays as 48°N 121°W / 48.02, -121.02 Completely wrong, should convert as 48°01′12″N, 121° 01′12″W
• {{coord|48.03|N|121.03|W|type:mountain}} displays as 48°N 121°W / 48.03, -121.03 Completely wrong, should convert as 48°02′N, 121° 02′W
• {{coord|48.05|N|121.05|W|type:mountain}} displays as 48°3′N 121°3′W / 48.05, -121.05 Correct conversion, but missing leading zero, should be 48°03′N, 121° 03′W
• {{coord|48.12|N|121.22|W|type:mountain}} displays as 48°7′N 121°13′W / 48.12, -121.22 Correct conversion, but missing leading zero, should be 48°07′N, 121° 13′W
• {{coord|48.120|N|121.220|W|type:mountain}} displays as 48°7′N 121°13′W / 48.12, -121.22 Wrong precision and missing leading zero, should convert as 48°07′12″N, 121° 13′12″W
• {{coord|48.119|N|121.219|W|type:mountain}} displays as 48°7′8″N 121°13′8″W / 48.119, -121.219 Correct conversion, but missing leading zero, should be 48°07′08″N, 121° 13′08″W

So Firefox is always showing the decimals, while Safari never does. I think this template needs major revision if it displays so differently in two completely modern, highly-standards-compliant browsers like Safari and Firefox (not to mention the conversion errors in both browsers). Thanks in advance for checking this out. --Seattle Skier (See talk tierS) 18:26, 18 April 2007 (UTC)

Thank you for you work on this; there are certainly some issues of concern. I've dropped a note on User:Quarl's talk page; he created the template at my request; he's been exceedingly helpful, so far, and should be along shortly.

As for display; please see: Template:Coord#Display for guidance on modifying your monobook.css

The Firefox vs. Safari issues sound CSS related; can you check that you have "hard refreshed" both browsers, please? And that you haven't got anything which might conflict in your monobook.css, as above? You might also try viewing your test pages in both browser, but with CSS disabled (you should then see DMS and decimal values). Also, are you logged on, or out, on each browser?

Andy Mabbett 21:32, 18 April 2007 (UTC)

UPDATE He appears to be working on it already; renditions may break, temporarily, while he's doing so,. Andy Mabbett 21:50, 18 April 2007 (UTC)

Thanks, Andy and Quarl, for looking into this quickly. I can see already that all the ones I had marked as Completely wrong and Wrong precision have now been fixed. Only the leading zeroes and browser issues remain.

Regarding the browsers, the display looks the same whether I'm logged in or out. Also, I can't find any options or settings in either browser to disable CSS, and Safari also has no separate "hard refresh" that I know off (like Shift-Reload in Firefox). As far as I know, I haven't made any special settings to my monobook.css, so I'm not sure why the browsers don't display the coords "in the format in which they are specified" as it says in Template:Coord#Display. The display seems fixed in each browser, even for other examples:

• {{coord|48.119|N|121.219|W|type:mountain}} displays as 48.119°N 121.219°W / 48.119; -121.219 (only dd°mm′ss″ in Safari, but both in Firefox)
• {{coord|48|07|08|N|121|13|08|W|type:mountain}} displays as 48°07′08″N 121°13′08″W (only dd°mm′ss″ in Safari, but both in Firefox)
• {{coord|48|07|N|121|01|W|type:mountain}} displays as 48°07′N 121°01′W (only dd°mm′ in Safari, but both in Firefox)

--Seattle Skier (See talk tierS) 00:31, 19 April 2007 (UTC)

 Done Hi Seattle Skier, thanks for the detailed bug report. As you've noticed, the precision bugs (including trailing zeroes) are fixed now, and leading zeroes are now inserted. Let me know if you find any more bugs.

I use Firefox so I'm pretty sure it works in Firefox; the symptom you describe is exactly what you would get with an old cached version of Common.css. It would affect you whether logged in or not. Control-Shift-R should work, but if not you can try refreshing this page: [2]. Or, you could invoke the "clear cache" option (Preferences => Network => Cache => Clear now). —Quarl ^(talk) 2007-04-19 00:56Z

Hi Quarl, thanks for fixing things so quickly. Things now look almost identical for me in Safari and Firefox, except there are extra blank spaces before the ss″ and N or W in Firefox only. It looks like this for me:

• {{coord|48.119|N|121.219|W|type:mountain}} displays as 48°07′   08″   N 121°13′   08″   W   (on screen in Firefox)
• {{coord|48|07|08|N|121|13|08|W|type:mountain}} displays as 48°07′   08″   N 121°13′   08″   W   (on screen in Firefox)

but if I copy and paste it into the edit box for this page, it shows this:

• {{coord|48.119|N|121.219|W|type:mountain}} displays as 48°07′08″ N 121°13′08″ W / 48.119, -121.219   (((not what I see on screen)))
• {{coord|48|07|08|N|121|13|08|W|type:mountain}} displays as 48°07′08″N 121°13′08″W / 48.11889, -121.21889   (((not what I see on screen)))

Why does the copied and pasted text from Firefox include decimals, while what is on the screen does not (and has those odd spaces)?

Safari still shows only this, onscreen and also pasted here:

• {{coord|48.119|N|121.219|W|type:mountain}} displays as 48°07′08″ N 121°13′08″ W
• {{coord|48|07|08|N|121|13|08|W|type:mountain}} displays as 48°07′08″N 121°13′08″W

So I'm still not sure how to get it to display decimals in Safari. I'll look into it again later. --Seattle Skier (See talk tierS) 01:22, 19 April 2007 (UTC)

Thanks, I removed an extra space between the ″ and N/E/S/W. I fixed a bug in detecting the input being decimal. Regarding differences in text when copied to clipboard, I don't see that in Firefox (version 2.0), but this is probably why it happens to you: the text is always there, but it is selectively hidden using CSS, I guess (your version of) Firefox copies it anyway. I don't see it as much of a problem; do you? Regarding spaces between 07′ and 08″, I don't see any; are you sure it's not just the font making it look like there is a space after every "′", or perhaps space changes due to paragraph justification? —Quarl ^(talk) 2007-04-19 02:17Z

Yes, the decimal detection is now working properly in both of my browsers, thanks. My Firefox is 2.0.0.3 (specifically: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3), but I'm not sure if the code-base is indentical on all platforms. I think the extra space is actually a font problem with the ′ and ″, because I see similar spacing issues even in typed text above which is not using {{coord}}. So that's a Firefox/font/OS issue, nothing to do with the template here. I won't worry about it much, even though it does look ugly (the spaces are huge, about __ wide), since Firefox is not my primary Wkipedia browser. --Seattle Skier (See talk tierS) 07:02, 19 April 2007 (UTC)

Another big "Thank you" to Quarl! Andy Mabbett 11:17, 19 April 2007 (UTC)

Display issues

I hate to drag this discussion further out but should {{coord|35.5|N|111.6|W|type:mountain}} display as 35.5, -111.6 or should it look like 35.5N 111.6W ? (With the active template: 35.5°N 111.6°W / 35.5; -111.6) This is on IE6 if that matters. I won't be able to check what this does under Firefox or Safari until tomorrow. --Burntnickel 11:48, 19 April 2007 (UTC)

Sorry, another one - how come the template no longer converts to human-readable dms for the display (while still linking to the accurate decimals for the link)? I assume there is a good reason. Obviously I can change my own monobook to display in this manner, but I think human-readable is more useful for encyclopaedic articles. Orderinchaos 13:37, 19 April 2007 (UTC)

By default, coord displays in the format used for data entry. Besides, some of us humans prefer decimal values! Andy Mabbett 14:47, 19 April 2007 (UTC)

Can we at least have the N/S and E/W back? :) (eg Shire of Bruce Rock) Orderinchaos 15:38, 19 April 2007 (UTC)

You've already go it, in: "31°52′52″S 118°08′53″E" . Andy Mabbett 16:16, 19 April 2007 (UTC)

It's not displaying - I'm seeing "the town of Bruce Rock ( -31.881, 118.148; post code: 6418)" This is on Firefox 1.5. Orderinchaos 16:24, 19 April 2007 (UTC)

That's because the input is decimal ("31.881|S|118.148|E"). Change to DMS and you will see "S" and "E". Andy Mabbett 16:43, 19 April 2007 (UTC)

So if I'm making a table of locations with coordinates I need to either make them all dms or decimal degrees to get them to appear consistantly? Some source material has them one way and other souce material has them in another. Is the conversion by hand worth it for consistancy or should I just leave everything as in the source then?

For consistent appearance by default; yes, they should all use the same format (that's no different to using the previous coordinate templates). Conversion need not be by hand, as there are on-line tools. Andy Mabbett 19:24, 19 April 2007 (UTC)

(drop indent) It's confusing when we start fixing these articles and employing the template in our work only to find it radically changing like it did yesterday without warning, which then impacts an increasing number of articles. If this sort of stuff keeps up you may well find consensus for use of it as a standard deteriorating. I for one am going to have to stop employing it in my work until these concerns are addressed, which is something I really don't want to have to do, as the template as it stood on 18 April *was* superior to what we had - however readers of articles I have written will have difficulty comprehending what is there now. Orderinchaos 23:09, 19 April 2007 (UTC)

You object to bugs being fixed? Andy Mabbett 23:11, 19 April 2007 (UTC)

As far as I see it, *this* is a bug. This is a case of something that people can read being substituted for something that most people can't. It goes without saying that one would not see ( -31.881,118.148) (complete with space in front of it) in the Britannica. The numbers as printed could relate to just about anything - temperatures? altitude? random data? There should also be an option to convert rather than forcing users to change monobook.css just to see the thing correctly. Despite being quite an IT-literate user, it took a fair bit of help to learn how to correctly modify this file on my own setup a few months ago. Orderinchaos 23:20, 19 April 2007 (UTC)

There is nothing to stop you prepending a coord with "located at" or "coordinates", or some such. coord gives editors and readers more choice then they had previously; you are proposing yet more functionality, which is noble, but which you need to raise on the MediaWiki site, not here (MediaWiki is the software which drive Wikipedia, and the changes you propose would require that to be modified). Andy Mabbett 23:41, 19 April 2007 (UTC)

How come it worked correctly until 18 April then? Orderinchaos 10:22, 20 April 2007 (UTC)

I referred to your "There should also be an option to convert"; there was no such option, on or before 18 April. Andy Mabbett 10:27, 20 April 2007 (UTC)

Hopefully this thread will be put to rest by the speedy work of the nice folks at wikimedia. I finally got around to submitting Andy Mabbett's excellent suggestion to have coordinate display user-configurable as bug 9685. Comments there might grease the skids? Saintrain 00:09, 25 April 2007 (UTC)

This template already displays DMS or degrees or both based on your preferences. Please see Template:Coord for how to set your preferences. There is the issue of whether the default should display DMS or what the template specified. Some people objected to always DMS, so we have to choose one. —Quarl ^(talk) 2007-04-26 01:37Z

I added an optional parameter "format" so the text can specify the default format (dms/dec) instead of having it detected based on input. The user preference still overrides.

{{coord|55.752222|37.615556}}	55.752222°N 37.615556°E / 55.752222; 37.615556
{{coord|55.752222|37.615556|format=dms}}	55°45′08″N 37°36′56″E
{{coord|55.752222|37.615556|format=dec}}	55.752222°N 37.615556°E / 55.752222; 37.615556
{{coord|55|45|08|N|37|36|56|E}}	55°45′08″N 37°36′56″E
{{coord|55|45|08|N|37|36|56|E|format=dms}}	55°45′08″N 37°36′56″E
{{coord|55|45|08|N|37|36|56|E|format=dec}}	55.75222°N 37.61556°E / 55.75222; 37.61556

—Quarl ^(talk) 2007-04-26 01:52Z

Thank you. --Burntnickel 01:38, 11 May 2007 (UTC)

Coordinate Conversion

I feel pretty igonorant about this, but is there a tool builtin to the wiki to convert dms to decimal degrees and back so as to avoid the by hand conversion? It seems like it would be to the most benefit to leave the coordiantes in the manner found in the source and have them translated on the fly. If I am going to convert all of the coordinates to one form or another is there a prefered format (dms vs. decimal degrees)? --Burntnickel 19:37, 19 April 2007 (UTC)

This template already does the conversion. It displays it as DMS or degrees based on your preferences. —Quarl ^(talk) 2007-04-26 01:35Z

Or the new "format" parameter, see above. —Quarl ^(talk) 2007-04-26 01:55Z

If you would like to maintain the format found in the source, you'd need to use one of the other coordinate templates (e.g. Template:Coor dm, Template:Coor dms). The output format with Template:GeoTemplate then displays the converted format. No need there for the additional computation done by Template:Coord or the inaccuracy this may add. -- User:Docu

You think it's OK to deny users their choice of preferred format? Why? Your latter comment appears both speculative and unfounded. Andy Mabbett 19:05, 28 April 2007 (UTC)

GeoTemplate offers full choice.

Apparently it's not this template as such that adds inaccuracy, but it depends on the way conversions from other templates to this one are done. -- User:Docu

altitude

could we add an additional optional parameter specifying altitude? do we have any "4d" geo-template where you could also encode speed, heading and datestamps, and possibly define "polygons", e.g. to trace roads, rivers or historical voyages? dab (𒁳) 13:16, 20 April 2007 (UTC)

Space bug

There's a nasty spacing *before* all coor d/m/s templates and an equally nasty space *after* coord templates. Can anyone fix both? Thanks! —☆ CieloEstrellado 03:09, 25 April 2007 (UTC)

Thanks, I fixed a bug where a space appears at the end of {coord} (it's actually a MediaWiki bug but I know the workaround, insert a "&#xfeff;"). Not sure which space before you're talking about. —Quarl ^(talk) 2007-04-26 01:34Z

Bug: display N/W/E/S

In the help:

{{Coord|43.651234|N|79.383333|W}}

it would be: " Toronto - decimal with Northing & Westing"

but the output is:

43.651234, -79.383333

without N W --WISo 12:18, 26 April 2007 (UTC).

Ops, there is an analogous discussion, but please fix the help! --WISo 12:21, 26 April 2007 (UTC)

The "help" is correct - it describes the input, and demonstrates the output. Andy Mabbett 13:21, 26 April 2007 (UTC)

The help page says: "parameters, which are optional, can be any type:, region:, or scale: setting which is recognised by the map server, such as the popular type:city and type:landmark options..." but doesn't say nothing about the format parameters, there are only two example. --WISo 14:44, 26 April 2007 (UTC)

Changed location of Barents Sea from (71°55′49″N, 41°20′49″E) to (71°56′N, 41°21′E)

The logic is that: ±½' of latitude (±½ Nautical Miles exactly) is approx ±1013 yards (exactly ±926m ≈ ±1km)

Traditionally Ship/Aircraft navigators used their divider's distance between the latitude lines as their unit of measure, i.e. 1 Nautical Mile.

Given the size of Barents Sea, ±1km seems reasonable. :-)

Could we also have a note somewhere extolling the virtues of using the Degree/Minute format (d°m′N d°m′W) for anything bigger then a ship? (This - as a consequence - becomes a great aid in mentally estimating distances between two objects.)

Is there a best location for such a note?

(OT: another useful conversion is: 2 knots ≈ 1.03m/s, esp for estimating wind speed)

NevilleDNZ 01:12, 29 April 2007 (UTC)

Precision is discussed at WP:GEO. Andy Mabbett 05:09, 29 April 2007 (UTC)

ThanX NevilleDNZ 06:06, 29 April 2007 (UTC)

New category

{{editprotected}}

Please add Category:Templates generating Geo. Thank you. Andy Mabbett 22:30, 10 May 2007 (UTC)

You can put that in the doc page inside <includeonly>. CMummert · talk 01:06, 11 May 2007 (UTC)

I already tried to edit the doc, but it says "This page is currently protected from editing because it is transcluded in the following pages, which are protected with the "cascading" option enabled: Template:Coord". I'm not sure why the cascading option needs to be enabled here . . . --Seattle Skier (talk) 01:25, 11 May 2007 (UTC)

You should have let me know. I went through and protected all the subpages individually as appropriate, so now the docs should be unprotected. CMummert · talk 02:09, 11 May 2007 (UTC)

OK. I just saw this page on my watchlist and tried to help out, but couldn't. I've added Category:Templates generating Geo to /doc now. --Seattle Skier (talk) 02:18, 11 May 2007 (UTC)

Thanks. I thought you were Andy Mabbett when I said you should have let me know about the protection. Sorry about the confusion. CMummert · talk 02:59, 11 May 2007 (UTC)

Thanks, both. Andy Mabbett 13:59, 11 May 2007 (UTC)