Template talk:Coord/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

Categorising faulty co-ordinates

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)

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)

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)

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)

Globe Icon

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)

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

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).

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)

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

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

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).

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)

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

[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)

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)

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)

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)

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)

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).

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)

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)

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).

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)

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

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)

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 with an inline icon or without icon contain the coordinates in wikitext already, they are just shown later on, like with references. Here:

• Coordinates section somewhere near the end of the article

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)

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)

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)

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)

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)

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)

Span title

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. 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)

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)

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)

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)

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)

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)

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)

Minor fix - {{{10}}}

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)

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)

The decimal output for the microformat doesn't ouput negative for all pages

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)

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

Coordinates for rivers?

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)

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

Southern Latitudes in Google Maps

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)

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)

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

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)

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)

Special:Book/pdf version : coordinates rendering

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)

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)

(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)

(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)

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

Magic words

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)

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)

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)

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)

Pop-up map broken

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).

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)

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)

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)

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

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)

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)

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)

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

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

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)

Strange display problem

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)

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)

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)

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)

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

Feature question

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. 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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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

Dim to replace Scale:?

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)

Thinking about errors

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)

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

coord usage error.

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

currently produces an error:

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)

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)

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)

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

Minutes with a decimal part

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. 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)

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)

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)

A stupid version of Coord

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)

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)

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 *.wiki.x.io --TheDJ (talk • contribs) 08:22, 30 March 2009 (UTC)

A proposal to simplify and improve geo markup in Wikipedia

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)

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

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)

• 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)
• 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)

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)

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)

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)

Category:Coord template needing repair down to 5 articles!

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)

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

Coor URL

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)

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)

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

Transfer coord template to another language

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)

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)

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)

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)

Why the strange syntax?

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)

Format of coordinates in quote

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)

This template can output 31°59′S 117°30′E, 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 ] 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)

Superfluous space

I noticed that if I put a punctuation mark after this template the result looks ugly because of space before the mark, like this: 50°5′17″N 14°24′12″E. I think the reason for this is in the {{Coord/link}} template. The part "<span class="geo-multi-punct"> / </span>" shouldn't do anything because that class has style set to display: none, but wikipedia somehow translates it into " <span class="geo-multi-punct">/</span> " (note the spaces before <span> and after </span>) in HTML, so the spaces are visible.

I know this is a very minor issue, but I don't know how can this be fixed, so can somebody help? Svick (talk) 14:10, 8 May 2009 (UTC)

Hmm, well noticed. I think it is HTMLtidy assuming that >/< is an error from the user in specifying the closing tag. Perhaps we should use / instead. —TheDJ (talk • contribs) 14:30, 8 May 2009 (UTC)

This is a HTML Tidy problem indeed, where Tidy doesn't want to start or end elements with spaces. It has been fixed a number of times with a dummy character, which however is a rather obscure solution and is easily forgotten in subsequent changes to the template, so you're seeing it again. The xfeffs could be added back, but their use was criticised not long ago; maybe there's an other character we could use to keep Tidy from shuffling spaces around? --Para (talk) 14:38, 8 May 2009 (UTC)

In this case we could either convert them to nbsp or, we can just remove them all together I guess. —TheDJ (talk • contribs) 14:51, 8 May 2009 (UTC)

The tiny group of people who browse without CSS or have added non-default rules might not like inline coordinates wrapped on lines from all the wrong places, or the "50°5′17″N 14°24′12″E / 50.08806°N 14.40333°E / 50.08806; 14.40333" above changing into "50°5′17″N 14°24′12″E/50.08806°N 14.40333°E/50.08806; 14.40333". --Para (talk) 08:41, 9 May 2009 (UTC)

This tiny group is now out of luck. They can present a solution and it will be implemented :D —TheDJ (talk • contribs) 11:05, 15 May 2009 (UTC)

This extra space problem is still with us. I would like to encourage the folks who understand this template to get it fixed as soon as possible. It is very noticeable in all the articles where the coordinates are included in the text of the article. I hope this can be resolved. --droll [chat] 08:14, 9 May 2009 (UTC)

 Done I used a HTML escaped unicode space character. Apparently HTMLtidy doesn't understand any type of Unicode HTML escaping. When they ever solved that, the problem might return btw. —TheDJ (talk • contribs) 11:56, 9 May 2009 (UTC)

