Template talk:Coord/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

→

Archive 10

New Geohack

I don't think the icon is a good idea and unlike others I object to it in Infoboxes/Geoboxes (e.g. Mendip Hills where it just takes up too much space). I've just discovered the Geohack, to which the coordinates always link, has a new, proposed, redesign which contains the Wiki Miniatlas at the top of the page (see here). I guess this the most elegant solution, while retaining the nice (indeed) functionality of the Wiki Miniatlas you also get the functionality of the old Geohack in one place and what's best, after a single click, without the need for two clickable objects on a single coordinates entry. – Caroig (talk) 04:16, 24 August 2007 (UTC)

I agree with the above statements. As an example, Template:Infobox Airport (see LAX Airport or most any other airport article) was previously able to display the coordinates on a single line but now wraps to two lines. Changing the infobox width is a possibility, but that would cause the infobox images to appear undersized (and using a larger default image size would cause problems since some of these images have been uploaded at a width of 200px). Also, the infobox uses small text which causes the globe icon to appear oversized (i.e. 33°56′33″N 118°24′29″W). Coordinates should display with a single link that takes the user to a page where they can choose from using the WikiMiniAtlas or visiting external sites for other maps and satellite/aerial photos. -- Zyxw 22:03, 1 September 2007 (UTC)

Globe icon causes unfortunate line breaks in {{Infobox Mountain}}

I appreciate the effort that went into the globe icon: in general, it is a nice feature.

WikiProject Mountain is having problems, because the extra space used by the globe icon causes odd line breaks in many mountains' infoboxes. For example, see Mount Whitney, Humphreys Peak, Mount Edgecumbe (Alaska) (under IE7 on Windows)/

Is there some way to fix this? Is there some option to off the feature? (Mountain articles often use Geobox templates in their external link section, that would be a good place for the icon, or in the title bar (as RedWolf suggests above))

I'm really open to different alternatives: what can we do? (I don't think that hacking on monobook.js is a general solution, because we want the readers to have a good infobox experience.)

Thanks! hike395 04:22, 24 August 2007 (UTC)

Discuss at m:Talk:WikiMiniAtlas. (SEWilco 19:21, 26 August 2007 (UTC))

How to show the globe icon ?

Where does the icon come from ? I tried to translate the template to Esperanto eo:Ŝablono:Koord, but I don't how to do to show the icon. Thanks to reply on my Esperanto talk page. Arno Lagrange ✉ 10:47, 21 September 2007 (UTC)

Display in title bar

Hi, I'm a wikipedian from ang:, and I'm wondering how you get the coord template to always show in the title bar. I'm not a wizard at wiki-syntax, unfortunately. I've put in a similar template up at the ang: version of Roanoke, Virginia. Any help would be appreciated. --JamesR1701E 12:42, 22 August 2007 (UTC)

It's a CSS hack: title coordinates are put inside an element with a 'coordinates' id, and then in MediaWiki:Monobook.css and other skin stylesheets there is a corresponding '#coordinates' rule that places the element near the title. --Para 15:56, 13 September 2007 (UTC)

hiding the coordinate link in the print stylesheet?

