Misplaced Pages

Revision as of 21:36, 5 January 2009

Template:Coord is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit protected}} to notify an administrator to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories. Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

	Geographical coordinates
Coord is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Misplaced Pages. 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

To help centralize discussions and keep related topics together, ] redirects here.

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

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

Removal of hCard microformat

An apparently undocumented feature of this template is that, if the name parameter is set, an hCard microformat is emitted. This causes problems in several ways:

• It can conflict with the use of the template inside other templates/ tables, such as infoboxes, which are themselves designed to emit an hCard. In such cases, redundant, and incomplete, second hCards are often generated.
• It precludes the use of additional hCard fields such as address properties, dates, etc.
• The name is hidden by CSS in the output HTML. Some microformat parsers, including the most popular, Operator, by default, ignore hidden content.
• Even where the coordinates relate to a person (such as those of a burial place) an HTML class of "org" is included; this flags the coordinates as belonging not to a person, but to an organisation or venue.

I propose that this be resolved by removing the mark-up <span class="vcard"> and <span class="fn org"> from the child-template {{Coord/link}}; along with their two paired closing tags. These classes are used only by the microformat; and are not styled in any Misplaced Pages skin. The name parameter would remain, still hidden, for use by other services. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:51, 18 September 2008 (UTC)

Removing the spans would break the structure by taking away the markup for the name. To retain the microformat functionality, used by a tool in {{GeoGroupTemplate}} for example, the associated HTML would then have to be written to articles directly, obfuscating the wikitext and making articles harder to edit. These issues were discussed thoroughly before, please see Archive 4#Moving microformat markup from articles to coord. --Para (talk) 22:05, 18 September 2008 (UTC)

What do you mean by "break the structure by taking away the mark-up for the name"? {{GeoGroupTemplate}} doesn't require an hCard "fn"; but will use the proper, parent hCard name where one is provided. Nothing in the earlier discussion resolves the points I list above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:09, 18 September 2008 (UTC)

Most coordinates on Misplaced Pages with a name parameter do not have surrounding classes or names in prose and removing the elements would therefore break compatibility with the microformat tools in the majority of cases. The widely supported modification a year ago did exactly the opposite of your proposal by clearing articles of markup that doesn't belong on article level. All issues except perhaps for the last one were discussed, resulting for example to the mention of infoboxes in the documentation of the template. On the last point: people don't have fixed coordinates; coordinates for a burial site are for the location of the grave. Inclusion of such detailed information in Misplaced Pages is questionable anyway. --Para (talk) 22:58, 18 September 2008 (UTC)

Unless you can cite evidence of such a case, I think your claim that "removing the elements would therefore break compatibility with the microformat tools in the majority of cases" is false; removing the classes from Coord would still leave it rendering a Geo microformat (which is what it was created to so in the first place), and the relevant tools are made to work with that. The changes of a year ago did a deal of damage; for instance here; where "label" (unformatted address) and "note" properties were removed from the hCard microformat; perhaps you could tell us how they can be replaced? The issues may have been discussed, but the problems were not resolved. Coordinates for the graves of dead people are labelled with the name of; and are part of the hCard of; the dead person, not of the grave, just as are the hCard's date of birth property, and such hCards do not use "fn org". The vCard specification, on which hCard is based, has a coordinates property explicitly for the coordinates of an individual. As an aside, it is odd to see you arguing so vociferously for the retention of a microformat, when you argue elsewhere, at the same time, that microformats should not be used on Misplaced Pages. There is already consensus for the inclusion of such information. As O have already said to you elsewhere today: If you wish to pursue a case against the use of microformats per se, then please do so in the appropriate forum; not here. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:30, 18 September 2008 (UTC)

Simple: just look at the HTML with Special:ExpandTemplates for example. If the spans are removed, the structure will end up broken and the information without markup. The last available database dump from July 2008 contains 88500 direct uses of coord|...|name=. Significant issues with their use have not been reported. --Para (talk) 18:30, 19 September 2008 (UTC)

It's not "simple" at all. Merely asserting that "...the structure will end up broken" tells us nothing more than did your previous unqualified assertion. How will it be broken? Will it be invalid? Not render correctly? What? Likewise, what information will be "without markup", and why will that matter? What do those spans do, other than carrying the HTML class names used only by the microformat?