Nice work. I got up this morning. The sun was out and there was no extra space. Life is good. Thanks. --droll [chat] 15:20, 9 May 2009 (UTC)

Thanks. Svick (talk) 22:58, 9 May 2009 (UTC)

 Undone. Turns out tidy does recognize space written as an entity, it's just that it was written incorrectly; "&#20;" isn't space, " " or " " are, so the broken entities were written into the display:none spans. If they are written correctly, tidy recognizes them and pulls them out of the spans, so I've undone the change. I can't really offer an alternative though. :\ Amalthea 10:32, 15 May 2009 (UTC)

Same problem at Template talk:Sort#Superfluous space, if we find a way to trick tidy here the fix should be aplied there, too. Amalthea 10:35, 15 May 2009 (UTC)

As an alternative to removing the space completely, we can use an   (] [),   (] [), or a   (] [). All are breaking spaces, and really aren't recognized by Tidy. I'd suggest using an   both here and at Template:sort, unless anyone knows of display issues with them. Amalthea 11:23, 15 May 2009 (UTC)

Some of those are also not recognized on IE5.5/6.0 —TheDJ (talk • contribs) 11:48, 15 May 2009 (UTC)

Damn you, IE!!1! But that was actually what I was afraid of whith using  (][), too, I had hoped that a named entity would have better support. Is FEFF displayed properly (=not) in old IEs? If so, then how about a proper breaking zero-width space, ​ (]​[)? Amalthea 12:27, 15 May 2009 (UTC)

Guess not. I should have read the whole talk page here before adding my 2¢. Amalthea 12:33, 15 May 2009 (UTC)

Is there a way to do this without  ? If people re-use the coordinates, it's likely to create problems elsewhere (templates don't process them). -- User:Docu

• Yes, we remove the spaces all together. —TheDJ (talk • contribs) 09:37, 18 May 2009 (UTC)
• (ec) Hmm, you mean reuse through copy&paste which might copy the invisible character? If no special whitespace characters can be used, I could only find a way to stop the space bleeding at the beginning, but not at the end:
  "X<span><i/> foo <i/></span>X" → "X<i/> foo <i/>X" (the underlined part is the span).
  The proper way of course would be to get HTMLTidy to stop doing that in the first place. This really is a bug. Amalthea 09:41, 18 May 2009 (UTC)

• If removing spaces affects only the few users that see both formats of coordinates, I wouldn't mind. -- User:Docu 09:30, 20 May 2009 (UTC)

Moon

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.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)

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)

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)

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)

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)

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)

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

Please see my proposal for coordinates for lunar, Martian and other non-terrestrial coordinates - this proposal is already implemented in Swignition. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:31, 25 May 2009 (UTC)

What source should I use if I find coords with Google Maps or Google Earth?

What source, if any, should I use if I find coords with Google Maps or Google Earth? Jason Quinn (talk) 16:23, 10 June 2009 (UTC)

Give google maps or google earth as the source: {{coord|12.345|-67.89|type:landmark_source:googlemaps}}... or {{coord|12.345|-67.89|type:landmark_source:googleearth}}.... —EncMstr (talk) 16:32, 10 June 2009 (UTC)

Great. Thanks. I've used that before. I think the sources description on the template page should be mention these explicitly. In fact, the whole sources section is potentially confusing. It doesn't really let the reader know if the sources can be free form or if there are a set set of tags that can be used. The WGS 84 example also had me thinking the source tag was for a more technical use than merely just giving your reference. Jason Quinn (talk) 18:04, 10 June 2009 (UTC)

Globe graphic in template

Per this FAC discussion, some editors, including myself, are finding that the globe graphic that appears in the coord template is distracting, especially in articles, such as the Battle of the Coral Sea, where the template is used frequently throughout the text. Also, the graphic, in large numbers, appears to slow the loading of the article. Is there an alternative, such as removing the graphic? Cla68 (talk) 06:00, 12 June 2009 (UTC)

I'd agree too that it can be distracting and it certainly is in the example you gave. The best solution is to update the template to allow a way to turn off the globe. I'm not good enough with templates to be able to do it though. Jason Quinn (talk) 13:51, 12 June 2009 (UTC)