Not the whole thing (for example the 1* 2' 3" N 4* 5' 6" E would stay) - the whole thing looks ugly in print mode (e.g. M62 motorway (an extreme case), or Amazon River (less extreme). Will ^(talk) 17:54, 22 August 2007 (UTC)

Can you be more specific about the problem? In what way is the M62 article extreme? (SEWilco 16:35, 23 August 2007 (UTC))

Eh, never mind. It's fine in print preview. Which is odd, as it wasn't a few days ago... Will ^(talk) 17:09, 23 August 2007 (UTC)

Terrible API!

Can someone explain why the API was designed to use : in some cases, = in others, | separating some paramters, and _ others? How are we supposed to remember this? Maury 19:14, 24 August 2007 (UTC)

Gah. Even after reading the docs I can't get it to work. Can someone fix Algonquin Radio Observatory for me? Maury 19:17, 24 August 2007 (UTC)

It's a result from a MediaWiki limitation, though the documentation could explain it more clearly. That will never solve the problem entirely though, as editors will still have to pay attention to which template they're using: you were trying to use {{coor dms}} with this template's documentation. Fixed. --Para 20:12, 24 August 2007 (UTC)

What limitation? Couldn't type= and region= be used, and trigger the appropriate URL incantation? But let's not propose that change yet, the name= is more direct and needed sooner. (SEWilco 01:39, 25 August 2007 (UTC))

They could, but Wikipedia:Template limits set a limit for the number and size of template transclusions, which is important on pages with lists of coordinates. The more parameters supported, the sooner it gets to the limit. Since coord uses about 30 subtemplates, it would hit the limit quickly. Support for each parameter would need to be added to at least 6 templates (like with the name addition). The abundance of parameters used probably isn't all documented either.

Coordinate parameters could be given as a single free form template parameter and still use '=' with them, by assigning it to a single template parameter like "n=parameter1=value1_parameter2=value2", but since the number of template parameters with this template is variable, the position of coordinate parameters in the template (the n) wouldn't be predictable or logical for editors to use.

Time to move all parsing and processing to software and use <geo>? --Para 09:41, 25 August 2007 (UTC)

I hope so. I've been treating coord as a prototype for defining what <geo> needs to do. It's fine if geo does more. (SEWilco 02:46, 26 August 2007 (UTC))

Interwiki

Please add interwiki ca:Plantilla:Coord.--Pere prlpz 19:14, 26 August 2007 (UTC)

Interwikis are in the user editable Template:Coord/doc page. Anyway,  Done. --Para 20:41, 26 August 2007 (UTC)

Moon

m:WikiMiniAtlas refers to "the experimental Moon layer". Can template coord be used to show a location in the Moon in WikiMiniAtlas? How?--Pere prlpz 11:48, 27 August 2007 (UTC)

At the german Geocoding project we are currently brainstorming on how to handle extraterrestrial coordinates. There already is the globe parameter, which you should set to moon (ie type:landmark_globe:moon). Some think it might be usefull to create separate templates for each e.t. body. To link to custom GeoHack pages, although the GeoHack maintainer has agreed to add globe sensitive mapping choices. I'd say use coord with globe, then we can always migrate using a bot if necessary. --Dschwen 16:39, 27 August 2007 (UTC)

'Frozen' co-ordinates

I don't know if this has been asked before, but I'm trying to figure out why on Template:Infobox UK station and Template:Infobox UK disused station the co-ordinates in the title bar are stuck in place when the page is loaded, and don't move with the page if, say, the window is resized. Compare this with any page using Template:Infobox UK place, where the co-ordinates DO move when the window is resized. The co-ordinates on the station templates seem to be slightly reduced in font size too for some reason.

Is there any way to fix this? I'm not sure if its an issue with the Template or coord, probably the former. I tried a few things but got no where! Can anyone help? --Dreamer84 22:12, 31 August 2007 (UTC)

It's been set to an absolute position. I see absolute positioning in the javascript which adds the globe. Discuss at m:Talk:WikiMiniAtlas. (SEWilco 03:57, 1 September 2007 (UTC))

Thing is though when the globe also appears in Template:Infobox UK place and there is no problem with the co-ordinates moving with the page. Besides, the problem has been present long before the globe was added. --Dreamer84 14:11, 1 September 2007 (UTC)

I picked a couple of articles using Template:Infobox UK station and Template:Infobox UK disused station (eg Bristol Temple Meads railway station, Chelfham railway station) and found that the globe + coords in the title bar did move with the page (monobook skin). Could you give specific articles which exhibit this fixed property? (The font size is reduced if the coords are placed in an infobox which has a reduced font size. There have been ongoing complaints about this, eg this request.) Carminis 14:54, 1 September 2007 (UTC)

The two articles you linked to work fine because they don't use the Infobox's template to get the co-ordinates: Bristol Temple Meads uses Template:Geolinks-buildingscale and Chelfham uses Template:coor title d. See Fairlie railway station and Fairlie Pier railway station for two articles that use the Infobox template to gather the code and become 'stuck'. See also West Kilbride, which gets its co-ordinates from the Infobox UK place code but with no problems. Basically I'm wanting the two infoboxes used on the Fairlie pages to produce co-ordinates exactly like the West Kilbride infobox. Apologies should have given examples in the first place. --Dreamer84 17:48, 1 September 2007 (UTC)

I still can't replicate this effect - what browser and skin are you using? (I agree that the font size is too small in the title bar, in all 3 pages.) Carminis 19:40, 1 September 2007 (UTC)

Monobook, using IE7. Just tried Firefox and it actually works fine. So I guess the question now is, why does IE7 move the co-ords in Infobox UK place fine, but not in Infobox UK station? --Dreamer84 19:58, 1 September 2007 (UTC)

I've tried all skins with Firefox and Opera, but not with IE. How odd. Carminis 20:19, 1 September 2007 (UTC)

Using display=inline

I just discoved that Google Earth will not parse display=inline and over 1,000 articles no longer show up. I would think that the default should be display=title. I added a sentence to the documentation so editors know that. CambridgeBayWeather (Talk) 17:03, 2 September 2007 (UTC)

Do we know why Google Earth can't parse it? Obviously this is something we need to fix ASAP. What's odd is that neither Coord nor Coord/display/inline has been edited in months... so was Google Earth ever able to include these inline coordinates? --CBD 23:31, 2 September 2007 (UTC)

It's by design; inline coordinates aren't important and each article is entitled to a single location. Google Earth was updated just recently with coord coordinates for the first time, during the last month or so. Prior to that, no coord data was visible at all. --Para 23:41, 2 September 2007 (UTC)

Which articles have disappeared? To my knowledge no external project has ever used any other coordinates from Wikipedia than the ones that apply to the entire article (ie. coordinates next to the title or within an infobox). --Para 23:41, 2 September 2007 (UTC)

So far I can't find a single Canadian airport (tried about 20-25) and some of the British and US ones that were changed from Coor dms to Coord have vanished from Google Earth. Here's 7 examples of airports that no longer appear in Google Earth and 2 that do.

• Toronto Pearson International Airport 43 40 38N 79 37 50W changed
• Montréal-Pierre Elliott Trudeau International Airport 45 28 14N 73 44 27W changed
• Bournemouth Airport 50 46 48N 1 50 33W changed
• Blackpool International Airport 50 46 17N 3 01 42W changed
• London Heathrow Airport 51 28 39N 0 27 41W changed
• London Gatwick Airport 51 8 53N 0 11 25W changed
• John F. Kennedy International Airport 40 38 23N 73 46 44W changed
• Barrow/Walney Island Airfield 54 07 44N 3 16 03W changed - Still in Google Earth
• Chichester/Goodwood Airport 50 51 34N 0 45 33W changed and not in Google Earth but changed earlier and appears here at 50 51 37N 0 45 29W because it was using coor title dms

Notice that the London and JFK airports are not using "display=inline" but still don't appear in Google Earth. I used these particular examples because I had them saved in Google Earth's "My Places" so I knew they were there before. CambridgeBayWeather (Talk) 09:04, 3 September 2007 (UTC)

Sorry should have thought to check ones like Rio de Janeiro-Galeão International Airport which is still using "coor dms" (22 48 32S 43 14 37W) and still appears in Google Earth. CambridgeBayWeather (Talk) 09:14, 3 September 2007 (UTC)

My understanding of this is that Google Earth has been picking up the coor family for some time, but didn't start doing anything with coord until around July 2007 (I looked unsuccessfuly in May/June for examples of coord being parsed). Accordingly if pages were switched to coord there did seem to be a risk that they would 'disappear' from Google earth and I suppose we now need to wait for them to reappear. (Coord seems to be superior but was rushed out prematurely.) I'm not sure whether the choice of 'display=' is a factor. -- roundhouse0 09:23, 3 September 2007 (UTC)

Well if Google Earth FAQ is correct then articles with infoboxes should use coor unless they also use "display=title". CambridgeBayWeather (Talk) 09:34, 3 September 2007 (UTC)

The google earth FAQ changed (to mention coord) around 25 June 2007. Wikipedia:Wikipedia Signpost/2007-06-25/Technology report mentions it and links to a google person whose email is given so perhaps someone could take up the matter of coord in infoboxes (some of which use latitude=, longitude= and call coord rather than using coord explicitly). -- roundhouse0 09:57, 3 September 2007 (UTC)

Ah, inline coordinates within infoboxes were indeed mentioned as a special case in the old Google Earth Wikipedia FAQ, with something like "if an infobox contains coordinates={{inline coordinate template}}, the data will be visible on Google Earth". I remember someone noting right after the FAQ was changed that the infobox case wasn't mentioned anymore, but I can't find that from the jungle of all discussions now, so I don't know if anything came out of it. Anyhow, it may well be that this special case got lost in the change, in which case we should probably contact the Wikimedia Chief Research Coordinator to get things back on track and to arrange things with Google, instead of any single Wikipedian starting to act as an intermediary. But first we should write some documentation ourselves on what coordinates we consider important enough for reuse, and how or where they can be found in articles, and actually put it up somewhere, instead of forgetting it on some talk page.

I also remember noting before Google announced their coord support, that some articles that had been prematurely converted from coor templates to coord were still visible, likely as a result of them only updating database rows but not deleting any. But again, I can't find where or with which articles I would have noticed it.

To be at least of some help, I checked on 8th August that no coordinates entered with the coord template were visible on Google Earth. They did write months ago on wikitech-l that support was added, but their data updates don't happen too often so we didn't know if it was working properly or not. Looking through User:The Anomebot2's contribs for a good timeline with newly added data, and comparing those to the database dump dates, Google seems to be using the latest 20070802 dump, since Bathorë for example is visible on Google Earth. --Para 13:35, 3 September 2007 (UTC)

Space character at end?

Take for example, this - there's automatically a space inserted after the coordinates link. Is this intentional? When putting the coordinates in brackets, it doesn't look nice at all. Will ^(talk) 18:43, 3 September 2007 (UTC)

This is a low level problem: HTML Tidy which all MediaWiki generated HTML on Wikipedia runs through, moves leading and trailing spaces from inside HTML elements outside the element. When one such space character is in a 'display:none', the move makes it visible. Depending on the coordinate entry format, the 'format' parameter, and the user's coordinate display preferences, this issue may or may not be visible for others. To demonstrate: (A<span> B</span>) renders as (A B), where the location of the space doesn't matter. (A<span style="display:none"> B</span>) however renders as (A B), which is what you're seeing with 'coord' now. This can be fixed by inserting some other character before the normal space, such as the zero width no-break space. (A<span style="display:none">&#xfeff; B</span>) will then render as (A B). With this template the character needs to be put before the last space in Template:Coord/link. --Para 21:50, 3 September 2007 (UTC)

(editprotected:) Near the end of Template:Coord/link, change

<span style="display:none"> (<span

to

<span style="display:none">&#xfeff; (<span

--Para 16:38, 23 September 2007 (UTC)

Y Done Orderinchaos 16:47, 23 September 2007 (UTC)

Coordinates display format

I suggest a format which would allow display in decimal but with labels N/S, E/W because most people expect those labels and using only positive/negative latitude and longitude (38.28443°N 3.58286°W / 38.28443; -3.58286) is, if not confusing, at least not as graphic. I do not quite like using the format 38°17′04″N 3°34′58″W either because the N or S is closer to the longitude which follows and many people are used to prefixing N/S/E/W to the number rather than placing it after. I would suggest the format N 38.28443, W 3.58286 and/or 38.28443 N, 3.58286 W be implemented GS3 22:10, 7 September 2007 (UTC)

overlinked

Don't you think that this template is overlinked? When I see "Coordinates: xy", I expect the whole string to link to tools.wikimedia.de instead of the first part linking to an explanatory article and the second to the proper page. Kids all over the world are taught in primary schools what coordinates are. The word "Coordinates" linking to its definition only tricks me into going to a wrong page sometimes. Please comment if you have similar feelings. 83.9.36.55 23:28, 11 September 2007 (UTC)

Documentation a mess

The current documentation is a mess which would easily tend to discourage the casual user. There should be an easy way of learning about the different parameters and their possible values. __meco 08:49, 18 September 2007 (UTC)

I agree. For the most part {{coord|lat|long|format=dms|display=title}} (the last two parameters optional) serves most purposes for decimal degrees, otherwise {{coord|deg|min|sec|N/S|deg|min|sec|W/E|display=title}} for normal degrees. That's about all the casual user actually needs to know most of the time. Orderinchaos 11:13, 21 September 2007 (UTC)

Google Earth not seeing Coord?

I was asked,

"Why are you going in and changing coor to coord? I've started a discussion on an issue related to this on Wikipedia talk:WikiProject London. Currently only Coor is being scraped by Google Earth."

hjuk 08:37, 28 September 2007 (UTC)

I don't know if this is a mistake, a temporary glitch, a Google database in need of its next update, or a problem with {{coord}}.
—wwoods 14:13, 1 October 2007 (UTC)

I pointed out in the London discussion that the only example given of a nonfunctional template has a call to coord which contains wikicode inside the template call, so Googlebot is probably not recognizing the template. I asked there for more examples. (SEWilco 19:32, 1 October 2007 (UTC))

Like other projects that use all coordinates from Wikipedia, they parse the wikitext without expanding the templates used. If the coordinates have been given in the format "{{Infobox UK place|latitude=x|longitude=y", they're not recognised as coordinates even though the template might later pass them to a coordinate template, so the coordinates aren't used and they won't be visible in external projects. If you see any exceptions to this with information that is visible though it according to this rule shouldn't be, it's because the external projects are trying to find workarounds for Wikipedia's tendency to constantly change data entry formats, such as using data from older database dumps where it wasn't hidden in an unknown format yet. There's two solutions: 1) start using coord directly or 2) convert all infoboxes and the like to use our preferred template parameter names for coordinate entry, inform parser maintainers of them, and tell them that anything that uses those parameters is an attempt at coordinate entry. --Para 19:34, 1 October 2007 (UTC)