I have reported significant issues with the use of the name parameter in Coord, above and predicted them - correctly - elsewhere, previously. For example,. you use of it on List of Gaudí Buildings means that the first table entry says, nonsensically, to readers with CSS disabled or unavailable that the coordinates of Bellesguard's Tower are "41°24′34″N 2°07′37″E / 41.40944, 2.12694 (Bellesguard's Tower)"; it does not degrade gracefully, as is good practice.

Despite this, I have not asked here for the name parameter to be removed, only for the hCard classes and their containing spans. If the spans are important, for some reason that escapes me, then just the classes can be removed, or renamed, leaving the (empty) spans in situ. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:43, 19 September 2008 (UTC)

I'm sorry, I should have been more clear, we can't expect everyone to be aware of what microformats are. When this template is used with the name parameter, the HTML ends up with span elements and some very specific class names, linking the coordinates to a descriptive name. Some tools in turn recognise these class names and can use the information as labels on a map. If either the encapsulating elements or the class names are removed, the given names will no longer be associated with the coordinates in the microformat, and the tools that used the microformat cannot find the information, as the only thing they look for are the elements with those very specific class names. I've understood microformats are quite popular indeed with coordinates, and many Misplaced Pages articles with inline coordinates link directly to a tool that depends on the markup this template creates with the name parameter. It would be a shame to make the descriptive information unavailable to the users of those tools, or to have to start writing the HTML this template creates into article wikitext instead. I hope this helps. --Para (talk) 00:35, 20 September 2008 (UTC)

So, to be clear, you're referring to the use of those spans/ classes in an hCard microformat only, and for no other purpose? If so, my earlier points apply: the use of a hidden name property in this way, in a microformat is broken, and causes the problems already identified. The spans/ classes should be removed as requested, in order that an hCard "fn" or "fn org" property can be applied to visible data, in a valid and appropriate manner. Your reference to direct links to "a tool that depends on the markup this template creates" seems to be a red herring, as that tool (GeoHack) does not use the spans/ classes to which this request applies. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:38, 20 September 2008 (UTC)

As far as I know, the additional HTML is there for microformat purposes only and is used by many microformat readers, including the Suda tool. They might even be the reason our users have used the parameter tens of thousands of times. The hiddenness of information visible though not directly adjacent to coordinates has been discussed already among your other concerns. The rest of this discussion can be found from the talk archives of this and another template. Please refer to them to find why your concerns aren't met with actions. The best part was perhaps "I've still seen no citation for any *prohibition* of hidden data in microformats". By adding the new parameter with its microformat functionality to this template after an RfC, the community agreed. Give it a rest, please. --Para (talk) 23:36, 20 September 2008 (UTC)

Nothing in what you write addresses the problems I have listed. The "Suda tool" and every other microformat reader will work equally well with Geo microformats with no name parameter; or where the name's class is applied to visible data as part of a more widely-scoped hCard microformat. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:43, 20 September 2008 (UTC)

Formatting preferences

I see this has been noted above, but has been unanswered so far.

If you use a decimal number for the coordinates then the "N", "S", "E" and "W" signs are ignored and the degree symbol is not displayed. Thus, {{coord|43.12|N|79.34|W}} displays as 43°07′N 79°20′W / 43.12°N 79.34°W / 43.12; -79.34. Is this intentional? I want and expect it to display as 43°07′N 79°20′W / 43.12°N 79.34°W / 43.12; -79.34 like the old template did, and I'm guessing that most other people would think likewise...

TIA, 86.134.43.109 (talk) 19:53, 12 November 2008 (UTC).

I also second the complaint about improperly switching away from the input format. Can that be fixed? Gene Nygaard (talk) 02:47, 10 December 2008 (UTC)

I too would like to see a way to label the decimal output format with the degree symbol and N/S/E/W. While there is something mathematically pure with two simple signed numbers to pin-point any location on earth, I think most encyclopedia readers would be more comfortable with the less-efficient but more-human-friendly labeled format. I've been avoiding using the decimal format for this very reason. And in addition to the precision loss problem demonstrated above, mismatched precisions between the coordinates looks bad as a matter of style. --GregU (talk) 03:29, 30 December 2008 (UTC)

I too would like to see a way to label the decimal output format with the degree symbol and N/S/E/W. Cush (talk) 17:39, 30 December 2008 (UTC)