I feel silly now. I never noticed before that clicking on the globe is different than clicking on the coordinates. I've always clicked on just the coordinates. Ignore me. Jason Quinn (talk) 13:53, 12 June 2009 (UTC)

Having a "|[something]=no" switch is worth considering. (I was going to say "globe", but that already means something else.)

—WWoods (talk) 15:24, 12 June 2009 (UTC)

| icon=no? —EncMstr (talk) 16:04, 12 June 2009 (UTC)

WikiMiniAtlas adds those blue icon to GeoHack links. I told Dschwen to add a downward arrow (▼) so it's obvious that it opens a window and not just decorative. You can disable it for inline links by adding var wma_settings = {onlyTitle:true}; to your monobook.js. — Dispenser 18:35, 13 June 2009 (UTC)

Okay, but what about disabling it for the common random reader so that prose is readable? I'm in favor of Wwood's solution above. —Ed (Talk • Contribs) 02:25, 17 June 2009 (UTC)

Well you would need to talk to User:Dschwen get the code for WikiMiniAtlas changed, so when it detects a CSS class or something. It would also mean disabling the feature for those who actually want it. But I don't think that is productive, instead the attention should be to focus on how to improve icon/interface. Currently the icon is a little large and as said before it is often mistaken for decoration similar to the external links icon. Alternative possibilities is to eliminate the text when displaying the icon in article bodies or reduce the size of the icon to about 12px. Another idea is to only display the icon, like maybe display=icon or something. And there might be an issue with the upcoming OSM integration. — Dispenser 18:11, 18 June 2009 (UTC)

Strange behaviour in Mont Blanc

Does anyone know what happened to the coordinates in the article Mont Blanc? They are given as

{{coord|45|50|1|N|6|51|54|E|type:mountain_region:IT|display=inline,title}},

which seems correct, but is translated by the template to 45°1′1″N 6°51′54″E.

This makes Mont Blanc appear way too much south, both in the infobox and also in Google Maps. -- Momotaro (talk) 12:59, 14 June 2009 (UTC)

Not the coordinate template. Enter CambridgeBayWeather, waits for audience applause, not a sausage 15:40, 14 June 2009 (UTC)

Ah, thanks, I did not see that! So – is the coordinate template just there so it can be parsed by Google Earth and similar programs? I just manipulated it a bit (in preview, of course), but there was no visible change in the article. -- Momotaro (talk) 23:21, 14 June 2009 (UTC)

You are right. Changing or removing the {{coord|45|50|1|N|6|51|54|E|type:mountain_region:IT|display=inline,title}} makes no difference at all. I tried using _scale:50000 but it still gave me the mountain scale. You might try asking at Template:Infobox Mountain. Enter CambridgeBayWeather, waits for audience applause, not a sausage 10:16, 16 June 2009 (UTC)

I just did that. -- Momotaro (talk) 14:43, 18 June 2009 (UTC)

New undesired behavior

I noticed today that this template is outputting the coordinates in the middle of the horizontal line underscoring the title of the article - instead of being above the article. This is happening with Chrome - and was not happening last week - though I'm not sure of the exact day when the behavior changed. --Trödel 05:54, 16 June 2009 (UTC)

It is probably the new version of chrome, not a new version of the template that make it happen. I have the latest version of chrome( which can remove thumbnails on the new tab page) and it does the same thing as you describe. --Stefan ^talk 06:03, 16 June 2009 (UTC)

It's not just Chrome. The same thing happens with FF and in IE the coordinates appear below the line. Enter CambridgeBayWeather, waits for audience applause, not a sausage 10:16, 16 June 2009 (UTC)

It broke with the revision upgrade they did yesterday. A CSS fix has been applied. — Dispenser 12:44, 16 June 2009 (UTC)

This fix does not fix the problem for me in Chrome 3.0.189 --Trödel 22:11, 18 June 2009 (UTC)

Nevermind - I must have had a cached version of the page I was looking at because a different page worked fine, and a refresh of my original page fixed the problem. --Trödel 22:15, 18 June 2009 (UTC)

Toolserver down

Coord is down. That is, if you click 10.2°N 20.3°W / 10.2; -20.3, or the upper right corner coordinate link of pages like Athens, the page is not found. Happens on both Microsoft Explorer and Flock (browser). Art LaPella (talk) 23:34, 2 July 2009 (UTC)