You mean that the template should require coord as a parameter, such as " | coords={{coord|…}}" so robots can see the coord invocation in the page's wikicode? (SEWilco 20:30, 1 October 2007 (UTC))

Exactly. MurphiaMan 21:06, 1 October 2007 (UTC)

Thanks, I almost understand, but will

|coords = {{coord|{{{latitude}}}|{{longtitude}}}|display=title}}

as, for instance, {{Infobox UK place}} uses them in displaying the appropriate header map? - or are parameters only set on execution. Cheers Kbthompson 10:02, 2 October 2007 (UTC)

Protected template

{{editprotect}} Please add {{pp-template|small=yes}}. Thanks. Rocket000 21:28, 16 October 2007 (UTC)

 Done Orderinchaos 23:45, 16 October 2007 (UTC)

Geolinks-coord Issues

The Geolinks templates may be superseded by recent changes in the coord template which provide a list of mapping services when the geographical coordinate is clicked on. Please participate in the discussion at Wikipedia_talk:WikiProject_Geographical_coordinates#Geolinks-coord_Issues. (SEWilco 17:30, 17 October 2007 (UTC))

ja:Template:Coord/input/dec

Please adding ja:Template:Coord/input/dec--Kanesue 10:50, 7 November 2007 (UTC)

Request for small change

Could the automatic [[Goegraphical coordinate system|Coordinates]] link displayed in the title be replaced by a parameter defaulting to that value? (I thought that was what the name parameter did, but obviously not - Lower Silesian Voivodeship.) It would be nice to be able to display coordinates in the title and at the same time specify what exact place they are the coordinates of.--Kotniski 19:12, 9 November 2007 (UTC)

The documentation says "name can be used to annotate inline coordinates for display in map services…" which is a little ambigous, because the exact result depends upon an external map service. For example, at Minnesota state parks#External links is a link Map of all coordinates which shows all the coordinates in the article; in this case from the table, where name was used to label each individual park's coordinates. (SEWilco 22:27, 9 November 2007 (UTC))

I removed the editprotected request because more discussion is needed about the proposed change. (SEWilco 22:28, 9 November 2007 (UTC))

OK, in that case it seems name is being used for something else, so another parameter would need to be defined for the purposes of my proposal. What I'm suggesting shouldn't be controversial - it won't affect the display of existing template calls, it would just provide an extra option. Let me amend the proposal slightly - the template can take an extra parameter, say label, which when non-empty (let's say |label=Central Park) causes the display in the title to look like Coordinates (Central Park): etc. instead of just Coordinates: etc.. I think it would be valuable to be able to specify more exactly what the coordinates refer to, particularly in the case of larger cities and regions.

If there are no objections to this idea, I can easily post the precise modification to the template code which would need to be made (only a few extra bytes in the template page and two subpages I think).--Kotniski 10:07, 10 November 2007 (UTC)

Related proposals seem to have appeared at Wikipedia talk:WikiProject Geographical coordinates#Template lacks. (SEWilco 14:41, 10 November 2007 (UTC))

Wikipedia uses single point coordinates for practical reasons, as it's much easier to define one central point than the boundaries. This single point is chosen to represent the whole article, and works fine with small scale objects such as landmarks, but gets us into problems when the scale is larger. For that there's workarounds: we can give the type of the object the coordinates represent, implying its size, or additionally give a specific scale. But another problem arises if the point is not chosen geographically as something "in the middle", but instead on some other basis. In that case the point no longer represents the whole article geographically, but only on this other basis, which is often a politically chosen point that may not be in the centre of the area at all, and has a scale of a different order of magnitude altogether.

About changing the title display: Having coordinates at the top of articles was controversial when it was first introduced, as the space is mostly used for small icons. Because the accuracy of obtaining coordinates is limited, the length of the coordinates field can never be too long, which is not the case with arbitrary names or labels.

I think articles of large scale objects need to maintain the geographical centre point as the title coordinate, while notable points within the area can be as named inline coordinates or in sub-articles. --Para 16:15, 10 November 2007 (UTC)

Well yes, one would expect the point chosen to be somewhere in the centre, but the exact geographical centre? Is that normal practice? It must be quite hard to work out where that is, for a start. (And it might not even lie within the region.) I would expect that with most cities some recognised central landmark or street intersection would normally be chosen. And with larger regions, the administrative headquarters if that's fairly central, or some other specific central landmark. Correct me if you're all doing it some more mathematical way, but this seems to me the most practical approach for editors and natural for readers. And if that's the approach (or at least one permitted approach), then it makes sense to tell everyone what the point in question is. It needn't increase the size of the title display by much; the label could even replace the word Coordinate, and a limit on the length of the label could be imposed/recommended. --Kotniski 18:03, 10 November 2007 (UTC)

Taking the optimistic view that silence indicates grudging consent, let me put up the precise edits I'm proposing (which as I say shouldn't affect anything currently existing):

{{editprotected}}

• In the source for Template:Coord, before:

}}</includeonly

insert:

|2={{{label|}}}

• In both {{Coord/display/title}} and {{Coord/display/inline,title}}, replace:

[[Geographic coordinate system|Coordinates]]

by:

{{#if:{{{2|}}}|{{{2}}}|[[Geographic coordinate system|Coordinates]]}}

The effect would be to allow template calls to pass an additional parameter called label, which if non-empty would be displayed in the title in place of Coordinates.--Kotniski 18:30, 12 November 2007 (UTC)

Title coordinates on Wikipedia represent the whole article, as does everything else in the title section of articles. If the coordinates have not been well chosen and are misleading to readers, the solution is not to describe why they have been chosen badly, but by correcting the mistake and choosing better coordinates. If you would like to change how coordinates are used on Wikipedia, please discuss at Wikipedia talk:WikiProject Geographical coordinates and perhaps the Village Pump. --Para 19:20, 12 November 2007 (UTC)

I'm not trying to change how coordinates are used; I just want the display to be that little bit more informative (in cases where editors are able to make it so). I don't understand why you object to that - no-one would be forcing you to use this feature. It isn't about defending poor choices of coordinates; it's about giving information about the coordinates chosen (presumably in the editor's opinion they will be the best ones). Of course the coordinates should "represent" the whole article, but that doesn't mean they aren't (in many cases) actually the coordinates of something more specific, and there seems to be nothing to be gained by concealing from the user what that something is - indeed that something will have been chosen because it does represent the article subject, so it wouldn't be at all out of place in the title section.--Kotniski 21:21, 12 November 2007 (UTC)

Changing the nature of Wikipedia title coordinates may not be your intention, but adding a subtitle next to the coordinates would do just that. It would add a mostly irrelevant text to the title and mix up the scale of articles; a country scale object might for example then have a landmark scale instead, which would be largely incorrect. There are editors on Wikipedia with the opinion that coordinates do not belong in the title at all, and I believe you would find a substantially larger number of people who don't think a notable landmark and its coordinates should be mentioned before any other information in the article. If it's not obvious what the coordinates of an article are representing, those coordinates are then not the natural choice to represent the article, and should be changed or removed altogether. For your problem I think you should follow the example of the article of France: the coordinates of the most notable object in the article are mentioned in a predictable location in the infobox, while the coordinates for the whole article in the title area are less precise large scale coordinates from around the center of the area. --Para 16:29, 13 November 2007 (UTC)

All right, let it be that way. But I think it would be worth discussing and drawing up guidelines about how to choose points to use as representative coordinates (and how to document that choice). With a nice compact area like France, which happens to have whole-degree lines crossing right in the middle of it, your method clearly works well (though note that even here discretion has been applied, formally speaking, since the chosen coordinates actually represent only Metropolitan France). But I fear we may not always be so lucky - we might find that the point given by that method actually lies outside the area in question or close to the edge of it. And with cities I would think that readers expect coordinates to represent the established central point of the city (like Charing Cross in London), rather than the geographical center (which depends on where the authorities happen to have drawn the city border). Particularly with coastal towns, there might be a significant difference between the two.--Kotniski 09:12, 14 November 2007 (UTC)

General discussions about coordinates probably should be at Wikipedia talk:WikiProject Geographical coordinates rather than tucked away in a template page. Incidentally, many cities are identified at the coordinate of the city hall because that's the point used by the national mapping agency (the surveyed point is often outside the building, such as a marker embedded in a flagpole foundation). (SEWilco 15:56, 14 November 2007 (UTC))

Scale parameters

The documentation on this page has improved considerably from past iterations -- kudos! However, I would suggest it desperately needs a section on using the scale tags. I'm trying to figure out how to focus on a single set of buildings on the south end of the Southampton Airport, but there's simply nothing in the documentation about how to do this. Maury (talk) 17:07, 14 January 2008 (UTC)

Coordinate parameters are the same for all the coordinate templates on Wikipedia, so the documentation links to Wikipedia:WikiProject Geographical coordinates#Parameters. Should the information there be transcluded to the documentation of all the coordinate templates? Most buildings are fine using type:landmark and its default scale, but if your building is exceptionally small or big, you'll need to add the scale parameter with a rough value that's more appropriate. As far as I know the number is imaginary, so it's basically a trial and error process. Please write something about this in the documentation if it's not obvious enough yet. --Para (talk) 20:33, 14 January 2008 (UTC)

Hold on! I thought scale was depricated and never well defined (correct me if I'm wrong). At least on de.wikipedia.org it's use has been discontinued in favour of dim, the object diameter in Meters. --Dschwen 20:42, 14 January 2008 (UTC)

No, that's only on the German Wikipedia so far. I don't know what scale is based on either, but since it's been used in Wikipedia from early on, it's probably somewhat consistent in all Wikipedia articles and in the relation between object sizes and the scaling used by external services. Dim as the length of the longest dimension of an object would indeed be more meaninful, but it's currently not supported in GeoHack. I guess all that's needed to add the support is to find how it would correspond to all the scales used by various services. --Para (talk) 21:20, 14 January 2008 (UTC)

Infoboxes

I have noticed that a number of infoboxes have started to include coordinates in them. This is good. However, I notice that this also places the same coords in the title area. This is bad. There's really no need to have both, infoboxes are generally located at the top anyway. Maury (talk) 17:11, 14 January 2008 (UTC)

Case of people putting "inline,title" in the infobox template code, they need to just put "inline" (or nothing at all as that is the default). Orderinchaos 17:20, 14 January 2008 (UTC)

Or if the infobox places the co-ords in the title, then the other coord code can be deleted. Simple. - 52 Pickup ^(deal) 18:06, 14 January 2008 (UTC)

Blue Globe Icon

I find the blue globe icon absolutely unsuitable for inline purposes—the coordintes should suffice.TINYMARK 03:07, 15 February 2008 (UTC)

Then switch it off. For the german Wikipedia I replaced the icon inline with a unicode char.--Dschwen 03:27, 15 February 2008 (UTC)

Why don't use the geotag icon? http://www.geotagicons.com/index.html 09:11, 10 June 2008 (UTC)

Minus sign

{{editprotected}} This template should display a minus sign, not a hyphen, for negative co-ordinates. For example, Niagara Falls should display as 43.080, −79.071 instead of 43.080, -79.071. Correct typography is crucial for maintaining a professional appearance on this encyclopedia. —Werson (talk) 06:12, 9 March 2008 (UTC)

 Not done the display of hyphens as opposed to minus signs is entirely dependent on how the coordinates were entered into the template, and nothing to do with how the template itself. This is an issue which must be fixed on a per-article basis - there is no way that I am aware of to force the template to treat a hyphen as a minus sign. Happy‑melon 20:09, 10 March 2008 (UTC)

Actually, the hyphen being processed by the GeoHack tool and a hyphen is not recognized. So it can not be used on a per article basis, it must be a hyphen using the present technology. {{coord|43.080|−79.071}} The coordinates at the top of the GeoHack page are zero. -- SEWilco (talk) 23:32, 10 March 2008 (UTC)

I was thinking that the template could parse the data and just replace it with a minus sign in the page, while still keeping a hyphen in the links to other software that rely on it. —Werson (talk) 02:19, 11 March 2008 (UTC)

It would be technically possible to have parserfunctions replace the displayed sign of negative numbers with another character. But looks like Google doesn't support it either [1], so it would break compatibility for those copying and pasting coordinates, in a way most people wouldn't realize how to fix. --Para (talk) 00:13, 11 March 2008 (UTC)

That's a good point. It occurs to me, though, that Google would be quick to add support for it if we changed it. They've been frequently updating the Google Earth engine to keep up with us so far; this would be a simple search-and-replace on their part. —Werson (talk) 02:19, 11 March 2008 (UTC)

interwiki. how?

I would like to add Polish interwiki: pl:Szablon:Koordynaty. How can I do it? Kubek15 ^{(Sign!) (Contribs) (UBX)} 14:06, 10 March 2008 (UTC)

See the box at the top of this page and the #Interwiki section. --Para (talk) 16:37, 10 March 2008 (UTC)

Scale not working

Resolved

 – Dschwen fixed the scale, see below. 84user (talk) 02:06, 30 July 2008 (UTC)

Why does the scale parameter not work with this template? In fact, it's not even clear if it's supported (no examples) Socrates2008 (Talk) 22:34, 21 March 2008 (UTC)

Scale is not well-defined. At least on de.wikipedia it has been superseeded with dim (object diameter in meters). --Dschwen 22:35, 21 March 2008 (UTC)

I'm curious what you mean by "not well-defined". Scale should be the denominator of screen units to map units as per Scale (map). Heptazane (talk) 01:34, 22 March 2008 (UTC)

What screen units? Pixels? Inches (what DPI)? A reasonable definition would probably be assuming 72DPI, but I haven't seen this defined anywhere. --Dschwen 01:43, 22 March 2008 (UTC)

Would someone mind pointing me at a working example that uses scale please? Socrates2008 (Talk) 10:52, 15 April 2008 (UTC)

OK, I'm assuming this does not work. Can it please be fixed? Thanks Socrates2008 (Talk) 11:10, 22 May 2008 (UTC)

Big thank you for fixing this! Socrates2008 (Talk) 05:24, 30 July 2008 (UTC)

Display problem

In Szczecin I'm seeing the title coordinates displayed so that they're half off the screen. Just my browser, or a formatting problem?--Kotniski (talk) 17:49, 29 March 2008 (UTC)

Seems to have resolved itself.--Kotniski (talk) 08:46, 1 April 2008 (UTC)

There is a general problem that has reappeared in which the co-ordinates are cut by the horizontal rule at the top of the article. Keith D (talk) 18:09, 29 March 2008 (UTC)

Looking at random articles I'm seeing the horizontal rule running through the top of the globe, with the coordinates just below the line. Maybe a browser with a different font would have a problem with the coordinates. If I change the size of my browser's text then the globe is usually not skewered (I can't make Firefox clobber the coord text). Do you have any regional announcements appearing on your pages? I presently see no Wikipedia notices at the top. -- SEWilco (talk) 18:38, 1 April 2008 (UTC)

The problem appears to have disappeared today on articles I have accessed. Keith D (talk) 18:46, 1 April 2008 (UTC)

I'm still seeing the problem using Firefox, e.g. on Mount Pelion West --Ozhiker (talk) 20:49, 1 April 2008 (UTC)

Ditto, minus the Mount Pelion West bit. - Dudesleeper / Talk 21:32, 2 April 2008 (UTC)

At the moment with Firefox I'm seeing the coordinates-over-line on Bathhouse Row {{Infobox_nrhp}} and Spelle {{Infobox Ort in Deutschland}} but not Hot Springs, Arkansas {{Geolinks-US-cityscale}}. I note that the problem version seems to have a slightly smaller font being used for "Coordinates", which implies differences in templates or CSS. -- SEWilco (talk) 17:11, 3 April 2008 (UTC)

The two above with the problem are using infoboxes which call {{coord}} with Degrees-Minutes-Seconds format; Hot Springs uses decimal degrees. Testing further. -- SEWilco (talk) 17:27, 3 April 2008 (UTC)

The coord template keeps emitting the same text. But add the table wrapping used in the infobox and I think the class triggers CSS code which changes the formatting. Invite the CSS people to look at it. -- SEWilco (talk) 17:55, 3 April 2008 (UTC)

{| class="infobox geography vcard" || Testing in a table {{coord|1|30|00|N|93|30|00|W|type:landmark|display=inline,title}} |} {| class="infobox" style="width: {{{boxwidth|240px}}}; font-size: 90%;" || Testing in a table {{coord|1|30|00|N|93|30|00|W|type:landmark|display=inline,title}} |}

Looks like it to me, that it depends on what includes {{coord}}. The CSS that both use is equal, but the fontsize and lineheight that both use is different because of what they inherit from the table cell that includes the templates. Best suggestion here is to force a fontsize and lineheight in the CSS for the span with id "coordinates" (defined in Monobook.css). Be aware that changes to that file can take up to 30 days to propagate to all visitors, so make sure you get it good in the first go. (suggest setting it with style="" in that element before actually taking those CSS changes back to the main CSS file). I believe recently the lineheights for elements in the header were slightly tweaked, which may be the cause for these problems. --TheDJ (talk • contribs) 18:34, 3 April 2008 (UTC)

The problem is not only linked to infoboxes as it occurs on articles that do not use infoboxes. It occurs on articles just using {{coor title dm}} e.g. Gatenby. Keith D (talk) 23:13, 5 April 2008 (UTC)

Another template issue: {{coor at dms}} like Shaker Heights, Ohio ... is this now a problem with more templates? Perhaps it has something to do with the hidden Wikimania 2008 banner as User:Martha Forsyth suggested below. Spencer^T♦C 01:08, 8 April 2008 (UTC)

Just checked the template pages themselves, the title coordinates on each appear to run in the with title line. Note: I'm not showing the Wikimania 2008 banner. Spencer^T♦C 01:11, 8 April 2008 (UTC)

Observation/thought:

Just got a bit of possibly insight. Was looking at Paisley Caves and noticed the positioning was just fine....then decided to "hide" the notification about scholarships to Wikimania 2008 - BINGO! the correct positioning disappeared. I know nothing at all about how the position of the "coordinates" line is determined, but this suggests to me that the position is linked not to the Page Title, but to the (physical) top of the page. If the link could be fixed, perhaps these would "stay put"? What causes the "top of the page" to move up or down w respect to any announcements that might appear above it? Define the position of the coordinates the same way? —Martha (talk) 00:39, 6 April 2008 (UTC)

It's just wrong! Why not shove it a little down so that it doesn't happen? Even 5px would clear it and have it not interfere with other contents. How hard is that? Alternately, some parameter fields can be added to allow the editors to relocate it relative to its default position. I get shivers down my spine whenever I see that horizontal line cross the coordinates out. Yuck... ~RayLast ^«Talk!» 14:28, 9 April 2008 (UTC)

I just noticed that a little above this thread, at #Infoboxes, 52 Pickup suggests removing "the other" set of coordinates. But, e.g., at Shaker Heights, Ohio I can only FIND one place in which they're listed, and that's in Infobox Settlement. The ones that show up in the title line mysteriously appear, but I don't know why (have always assumed they're picking up on the coordinates given in the infobox). —Martha (talk) 19:06, 9 April 2008 (UTC)

Confirmed, caused by the sitenotice. Under investigation. --TheDJ (talk • contribs) 19:27, 9 April 2008 (UTC)

The sitenotice was disabled by User:MZMcBride, but this doesn't seem to help much. It's a strange case for sure... --TheDJ (talk • contribs) 19:45, 9 April 2008 (UTC)

In response to the question about the Shaker Heights, Ohio article, "the other" set of coordinates is generated by: "Shaker Heights is located at {{coor at dms|41|28|35|N|81|33|6|W|city}}". The {{coor at dms}} template is equivalent to using {{coord}} with display=inline,title. If you change that to use {{coor dms}} it will only display the coordinates inline. -- Zyxw (talk) 00:39, 10 April 2008 (UTC)

Things seem to be displaying better today, for me at least (was something changed?) - the coordinates at the top of the page are not cut through by the line. But they are below the line, in what looks like an indeterminate position, not visually related either to the page title, or "From Wikipedia, the free encyclopedia". From a design point of view, I personally would be MUCH happier if the coordinates that appear at the top of a page (no matter what template puts them there) could be baseline-aligned with the page's title, in exactly the same way that [edit] appears, right-aligned, with section titles. Can that not be arranged, by some clever programmer? —Martha (talk) 17:03, 10 April 2008 (UTC)

It seems a little better to me too but it still is not completely satisfactory. The coords are not crossed by the middle now but the little globe still intersects with the line. Has anyone found the cause? ~RayLast ^«Talk!» 21:10, 10 April 2008 (UTC)

I think that's how it usually is. Spencer^T♦C 11:16, 11 April 2008 (UTC)

Further note

Please look at Paisley Caves - the only place I can find coordinates on that page is in {{Infobox Cave}}. Apparently putting coordinates in that infobox puts them on the page in TWO places. Maybe this is true elsewhere?? —Martha (talk) 17:12, 10 April 2008 (UTC)

It is often true that coords in an infobox appear necessarily both in the title bar and the infobox. I have argued previously that an editor deserves the choice of either, neither or both, but met with opposition (from Andy Mabbett, now blocked). A skilled infoboxer ought to be able to offer a choice. -- roundhouse0 (talk) 17:33, 10 April 2008 (UTC)

If using {{coor d}}, {{coor dm}}, or {{coor dms}} in the infobox, adding "at" in the middle will also give you title coordinates from the following templates: {{coor at d}}, {{coor at dm}}, or {{coor at dms}}, which are in essence, are combinations of two templates. So: {{coor d}} + {{coor title d}} = {{coor at d}}. I think that coordinates should be displayed both in the title bar and the article, to give us some standards, instead of having it not appear, or appear once. Spencer^T♦C 01:21, 13 April 2008 (UTC)

Fixing the position

Ok, I think everyone knows that the coord element is breaking just too fast. The primary reason is that it fixes its offset to the "top" as 3.5em. That makes it at least "scale" when people have a larger default fontsize than normal, but it is still problematic whenever {{coord}} is included from a table that has "font-size: 90%" or something, or when additional elements are added above the line (such as sitenotice). There is really only one way to fix this, and that is by making sure that the the coordinates element is simply properly positioned within the flow of the DOM. It needs to BE in that corner instead being positioned towards that corner.

As such I think we should propose to add the following to MediaWiki:monobook.js:

addOnloadHook( function moveCoord() {
  var coord_elem = document.getElementById( 'coordinates' );
  if( coord_elem ) {
    var ourcontent = document.getElementById( "bodyContent" );
    if( ourcontent ) {
      var tempelem = coord_elem.parentNode.removeChild( coord_elem );
      tempelem.style.position = "relative";
      tempelem.style.top = 0;
      ourcontent.insertBefore( tempelem, ourcontent.firstChild );
    }
  }
});

This makes sure that the position is always just below the H1 header line. It makes sure that the fontsize of the elements is not dependent on the fontsize of the element that includes the coordinates, and it scales perfectly in all cases. If people do not have JS enabled, then the current behaviour will still be "good enough". --TheDJ (talk • contribs) 22:36, 12 April 2008 (UTC)

For people who would like to test: add importScript('User:TheDJ/movecoord.js'); to your monobook.js. --TheDJ (talk • contribs) 22:55, 12 April 2008 (UTC)

What about the other coordinates templates, like {{coor d}}, {{coor dm}}, {{coor dms}}, {{coor title d}}, {{coor title dm}}, {{coor title dms}}, {{coor at d}}, {{coor at dm}}, and {{coor at dms}}. These were also having issues. Spencer^T♦C 01:24, 13 April 2008 (UTC)

These all use the same HTML. It doesn't matter what template you use, as long as it produces an HTML element with CSS id. "coordinates". --TheDJ (talk • contribs) 19:03, 13 April 2008 (UTC)

I think I did the right thing: added <code>importScript('User:TheDJ/movecoord.js');</code> to my otherwise-empty monobook.js - but I'm not sure it made any difference. What am I looking for, in "testing" this? —Martha (talk) 23:45, 15 April 2008 (UTC)

Check out Shaker Heights, Ohio for instance. Here the coordinates used to be "cut" by the header line. This was caused by it being included from a table cell with "font-size:90%". With this in your monobook, the coordinates should no longer be cut by the header, and should have the font-size that it is supposed to. --TheDJ (talk • contribs) 01:01, 16 April 2008 (UTC)

It seems to be OK - the top of the little "show location on an interactive map" graphic very slightly intersects the line but the text is all below the line, and it's a smaller point size. I guess my "testing" should consist of letting you know if I do find a page that still looks wrong — right? —Martha (talk) 05:10, 16 April 2008 (UTC)

I think so. I imported the script are looking for pages. Spencer^T♦C 22:59, 16 April 2008 (UTC)

Here: Found a page: Poljane Grammar School. It still cuts is a bit close. Same with Gihtsejiegŋa. Spencer^T♦C 23:01, 16 April 2008 (UTC)

Comment: Even with the script imported, Template:Infobox Glacier still cuts the coordinates closely. Same with Template:Infobox High School (ignore redirect), only if the title coordinates are based in the box. Spencer^T♦C 23:08, 16 April 2008 (UTC)

What browser are you using? Because I'm not seeing it on Safari 3 or Firefox 2.0 --TheDJ (talk • contribs) 01:34, 17 April 2008 (UTC)

You didn't include it in your monobook properly. You added the <code> markup, which is just decorative styling and not intended to be included in your monobook.js --TheDJ (talk • contribs) 01:40, 17 April 2008 (UTC)

Now none of this is working. Spencer^T♦C 01:25, 28 April 2008 (UTC)

Bug with some value and dms output

1. {{coord|2.4333|-73.9667|format=dms}} actually display « 2° 25′ 60″ N 73° 58′ 00″ W » 60 seconds ? expected 2° 26' 00″ (2°26′00″N 73°58′00″W)
2. more boring {{coord|2.433333333333|-73.9667|format=dms}} « 2° 25′ 00″ N 73° 58′ 00″ W » expected 2° 26' 00 (2°26′00″N 73°58′00″W)

- phe 12:01, 11 April 2008 (UTC)

Hm, that's funny. Spencer^T♦C 01:16, 13 April 2008 (UTC)

Hmm, clearly a rounding error. --TheDJ (talk • contribs) 19:25, 16 May 2008 (UTC)

OK, these are errors in the dec2dms scripts. Basically, there is no "carry" in the calculation like there should be. I don't really know how to do this in parserfunction code. I'm not sure if it is even possible. --TheDJ (talk • contribs) 20:59, 16 May 2008 (UTC)

Line wrapping

Using {{coor dms}}
Coordinates	58°40′36″N 156°38′57″W

Using {{coord}}
Coordinates	58°40′36″N 156°38′57″W

Note: The following details a bug that occurs in Internet Explorer 6, therefore users of other browsers may not see anything wrong in the following examples.

The infoboxes to the right show how {{Coor dms}} and {{Coord}} wrap coordinates when they cannot fit on a single line. Template:Coor dms wraps at the space between the latitude and longitude. This was done back in 2006 (see Template talk:Coor dms/archive001#Line wrapping) with the addition of the following:

<span style="white-space:nowrap">{{{1}}}°{{{2}}}′{{{3}}}″{{{4}}},</span> <span style="white-space:nowrap">{{{5}}}°{{{6}}}′{{{7}}}″{{{8}}}</span>

Template:Coord/link (the output sub-template of Template:Coord) replaces that with:

<span class="latitude">{{{dms-lat}}}</span> <span class="longitude">{{{dms-long}}}</span>

Since .latitude and .longitude are defined in MediaWiki:Common.css as white-space:nowrap; one might expect both templates to wrap at the space. That is the case in Windows XP with the Firefox, Opera, and Safari browsers. However, when using Internet Explorer 6 the coordinates in the second infobox appear as:

58°40′36″N 156°38′

57″W

To ensure that the infobox or template CSS is not causing this problem, the following example uses the classes directly:

Code:	<span class="latitude">58°40′36″N</span> <span class="longitude">156°38′57″W</span>
Output:	58°40′36″N 156°38′57″W

So, while it may seem redundant, the fix for IE6 is to add style="white-space:nowrap" after class="latitude" and class="longitude":

Code:	<span class="latitude" style="white-space:nowrap">58°40′36″N</span> <span class="longitude" style="white-space:nowrap">156°38′57″W</span>
Output:	58°40′36″N 156°38′57″W

Note that class="latitude" and class="longitude" cannot be removed because they are needed for the Geo microformat (as explained in MediaWiki:Common.css and Template:Coord/link/doc). -- Zyxw (talk) 05:13, 22 May 2008 (UTC)

{{editprotected}}

To fix the bug described above, edit Template:Coord/link and make the following changes:

Replace <span class="latitude">

With <span class="latitude" style="white-space:nowrap">

and

Replace <span class="longitude">

With <span class="longitude" style="white-space:nowrap">

-- Zyxw (talk) 05:22, 22 May 2008 (UTC)

I think there's a better fix for this - looking into it now... --- RockMFR 05:38, 22 May 2008 (UTC)

This should do it. --- RockMFR 05:53, 22 May 2008 (UTC)

That works. Thanks. -- Zyxw (talk) 06:31, 22 May 2008 (UTC)

Category

{{editprotected}} Dear administrator, please add the category to this template:

<noinclude>[[Category:Coord template]]</noinclude>

Thank you in advance, --Julian (talk) 23:08, 10 June 2008 (UTC)

 Done but categories aren't often added to the templates themselves, but to the documentation, which is unprotected. Thanks, PeterSymonds (talk) 23:12, 10 June 2008 (UTC)

Category 2

{{editprotected}}

Dear administrator, I apologize since I had not noticed that the discussion page was a redirect. I wanted to add a category to {{Coord/dec2dms/d}} by adding

<noinclude>[[Category:Coord template]]</noinclude>

I also suggest to make a change in the pages {{Coord/input/dm}} and {{Coord/input/dms}}. It is the replacement of

{{coor dms2dec| 

by

{{coord/dms2dec|

There are 2 occurrences on each template. The templates {{coor dms2dec}} and {{coord/dms2dec}} are equivalent, since the former is a redirection to the latter. However, the main one is {{coord/dms2dec}}. A similar renaming was already done in {{Coord/input/d}}.

Thank you very much in advance. Regards, --Julian (talk) 00:30, 11 June 2008 (UTC)

Done Happy‑melon 14:57, 11 June 2008 (UTC)

Please clarify syntax

I think it would be useful to clarify some aspects of the syntax.

The Template:Coord page lists

{{coord|latitude|longitude|coordinate parameters|template parameters}}

{{coord|dd|N/S|dd|E/W|coordinate parameters|template parameters}}

{{coord|dd|mm|N/S|dd|mm|E/W|coordinate parameters|template parameters}}

{{coord|dd|mm|ss|N/S|dd|mm|ss|E/W|coordinate parameters|template parameters}}

As valid formats, but about 370 pages use

{{coord|template parameters|dd|mm|ss|N/S|dd|mm|ss|E/W|coordinate parameters}}

And it seems to work. For example Saint-Jean-de-Matha, Quebec

Could someone in the know either clarify that this is legal or not legal? And perhaps include the clarificaion in the usage and/or examples section?

Also, should unused parameters be indicated by an empty field (||), or just left out completely.

There are about 45 articles with something like {{coord|32|01|S|117|24|E|type:town}} Note the missing seconds. It sort of works (displays '" with no number between see Quairading, Western Australia

Is this considered valid syntax? Either way, a clarification in the usage section might be useful.

Also, is it legal to have no geographic coordinates, just a type?

—Preceding unsigned comment added by 24.5.188.87 (talk • contribs)

A more general question: how easy do users of this template find it to fix incorrect syntax of others?

For the other coordinates templates, it's easily fixed, as the template defines the input format and errors are easy to find with, e.g. template-tiger. -- User:Docu

Yes, better template documentation is needed.

{{coord|latitude|longitude|coordinate parameters|template parameters}}

• This refers to supplying latitude and longitude as signed decimals, '-' = South latitudes, '-' = West longitudes

{{coord|dd|N/S|dd|E/W|coordinate parameters|template parameters}}

• This refers to supplying latitude and longitude as unsigned decimals with N/S and E/W required.

{{coord|dd|mm|N/S|dd|mm|E/W|coordinate parameters|template parameters}}

• Same with decimal minutes.

{{coord|dd|mm|ss|N/S|dd|mm|ss|E/W|coordinate parameters|template parameters}}

• Same with decimal seconds.

{{coord|template parameters|dd|mm|ss|N/S|dd|mm|ss|E/W|coordinate parameters}} Could someone in the know either clarify that this is legal or not legal?

• Positional parameters should usually be before "named" parameters, but reversing them works with some templates - generally NOT recommended. i.e. template modifications could potentially break that "undocumented" syntax

Also, should unused parameters be indicated by an empty field (||), or just left out completely.

• Unused positional parameters are typically left out completely (how it is currently documented), empty fields are usually not inserted, I am not sure what happens if empty fields are used. See example you cited below where they display as '*'.

There are about 45 articles with something like {{coord|32|01|S|117|24|E|type:town}} Note the missing seconds. It displays '" with no number. Is this considered valid syntax?

• Empty positional fields are not a documented syntax. The question becomes: Does '*' mean an unknown or zero?

Is it legal to have no geographic coordinates, just a type?

• Generally NOT in a coordinate family template. If you look up Geo Microformat, and then the underlying hCard. A "no coordinates" hCard template could be created to handle types with no coordinates. The question would be the "intent" of no coordinates? Because they are inaccurate, more than one, uncertain, unknown, ... ? Each case has a particular way of "dealing" with them.

LeheckaG (talk) 07:24, 25 July 2008 (UTC)

how easy do users of this template find it to fix incorrect syntax of others?

• Personally, I find it easy to correct coordinate template syntax.

I am not familiar with "template-tiger"? It would be a little challenging (because of the optional parameters), but a Regular expression can be created which matches the documented Coord template syntax. A bit easier might be two or three regular expressions to match coordinates, coordinate parameters, and template parameters separately (coordinate parameters and template parameters would more likely be combined). A few of the examples above do not match the documented syntax, but currently work, although they might not in the future if template updates are made. LeheckaG (talk) 08:01, 25 July 2008 (UTC)

don't see microformat

Why in some page like Sudbury_Neutrino_Observatory I can't see any geo microformat using operator extension for firefox? --Wiso (talk) 22:27, 15 July 2008 (UTC)

I am not sure what you do not see? Does it work on other articles for you and not this one, or not at all and you are citing this example? For me (checked with Firefox 2.0.0.14 on MacOS X 10.3.9, PowerBook G4 17), the coordinates do appear in the article's title bar and viewing the page source code, there appear to be various geo (Cascading Style Sheet) classes inline (which is what the the geo microformat is). Which version of Firefox and which OS/platform, with specific extension and version? LeheckaG (talk) 07:37, 25 July 2008 (UTC)

I'm using Linux, openSuSE 12 64 bit, firefox 3.0. The coordinate appears correctly, but with the operator extension I can't see the microformat. --Wiso (talk) 20:41, 29 July 2008 (UTC)

Which "operator extension"? If you look at the HTML source code for the article cited above, using the defaults: common.css,Monobook.css,... I receive:

<p>
 <span id="coordinates"><a href="/wiki/Geographic_coordinate_system" title="Geographic coordinate system">Coordinates</a>:
  <span class="plainlinksneverexpand">
   <a href="http://stable.toolserver.org/geohack/geohack.php?pagename=Sudbury_Neutrino_Observatory&params=46_28_00_N_81_10_22_W_region:CA-ON_type:landmark" class="external text" title="http://stable.toolserver.org/geohack/geohack.php?pagename=Sudbury_Neutrino_Observatory&params=46_28_00_N_81_10_22_W_region:CA-ON_type:landmark" rel="nofollow">
    <span class="geo-default">
     <span class="geo-dms" title="Maps, aerial photos, and other data for 46°28′00″N 81°10′22″W">
     <span class="latitude">46°28′00″N</span>
     <span class="longitude">81°10′22″W</span>
    </span>
   </span>
   <span class="geo-multi-punct"> /
   </span>
    <span class="geo-nondefault">
     <span class="geo-dec geo" title="Maps, aerial photos, and other data for 46.466667 -81.17278">
      <span class="latitude">46.466667</span>,
      <span class="longitude">-81.17278</span>
     </span>
    </span>
   </a>
  </span>
 </span>
</p>

to me, it appears they have Geo (microformat): (geo*, latitude and longitude span classses).

{{Coord}} uses {{Coord/link}} to output the microformat:

<span class="plainlinksneverexpand">[{{Coor URL}}{{{param}}}{{#if:{{{name|}}}|&title={{urlencode:{{{name}}}}}}}
 <span class="{{#ifeq:{{{default|}}}|dec|geo-nondefault|geo-default}}">
  <span class="geo-dms" title="Maps, aerial photos, and other data for {{{dms-lat}}} {{{dms-long}}}">
   <span class="latitude">{{{dms-lat}}}</span>
   <span class="longitude">{{{dms-long}}}</span>
  </span></span>
  <span class="geo-multi-punct"> / </span>
  <span class="{{#ifeq:{{{default|}}}|dec|geo-default|geo-nondefault}}">{{#if:{{{name|}}}|<span class="vcard">|}}
   <span class="geo-dec geo" title="Maps, aerial photos, and other data for {{{dec-lat}}} {{{dec-long}}}">
    <span class="latitude">{{{dec-lat}}}</span>,
    <span class="longitude">{{{dec-long}}}</span>
   </span>{{#if:{{{name|}}}|<span style="display:none"> (<span class="fn org">{{{name|}}}</span>)
  </span>
 </span>|}}]
</span>
<noinclude>{{template doc}}</noinclude>

The templates set a CSS ID of "coordinates" and are dependent on MediaWiki:Monobook.css:

#coordinates {  
    position: absolute;
    z-index: 1;
    border: none;
    background: none;
    right: 30px;
    top: 3.7em;
    float: right;
    margin: 0.0em;
    padding: 0.0em;
    line-height: 1.5em;
    text-align: right;
    text-indent: 0;
    font-size: 85%;
    text-transform: none;
    white-space: nowrap;
}

and MediaWiki:Common.css which has:

/* Geographical coordinates 
 
To display coordinates using the notation in the source code, write this in your User:Username/monobook.css:
   .geo-default { display: inline } .geo-nondefault { display: none } 
   .geo-dec { display: inline } .geo-dms { display: inline }
 
To display coordinates using decimal notation, write this in your User:Username/monobook.css:
   .geo-default { display: inline } .geo-nondefault { display: inline } 
   .geo-dec { display: inline } .geo-dms { display: none }
 
To display coordinates using DMS notation, write this in your User:Username/monobook.css:
   .geo-default { display: inline } .geo-nondefault { display: inline } 
   .geo-dec { display: none }   .geo-dms { display: inline }
 
To display coordinates in both decimal and DMS notation, write this in your User:Username/monobook.css:
   .geo-default { display: inline } .geo-nondefault { display: inline } 
   .geo-dec { display: inline }   .geo-dms { display: inline }
   .geo-multi-punct { display: inline }
 
See [[Template:Coor link]] for how these are used.
 
Note that the classes "geo", "longitude", and "latitude" are not just styles but also used by the [[Geo microformat]], so the names should not be changed.
*/
 
.geo-default { display: inline; }
.geo-nondefault { display: none; }
.geo-dms { display: inline; }
.geo-dec { display: inline; }
.geo-multi-punct { display: none; }
 
.longitude, .latitude {
    white-space: nowrap;
}
 
/* This is used for the Geo microformat, but no style is needed for now other than .geo-dec. */
.geo { }
 
/***** end Geo-related */

it relies on Geo microformat readers to look for the title= or PAGENAME to use as the name to associate with the latitude and longitude. LeheckaG (talk) 07:09, 30 July 2008 (UTC)

Scale not working for me

Resolved

 – Dschwen fixed it. 84user (talk) 02:06, 30 July 2008 (UTC)

I have boldy edited the documentation to indicate that scale does not work. If I am mistaken and it does work, could someone provide a working example? I echo User:Socrates2008 comments above from May. It seems scale does not override the type parameter's default scale, which differs from the behaviour explained in Wikipedia:WikiProject Geographical coordinates (WP:GEO COOR).

Here are examples of scale not working (click on blue globes to see):

* US city at 1:1000 {{coord|44.4|-111.1|type:city_region:US_scale:1000|display=inline}} * [[Sark]] at 1:1000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:city_scale:1000}} * Sark at 1:10000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:city_scale:10000}} * Sark at 1:100000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:city_scale:100000}} * Sark at 1:1000000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:city_scale:1000000}} and also for type:landmark : * Example from [[WP:GEO COOR]] 1:2000 {{coord|51|28|40|N|0|0|6|W|type:landmark_scale:2000_region:GB}} * ditto 1:8000 {{coord|51|28|40|N|0|0|6|W|type:landmark_scale:8000_region:GB}} * Sark at 1:1000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:landmark_scale:1000}} * Sark at 1:10000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:landmark_scale:10000}} * Sark at 1:100000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:landmark_scale:100000}} * Sark at 1:1000000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:landmark_scale:1000000}} and for type:airport : * airport with no scale {{coord|49|25|59|N|2|21|39|W|display=inline|type:airport}} * airport at 1:1000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:airport_scale:1000}} * airport at 1:8000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:airport_scale:8000}} * airport at 1:50000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:airport_scale:50000}} * airport at 1:400000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:airport_scale:400000}} -84user (talk) 00:29, 30 July 2008 (UTC)

