Template talk:Coord

Conversion: For issues to be considered in upgrading other coordinates templates to this one, please see /conversion.

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.
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 44.4°N 111.1°W / 44.4; -111.1
• Sark at 1:1000 49°25′59″N 2°21′39″W
• Sark at 1:10000 49°25′59″N 2°21′39″W
• Sark at 1:100000 49°25′59″N 2°21′39″W
• Sark at 1:1000000 49°25′59″N 2°21′39″W

and also for type:landmark :

• Example from WP:GEO COOR 1:2000 51°28′40″N 0°0′6″W
• ditto 1:8000 51°28′40″N 0°0′6″W
• Sark at 1:1000 49°25′59″N 2°21′39″W
• Sark at 1:10000 49°25′59″N 2°21′39″W
• Sark at 1:100000 49°25′59″N 2°21′39″W
• Sark at 1:1000000 49°25′59″N 2°21′39″W

and for type:airport :

• airport with no scale 49°25′59″N 2°21′39″W
• airport at 1:1000 49°25′59″N 2°21′39″W
• airport at 1:8000 49°25′59″N 2°21′39″W
• airport at 1:50000 49°25′59″N 2°21′39″W
• airport at 1:400000 49°25′59″N 2°21′39″W

-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 49°25′N 2°21′W
• type:country_scale:10000000 49°25′N 2°21′W
• type:country_scale:50000000 49°25′N 2°21′W

• type:state_scale:1000000 49°26′N 2°22′W
• type:state_scale:3000000 49°26′N 2°22′W
• type:state_scale:9000000 49°26′N 2°22′W

• type:adm1st_scale:200000 49°26′N 2°22′W
• type:adm1st_scale:1000000 49°26′N 2°22′W
• type:adm1st_scale:5000000 49°26′N 2°22′W

• type:adm2nd_scale:100000 49°26′N 2°22′W
• type:adm2nd_scale:300000 49°26′N 2°22′W
• type:adm2nd_scale:900000 49°26′N 2°22′W

• type:city_scale:20000 49°26′N 2°22′W
• type:city_scale:100000 49°26′N 2°22′W
• type:city_scale:500000 49°26′N 2°22′W

• type:airport_scale:10000 49°26′N 2°22′W
• type:airport_scale:30000 49°26′N 2°22′W
• type:airport_scale:90000 49°26′N 2°22′W

• type:isle_scale:20000 49°25′59″N 2°21′39″W
• type:isle_scale:100000 49°25′59″N 2°21′39″W
• type:isle_scale:500000 49°25′59″N 2°21′39″W

• type:landmark_scale:2000 49°25′59″N 2°21′39″W
• type:landmark_scale:10000 49°25′59″N 2°21′39″W
• type:landmark_scale:50000 49°25′59″N 2°21′39″W

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

Named parameters for region/type etc

Following a lenghty discussion on WT:GEO, it appears that one of the features from other templates that could improve others, was the introduction of named parameters for parameters such as type, region, scale.
This would result in using "type=landmark|region=GB|scale=5000" instead of "type:landmark_region:GB_scale:5000".

Using pipes (|) instead of underscores (_) has also the advantage of being closer to the way people use parameters in wikipedia. Probably already now, {{coord}} is frequently used this way. If we want to identify the pages, adding this sample code to {{coord}} would categorize all these pages into a maintenance category Category:coord template needing repair.

All articles that would end up in the category currently need repair as information on region/type/scale is present in the article, but not passed on to geohack. Check, e.g. this version of Carreño.

If we decide to use named parameters, the named parameters can be used within the template to check input. {{coord}} would need to be modified slightly to pass them on to geohack. -- User:Docu

Maintenance category to find and fix excessive number of input fields

Similar to checks in {{coor at dms}} and {{coordinate}}, I'd like to add checks to verify if the there aren't any excessive number of input fields. Sample:

• For Template:Coord/input/d,
• the input should be 12°N 12°W
• not 12°N 12°W
which renders as 12°N 12°W
  )

The subpage includes additions to make to each template. Any article with an excessive number of input fields would be categorized in . -- User:Docu