And Firefox 3.5. This is presumably related to the MediaWiki update that was rolled out yesterday. Hesperian 00:30, 3 July 2009 (UTC)

I suspect it was today's power outage at the European data center that did it. --Carnildo (talk) 03:25, 3 July 2009 (UTC)

That would take down many of the toolservers, which host services like these. Sounds like a reasonable explanation. —TheDJ (talk • contribs) 18:53, 3 July 2009 (UTC)

I take that none of you are on the mailing lists or in the IRC channel. Also, the stable server that GeoHack runs on has change, but you shouldn't notice any difference. — Dispenser 19:23, 3 July 2009 (UTC)

Having problems today (2009-08-25) 'The connection was refused when attempting to contact stable.toolserver.org.' --Brunnian (talk) 06:24, 25 August 2009 (UTC)

Precision Question

I note than in many cases this template is used in its degree minute second (dms) form rather than either decimal degrees or degrees and decimal minutes. A second of latitude (and of longitude at the equator) is approximately 31 meters or 100 feet. In an urban setting that will often not be precise enough to specify which of several buildings is of interest. Since a degree of latitude is about 111,120 meters, four places of decimal degrees is enough to specify position to 11 meters, while five places will often be more precise than the accuracy of the underlying data.

Is it possible to generally encourage the use of decimal degrees? If so, what is the procedure? Or is this a fool's errand? Jameslwoodward (talk) 12:49, 25 July 2009 (UTC)

It's a fool's errand, not least since many of us, used to a lifetime of DMS, cannot bear decimal coordinates. The solution is to have decimal seconds in a DMS coord. There is not any good excuse for missing the target when specifying a coordinate, either under decimal or DMS formats. --Tagishsimon (talk) 20:10, 25 July 2009 (UTC)

I am used to seeing coords as XX° XX.XXX (N|S), XX° XX.XXX (E|W), but the template does not seem to support this format. This discussion seemed related to my inquiry. Is there a reason the template does not support this format? --Bsay@CSU[ π ] 02:13, 11 August 2009 (UTC)

If I understand your meaning, is this not what you want: 12°34.567′N 10°24.876′W. If, however, you want the template to dispense with pipes, you are out of luck. --Tagishsimon (talk) 20:15, 12 August 2009 (UTC)

Appearance of line wrapped coordinates

Mount Whitney
Highest point
Elevation	14,505 feet (4,421 m)
Coordinates	36°34′42.89″N 118°17′31.18″W

Mount Whitney
Highest point
Elevation	14,505 feet (4,421 m)
Coordinates	36.5785806°N 118.2919944°W

I have always had a problem with how line wrapped coordinates appear in infoboxes. I just looks typographically clumsy. I'd like it to look like in this example but I have no idea how it could be done. –droll [chat] 18:38, 24 August 2009 (UTC)

I tried using a table cell but that ended in disaster. –droll [chat] 18:51, 24 August 2009 (UTC)

I don't see a difference. Can you specify your browser ? —TheDJ (talk • contribs) 19:00, 24 August 2009 (UTC)

Mount Whitney
Elevation	14,505 feet (4,421 m)
Coordinates	36°34′42.89″N 118°17′31.18″W

I think he meant compared to how it looks using this template – see the third example (I substed the template and narrowed it so that it would wrap for me). Note that latitude and longitude aren't aligned. Svick (talk) 19:47, 24 August 2009 (UTC)

There is no way that I can think of that we can do this reliably. I have made some small changes to the CSS, that will do this, but we can't implement that globally, every single infobox will have to have this code separately, and I'm not sure how well this works on older browsers and for people who have Javascript disabled. —TheDJ (talk • contribs) 21:17, 24 August 2009 (UTC)

And for clarity, this is why it wouldn't work globally, 36°34′42.89″N 118°17′31.18″W because this property only really works when coord is at the beginning of a paragraph, and not when it is inline like it is here. —TheDJ (talk • contribs) 21:22, 24 August 2009 (UTC)

perhaps if we add a class to the primary span, so that it becomes "coord plainlinks nourlexpansion", then the following might work: table.infobox td span.coord { padding-left:2.2em;text-indent:-20px; }. I'm not so sure how many people would welcome this however. —TheDJ (talk • contribs) 21:29, 24 August 2009 (UTC)

