Geographical coordinates

Coord is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Wikipedia. If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.Geographical coordinatesWikipedia:WikiProject Geographical coordinatesTemplate:WikiProject Geographical coordinatesGeographical coordinates articles

Geography Template‑class

This template is within the scope of WikiProject Geography, a collaborative effort to improve the coverage of geography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.GeographyWikipedia:WikiProject GeographyTemplate:WikiProject Geographygeography articles Template This template does not require a rating on Wikipedia's content assessment scale. WikiProject Geography To-do list: Here are some tasks awaiting attention: Article requests : See Requested articles/Social sciences/Geography, cities, regions and named places and Missing articles about Locations Assess : Tag related article talk pages with {{WikiProject Geography}}. To help assess the quality and importance of geography articles, please see: Unassessed geography articles and Unknown-importance geography articles. Cleanup : See Geography articles needing attention Deletion sorting : Listed at Geographic related deletion discussions Geographical coordinates : See Articles missing geocoordinate data by country Infobox : See Geography articles needing infoboxes Map : See Wikipedia requested maps Notability : See Geography articles with topics of unclear notability Photo : See Wikipedia requested photographs of places Stubs : See Geography stubs

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 14

Whilst editing or browsing, I occasionally come across articles such as this one, which produces an error message in large red letters across the top of the screen. I'm not an expert on the intricacies of this template, so I haven't fixed it. (I tried previewing it changing the O to an E, but it didn't work). What would be useful would be for the template to automatically add a category to any faults it finds, say Category:Pages with faulty co-ordinates or something. This would allow editors experienced with this template to easily target and fix the problems. Is this possible? —  Tivedshambo  _(t/c) 17:31, 5 January 2009 (UTC)[reply]

It used to be possible with the old templates, but they were unfortunately deleted. Since this template attempts to be everything the old ones were together, there are space constraints with multiple transclusions and I doubt we can add the error checking functionality here. User:Dispenser however runs a daily check on all coordinates with an external tool to produce error logs: see tools:~dispenser/view/File_viewer and click on coord-enwiki.log. --Para (talk) 17:47, 5 January 2009 (UTC)[reply]

The categories which were deleted were those for the deprecated coor * templates; they were deleted by the correct, consensual process. Category:Coord template needing repair still exists. Note also that the categoeies were only added to the coor * templates while they were being deprecated; over 18 months after {{Coord}} was created to replace them. I have fixed the coordinates on Lokomotivfabrik Floridsdorf. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:28, 5 January 2009 (UTC)[reply]

I've produced a template, {{repair coord}}, that can be added to an article which has faulty or inaccurate coordinates (i.e. either the syntax is incorrect or the coordinates point to the wrong location). It categorises articles into Category:Coordinates templates needing maintenance. —  Tivedshambo  _(t/c) 13:37, 14 January 2009 (UTC)[reply]

Cleanup of this page is needed : an unwanted picture appears ; a problem with the template itself, or one of the subtemplates ? Baronnet (talk) 19:08, 11 January 2009 (UTC)[reply]

What picture are you referring to?! The blue globe? --Dschwen 19:38, 11 January 2009 (UTC)[reply]

I'm not a big fan of the globe. It can be very intrusive; take a look at Pole of inaccessibility. Can we make it more subtle and less in-your-face? 86.134.10.5 (talk) 05:16, 16 January 2009 (UTC).[reply]

The globe is indeed very intrusive, and in fact rather unaesthetic (it disrupts the reading flow and influences the spacing between lines of text). But unfortunately requests for alterations have been rejected. Cush (talk) 06:54, 16 January 2009 (UTC)[reply]

Can we request a compromise - have it in the header but not in-line? —  Tivedshambo  _(t/c) 07:31, 16 January 2009 (UTC)[reply]

That sounds like a good compromise to me. -- The Anome (talk) 12:11, 17 January 2009 (UTC)[reply]

What do you mean by "in the header"? Do you mean when the coordinates appear at the extreme top right of an article? I think we need some sort of link to the pop-up map in inline use; it would be a shame to lose that feature. Just something more discreet than the big blue splodge. 86.133.242.226 (talk) 00:57, 18 January 2009 (UTC).[reply]

I concur. The loud globe icon makes the article above look awful. I think making it smaller inline would only be a slight improvement but still bad. But the pop-up map function is useful. Could change the icon to something in the more-subtle style of the external link icon, so that it won't grab your eye unless you're actually reading that part of the text. Or the only other idea I have would be to have no icon inline. Clicking on the coordinates would pop up the map instead of taking you to the toolserver, and there would then be a link on the map to take you on to the full server if this preview isn't sufficient. This also avoids an immediate external link in the text which is normally considered poor style. If no JavaScript, it falls back to present mode of going to toolserver if you click on the coordinates.

I actually prefer this latter idea over using any icon, as an icon is not needed to label the coordinates (unlike the external link icon). Its only purpose is as something different to click on. No icon at all would be cleaner functionally and also better style aesthetically. --GregU (talk) 04:18, 18 January 2009 (UTC)[reply]

How about just [map]? (I agree the icon is ugly) Orderinchaos 04:59, 18 January 2009 (UTC)[reply]

[outdent] I must admit, I'd never realised the globe was clickable before. Having said that, I don't think much of the pop-up it produces either - Britain looks pretty squashed, and the maps and satellite/aerial views are of poor quality compared with Google maps or UK streetmap. I wouldn't be in favour of having the pop-up map come up as the default, but on the other hand I suspect other users will protest if that functionality is lost. The only other suggestion I can make is to have an in-line link like "Erdington 52°31′25″N 1°50′16″W (Popup)", where popup brings up the pop-up map. And without the globe, which seems to have appeared in the link when I previewed the message even without using the coord template. Odd. —  Tivedshambo  _(t/c) 08:31, 18 January 2009 (UTC)[reply]

I agree that the quality of the pop-up map isn't great. It seems to use some kind of weirdly distorted projection for higher latitudes. For me, the link overlays are pretty dreadful too -- they frequently overlap and/or are illegible due to clipping or being overlaid on a too-similar colour in the case of some of the aerial photos. Nevertheless, I still think the best option is to lose the globe, have the pop-up map come up when you click the coordinates, and have on the pop-up map a link to "Other maps" (or whatever) that takes you to the "Map sources/GeoHack" page. Incidentally, can we also change the "GeoHack" name? With the connotations of "hack", it doesn't exactly make it sound like a quality product. 86.134.55.56 (talk) 04:33, 21 January 2009 (UTC)[reply]

Following my previous post, with my unexpected discovery that the globe appears even in a direct external link, I've been looking in detail at the code of this template. I've come to the conclusion that the globe must be produced either by a css or js script somewhere, or directly by the wiki software. As yet, I'm not sure which, though i'm still looking. Either way, this is probably not the best place to request a change. If it's in the software, then it should be raised in Bugzilla. If it's a script, then it should be discussed on the appropriate talk page. Could a developer of this template point us in the right direction please? —  Tivedshambo  _(t/c) 06:18, 21 January 2009 (UTC)[reply]

The icon is added by meta:WikiMiniAtlas, called in MediaWiki:Common.js. See #Image size of the globe above. Wikipedias in some languages have changed it in their MediaWiki:Common.js to a different size or image. --Para (talk) 15:18, 21 January 2009 (UTC)[reply]

Thanks for that - it means disabling the blue globe is fairly straightforward if users want to do it. I've added the code to Template:UF-coord-classes. I suggest we leave the globe enabled by default, but registered users can switch it off if they so desire. —  Tivedshambo  (t/c) 16:05, 21 January 2009 (UTC)[reply]

If the consensus is that the globe is overly intrusive then any solution needs to work for everyone. A fix that relies on users customising their accounts is unsatisfactory; most Wikipedia readers won't benefit from it. 86.133.240.160 (talk) 02:04, 22 January 2009 (UTC).[reply]

The globe has been here way over a year. It'll take a lot more than a few complainers to get a consensus. Furthermore it annoys me quite a bit that this discussion takes place under the heading "Bug". --Dschwen 04:10, 22 January 2009 (UTC)[reply]

And to elaborate. The Wikiminiatlas is opened about 4000 times a day from over 2500 distinct IPs each day (recurring users on different days). Just to get you an idea about "consensus". --Dschwen 04:18, 22 January 2009 (UTC)[reply]

I said if (though, as it happens, I don't see anyone here supporting it; in fact, I see a lot of people agreeing that it's ugly and intrusive). I have no idea what point you are trying to make with your stats. The heading is wrong; the discussion veered off. Change it if it bothers you. 86.133.240.160 (talk) 04:51, 22 January 2009 (UTC).[reply]

The fact that the globe has been there for a year does not mean it is beautiful. It still could be changed to a version that does not disrupt text flow and does not impact line height. Just let somebody with taste re-design it. Cush (talk) 15:02, 25 January 2009 (UTC)[reply]

I agree with the above comments on intrusiveness and aesthetics, and would support some redesign. Knepflerle (talk) 16:33, 26 January 2009 (UTC)[reply]

On the german Wikipedia I had replaced the blue globe with a unicode symbol (♁, which is the symbol for earth) for all inline coordinates (the blue globe remains in the title coords on the top right of the page). --Dschwen 16:42, 26 January 2009 (UTC)[reply]

I think a set of incomprehensible blue numbers in the middle of text is distracting, and icons don't make it much worse anymore. The references tag supports multiple groups now, and inline coordinates could be taken out from text but still kept linked from there. For example, these links to some place^{[coord 1]} with an inline icon or without icon^{[coord 2]} contain the coordinates in wikitext already, they are just shown later on, like with references. Here:

It would be nice to be able to hide the group name from the visible link, somehow. It might be possible to put some of the wikitext into the coord template to have it create the ref tags (if possible?). We could add another display parameter for that, and the user would have to add <references group="coord" /> or {{coordlist}} to the end of the article to make sure the coordinates will be visible. I'm not sure I like it myself, but this is one possibility. --Para (talk) 18:45, 26 January 2009 (UTC)[reply]

Hmm, that is actually a pretty decent idea. I think i might support such a change. --TheDJ (talk • contribs) 00:32, 28 January 2009 (UTC)[reply]

mw:Extension:Cite/Cite.php#Templates might pose problems, thought the information could also be out of date. We'd need to test, or find an existing template from Category:Citation templates that contains <ref>. --Para (talk) 11:46, 28 January 2009 (UTC)[reply]

Came here to see if it was possible to supress the coorodinates down to [maps] and saw this section. I tried it out at Baffin Island and I think it looks pretty good. CambridgeBayWeather Have a gorilla 15:18, 3 February 2009 (UTC)[reply]

You can also do a navbox to further reduce article clutter. EG: Battle_of_Corydon#External_links has a box with engagments. These all emit locations, one of which is a coordinate. -J JMesserly (talk) 18:15, 28 February 2009 (UTC)[reply]

I very much like this idea. I think it should also be used in conjunction with the change proposed above to add [map] next to the link instead of an icon. Adding the ref tag to template shouldn't be a problem, if you're having any problems with it you can drop me a message on my talk page. --Nezek (talk) 10:40, 1 March 2009 (UTC)[reply]

Resolved

 – Change finally implemented.

The tool tip link includes the full coordinates, e.g. "Maps, aerial photos, and other data for 34°40′37″N 118°11′10″W" when hovering with the mouse pointer over 34°40′37″N 118°11′10″W / 34.67694°N 118.18611°W / 34.67694; -118.18611. It was suggested earlier (Template_talk:Coor_URL/Archive01#Span_title) to limit this to the text "Maps, aerial photos, and other data for this location".

This was implemented for most coordinates templates (1), but this template appears to have been omitted. I suggest that we include this change in the next update of Template:Coord/link. Sample code is at [1]. -- User:Docu

Quarl was concerned the last time that putting the page name in the tooltip would be misleading with inline coordinates about something else. Now that we have the name parameter, I would like to see the name of the page or the name of the inline coordinates used, which in turn would encourage people to add it to inline coordinates where it's missing. The tooltip could have "for {{{name|{{PAGENAME}}}}}". It may however still not be widespread enough (see results of the sslloooww tools:~para/cgi-bin/coord_unnamed). So until it is, I think "for this location" is fine. --Para (talk) 12:37, 5 February 2009 (UTC)[reply]

I'd suggest "Maps, aerial photos, and other data for {{{name|this location}}}". The PAGENAME will often be inappropriate. —AlanBarrett (talk) 15:27, 5 February 2009 (UTC)[reply]

Sounds good to me. I changed [2] accordingly. -- User:Docu

Most articles with coordinates have a strong link to the pagename, and if we want to use a name for coordinates in tooltips at all, it would be odd to never use the name of the page. It may be inappropriate in some cases (graveyard coordinates in articles about people or museum coordinates in articles about paintings come to mind), but then that's a good reason to give them another name or omit the coordinates altogether. --Para (talk) 00:35, 11 February 2009 (UTC)[reply]

So you'd rather have "this location" ? -- User:Docu

I believe simply "this location" is better in all cases. The tooltip should rephrase the purpose in another way to clarify, not just repeat a placename that can already be seen. Saying "location" actually provides more context. --GregU (talk) 06:58, 11 February 2009 (UTC)[reply]

I'd rather have names only or "this location" only, but not a mix of the two. I disagree that "this location" provides more context, when "this" could refer to the subject of the entire page or something mentioned near the coordinates, and when the tooltip already describes the information available behind the link, very much related to locations. --Para (talk) 14:07, 11 February 2009 (UTC)[reply]

Ok, let's go for the initial solution "this location" then. -- User:Docu

Trying to shoehorn name properties into a coordinates template is not a valid reason to start omitting coordinates from articles. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:49, 11 February 2009 (UTC)[reply]

Docu says "this template appears to have been omitted", but what actually happened is that I told him that "the coor * templates are on the verge of being deprecated, and replaced with {{coord}}" and he chose to ignore that and forge ahead anyway. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:53, 11 February 2009 (UTC)[reply]

Resolved

 – Bug fixed.

Unresolved

 – Suggested new format needs to be developed.

Currently the {{coord|1|2|2|N|1|2|2|E|type:landmark|region:NO}} isn't recognized as an error as the validation function in {{Coord/input/dms}} doesn't receive the 10th unnamed field.

It does work for other formats, e.g. {{coord|1|2|N|1|2|E|type:landmark|region:NO}} is recognized by {{Coord/input/dm}} as an error as the 8th unnamed parameter is passed on.

To fix it, {{coord}} needs the following change: [3]. It could be included in the next series of updates of the coord family. -- User:Docu

Would it be confusing for the less initiated editors, though? Now all colon parameters are separated with an underscore, but with this change they would look more like normal template parameters, and people would no doubt try to use type=landmark or region=NO. Simplifying parameter usage and dropping the colon usage altogether would be a good direction for improvement, but someone needs to test how many modifications it would require to support all the possible parameters, and how it would change expansion limits. Anyway, support for more unnamed parameters would also require concatenation in all the input templates. --Para (talk) 00:43, 11 February 2009 (UTC)[reply]

To clarify: the change doesn't add support for additional ways of formatting, it just checks if too many parameters were added. {{Coord/input/dms}} already checks for {{{10}}}, but never finds any as {{coord}} doesn't pass it on. The check works with {{Coord/input/dm}} {{Coord/input/d}} etc. The categorization from {{Coord/input/dms}} could be added directly to {{coord}}.

As it simply outputs an error category, it helps with using the current format.

In general, I'd favor a solution like /Archive_9#Named parameters for region/type etc. This would need some work though .. -- User:Docu

Ah, of course, I don't know how I interpreted it the other way round. Better error detection sounds good, yes. --Para (talk) 14:38, 11 February 2009 (UTC)[reply]

Resolved

 – Bug fixed

Some pages seem to lack the - in the <span class="geo"> element for positions west of the prime meridian. For example Leeds doesn't, but oddly London does.

This worked fine a few weeks ago when the pages were outputting the full microformat.

Sorry if this is the wrong place to put this, but I'm new to this. -- — Preceding unsigned comment added by 86.26.250.85 (talk • contribs)

Neither Leeds nor London use {{coord}} directly. Leeds uses {{Infobox UK place}}. That infobox seems to use some workaround to fix a problem {{coord}} had earlier. Thus you might want to try Template talk:Infobox UK place. -- User:Docu

Thanks for noticing, the bug is indeed with the microformat output only, and it's been this way for over three weeks now! This is happening when the template is called with degrees and letters S or W, like {{coord|1|N|2|W}}. Looks like we have hemispheres swapped in the conversion at Template:Coord/input/d and the template is testing a case that will never happen:

  |dec-lat={{#ifeq:{{{2}}}|W|-}}{{{1}}}
  |dec-long={{#ifeq:{{{4}}}|S|-}}{{{3}}}

The W should be an S and the S a W. --Para (talk) 13:25, 18 February 2009 (UTC)[reply]

Good catch! Looks like that output wasn't much used. Despite that, as the job queue was short, I made the change. -- User:Docu

When adding coordinates to river articles, which point it should reference? The beginning, the mouth, the mid point, something else? Renata (talk) 12:43, 27 February 2009 (UTC)[reply]

Check out Wikipedia:WikiProject Geographical coordinates/Linear, Regards,  Badgernet  ₪  14:19, 27 February 2009 (UTC)[reply]

When Google Maps links to a Wikipedia article, it appears to have trouble with latitudes in the format -X°N. Notice that the Reserve Bank of Australia, with a latitude of -33.868086°N, is shown on Google Maps as located somewhere in the Pacific Ocean. Alternately, Australia, with a latitude of 35°18′S, is located in the proper place on the map.

So, what's the convention for latitudes in the Southern Hemisphere? Is it important to have them in a format that Google Maps can make sense of? It might be easier to request that Google update their code to read the -X°N style, particularly if that's accepted notation in the world of geography. Not sure if this is a problem for longitude as well...

Also, while I'm on the subject, an even bigger error than an Australian bank being in the middle of the Pacific Ocean is Venus's Baltis Vallis being right next door. Is there some way that non-Earth features can be marked so that they don't get picked up by Google Maps (and, potentially, do get picked up by Google Moon, Google Mars, or a hypothetical Google Venus)? Maybe it's as simple as Venus X°N Y°E (unfortunately, I don't know how often Google crawls Wikipedia to update the coordinates; it could take a significant amount of time to figure this out through trial and error). Khakiandmauve (talk) 22:32, 27 February 2009 (UTC)[reply]

Isn't -33°N a bit strange? Why don't you simply write -33° or 33°S ? −Woodstone (talk) 22:52, 27 February 2009 (UTC)[reply]

Use globe:venus in the parameter section (where you put type:landmark etc.). --Dschwen 00:00, 28 February 2009 (UTC)[reply]

It's not marked with a coord tag; I think Google is pulling the information from Template:Infobox_feature_on_Venus, which doesn't have a globe parameter. Although I see how the globe parameter is being used for, say, Olympus Mons, which doesn't appear on the map. Khakiandmauve (talk) 00:47, 28 February 2009 (UTC)[reply]

Then Template:Infobox_feature_on_Venus is definitely broken. It must generate globe:venus on the coordinates. And thus should be using coord. --Dschwen 03:46, 28 February 2009 (UTC)[reply]

Resolved

 – see Template:Coord#Coordinates_in_PDF

Please check Help:Books/Feedback#Coordinates. -- User:Docu

{{Coord/display/inline,title}} needs to be changed to hide the coordinates part above the title. The PDF generation does not evaluate CSS styles. Therefore the coordinates are shown twice inline. It should be changed using {{Hide in print}} like this:

{{{1}}}{{Hide in print|<span style="font-size: small;"><span id="coordinates">[[Geographic coordinate system|Coordinates]]: {{{1}}}</span></span>}}<noinclude>{{pp-template|small=yes}}{{template doc|Template:Coord/sub doc}}[[Category:Coord template]]</noinclude>

and {{Coord/display/title}} should be added to Category:Exclude in print --He!ko (talk) 11:58, 1 March 2009 (UTC)[reply]

Heiko, there are two different issues, for different ways this template works:

(1) for display=inline,title, pdf is displaying the inline version twice (once the standard version, once the microformat version). The suggested fix doesn't address this.

(2) for display=title, the coordinates are not displayed in the pdf version, while they work in the print version. The second fix doesn't address this either.

In both cases, the coordinates should be display with the title as this is being done in the print version (link "printable version" on articles). -- User:Docu

(1) Why? The fix omits the span (goes to the top of the page) and thus the coorrdinates won't show up twice. --He!ko (talk) 15:51, 1 March 2009 (UTC)[reply]

(2)They work in the print version (HTML+CSS) but won't in the PDF as no CSS is supported. Simply writing the coordinates wherever the template is used in the markup may lead to unexpected results. --He!ko (talk) 15:51, 1 March 2009 (UTC)[reply]

(1) The duplication wasn't on the top of the page in Ben Nevis, but in the infobox field. The solution below (Template:PrintCoord/link) avoids the issue and has the advantage that {{coord}} itself wont get more complex. -- User:Docu

(2) The solution below isn't ideal, but is there a way to have it rendered before or after the article text? (prepend or append)-- User:Docu

I solved (1) by creating Template:PrintCoord/link. This also got rid of the URL to geohack being included at the end of the article.

For (2) (Old Town, Edinburgh at Help:Books/Feedback#Coordinates), the new Template:PrintCoord/display/title displays the coordinates in the article at the location of the template (new pdf version at Old Town, Edinburgh pdf). Previously these coordinates were omitted. This isn't ideal, but better than before. -- User:Docu

Currently (20:54, 2 March 2009 (UTC)), the Print version don't appear to work anymore. -- User:Docu

I was informed that a simply class="noprint", should also work. That might be easier to do perhaps, since spans are already in use. --TheDJ (talk • contribs) 21:06, 2 March 2009 (UTC)[reply]

Template:PrintCoord/link was quite easy to do, it just doesn't work right now. -- User:Docu

There are now two sample test pages at:

• Help:Books/Feedback/Tests/coord 1
• Help:Books/Feedback/Tests/coord 2

-- User:Docu

I don't know if this is the best place to start with this question but here goes.

The problem is that there are many templates, including one that I've been working on ({{Infobox Protected area}}), that display a map with a mark at a specific location based on geo data, all kinds of nasty kludging is required. They call templates like {{superimpose}} and {{Location map}} to get the job done. They work but require special coordinate formats or manufactured data. {{Location map}} will work with decimal latitude and longitude data.

My dream would be that there would be a way to access the latitude and longitude information in dec format. I noted when examining the source HTML code for articles using {{coord}} that vcard geo data is always embedded in decimal format. If that data could be accessible to a template coder things would get very simple.

It appears that the VariablesExtension is not likely to be implemented anytime in the near future. See bugzilla:7865. I've tried to think of other ways like writing a parser template that would extract the data from the coord template but that would not be easy for me and must have been done already while writing this template.

The dream way would be for the coord template to create two magic words. See also Manual:Variable. Something like {{LATITUDE}} and {{LONGITUDE}}. This would require some javascript. As I say this is a dream thing and I have no idea if it is feasible.

I would be more than happy with a parser templates. Something like {{latitude|{{{coords}}}}} and {{longitude|{{{coords}}}}} but this might add unnecessary and redundant overhead.

Any thoughts or comments would be greatly appreciated. --DRoll (talk) 03:43, 9 March 2009 (UTC)[reply]

Converting between decimal and dms format isn't that difficult, but you're right in that it doesn't make much sense to have the functionality in all templates that use coordinates to display a map, instead of transcluding it from somewhere. The main coord template calls its input templates to do the conversion, and passes the results to display templates. It would probably be possible to write a coord interface template that would just do the conversion with coord's subtemplates, but not format the results for display.

All magic words I can think of apply to the entire page, so that idea wouldn't work as many pages have multiple coordinates and therefore multiple contexts. But since any such software support would require MediaWiki changes, and the King of MediaWiki is favourable to geographical coordinates, now might be a good time to propose software features. If anything gets added, it will most likely be along the lines of mw:Extension:Gis/geo tag, which in the case of infobox maps would be filled in from usual parameter names in the infobox and then called multiple times with extension parameters like "convert=decimal lat" or so. --Para (talk) 12:57, 9 March 2009 (UTC)[reply]

One could indeed imagine that the primary coordinates of an article were available through magic words within the page.

In the past we mainly thought about coming up with new magic words to work with the GeoTemplate output page (older) and various ways to standardize input formats. As many other things, input is done with templates as this is the only way for now. At least, one template has it down to inputing coordinates through only two (named) template fields.

There are a few extensions other than Gis (mw:Category:GIS extensions) that already provide direct display similar to magic words, e.g. GeoRSS, e.g. entry/display here and display here.

If one wants to browse Wikipedia articles with coordinates nearby, dispenser's tool linked on GeoTemplate provides reguarly updated data. We just need to work on the interface or provide feeds to the others for regular updates. -- User:Docu

I think I was unclear in my request. Perhaps it was too late a night when I wrote it. What I need I now realize are two templates. The first would return the latitude in decimal format. The second would return the longitude in decimal format. The templates might work something like this.

{{My Template
 .
 .
 |coord = {{Coord|44|26|N|15|03|E}}
 .
 .
}}

Then in the code for My Template:

 .
 .
 {{Location map
   |Croatia
   |label = Pag
   |label_size = 200
   |lat = {{latitude|{{{coord}}} }}           
   |long = {{longitude|{{{coord}}} }}
   |marksize = 14
   |position = right
   |width = 300
   |float = right
   |background = #FFFFDD
   |caption = Pag Island on the map of Croatia
 }}
 .
 .

I suspect that there is a sub-template for {{coord}} that does this already since the vbox class geo contains this data. Where do I find the code. --droll [chat] 01:53, 10 March 2009 (UTC)[reply]

There are other templates like {{Infobox Settlement}} that call {{coord}} and re-use the coordinates for other things (location map), but they require latitude and longitude to be entered separately. -- User:Docu

you can't do that the other way around. {{coord}} transcludes too much information for that. The only way i see is with the technique Docu describes. Or when we finally get a true geocode extension for Wikipedia. Now THAT would be great. --TheDJ (talk • contribs) 11:01, 10 March 2009 (UTC)[reply]

I've noticed that the pop-up map you used to get when you clicked on the lovely(!) blue globe seems to be broken. I just get a blank box now. Even though there were some design and quality issues with this feature, I think it's worth hanging on to. Anyone else seeing the same? 86.161.42.191 (talk) 02:51, 11 March 2009 (UTC).[reply]

It has been reported elsewhere, but I've not seen any response to it yet. T'other bug said it was dead in IE but working in Firefox ... and I can confirm the latter right now. --Tagishsimon (talk) 02:56, 11 March 2009 (UTC)[reply]

What does It has been reported elsewhere mean? Where? Sorry, but you cannot expect me to roam across the entire wiki to find bug-reports in odd places. Especially if there is a bugtracker for the WMA. Just go to meta:WikiMiniAtlas. --Dschwen 15:59, 11 March 2009 (UTC)[reply]

Works for me and looks good. A pop-up blocker or bad java version might be a user proplem but that just a guess. --droll [chat] 05:58, 11 March 2009 (UTC)[reply]

Doesn't work for me in IE. Does in Firefox. --Tagishsimon (talk) 06:17, 11 March 2009 (UTC)[reply]

Sorry, I didn't try it in IE as I only use Firefox. It's kink of buggy even in Firefox. I'd say its not ready for prime time yet. Probably should not have been rolled out. --droll [chat] 10:10, 11 March 2009 (UTC)[reply]

Why is nobody reporting that bug? The box will stay blank if there is a problem with the toolserver. I tested it in various browsers (IE, Firefox, Safari, Chrome, Opera, Konqueror) and it worked for me then. It does not use Java, just Javascript. What does "kind of buggy" mean? --Dschwen 12:35, 11 March 2009 (UTC)[reply]

I've tested two contemporary IE browsers on two different machines on two different network infrastructures, and IE fails in both. I get an error, Line 227, Char 1, Error:Object Expected, Code 0, http stable.toolserver.org/wma/iframe.html?55.41000_1.7054_600_400_en_4_en. YMMV --Tagishsimon (talk) 14:05, 11 March 2009 (UTC)[reply]

Ok, now we're talking! I'm looking into this right now. Must be a recent change. --Dschwen 14:53, 11 March 2009 (UTC)[reply]

Hmm, works in IE8. Which version are you using? --Dschwen 14:55, 11 March 2009 (UTC)[reply]

Ok, checked it in IE6 and indeed found a bug I introduced when adding several translations. Fixed. Works. --Dschwen 15:56, 11 March 2009 (UTC)[reply]

I came across a problem while testing a template I'm developing and I think it might be caused by this template. In two of the optional skins the coordinate field is corrupted. Please see Template:Coord/testcases for two examples and a further explanation. These examples use well tested templates. Thanks. --droll [chat] 00:00, 25 March 2009 (UTC)[reply]

Those two skins have never supported the "title" mode of coordinates. If you want to set the position for title coordinates in those skins, then you are welcome to propose a change. --TheDJ (talk • contribs) 00:34, 25 March 2009 (UTC)[reply]

See MediaWiki:Simple.css and MediaWiki:Myskin.css. These lack the definition for #coordinates{} which the other skins (see for instance MediaWiki:Monobook.css) do have. --TheDJ (talk • contribs) 00:38, 25 March 2009 (UTC)[reply]

Thanks. I might worry about it when I have some free time then. I was first afraid it was a bug in my new template. I guess its just and undocumented feature as we used to say. --droll [chat] 00:45, 25 March 2009 (UTC)[reply]

In 2006, WAS had prepared the necessary changes for some of the skins (e.g. MediaWiki_talk:Cologneblue.css). Apparently there are not enough maintainers for some of the other skins. --- User:Docu

Can I rely on the following strangely formed template to work in the future or is there a better way. Many templates ask for coordinate input to be entered explicitly rather than using this template directly, I'm trying to write a general case template that will fill in the data.

Template input looks like this:

{{My new template
| lat_deg = 22
| lat_dir = S
| lon_deg = 43
| lon_dir = W
| type    =
| scale   =
| region  =
| display = inline
| name    =
}}

It is easy to construct {{coord|22|S|43|W||display=inline|}} and it produces 22°S 43°W / 22°S 43°W / -22; -43. Will this create an entry in a hidden category.

Clearly {{coord|22|||S|43|||W||display=inline|}} does not work but it I can work around that. I'd be more than thankful if someone could help with this. If I start to be a pest let me know. I won't be offended.--droll [chat] 12:00, 25 March 2009 (UTC)[reply]

Seems fairly robust, the question largely would be "why is it useful?" i guess. --TheDJ (talk • contribs) 14:06, 25 March 2009 (UTC)[reply]

Template:Geobox coor has a workaround for the empty field problem. Please use the field names suggested at Wikipedia:GEO#Creating_new_templates instead of lat_deg, lat_dir, lon_deg, lon_dir.

BTW the consensus is that we won't create additional templates to {{coord}} if input is mainly limited to coordinates as in your new template. -- User:Docu

The new syntax, thanks to your suggestion, is:

{{User:Droll/sandbox
| lat_d   = 37
| lat_m   = 51
| lat_s   = 00
| lat_NS  = N
| long_d  = 119
| long_m  = 34
| long_s  = 04
| long_EW = W
| type    = landmark
| region  = US-CA
| scale   = 300000
| source  = GNIS
| display = inline
| format  = dms
| name    = Yosemite
}}

The defaults create {{coord|37|51|00|N|199|34|04|type:_region:_scale:_source|format=dms|display=inline}}. Currently coord does not complain about this. You can see a prototype of the template here and test cases at here but the contents of these pages will change as I move along to something else. Any further help will be appreciated. It handles the no minutes and no seconds cases. What does "the consensus is that we won't create additional templates" mean. --droll [chat] 00:50, 26 March 2009 (UTC)[reply]

It means that there should be reasons to create a NEW template that does things you cannot currently do with coord. My question above is not anwered "Why is this useful?" What does this template do that coord could not do? --TheDJ (talk • contribs) 02:52, 26 March 2009 (UTC)[reply]

I also created Template:Decdeg to simplify input to sub-templates like Template:Location map. Comments also appreciated about that one. --droll [chat] 00:58, 26 March 2009 (UTC)[reply]

I'm not trying to compete with coord. I think you misunderstood. Take a look at Template:Infobox Protected area/sandbox. I could have included the code in User:Droll/sandbox in Template:Infobox Protected area/sandbox but it is reusable in other geo related infoboxes such as Template:Infobox mountain if it is updated. I know you have worked with Template:Infobox mountain and you know how easy it is to make a mistake. Better the wheel does not have to be reinvented each time someone writes a new template. It's the same reason I wrote Template:Decdeg. Its a task that does not have to be repeated. C has a library of simple functions for the same reason. Nobody rewrites strlen every time they need to know the length of a string. I hope this clarifies my reasoning. If not you will ask your question in with more detail. Perhaps I'm missing something. --droll [chat] 04:04, 26 March 2009 (UTC)[reply]

I looked at Template:Geobox2 coor and Template:Geobox2 coor title and I guess I could have used those but it would not have been as general a solution in my opinion. --droll [chat] 04:13, 26 March 2009 (UTC)[reply]

After much discussion, we are currently using {{coord}} of the choices at WP:WikiProject_Geographical_coordinates/comparison. We can always move on or improve on {{coord}}, but in general, IMHO it's preferable to stick with coord for now.

If your new template is just meant to be one that is being used within infoboxes rather than in articles directly, I think it would be acceptable. It should be named accordingly though, e.g. "Infobox coor convert". Possibly, you might want to use commons:Template:coordinate to start with. As for Template:Geobox2 coor/Template:Geobox2 coor title and Template:Geobox coor, they could probably need some improvements. BTW, IMHO Infobox Mountain works fine now, but you will notice there always special cases and incomplete uses that are easier to "fix" in the template than in articles.

For your sample, I think population should be a separate field as well, especially if it's meant to be used in infoboxes. The solution at {{Infobox UK place}} seems to work reasonably well (see testcases2, view the html source to check). Switching between inline and inline,title should be easier than adding the entire string in every article. If coordinates are given in the infobox, they are almost always meant to be for inline,title. It's a bit different when multiple coordinates are given, e.g. as in geobox.

One could imagine simply adding named parameters to {{coord}}, after all, yours is mainly a "coord named" version. -- User:Docu

I wholeheartedly support named parameters. I think it might not eliminate the need for my proposed template but I'm going to have to think about that some more. As for the population parameter I put that one off for another day when I was working on it and then promptly forgot about it. I'll get back to it. --droll [chat] 22:30, 26 March 2009 (UTC)[reply]

I had time to think about the city population problem. The template simply passes on any value assinged to type so syntax coord uses can still be used. I will include a population field as it makes sense. After checking that the type is city the template will simply concatinate city( + population + ) and pass it on. --droll [chat] 05:12, 27 March 2009 (UTC)[reply]

The problem is that people put all sort of things in population fields and the field should use just two formats: digits only and digits with a commas. Even the check in the UK infobox isn't perfect as it passed on the value "3,500+ (2005)" on Cults, Aberdeenshire. -- User:Docu

In noticed something similar. I was hoping the function might be able to abstract the number out of cite(300,000). It returned city(300000) which is nice I guess but not what I was hoping for. Still there seems to be no hurry about string functions. I checked what's going on over there and they still can't figure out how they want to implement strlen. --droll [chat] 10:49, 27 March 2009 (UTC)[reply]

I'm not sure, but I wouldn't wait for them. -- User:Docu

As a heads up, there's discussion of whether a parametere dim: should replace scale: at Wikipedia talk:WikiProject Geographical coordinates#sk geo report. --Tagishsimon (talk) 19:20, 26 March 2009 (UTC)[reply]

Currently there is error trapping code in the template such as:

{{#ifeq:{{{region|XYZ}}}|XYZ||[[Category:Coord template needing repair|R{{PAGENAME}}]]}}

I think it might be interesting to consider one of the two following changes:

{{#if:{{NAMESPACE}}||{{#ifeq:{{{region|XYZ}}}|XYZ||[[Category:Coord template needing repair|R{{PAGENAME}}]]}}}}

This would trap only pages in the article space.

{{#ifeq:{{NAMESPACE}}|User||{{#ifeq:{{{region|XYZ}}}|XYZ||[[Category:Coord template needing repair|R{{PAGENAME}}]]}}}}

This would not trap errors in the user space. Just a thought. --droll [chat] 10:33, 27 March 2009 (UTC)[reply]

The main reason why {{coord}} doesn't check for namespace is that I wasn't sure how it might affect pages with hundreds of coordinates. If the template gets too complex the last instances stop working (sample: User:EncMstr/test1/coord). Looking at Category:Coord template needing repair, I don't think the couple of non-articles matter that much. --- User:Docu

The following code {{coord|37|48||N|113|55|29|W}}

currently produces an error: 37°48′N 113°55′29″W / 37.800°N 113.92472°W / 37.800; -113.92472Invalid arguments have been passed to the {{#coordinates:}} function

This is due to one of the conversion templates that produces the vcard coordinates in dec notation, is not checking wether or not a value that is used in the calculation is present at all. I think we should fix that, because as far as I know, we don't require equal granularity for coordinates do we ? --TheDJ (talk • contribs) 13:48, 27 March 2009 (UTC)[reply]

the issue is with dms2dec. {{coord/dms2dec|N|37|48|}}. The 4th param is not a valid input point for calculations, and thus fails. The options are to either make dms2dec and dm2dec more "safe" (i prefer this), or the templates that use it should always feed "valid" input. The last option, is we decide that this is not valid all together, and then we should add an error category test for it. --TheDJ (talk • contribs) 14:04, 27 March 2009 (UTC)[reply]

I might be mistaken, but I think it only happens since the last time we revised the template. Currently these errors can be found through Category:ParserFunction errors and once in a while I fix some of them.

Personally, I don't think {{coord|37|48||N|113|55|29|W}} should be a valid input. -- User:Docu

I propose adding {{#ifexpr:({{{2|yes}} = "yes") or ({{{3|yes}} = "yes") or ({{{6|yes}} = "yes") or ({{{7|yes}}} = "yes")|[[Category:Coord template needing repair|e{{PAGENAME}}]]|}} to {{coord/input/dms}}. I think that should detect this case. A similar check can be added for dm. What do you think ? (untested btw) --TheDJ (talk • contribs) 19:14, 28 March 2009 (UTC)[reply]

Let's test it and if it works, add it. Category:ParserFunction errors is a bit messy. -- User:Docu

The revised version of tools:~dispenser/view/File_viewer#log:coord-enwiki.log should catch this. With the error message in the article and that report, it should be sufficiently covered. -- User:Docu

I've come across several pages that use form {{coord|37|12.345|N|119|12.345|W|format=dms}} and the result is 37°12.345′N 119°12.345′W / 37.205750°N 119.205750°W / 37.205750; -119.205750. I don't think that is quite in the spirit of things. This is a popular format in the Geocaching community but I don't know how broadly it is used elsewhere.

Anyway I've been thinking about the problem with a page like User:EncMstr/test1/coord. It seems to me that page is a rare and special case and the aim should be to code for the general case. Another solution would be to have a stupid version of Coord that could be used on the few pages like EncMstr's page. It would do no format or error checking and maybe not even display the globe. It might have fewer parameters than the smart version. In the documentation for the stupid Coord it would state that the user is responsible for double checking there data and warn that it is not for general use. Seems like most errors could still be trapped down the road by something like Dispenser's tool. I'd like to try to code it if there is any agreement. --droll [chat] 04:46, 30 March 2009 (UTC)[reply]

Having the tool track it down is nice, but the editor who just geocoded the value really ought to receive some feedback too. Maybe they can check it on the spot.... —EncMstr (talk) 05:37, 30 March 2009 (UTC)[reply]

In my opinion the format used above is a valid format in the world outside Wiki. So I don't see it as invalid input. I think the template should test for the case and deal with it as it does with decimal degrees. Something like {{#if:{{{minutes|}}} | {{#ifexpr: ({{{minutes}}} > abs:{{{minutes}}) | seconds = {{#expr:( {{{minutes}}} - abs:{{{minutes}}} ) * 60 and deal with it | continue }}}}.

I personally like the wild idea of converting every thing to decimal degrees and then converting it to dms for display anytime dec is not requested. This would clean things up when editors enter seconds to the hundredth place which is valid but unsightly. Geohack works with that now and displays both dec and dms when dec format it fed to it. I really think we should standardize on one display format anyway. --droll [chat] 06:29, 30 March 2009 (UTC)[reply]

So I wrote a very simple version of Coord and tested EncMstr's page. The results were dramatic. Not only did the test page in my work space complete but for EncMstr's page using Coord:

NewPP limit report

Preprocessor node count: 233203/1000000

Post-expand include size: 2048000/2048000 bytes

Template argument size: 767240/2048000 bytes

Expensive parser function count: 0/500

and for a simple version of the tempate:

NewPP limit report

Preprocessor node count: 35522/1000000

Post-expand include size: 211936/2048000 bytes

Template argument size: 53280/2048000 bytes

Expensive parser function count: 0/500

That is very dramatic. So I'd say there should be heavy error checking in Coord and have a special version for special cases. --droll [chat] 05:39, 30 March 2009 (UTC)[reply]

Another advantage (or maybe disadvantage) is that no hcards are produced. On a page like the test page that might be a good thing especially since no name parameter is given and all those coordinates become associated with the page name which is meaningless.

A side effect of the simple version is that the external link icon is displayed. If I remember correctly there is a way of not displaying that but it might serve as an indicator that Coord was not used. For now the simple template can be found here and the test page here. --droll [chat] 06:00, 30 March 2009 (UTC)[reply]

I don't think anyone was expecting anything else. It's why we all really would like to see an actual geocoding extension that is usable in *.wikipedia.org --TheDJ (talk • contribs) 08:22, 30 March 2009 (UTC)[reply]

I've analyzed Wikipedia's HTML code for representing geographical coordinates. The current code is verbose and does not support the Geo microformat correctly. Three alternatives, differing on functionality and code size, are suggested as replacements.

--Howcome (talk) 21:34, 6 April 2009 (UTC)[reply]

test --Dschwen 00:27, 7 April 2009 (UTC)[reply]

59°56′N 10°41′E

Well, so much for using abbr. That solution came up a couple of months ago and was scrapped as the tag was (and still is) on the html blacklist. Otherwise, as usual, great work! --Dschwen 00:29, 7 April 2009 (UTC)[reply]

• abbr: Wikimedia setup issue, bugzilla:671
• &#xFEFF: Wikimedia setup issue with HTML Tidy, entity used as a workaround. Another zero-width space could possibly replace.
• Geo: implementations recognise the current markup, see Oslo with a geo conversion tool or the mentioned Operator in "hidden microformats" mode.
• URL title: MediaWiki issue, [http://link title] syntax uses link as title.
• CSS: Push to MediaWiki:Common.css, wait for max-age to expire, edit template. meh.
  • We recently looked at plainlinksneverexpand. Basically, we are all afraid to break stuff :D --TheDJ (talk • contribs) 02:09, 7 April 2009 (UTC)[reply]
• CSS generated content: Not supported for over half of readers.

These seem to be more of bugzilla/wikitech-l type of issues. Hopefully GSoC and the announced OSM integration produces an extension that would generate the html in php and not parserfunctions. --Para (talk) 01:08, 7 April 2009 (UTC)[reply]

Yeah i really hope that we will now soon see some better extensions to be used for geotagging and adding maps. The template, wikicode, parserfunctions and javascript, have reached their limits for the size that Wikipedia has become in my opinion. --TheDJ (talk • contribs) 02:19, 7 April 2009 (UTC)[reply]

Thanks for some great feedback. I have chosen to analyze what come out from Wikipedia's servers, not what goes on inside – technically or organizationally. It's good to see that people know where changes must be made, even if it's impossible to make the changes outright. Looking at the code, I also understand that people may be afraid to break stuff. Most "breaks" would be stylistic though, they wouldn't prevent people from getting the content. And, I do believe features like generated content can be added to enhance the experience without breaking anything. Be bold! (but don't use the <b> tag :-)

--Howcome (talk) 07:48, 7 April 2009 (UTC)[reply]

By "not supporting Geo correctly", you meant it was missing the fn org / hcard stuff, right? For fn, this template would have to require the contributor to name the location. There is nothing to place in fn, and there could be multiple locations mentioned on the page, so it is hazardous to assume the name of the page. Coord is useful as a geo emitting primitive for use by other templates. For example, consider the microformats emitted by USS Queen of the West (1854). Is that more like what you were expecting for "correct" Geo support? -J JMesserly (talk) 00:33, 8 April 2009 (UTC)[reply]

Incredible! We are close to perfection! -- User:Docu

Three, now, with only Gymnasium 9 (Simferopol), Hakha, and Whitefish River (Northwestern Ontario) left to go. -- The Anome (talk) 14:51, 7 April 2009 (UTC)[reply]

And now there are none left. Amazing. -- The Anome (talk) 09:38, 8 April 2009 (UTC)[reply]

I was looking at the most transcluded pages, and noted that there are 100000 more usages of {{Coor URL}} (on a total of 370000) then that there are of {{Coord}}. In that respect, it might be that there is a set of templates that really ought to be updated somewhat or at least evaluated if their reason for not using coord is a good reason. I think that list comes down to this. What do you guys think ? --TheDJ (talk • contribs) 14:43, 8 April 2009 (UTC)[reply]

There are 795 templates referencing Coor URL. Some of them are obviously higher use than others. The lowest hanging fruit to fix would be the highest usages. —EncMstr (talk) 18:41, 8 April 2009 (UTC)[reply]

Even if it uses {{coord}} it will use {{coor URL}}. Ideally everything but templates for the other planets would be using coord, but as we move towards using external links, this gets less important.

BTW there is still the direct links. -- User:Docu

If you got your numbers from Special:MostLinkedTemplates, it's likely that they changed quite a lot since Sept 2008. At least {{coor dms}} isn't used 77,000 times anymore. -- User:Docu

Just tried converting List of artificial objects on the Moon to use marked up {{coord|29.1|N|0|W|globe:Moon}} instead of bare coordinates (currently displayed as 29°06′N 0°00′E / 29.1°N -0°E / 29.1; -0). Is the "globe:XYZ" stuff supposed to work and, if not, what needs fixing (eg. to make it point correctly at moon.google.com)? —Sladen (talk) 13:01, 13 April 2009 (UTC)[reply]

As far as I know, support for other planets is not yet completed in wikiminiatlas nor in Geohack. --TheDJ (talk • contribs) 20:00, 13 April 2009 (UTC)[reply]

Excellent. So, next question; how can it be fixed to know about Luna? (I'm hoping that somebody already familiar with the Coord macro might bite, rather than me having to investigate from scratch). —Sladen (talk) 10:02, 16 April 2009 (UTC)[reply]

There's MoonHack for them. Template:Coord/link could be modified to react to globe:moon, but often these coordinate parameters come together with other parameters, and Wikipedia doesn't have string functions to use just one. Best solution is probably to have GeoHack redirect requests with globe:moon to the moon page. --Para (talk) 15:32, 16 April 2009 (UTC)[reply]

If either of those can be made to work in a way that agrees with the current globe:moon documentation that would be an ideal solution. Is it not possible to just grep for the string ".*global:moon.*" within the macro parameter (I thought Mediawiki template language was supposed to be Turing complete). ..and it it is not possible, who would need contacting to get GeoHack fixed externally? —Sladen (talk) 17:14, 16 April 2009 (UTC)[reply]

Turing complete means only that anything might be able to be done; it says nothing about how practical or useful such a solution might be, and that is definitely the case for templates. GeoHack was originally written by Magnus Manske, but—I think—has been maintained lately by Dispenser. —EncMstr (talk) 22:07, 16 April 2009 (UTC)[reply]

I've added support for globe: subpages into GeoHack with the layout update today. — Dispenser 19:57, 24 April 2009 (UTC)[reply]

Hello! Is it possible to somehow easy transfer coord template to another language Wikipedia? Or do I really need to copy coord template and all its countless subtemplate pages separately? By the way, this coord subtemplate system seems somewhat huge, clumsy mechanism if we look at the small output it generates for the user (a link to the appropriate Geo Hack website)… --Knakts (talk) 12:42, 18 April 2009 (UTC)[reply]

It also has conversion routines, microformat, and personal preferences for different views.. And you will have to copy all the subtemplates :( --TheDJ (talk • contribs) 13:29, 18 April 2009 (UTC)[reply]

It also has conversion routines, microformat, and personal preferences for different views - I hope that somebody is actually using all that… Anyway, it sounds unfamiliar and complicated to a simple user like me. :) Thank you for the answer though! I'll try to copy the templates sometime then. --Knakts (talk) 15:32, 18 April 2009 (UTC)[reply]

If you want to start with decimal coordinates only, you could initially just use {{coor title d}}.

BTW, in any case, you also need to make the changes to the various css for display, e.g. #coordinates on MediaWiki:Monobook.css. --- User:Docu

Thanks for the advice! Do I copy the "tl" template and rename it to "coord" or should I use "tl" with this name? It simply doesn't sound very clear what it is for. :) --Knakts (talk) 09:50, 19 April 2009 (UTC)[reply]

Why is it "region:US-WI_type:landmark" instead of "region=US-WI|type=landmark" like other templates? --Apoc2400 (talk) 19:09, 19 April 2009 (UTC)[reply]

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

Q: How do I mark up coordinates if they appear within a quote in a format that doesn't match what this template outputs?

I want to mark up coordinates that appear within a quotation. The format of the coordinates in the quotation is "lat. 31°59'S, long. 117°30'E". This template doesn't use that format, and it wouldn't be proper for me to change the format inside a quote. Any ideas? Hesperian 14:02, 24 April 2009 (UTC)[reply]

This template can output 31°59′S 117°30′E / 31.983°S 117.500°E / -31.983; 117.500, which is close to your format. Unless the quote is about the format of the coordinates, you should be able to insert it with square brackets, e.g. "asdf asdf [ 31°59′S 117°30′E / 31.983°S 117.500°E / -31.983; 117.500 ] asdfasdf asdf ". If the coordinates in the quote don't use the WGS84 datum, the {{coord}} shouldn't be used though. To avoid any accidents, it's worth wrapping it in nowiki tags, as e.g. on Cape Howe. -- User:Docu

Thanks; I found further information that obviated the need for a quote. Regarding datums, in Australia we generally use GDA94 these days, which is within a metre or so of WGS. At the time of the quotation we would have been using AGD66, which is about 200 metres off WGS, which I think would have been acceptable given that I'm only giving precision to the minute. Hesperian 15:01, 24 April 2009 (UTC)[reply]