It would indeed make sense to make the decimal coordinates look like coordinates as well. Many users have also requested it before, at least at Template talk:Coord/Archive 1#Display issues, Template talk:Coord/Archive 1#Bug: display N.2FW.2FE.2FS, Template talk:Coord#N.2FS and E.2FW display for decimals and Misplaced Pages talk:WikiProject Geographical coordinates#COORD Template and digital N.2FS.2FE.2FW output. I have created Template:Coord/doc/internals to start documenting this template, and it seems that there are two possible ways to do this change:

• Directly in the link creating template Template:Coord/link with parserfunctions to treat negative numbers.
• In Template:Coord/input/d and Template:Coord/input/dec to give the currently fed coordinates in addition to ones formatted for display.

--Para (talk) 20:17, 30 December 2008 (UTC)

Before expending such energy, you would be wise to determine - through a centralised discussion, with notices in relevant fora - whether there is community consensus to make this change. Your "many" is actually only a handful of people, compared with the thousands who use the template with no concern for this issue. I'm sur enone of us want to see a repeat of the debacle over date formatting. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:28, 30 December 2008 (UTC)

I note that Google Earth displays the cursor location as lat 25.166763° lon -91.136274° elev 0 ft. I had never noticed the lack of NSEW and don't really care whether it appears or not. —EncMstr (talk) 21:19, 30 December 2008 (UTC)

In this case the "lat" and "lon" labels provide the needed context, so N/S/E/W is not needed. --GregU (talk) 19:39, 31 December 2008 (UTC)

In what way does the presence, when {{Coord}} is used, of a globe icon not provide context? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:57, 1 January 2009 (UTC)

It does not distinguish between the two numbers. --GregU (talk) 17:47, 2 January 2009 (UTC)

It does not need to, because the order in which they appear is not only significant, but standardised. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:55, 2 January 2009 (UTC)

User:Pigsonthewing has previously shed some pearls of wisdom on this, such as "a Javascript-based alternative would by inaccessible to some people" and "Javascript is not, as pointed out above, accessible to everyone". The Javascript-added globe icon is also excluded from printouts of Misplaced Pages pages. When it is visible, it only hints of the numbers being coordinates, but that doesn't say anything about latitude and longitude. Their ordering is not universal; the KML standard for example uses the longitude,latitude order. Displaying the N/S/E/W makes clear what's what, just like using symbols for degrees, minutes and seconds. --Para (talk) 00:44, 2 January 2009 (UTC)

The distinction between coordinates in decimal format and coordinates in degrees, minutes & seconds format does not extend to formatting of negative numbers. The Misplaced Pages community however has since 2005 formatted coordinates with cardinal directions instead of mathematical symbols, and any new templates replacing old ones should continue that practice unless there is significant support for change. Here on the talk page of the concerned template and on the talk page related to geographical coordinates in Misplaced Pages, majority of editors with good rational support to correct the template and make Misplaced Pages's coordinate formatting consistent. This issue is not analogous to manual of style related topics where thousands of articles have had to be edited, as the changes will be done on a few templates only and not on all the pages using the template.

I have therefore taken the time to implement my first option from above: User:Para/Coordlink. Only Template:Coord/link needs modification in that one. Like the current coord template, it still has the #Precision glitch, and I don't know if it's possible to fix it with all the conversions going inside the template. Test cases are below. The second option would be more elegant to keep the link template just for concatenation without much logic, but it would require edits to all the input templates to pass decimal coordinates for both display and geo microformat use, and might not be worth the trouble. --Para (talk) 21:01, 1 January 2009 (UTC)