Uh oh. I've been procrastinating the implementation of scale. Guess it's time to get cracking now. Btw. scale should be supported by the geohack (when clicking the coordinate link). --Dschwen 00:39, 30 July 2008 (UTC)

Ok, since I programmed most of it already I just had to plug in the formulas. Should be working now (clear the cache). Tell me if I got the scales (and dims) wrong. --Dschwen 00:59, 30 July 2008 (UTC)

If you look at the URLs generated above, they have the appropriate scales, so your scale problem is not with {{Coord}}, it is "downstream". The "scale" issue is at {{GeoTemplate}}, only some links have the "scale" parameter implemented. LeheckaG (talk) 01:13, 30 July 2008 (UTC)

He was talking about the WikiMiniAtlas "(click on blue globes to see)". --Dschwen 01:45, 30 July 2008 (UTC)

Yes, I find scale now works, after Dschwen's changes. Thanks. The toolserver.org/geohack URLs show the correct type and scale and when I click Google Maps it shows the expected scale. The javascript interactive map (the globe) appears to be limited to a minimum scale bar length of 1 kilometre, but it also works as expected above 1 kilometre (about 1:100000). Here are the additional test cases that I checked.

* type:country_scale:2000000 {{coord|49|25|N|2|21|W|display=inline|type:country_scale:2000000}} * type:country_scale:10000000 {{coord|49|25|N|2|21|W|display=inline|type:country_scale:10000000}} * type:country_scale:50000000 {{coord|49|25|N|2|21|W|display=inline|type:country_scale:50000000}} * type:state_scale:1000000 {{coord|49|26|N|2|22|W|display=inline|type:state_scale:1000000}} * type:state_scale:3000000 {{coord|49|26|N|2|22|W|display=inline|type:state_scale:3000000}} * type:state_scale:9000000 {{coord|49|26|N|2|22|W|display=inline|type:state_scale:9000000}} * type:adm1st_scale:200000 {{coord|49|26|N|2|22|W|display=inline|type:adm1st_scale:200000}} * type:adm1st_scale:1000000 {{coord|49|26|N|2|22|W|display=inline|type:adm1st_scale:1000000}} * type:adm1st_scale:5000000 {{coord|49|26|N|2|22|W|display=inline|type:adm1st_scale:5000000}} * type:adm2nd_scale:100000 {{coord|49|26|N|2|22|W|display=inline|type:adm2nd_scale:100000}} * type:adm2nd_scale:300000 {{coord|49|26|N|2|22|W|display=inline|type:adm2nd_scale:300000}} * type:adm2nd_scale:900000 {{coord|49|26|N|2|22|W|display=inline|type:adm2nd_scale:900000}} * type:city_scale:20000 {{coord|49|26|N|2|22|W|display=inline|type:city_scale:20000}} * type:city_scale:100000 {{coord|49|26|N|2|22|W|display=inline|type:city_scale:100000}} * type:city_scale:500000 {{coord|49|26|N|2|22|W|display=inline|type:city_scale:500000}} * type:airport_scale:10000 {{coord|49|26|N|2|22|W|display=inline|type:airport_scale:10000}} * type:airport_scale:30000 {{coord|49|26|N|2|22|W|display=inline|type:airport_scale:30000}} * type:airport_scale:90000 {{coord|49|26|N|2|22|W|display=inline|type:airport_scale:90000}} * type:isle_scale:20000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:isle_scale:20000}} * type:isle_scale:100000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:isle_scale:100000}} * type:isle_scale:500000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:isle_scale:500000}} * type:landmark_scale:2000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:landmark_scale:2000}} * type:landmark_scale:10000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:landmark_scale:10000}} * type:landmark_scale:50000 {{coord|49|25|59|N|2|21|39|W|display=inline|type:landmark_scale:50000}} I will now change my documentation edit to show it's working! -84user (talk) 01:58, 30 July 2008 (UTC)I see you've done it already! -84user (talk) 02:06, 30 July 2008 (UTC)