Why not turn this on by a parameter? Svick (talk) 21:34, 24 August 2009 (UTC)

Oops

"You have chosen to download geohack.php, which is a PHP file." Have you checked your server today? -- SEWilco (talk) 00:34, 1 September 2009 (UTC)

Dim documentation

Just as a reminder, the dim: parameter needs to be explained in the documentation. thanks --Tagishsimon (talk) 15:46, 2 September 2009 (UTC)

I've done a first pass. --Tagishsimon (talk) 16:25, 2 September 2009 (UTC)

Problem with * in article heading

The template breaks if the article heading begins with an *. Eg. *scape Youth Space. Is anyone able to fix this? - oahiyeel ^talk 07:54, 11 September 2009 (UTC)

The problem lies in {{Coor URL}}. It seems that whenever variable value begins with *, it is treated as a list item (like the * would be on a beginning of a line). I don't know how to fix this. Svick (talk) 09:48, 11 September 2009 (UTC)

It is caused by bugzilla:12974, which doesn't seem to be fixed anytime soon. Svick (talk) 12:09, 11 September 2009 (UTC)

Until a solution is found, I've moved the article to Scape Youth Space. It may be that the asterisk breaks other things, too. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:07, 11 September 2009 (UTC)

Undefined parameters

I discovered that {{Coord}} doesn't take undefined parameters. Meaning that something like {{Coord|34||N|55||E}} will return an error (two actually).

34°N 55°E

Can something be done to change this? I may add that this would be an important and possibly necessary improvement if we ever want to call the Coord template with variables (which is where I am coming from). Debresser (talk) 12:58, 14 October 2009 (UTC)

I agree that this ought to be fixed. Probably needs an admin however. --Stepheng3 (talk) 19:03, 14 October 2009 (UTC)

That is for sure. The problem is that we need somebody who knows how to do that. And such admins are rare, and are likely already watching this page. I think the editprotected request is more for when you have the solution, but need an admin to implement it because the page is protected. Debresser (talk) 19:07, 14 October 2009 (UTC)

How about writing the coordinate as {{coord|34|N|55|E}} which gives 34°N 55°E? —EncMstr (talk) 19:15, 14 October 2009 (UTC)

With all due respect, but you answer a question by saying "don't do that". As I mentioned above, what if somebody were to do just that? Because he wanted to add the minutes later, after recalculating them? Or, again as above, because it is another page calling a coord function? Debresser (talk) 19:28, 14 October 2009 (UTC)

I'm an admin watching the page but freely admit I don't know how to fix it. Orderinchaos 19:37, 14 October 2009 (UTC)

I don't know if it's possible to make the template work with unnamed empty parameters, as its d/dm/dms detection is based on the number of unnamed parameters given, and the precision of the conversion depends on that as well I think. How about choosing the call depending on the data available? Ie. if lat_s then coord|d|m|s|NS|d|m|s|EW else if lat_m then coord|d|m|NS|d|m|EW else coord|d|NS|d|EW. --Para (talk) 19:58, 14 October 2009 (UTC)

I don't know much about template programming, but I assumed there would be an easy/obvious way to filter out empty parameters before passing them to the next template. For simplicity, perhaps {{Coord}} could do the filtering and the current {{Coord}} functionality could be moved to a new template with a different name. --Stepheng3 (talk) 20:22, 14 October 2009 (UTC)

I think Para is onto something. And perhaps that something can be build into Coord more or less like Stepheng3 suggests. I am not familiar with this template, but having just worked on the Tfd and Citation/core families I am reluctant to take on a new project. Debresser (talk) 21:06, 14 October 2009 (UTC)

I've done some more looking into this. While the filter template I suggested is possible, the limit on template recursion means that a 9-parameter filter must handle 512 cases -- awkward to say the least! A partial fix would be to modify {{Coord/input/dms}} so that the 2nd, 3rd, 6th, and 7th parameters default to 0 instead of "" and to modify {{Coord/input/dm}} so that the 2nd and 5th paramters default to 0 instead of "". That should handle the issues described by Debresser. --Stepheng3 (talk) 22:25, 14 October 2009 (UTC)

That could easily be tested, Stepheng3. Debresser (talk) 23:10, 14 October 2009 (UTC)