Wikitext	Current output	Expected	Proposed coord/link Superseded by next proposal	Proposed coord/input/d & coord/link
{{coord|1|2}}	1°N 2°E / 1°N 2°E / 1; 2	1°N 2°E	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function
{{coord|1|-2}}	1°N 2°W / 1°N 2°W / 1; -2	1°N 2°W	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function
{{coord|1|N|2|E}}	1°N 2°E / 1°N 2°E / 1; 2	1°N 2°E	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function
{{coord|1|N|2|W}}	1°N 2°W / 1°N 2°W / 1; -2	1°N 2°W	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function
{{coord|1.10|2.00}}	1°06′N 2°00′E / 1.10°N 2.00°E / 1.10; 2.00	1.10°N 2.00°E	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function
{{coord|1.10|-2.00}}	1°06′N 2°00′W / 1.10°N 2.00°W / 1.10; -2.00	1.10°N 2.00°W	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function
{{coord|1.10|N|2.00|E}}	1°06′N 2°00′E / 1.10°N 2.00°E / 1.10; 2.00	1.10°N 2.00°E	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function
{{coord|1.10|N|2.00|W}}	1°06′N 2°00′W / 1.10°N 2.00°W / 1.10; -2.00	1.10°N 2.00°W	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function	Coordinates: Missing latitude Invalid arguments have been passed to the {{#coordinates:}} function
{{coord|1|2|3|N|4|5|6|W}}	1°2′3″N 4°5′6″W / 1.03417°N 4.08500°W / 1.03417; -4.08500	Current DMS just for comparison, no changes proposed there.

There was significant support for change to the current {{Coord}} template, which has been in use since 2007. As I have already pointed out, a significant change to the current behaviour, to many thousands of articles, should not be made without first obtaining consensus at a centralised discussion, with pointers posted in all the appropriate fora. This very much is analogous to Mos issues with date formatting, and we've all seen where non-consensual changes to that led. If there is such consensus, then the three alternative presentations it offers to users should each be given classes and styled such that users may choose which of these they can see, as they currently can for the two options in the live template. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:41, 1 January 2009 (UTC)

Why do you propose inconsistent precisions? I see -2.00 becoming 2 W and 2 becoming 2.00 E. Precision should not be modified by formatting. −Woodstone (talk) 22:57, 1 January 2009 (UTC)

That is unfortunately the current state of the template that fixing the formatting problem doesn't address. See below. --Para (talk) 23:15, 1 January 2009 (UTC)

I found a fix for this. Modifications are necessary to Coord/input/d, Coord/link and a new template Coord/negzeropad. Demo test cases are in the above table. There are a few inconsistencies with commas and hidden decimal formatting of dms coordinates, where the fix would be to make Coord/input/dm and Coord/input/dms use the dec-lat/long-display parameter as well. --Para (talk) 21:31, 4 January 2009 (UTC)

Your latest version is emitting invalid geo microformats. My previous comments also pertain. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:01, 4 January 2009 (UTC)

Fixed. Thanks for testing. --Para (talk) 22:45, 4 January 2009 (UTC)

Seems useful and an obvious improvement. I disagree about the need of a large scale consensus finding process. This is a case of Bold-Revert-Discuss. --Dschwen 23:14, 4 January 2009 (UTC)

Looks good and sound to me. I'd say go for it. --TheDJ (talk • contribs) 14:25, 5 January 2009 (UTC)

Concur. --GregU (talk) 15:26, 5 January 2009 (UTC)

This affects many tens, if not hundreds, of thousands of articles. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:17, 5 January 2009 (UTC)

I still see some issue with geo-default -> geo-dec spans for microformatting.

<span class="geo-default">
 <span class="geo-dec" title="Maps, aerial photos, and other data for 1.10 2.00">1.10°N 2.00°W</span>
 <span style="display:none"> / <span class="geo">1.10; 2.00</span></span>
</span>

Which was originally:

<span class="geo-default">
 <span class="geo-dec geo" title="Maps, aerial photos, and other data for 1.1 -2">
  <span class="latitude">1.1</span>, 
  <span class="longitude">-2</span>
 </span>
</span>

--TheDJ (talk • contribs) 16:43, 5 January 2009 (UTC)

The old one followed Geo (microformat)#Three classes while the now one follows Geo (microformat)#One class. The shorthand notation wasn't used for the original version presumably because ; is not a common separator. Negative coordinates are however no longer shown, so the odd separator is fine inside the geo display:none element. --Para (talk) 16:48, 5 January 2009 (UTC)

To demonstrate, the stub demo template {{User:Para/Coord/input/dec|0.0000|23.4567}} shows Coordinates: Missing latitude
Invalid arguments have been passed to the {{#coordinates:}} function in a microformat based mapping tool without problems. Likewise for {{User:Para/Coord/input/d|0.0000|N|34.5678|E}}: Coordinates: Missing latitude
Invalid arguments have been passed to the {{#coordinates:}} function (examples coordinates chosen to be first on the sorted list of coordinates from this page – but turns out the tool actually shows them in longitude,latitude order so they're last in the list). --Para (talk) 18:28, 5 January 2009 (UTC)

I note that you again overlook, or ignore, my comments time stamped 22:41, 1 January 2009 (UTC). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:16, 5 January 2009 (UTC)

This formatting problem was not brought to the attention of all the people who discussed converting coor templates to coord. Everyone interested in fixing the problem have now had a chance to comment here, at GEO or at MOS and there has been nothing but support. Re-re-repeating your concerns that nobody shares didn't work the last time and it's not going to work now either. --Para (talk) 18:28, 5 January 2009 (UTC)

Modifications

{{editprotected}} This page is the discussion page for all the protected subtemplates of this template. Please update from the following table the ends of the templates. The beginning and end of the code matches a recognisable position in the templates. The modifications need to be copied from the wikitext and not the HTML, as they contain HTML entities.

Thanks. --Para (talk) 16:42, 5 January 2009 (UTC)

This proposal will remove from view a useful output format (numbers only, e.g. "1.10,-2.00"), preferred by some suers and useful for copy-n-pasting into mapping and other tools. I therefore object to this "editprotected" change (or anything like it), until such time as there has been a proper and widely-notified discussion, with demonstrable consensus, as suggested in my comments time stamped 22:41, 1 January 2009 (UTC)

Precision glitch

Broken out of "Formatting problems" section above

There is another way in which template {{coor}} is not broken like this one is. Compare:

• {{coor d|43.10|N|79.00|W}} → 43°06′N 79°00′W / 43.10°N 79.00°W / 43.10; -79.00
• {{coord|43.10|N|79.00|W}} → 43°06′N 79°00′W / 43.10°N 79.00°W / 43.10; -79.00

What's with the improper loss of precision in the display? Why in the world is there any discussion whatsoever about "updating" other templates to this broken one? Gene Nygaard (talk) 02:42, 10 December 2008 (UTC)

And in addition to the precision loss problem demonstrated above, mismatched precisions between the coordinates looks bad as a matter of style. --GregU (talk) 03:29, 30 December 2008 (UTC)

"Mismatched precision" might be intentional. I remember someone describing their application of appropriate precision for a semi-linear feature such as a park (I don't remember what it was). They decided on more decimal places of precision for the narrow dimension than the lengthwise, something like (44.12, -123.4567). —EncMstr (talk) 20:04, 31 December 2008 (UTC)

As long as MediaWiki and PHP render {{#expr:-1*-1.0}}, {{#expr:abs(-1.0)}} and {{#expr:-1.0+2.0}} as 1, 1 and 1, I'm not sure it's possible to fix this for all the cases. --Para (talk) 01:45, 2 January 2009 (UTC)

Actually, looks like Wikipedians have built some character hacks where the math fails: {{rnd|49|{{precision|49.00}}}} renders 49.00, "rounding" the number to the original or derived precision. It could probably be used at some of the early processing stages of the template, where it sometimes already uses the precision function. Similarly, {{rnd|-1.1|{{precision|1.10}}}} = −1.10 and might solve the formatting problem in the section above, but the unicode minus from the rnd template breaks things, and would need to be modified or copied over here for a special version. Using these hacks could also be too much with the parsefunction limits on some coord heavy list pages. --Para (talk) 12:05, 2 January 2009 (UTC)

Good find. Wikipedians are so clever. It does look like it would be stretching things too far/deep. Maybe the best bet would be to get the needed functionality added to #expr; seems we have a strong case for adding yet another operator or so. --GregU (talk) 19:16, 2 January 2009 (UTC)

I'm not sure whether it should be a fix in PHP or in MediaWiki, but there has probably been lots of discussion on how number handling is implemented in different programming languages and whether their operators lose precision. Since that discussion is a bit far from here, I did a little workaround following the example of {{precision1}} by handling only up to certain number of decimals. It's quite a bit lighter than the rnd&precision templates. {{User:Para/negzeropad|-1.10|1.1}} renders as User:Para/negzeropad. There the -1.10 would be the original value and 1.1 the one after abs. I also came up with a fix to Gene's 43.10 problem above by removing an unneeded dec2dms transformation from the degrees only case; see the above section for test cases. --Para (talk) 20:17, 4 January 2009 (UTC)

Image size of the globe

Can the size of the globe be adjustable? On some articles it is simply too large. It can keep it's current size as the default value. -- Cat 22:51, 14 December 2008 (UTC)

Actually it would be nice if I could add a newline char between the NS data and EW data. So that it displays like on the right. -- Cat 22:58, 14 December 2008 (UTC)

Yes, it is adjustable. The meta:WikiMiniAtlas manual explains how. (use the buttonImage config parameter and set it to a smaller version of the globe, i.e. ) --Dschwen 17:57, 30 December 2008 (UTC)

Bug in this template

Finding a longitude reported as "-104.6" in Pueblo Community College, I changed it to a correct minus sign (per WP:MOSMATH) so that it said "−104.6". But then when I clicked on it, it showed the wrong location on the map. Clearly that needs to get fixed. Michael Hardy (talk) 01:43, 19 December 2008 (UTC)

Do you mean that you changed "-" to "−"? That's not a bug as very few editors would expect to put anything other than a "-" to get west coordinates. Also WP:MOSMATH and Misplaced Pages:Manual of Style (dates and numbers)#Common mathematical symbols is about writing math articles not using math symbols in actual calculations like this and {{convert}}. CambridgeBayWeather Have a gorilla 02:53, 19 December 2008 (UTC)

(e/c) Depends, − is HTML. The backends of template/expr/map server, might not necessarily deal with that very well either, since they deal with numbers, not HTML. The correct character is simply the unicode char: −. Although I doubt any of the systems are guaranteed to understand that. It would be interesting to find out where these limitations are however.

A quick test of #expr seems to indicate that both the unicode and HTML form are supported. What the templates themselves support, I'm not 100% sure yet. It seems however, that both geohack as well as the wikiminiatlas, do NOT support this character. WMA seems to do a hard regexp for - in the information it is handed. Geohack is broken in a similar method, the URL is correct, but the backend does not handle that unicode character, only the -. I propose you file a bugreport on http://bugzilla.wikimedia.org --TheDJ (talk • contribs) 03:05, 19 December 2008 (UTC)

hm, the unicode minus issue came up before. I thought I changed the WMA accordingly. I'll look into that. --Dschwen 04:42, 19 December 2008 (UTC)

Yeah, in this edit in September I added unicode minus support. Any more minus symbols I'll have to add? --Dschwen 04:44, 19 December 2008 (UTC) P.S.: the serverside coordinate parser might need to be fixed (so that the labels appear at the correct coordinates). --Dschwen 04:56, 19 December 2008 (UTC)

This was last discussed at /Archive 6#Minus sign and at WT:WikiProject Geographical coordinates/Archive 22#ParserFunction Expr.php will soon correctly handle unicode minus. Following the bug fix that was mentioned there, MediaWiki and therefore this template as well can now parse the unicode minus by replacing it internally with an ascii minus. GeoHack and all other tools that use Misplaced Pages coordinates would need a similar fix.

However, I think it's still premature to make Misplaced Pages coordinates use the unicode minus. None of the services I tried from the GeoTemplate list support the unicode minus, not in the url or when copied and pasted to their search box. While we could modify this template and GeoHack to display all negative numbers with the unicode minus but keep to ascii in urls, it would still break manual and machine reuse of Misplaced Pages coordinates in a way that's not obvious to fix. There's still some unicode evangelism to be done outside Misplaced Pages. --Para (talk) 11:31, 19 December 2008 (UTC)

Table of contents mess

Will someone please fix Template:Coord/doc so that the table of contents isn't plastered all over the top of the documentation text (there and when transcluded on the template page). I'd suggest just the no table of contents command (don't remember what it is for sure, probably NOTOC bracketed by two underscores at each end or something along those lines). Gene Nygaard (talk) 13:19, 5 January 2009 (UTC)

Fine here. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:54, 5 January 2009 (UTC)

A floating TOC will overlap the quick ref table unless you have a wide enough screen (or a non stnadards-compliant webbrowser, I guess :-) ). I remove the floating thingie and put the toc below the quickref. --Dschwen 18:16, 5 January 2009 (UTC)

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. I have fixed the coordinates on Lokomotivfabrik Floridsdorf. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:12, 5 January 2009 (UTC)

• WikiProject Microformats pages
• WikiProject Geographical coordinates pages