ISO 6709

It would be nice to support this format; it's not too much work to put those pipes in, but would be great if it wasn't necessary. Seems like a simple regexp to validate it. Miken32 (talk) 17:00, 4 August 2008 (UTC)

Actually, ISO 6709 seems like a "condensed" family of formats, Either: DDD.DDDD, DDMM.MMM, DDMMSS.SS; optional NNNN altitude and optional feet label - instead of meters for altitude. For {{Coord}} - implementation would be either:

• to add additional options for the format= template parameter or
• to "always" output it in addition to what is output now.

The question would be: What is going to read the ISO 6709? One would need to know what is going to read the ISO 6709 coordinates in order to figure out what goes around them. LeheckaG (talk) 17:27, 4 August 2008 (UTC)

Fastcgi error now in Coord display

There's an error noted in Template talk:infobox nrhp2#Latitude/longitude links aren't working which is blamed on an error here in this Coord template, which NRHP2 relies upon. Was something changed? doncram (talk) 01:06, 5 August 2008 (UTC)

Coord also fails for Abu Dhabi (city), which is unrelated to nrhp2. Art LaPella (talk) 01:07, 5 August 2008 (UTC)

It's not just this particular template. Geolinks-US works but almost nothing else does including most of the other coordinate templates. CambridgeBayWeather Have a gorilla 04:48, 5 August 2008 (UTC)