I have made the above changes in Template:Coord/input/dm/sandbox and Template:Coord/input/dms/sandbox with the editsummary "Following suggestion by Stepheng3". Now somebody should set up the test. I just don't know which templates are used, so I can't do more than this. Debresser (talk) 23:22, 14 October 2009 (UTC)

I got my changes working in the sandbox. I also added some new cases to Template:Coord/testcases and got them working with the sandbox templates. Since I'm so inexperienced with templates, I'd appreciate it if someone would review my work. Once that's done, I think all that's needed is for someone with admin powers to transfer the contents of Template:Coord/input/dm/sandbox and Template:Coord/input/dms/sandbox to the live templates. --Stepheng3 (talk) 01:52, 15 October 2009 (UTC)

The extra cases on Template:Coord/testcases are 2c and 3e. Debresser (talk) 01:57, 15 October 2009 (UTC)

Looks good. I'm activating the editprotected request again. Debresser (talk) 01:58, 15 October 2009 (UTC)

I had a testcase between my User:Debresser/Sandbox and User:Debresser/Testcases, and with {{Coord/sandbox}} they work. The test involves making a template that delivers geographical parameters to Coord. Caveat: I still need to have the parameters, but I am allowed to leave them undefined. Having a look at User:Debresser/Testcases will show you how great this improvement is. Debresser (talk) 02:59, 15 October 2009 (UTC)

I've copied in the dm/sandbox (01:28 UTC) and dms/sandbox (01:38 UTC) to the live templates. If there's any problems or additional changes needed, make them there and test them and I can do the same again. Orderinchaos 04:24, 15 October 2009 (UTC)

My tool log produce "Zero assumed" warnings if there a blank in the coordinate. If the issue is with mathematical expression you could try something like 0{{{2|}}} which I don't think will cause any issues. — Dispenser 04:18, 15 October 2009 (UTC)

So what is it you want to say? That you too have a problem, or that the solutions breaks your tool? Debresser (talk) 04:22, 15 October 2009 (UTC)

I think Dispenser means putting a 0 in front of the number so if it is null it will return "0", if say 45 is input it will say "045" etc. Orderinchaos 04:27, 15 October 2009 (UTC)

And why would anybody want to write 045 degrees? That's not done. Strange. Debresser (talk) 04:41, 15 October 2009 (UTC)

I don't know how it works but if it's pure numeric output the "0" would be lost. My initial testing suggests it wouldn't be. (Of course, I may have misunderstood the proposal.) Orderinchaos 05:07, 15 October 2009 (UTC)

Really does be everything need to explained down to the smallest detail? The calculation are failing because the expression is empty. A nice little hack around that can be to simply prefix the parameter with zero like so {{#expr:0{{{2|}}} }}. Of course the solution implemented is probably the worse as it break the meaning of an empty minutes or seconds being (that we don't know the value) and instead it will tell every tool we know the value to be (very precisely) zero.

Now, looking at the original request (a programmer that's lazy) wants the template to automatically switch between D, DM, DMS based on the values given. This could be done by adding to the branch logic, if we should is another question. — Dispenser 05:42, 15 October 2009 (UTC)

I've created new sandbox versions of the input functions that I hope will meet everyone's requirements:

1. blank fields do not appear to imply greater precision,
2. no change to the branch logic, and
3. uses Dispenser's clever hack to convert blank fields to "0" for numeric calculations.

Everyone please take another look. --Stepheng3 (talk) 09:32, 15 October 2009 (UTC)

Seems to work for me, I trialled it with several sets of coordinates. I'm happy to update the live template when necessary (this page is on my watchlist and I'll be around for another few hours yet). Orderinchaos 10:36, 15 October 2009 (UTC)

I saw you made the change when suddenly both cases on my testcases userpage were working. It works even better than expected, because not only empty but even completely undefined coordinate parameters are accepted as well. I'd recommend everbody here to have a look at my sandbox and its testcases to see how {{Coord}} can be called with variables. Thank you for this improvement. Debresser (talk) 13:33, 15 October 2009 (UTC)

No worries, although my only role in it was to activate the change (cut and paste from sandbox to live). I wish I *could* program that good :) Orderinchaos 14:00, 15 October 2009 (UTC)