Issue is Coor(d) family of templates generating "malformed" URLs (at least from ToolServer's viewpoint) when supplied with some coordinates or coordinate/template parameters and not others, see Wikipedia talk:WikiProject Geographical coordinates#Fastcgi error.

LeheckaG (talk) 07:44, 5 August 2008 (UTC)

Missing closing span tag in Template:Coord/link

{{editprotected}} Template:Coord/link contains 13 <span> tags but only 12 </span> ones. I think it's the very first span that's missing it's closing tag, so another </span> should go right at then end before <noinclude>.

Also in Template:Coord/link, the closing ] wrapped arround {{Coor URL}} should be moved immediately to the right of the </span> tag following it. That should make it so every opening tag rendered to the page has a closing tag, and the tags are closed in the proper order, I think. So, the end of the template would then be:

(<span class="fn org">{{{name|}}}</span>)</span></span>|}}</span>]</span><noinclude>{{template doc}}</noinclude>

M blaine 1986 (talk) 04:44, 26 August 2008 (UTC)

As M blaine indicated, span(s) do not "balance".

<span class="plainlinksneverexpand">[{{Coor URL}}{{{param}}}{{#if:{{{name|}}}|&title={{urlencode:{{{name}}}}}}}
 <span class="{{#ifeq:{{{default|}}}|dec|geo-nondefault|geo-default}}">
  <span class="geo-dms" title="Maps, aerial photos, and other data for {{{dms-lat}}} {{{dms-long}}}">
   <span class="latitude">{{{dms-lat}}}</span>
   <span class="longitude">{{{dms-long}}}</span>
  </span>
 </span>
 <span class="geo-multi-punct"> / </span>
 <span class="{{#ifeq:{{{default|}}}|dec|geo-default|geo-nondefault}}">
  {{#if:{{{name|}}}|<span class="vcard">|}}
   <span class="geo-dec geo" title="Maps, aerial photos, and other data for {{{dec-lat}}} {{{dec-long}}}">
    <span class="latitude">{{{dec-lat}}}</span>,
    <span class="longitude">{{{dec-long}}}</span>
   </span>
   {{#if:{{{name|}}}
  |<span style="display:none"> (
    <span class="fn org">{{{name|}}}</span>)
   </span>
  </span>
  |}}
<!-- closing </span> for 2nd. #if: {default|} is missing from here -->
 ]
</span>
<noinclude>{{template doc}}</noinclude>

The pair of #if: {name|} parser functions balance as the 1st. conditionally opens (1) span, and the 2nd. conditionally opens (1) span, and closes (2) spans.

Given the [] bracketing, rather than M blaine's hypothesis of the 1st. (plainlinksneverexpand) span being imbalanced, the source of the imbalance is the 2nd. #ifeq: {default|} and as M blaine said, there should be a </span> in between the closing }} for the #if: {name|} and the closing ]right-square-bracket. LeheckaG (talk) 06:30, 26 August 2008 (UTC)

Done. --- RockMFR 16:54, 1 September 2008 (UTC)

Thank you - diff between previous and current version looks good. LeheckaG (talk) 18:19, 1 September 2008 (UTC)

Map sources/GeoHack vs. WikiMiniAtlas

Maybe I'm not taking full advantage of the various coordinate parameters, but as far as I can see, the Map sources/GeoHack image is not far from useless. The scale is so small, the red dot covers the entire island of Taiwan. When I alter "type" it has no effect on Map sources/GeoHack, but a clear effect on WikiMiniAtlas. If I'm missing some vital point, then please clue me in. If I'm not... then why are we still using Map sources/GeoHack ? Ling.Nut ^{(talk—WP:3IAR)} 01:58, 6 September 2008 (UTC)

If you like to comment on Template:GeoTemplate, Template talk:GeoTemplate would be the better forum.

The mini-map on geohack (Template:GeoTemplate) is always the same, similar to a locator map. What changes is the focus provided by the various linked mapping sites, e.g. Google, etc.

To work well, there are three factors:

• appropriate type or scale need to be defined with the coordinates (in {{coord}} e.g.)
• the settings for a specific map site need to be defined correctly (on Template:GeoTemplate)
• the map site needs to have a map available for the selected scale.

-- User:Docu

CSS issue

The coordinates used by Mahim Fort in Infobox Building do not appear correctly. It seems to be higher than normal. Can anyone please check? =Nichalp «Talk»= 16:40, 15 September 2008 (UTC)

It's a known problem that still looks for a more general solution. The way the coordinates template inherits the font size for display in the article's title needs to be changed (probably in Template:Coord/display/inline,title).

For this infobox there is a simple fix that I just applied. -- User:Docu

Coord needs repair (on 1844 pages)

Intial header restored by/at the request of User:Docu

After applying most of the checks suggested earlier, these now identify 1844 pages where the coord template was applied incorrectly. All these pages appear in Category:Coord template needing repair. They are much more {{coord}} templates that need repair than of the coor d/dm/dms set.

Current count as of 06:55 (UTC) on Tuesday May 7, 2024 is 0 -- User:Docu

Presumably the higher number for Coord is a result of Coord's greater popularity; and that you fixed many of the older templates in the last week or two, but did not do so for Coord. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:06, 16 September 2008 (UTC)

Other templates more popular, check Special:MostLinkedTemplates. A few are due to that fact Pigsonthewing converted some broken coor d/dm/dms templates to coord instead of fixing them. -- User:Docu

Please stop making false assertions like that; I've already refuted them on my talk page. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:21, 16 September 2008 (UTC)

"33 Template:Coord ‎(241,750 links)" - none of the deprecated "coor *" templates is above that. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:23, 16 September 2008 (UTC)

You are correct about the frequency of {{coord}}. It's used (directly or indirectly) by 240,000 of 340,000. Direct uses may be lower though [2]-- User:Docu

A couple of faulty scripts causing these problems have been identified. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:56, 16 September 2008 (UTC)

Most of the ones I looked at (other than the ones in the diff Andy identifies above) were simply miscoded by whoever put them in, I don't think there's any cause to hassle people in here over it. It's the reality of a wiki that many people simply don't understand how things work and copy coordinates in from Google Maps or code in from other pages (which may well itself be faulty). I've fixed a few, will turn my attention to reducing the number once off wikibreak later this week. Orderinchaos 17:18, 16 September 2008 (UTC)

If they are reguarly cleaned up, this isn't really a problem. Participants of WP:GEO might be inclined in help with this. -- User:Docu

Whereas coord title * templates need repair on ~2,000+ pages; and that's not including coor d* and coor at *. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:56, 23 September 2008 (UTC)

Afraid I have to stick my hand up here - I'm responsible for a significant proportion of the {{coord}} problems. Have seen just about every article I've geotagged in the past 18 months being fixed in the past week or so. Socrates2008 (Talk) 12:14, 23 September 2008 (UTC)