Template talk:Coord/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

→

Archive 10

Named parameters for region/type etc

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

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

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

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

Maintenance category to find and fix excessive number of input fields

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

• For Template:Coord/input/d,
• the input should be {{coord|12|N|12|W|region:XY_type:landmark}}
• not {{coord|12|N|12|W|region:XY|type:landmark}} which renders as {{coord|12|N|12|W|region:XY|type:landmark}}

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

A degree with 60 minutes, a minute with 60 seconds

Sometimes input is made in the degree/minutes/seconds format instead of decimal format, e.g. {{coord|12|67|85}} instead of {{coord|12.6785}}

To be able to identify and fix these uses of {{coord}}, I'd suggest to make an addition similar to the ones used on {{coor at dms}} or {{coordinate}}. (sample fix}}

This would categorize all articles with minutes/seconds equal to or exceeding 60 seconds in Category:coord template needing repair. -- User:Docu

Not every case of 60-seconds/60-minutes is faux-decimal. I would suspect that almost all case of values of exactly 60 are the result of poor round-off code.

Although I agree that seconds or minutes values > 60 probably indicate the entry of decimal values in faux-dms format, values of exactly 60 are more likely to be the result of careless rounding-off of floating-point values in badly-written numerical-processing code. For example, 1° 24' 00" might end up being represented 1° 23' 60" after conversion to floating-point followed by conversion back to DMS.

It's easily done; I've done it myself, and I've seen similar values output from Google Maps, who should know better. For example, see this: http://maps.google.com/maps?ll=6.8,-1.083333&spn=0.1,0.1&q=6.8,-1.083333 , which displays as +6° 47' 60.00", -1° 4' 60.00 within Google's interface. -- The Anome (talk) 08:59, 16 September 2008 (UTC)

We could modify the template to categorize only articles with minutes/seconds > 60. Note that geohack converts 1°60' to 2°. -- User:Docu

template:Coord/dec2dms/dms

(separated from previous section with new header by Docu).

Better to fix the bug in template:Coord/dec2dms/dms, I fixed it on fr a few month ago. Adapt it from fr: to en: ? - phe 17:55, 11 September 2008 (UTC)

Reading your post, I'm wasn't sure what the nature of the bugs was, but it appears to be related to :

the output generated with "format=dms" when the input is in decimal format.

I generated a series of tests at template:coord/dec2dms/dms/testcases and it looks like values in minutes don't round correctly. With fr:Template:Coord the same tests give a better result. -- User:Docu

Yes, I misread the above section, I was thinking about the 60″ with {{coord|2.4333|-73.9667|format=dms}} --> 2°25′60″N 73°58′00″W. Quite possible the same rounding problem exist with other template [1], I didn't fix them on fr: phe 08:24, 12 September 2008 (UTC)

I updated template:Coord/dec2dms/dms with the fr:template:Coord/dec2dms/dms. The testcases are working now correctly. As I'm not sure when/how the other templates are called. I leave the others for now. -- User:Docu

Latitude >90° and longitude >180°

According to Template:Coord/doc, {{coord}} is to be used only for Earth. Thus we could add the above limits for degrees latitude and longitude. Most coor d/dm/dms templates already check for latitude >90°.

Code would be similar as the one for minutes/seconds. I will adapt it and add it here. Articles would also be categorized in Category:Coord template needing repair. -- User:Docu

WP:Geo has a "to do" item of "Add an attribute for other planets and the moon"; and Coord has a "globe" parameter. There is also a proposal to add a corresponding "body" and a "schema" property to the Geo microformat and to the vCard specification.

What effect will the proposed changes have on the maximum number of instances of Coord which can be used on one page?

Isn't checking for such errors best done by a bot? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:20, 16 September 2008 (UTC)

How would such a bot work? -- User:Docu (signature added per [2]: Docu (talk · contribs))

By applying the same rules of logic as currently encoded into the template; but in the manner used by SmackBot and similar bots. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:26, 18 September 2008 (UTC)

That a bit too much summarized for me: How would it identify Latitude >90° and longitude >180° ? How would the bot fix them? -- User:Docu

I think the former would be achieved by comparing the existing value with a value of 90/ 180 respectively and seeing which was bigger; but where did I say it would fix them? How would your proposal fix them? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:43, 18 September 2008 (UTC)

So the bot would just read all pages and output a list? Then re-read them later? If we build in a check, incorrect uses will be identified directly, no use to do so later. -- User:Docu

Output a list, or add a category. Bot checks, and repairs, seem to work well for many other templates. Please will you now address the other points I raised in my first post in this section? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:55, 18 September 2008 (UTC)

Maybe you should try to implement your proposal. If it improves things, it is fine with me. -- User:Docu

I repeat: Please will you now address the other points I raised in my first post in this section?. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:06, 18 September 2008 (UTC)

Did you make any progress with your bot proposal? -- User:Docu

The bot wouldn't have to read all pages, the coordinates are stored in the externallinks table in the db. Extracting those is a matter of minutes. --Dschwen 23:05, 1 October 2008 (UTC)

FCC/CRTC still use NAD27 – broadcast stations show errors

There is an issue with broadcast stations in North America: both the FCC (U.S.) and CRTC (Canada) still use NAD27. Displaying these as NAD83/WGS84 causes errors in pinpointing the position of many stations. This is obvious when looking at aerial images of the antenna site, and the marker doesn't even touch the building or tower. It would be nice to have a parameter like "datum=NAD27" to indicate that a conversion should be done.  –radiojon (talk) 22:12, 26 September 2008 (UTC)

For the links on Template:GeoTemplate to work, the input needs to use the WGS84 datum. There are a few templates at Category:Coordinates conversion templates to convert coordinates to this datum. As {{coord}} doesn't convert, coordinates with another datum shouldn't use it. -- User:Docu

Geohack outputs of coordinates with some other coordinates systems (see Template:GeoTemplate/doc#Position, [3]). If it's helpful to provide coordinates with NAD27 datum for links to websites, you may want write code to enable geohack to provide this. -- User:Docu

Industry Canada recently converted all of its coordinates to the NAD83 datum. --  Denelson83  10:01, 4 November 2008 (UTC)

Name with square brackets, e.g. {{coord|30.815838|N|45.996070|E|name=Eridu [Eridug, Tell Abu Shahrain]}}

Apparently square brackets in names break the display, e.g at Cities_of_the_Ancient_Near_East. Either we remove square brackets from the names or we try to find some fix for {{coord}}. Apparently the same with {{coor d}} works. -- User:Docu

Another example of how the implementation of the "name" parameter in {{coord}} is broken; especially when the data entered is different from that displayed on the page. Good catch. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:21, 1 October 2008 (UTC)

Meh, why use square braces in the first place? Are we out of round ones? Single square braces are wiki syntax for an external link. --Dschwen 19:58, 1 October 2008 (UTC)

That's it. {{coord/link|dms-lat=1|dms-long=2|name=T[es]t}} expands to {{coord/link|dms-lat=1|dms-long=2|name=T[es]t}}. Why? The template outputs this wikitext:

<span class="plainlinksneverexpand">[http://stable... T[es]t</span>)</span></span></span>]</span>

This is still correct and so the template code works fine (the spans have been checked to be balanced). When however the wikitext parser converts that into HTML, it incorrectly ends the A element inside an element that has been opened within the A element:

<span class="plainlinksneverexpand"><a href="http://stable... T[es</a>t</span>)</span></span></span>]</span>

I don't know if the parser generally respects HTML structure while parsing wikitext, but here it just ends the search at the first match for a closing bracket. Bug, feature, or just too bad? --Para (talk) 22:07, 1 October 2008 (UTC)

Is there a reason for not accepting round braces? Makes no sense to me. --Dschwen 17:33, 24 December 2008 (UTC)

Square brackets are used so you could pass the name parameter to Google Maps and the other maps servers that do not accept parentheses in place names. We talked about that a while back. Cush (talk) 14:17, 24 December 2008 (UTC)

N/S and E/W display for decimals

Is there away to display N/S and E/W for coordinates with input in decimal format, e.g.

{{coor d|44.9|N|85.7|E}}

displays as

44.9° N 85.7° E

whereas

{{coord|44.9|N|85.7|E}}

displays as:

44.9, 85.7

-- User:Docu

'title' font size

Some infoboxes, such as 'infobox shopping mall' have an entry for coordinates. It works fine, but there is a slight issue that I'm not certain is easily fixable (see Lakehurst Mall as an example.) If I try using display=inline,title in the coord template, it does work, but the text on the title line is smaller than normal, as it looks like it's using the infobox's font size. Is this something that can be fixed? Would somebody need to edit the coord template to force a fixed font size for title? Or would the infobox template need to be updated? I'd rather not use a separate standalone coord template, as that could lead to conflicts if they get changed for some reason, and somebody doesn't update both. Andyross (talk) 22:21, 15 October 2008 (UTC)

It's a known problem that needs fixing. I made Template:Coord/display/inline,title-sandbox to experiment, e.g. {{coord|42|20|34|N|87|53|56|W|display=inline,title-sandbox}} calls it. Sample: 42°20′34″N 87°53′56″W. -- User:Docu

http://www.maxdesign.com.au/presentation/relative/ gives some explanation. An absolute size keyword (e.g. x-small) seems to solve the size issues. Next problem is its position relative to the horizontal line below the article's title. -- User:Docu

The CSS and Javascript magicians at MediaWiki talk:Common.js#Topbar content have fixed the overlapping of the line with coordinates and icons. It's a bit of a hack, but so was the entirely absolute positioning, and most people run Javascript anyway. --Para (talk) 19:00, 7 November 2008 (UTC)

Note that we just fixed the broken positioning for when the sitenotice is active. The size of the text is still a problem. However, using fixed font-sizes is not the solution either. Basically, the place where this icon is included is simply not the right spot. In the past we have considered using Javascript to correct this. There is a chance that we may still implement this solution in the long run, but we are still discussion it. --TheDJ (talk • contribs) 22:31, 7 November 2008 (UTC)

Spaces between pipe symbol and text

This template is very sensitive to spaces if any left between pipe symbol and text. Whenever such a space is left, it displays error without specifying what caused the error. I think code should be modified to automatically remove space or to be made insensitive to space. Meanwhile this is fixed, code should display error message saying one of the error could be space between pipe and text. —Preceding unsigned comment added by Pruthvi.vallabh (talk • contribs)

I've conducted some texts, and that doesn't seem to be the case for most uses. Please can you give examples? Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:15, 17 October 2008 (UTC)

This time I checked carefully. It is happening only when there is space between N and pipe symbol. You can see this at User:Pruthvi.vallabh/sandbox pruthvi (talk) 11:28, 17 October 2008 (UTC)

I see what you mean; thank you. It is a bug (but easily avoided by omitting spaces); I have no idea how to fix it, though :-( Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:20, 17 October 2008 (UTC)

This template seems to use parameter concatenation with the hemisphere specifiers (N,S,E,W) to find whether the coordinates are in decimal, degrees&minutes or degrees&minutes&seconds format. Since they are unnamed parameters, MediaWiki does not strip whitespace from them, and any spaces after N and S or before E and W will end up with an error, as the concatenation won't match with NE, NW, SE or SW. I suspect it has been implemented in this way to minimise the template pre-expansion size since that's limited. It would be possible to put the parameters through a dummy parserfunction to strip the whitespace before concatenation or use parserfunctions to replace the concatenation altogether, but that would make the template code longer again and I don't know if it's worth the trouble of long coordinate list pages breaking. --Para (talk) 17:29, 17 October 2008 (UTC)

Personally, as with other templates, I find putting whitespace before the optional parameters adds readability and allows it to wrap. E.g.:

{{coord|1|2|3|N|4|5|6|W |format=dms |region:AB_type:landmark_scale:1000000_source:internet |name=UndisambiguatedName |display=title,inline}}

vs.

{{coord|1|2|3|N|4|5|6|W|format=dms|region:AB_type:landmark_scale:1000000_source:internet|name=UndisambiguatedName|display=title,inline}}.

—WWoods (talk) 01:39, 20 October 2008 (UTC)

the work-around here is to use:

{{coord|1|2|3|N|4|5|6|W| format=dms |region:AB_type:landmark_scale:1000000_source:internet |name=UndisambiguatedName |display=title,inline}}

BTW, I changed your tt tags to code, as that's more meaningful. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 07:24, 20 October 2008 (UTC)

Is there a difference between

"...6|W |format=..." and

"...6|W| format=..."?

I haven't seen any effect. —WWoods (talk) 18:29, 20 October 2008 (UTC)

Interwiki

Please, add de-interwiki: de:Vorlage:Koordinate Artikel. Ludmiła Pilecka (talk) 16:18, 18 October 2008 (UTC)

Floating over the top line: How?

How is this template able to float over the top line? thank you. Odessaukrain (talk) 14:11, 20 October 2008 (UTC)

I got a response: Template_talk:GeoTemplate#Template:Coord_Floating_over_the_top_line:How? Yay. Odessaukrain (talk) 14:29, 20 October 2008 (UTC)

Geo class documentation

The geo classes currently have their documentation placed as a large comment inside MediaWiki:Common.css. I am planning to move that documentation to the /doc page of Template:Coord/link, since that is the place the comment currently points to for more information.

For more explanation about this, and to discuss it, see MediaWiki talk:Common.css#Geo class documentation.

--David Göthberg (talk) 23:10, 3 November 2008 (UTC)

I have replied there, but note that I have also created {{UF-coord-classes}}, to contain that explanatory text and allow its use on several pages 9some of which had it already). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:44, 3 November 2008 (UTC)

Inline references in Coord

Would it be possible to amend {{coord}} such that it could carry an inline reference? See a discussion at Wikipedia talk:WikiProject_Geographical coordinates#Citing verifable sources. Please give it your consideration. thanks --Tagishsimon (talk) 00:30, 5 November 2008 (UTC)

No.wp

Hi. Please add the norwegian link: [[no:Mal:Koordinater]] to this protected page. Prillen (talk) 10:22, 10 November 2008 (UTC)

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

Removal of hCard microformat

Unresolved

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 Wikipedia 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 Wikipedia 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 Wikipedia 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 Wikipedia. There is already consensus for the inclusion of such information. As I 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 Wikipedia 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"[4]. 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

This section was originally titled Formatting problems - Wbm1058 (talk) 15:43, 17 February 2013 (UTC)

Resolved

 – Suggested change implemented, bug fixed.

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.12°N 79.34°W / 43.12; -79.34. Is this intentional? I want and expect it to display as 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/Archive 9#N.2FS and E.2FW display for decimals and Wikipedia 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"[5] and "Javascript is not, as pointed out above, accessible to everyone"[6]. The Javascript-added globe icon is also excluded from printouts of Wikipedia 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 Wikipedia community however has since 2005 formatted coordinates with cardinal directions instead of mathematical symbols[7], 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 Wikipedia, majority of editors with good rational support to correct the template and make Wikipedia'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; 2	1°N 2°E	{{User:Para/Coordlink|dms-lat=1°N|dms-long=2°E|dec-lat=1|dec-long=2|default=dec}}	{{User:Para/Coord/input/dec|1|2}}
{{coord|1|-2}}	1°N 2°W / 1; -2	1°N 2°W	{{User:Para/Coordlink|dms-lat=1°N|dms-long=2°W|dec-lat=1|dec-long=-2|default=dec}}	{{User:Para/Coord/input/dec|1|-2}}
{{coord|1|N|2|E}}	1°N 2°E	1°N 2°E	{{User:Para/Coordlink|dms-lat=1°N|dms-long=2°E|dec-lat=1|dec-long=2|default=dec}}	{{User:Para/Coord/input/d|1|N|2|E}}
{{coord|1|N|2|W}}	1°N 2°W	1°N 2°W	{{User:Para/Coordlink|dms-lat=1°N|dms-long=2°W|dec-lat=1|dec-long=-2|default=dec}}	{{User:Para/Coord/input/d|1|N|2|W}}
{{coord|1.10|2.00}}	1.10°N 2.00°E / 1.10; 2.00	1.10°N 2.00°E	{{User:Para/Coordlink|dms-lat=1°06′N|dms-long=2°00′W|dec-lat=1.10|dec-long=2.00|default=dec}}	{{User:Para/Coord/input/dec|1.10|2.00}}
{{coord|1.10|-2.00}}	1.10°N 2.00°W / 1.10; -2.00	1.10°N 2.00°W	{{User:Para/Coordlink|dms-lat=1°06′N|dms-long=2°00′W|dec-lat=1.10|dec-long=-2.00|default=dec}}	{{User:Para/Coord/input/dec|1.10|-2.00}}
{{coord|1.10|N|2.00|E}}	1.10°N 2.00°E / 1.10; 2.00	1.10°N 2.00°E	{{User:Para/Coordlink|dms-lat=1°06′N|dms-long=2°00′E|dec-lat=1.10|dec-long=2.00|default=dec}}	{{User:Para/Coord/input/d|1.10|N|2.00|E}}
{{coord|1.10|N|2.00|W}}	1.10°N 2.00°W / 1.10; -2.00	1.10°N 2.00°W	{{User:Para/Coordlink|dms-lat=1°06′N|dms-long=2°00′W|dec-lat=1.10|dec-long=-2.00|default=dec}}	{{User:Para/Coord/input/d|1.10|N|2.00|W}}
{{coord|1|2|3|N|4|5|6|W}}	1°2′3″N 4°5′6″W	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

{{User:Para/Coord/input/dec|0.0000|23.4567}}

in a microformat based mapping tool without problems. Likewise for {{User:Para/Coord/input/d|0.0000|N|34.5678|E}}:

{{User:Para/Coord/input/d|0.0000|N|34.5678|E}}

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

There is no "formatting problem"; just a difference of opinion over formatting preference. The diff you cite merely shows how your similar behaviour in the past caused a broken behaviour to be implemented, with sound advice ignored. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:48, 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.

Template	Code
Template:Coord/link	data for {{{dec-lat}}} {{{dec-long}}}">{{{dec-lat-display|{{#ifexpr:{{{dec-lat}}}<0|{{Coord/negzeropad|{{{dec-lat}}}|{{#expr:abs{{{dec-lat}}}}}}}°S|{{{dec-lat}}}°N}}}}} {{{dec-long-display|{{#ifexpr:{{{dec-long}}}<0|{{Coord/negzeropad|{{{dec-long}}}|{{#expr:abs{{{dec-long}}}}}}}°W|{{{dec-long}}}°E}}}}}</span><span style="display:none"> / <span class="geo">{{{dec-lat}}}; {{{dec-long}}}</span></span>{{#if:{{{name|}}}|<span style="display:none"> (<span class="fn org">{{{name|}}}</span>)</span></span>|}}]</span><noinclude>
Template:Coord/input/d	|dec-lat={{#ifeq:{{{2}}}|W|-}}{{{1}}}|dec-long={{#ifeq:{{{4}}}|S|-}}{{{3}}}|dec-lat-display={{{1}}}°{{{2}}}|dec-long-display={{{3}}}°{{{4}}}|param={{{1}}}_{{{2}}}_{{{3}}}_{{{4}}}_{{{5|}}}|default={{#if:{{{format|}}}|{{{format}}}|{{#ifeq:{{coord/prec dec|{{{1}}}|{{{3}}}}}|d|dms|dec}}}}|name={{{name|}}}}}</includeonly>
Template:Coord/negzeropad	Protect

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

I don't understand this: will remove from view a useful output format. Why should the output format be decided on an article by article basis inthe first place? The template output should reflect only the properties of the coordinates (i.e. precision) and not personal preference by the editor who added the coordinate. --Dschwen 22:09, 5 January 2009 (UTC)

I agree, article by article formatting sounds like a bad idea in this case. If people want output per "personal preference", then I'm sure a separate effort can be started that shows people the format they want to see in articles. It is however not relevant to this in my opinion. I'm re-enabling the editrequest, because my "last minute" concern about micro-formats is invalid. --TheDJ (talk • contribs) 11:58, 6 January 2009 (UTC)

{{Coord}} already has that facility; this proposal removes one of the current choices, and should not be enacted until that is remedied. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:25, 6 January 2009 (UTC)

No, it changes the output method of one of the choices. From pure decimal to decimal with N/E/S/W. --TheDJ (talk • contribs) 12:42, 6 January 2009 (UTC)

Users can currently elect to see coordinates in the format "1.10,-2.00". Will they still be able to do so if this proposal proceeds unaltrered? No. That choice will be removed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:07, 6 January 2009 (UTC)

It's 'not' decided on "on an article by article basis"; {{Coord}} allows the user to select which format they prefer; the current proposal will replace one choice, rather than adding one. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:25, 6 January 2009 (UTC)

Format preferred by some users, other than Mabbett? Cite needed. There are around 8.6 million registered users on Wikipedia. Those users have created around 6900 style sheets in their userspace. In the whole of Wikipedia, there are less than 10 pages that set the display of geo classes at all. Converting between decimal degrees and degrees, minutes & seconds requires the use of division, modulo, multiplication, addition and subtraction, while it's trivial to change coordinates with cardinal directions to coordinates with negative numbers. Here's a word of advice: many mapping tools understand coordinates with cardinal directions, many browsers include the display:none elements when copying coordinates from Wikipedia, and GeoHack can convert to the many other formats.

There is no reason to further complicate this template with an addition to generate trivial conversions. It would only allow a small group of editors to choose from two additional display formats with minor differences (dms with negatives, decimal with negatives) over what the community has decided is best for the two existing entry formats. The handful of users who wish to have Wikipedia provide its contents in all sorts of different formats can use browser side scripting to convert it for them. If and only if a group of editors shows up after the change with good reasoning to request negative numbers back, we can take it under consideration again. For now the markup for negative numbers doesn't need to be generated to everyone. --Para (talk) 12:28, 6 January 2009 (UTC)

I've disabled the editprotected request for now as there is no consensus for its fulfillment. {{Nihiltres|talk|log}} 20:47, 6 January 2009 (UTC)

Please look again. Demonstratable consensus for this change is that Cush, EncMstr, Ploversegg, Dispenser (all at WT:GEO), IP at the top of this topic, Gene Nygaard, GregU, Dschwen, TheDJ and Para all support the change. This is a common number of people participating in any geographical coordinates related topic, maybe even more than usually. And then there's Pigsonthewing, typically opposing all by himself and requiring futile exercises to stall the process when consensus is clear but doesn't support his lone opinion. Consensus does not require unanimity. --Para (talk) 20:53, 6 January 2009 (UTC)

Complete agreement. Cush (talk) 23:51, 6 January 2009 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. --Elonka 19:41, 11 January 2009 (UTC)

Quite - that's what I've been suggesting all along. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:14, 12 January 2009 (UTC)

The people you name may have asked for the new format you propose to add; there has been no proper discussion of the removal of the existing format; a format which was added by consensus in 2007 and rolled out by further consensus in late 2008. As I have already pointed out, a significant change to the current behaviour, on many thousands of articles, should not be made without first obtaining consensus at a centralised discussion, with pointers posted in all the appropriate fora. Your refusal to so this, and your again resorting to ad hominem attacks, makes it seem that you may not be confident of obtaining such consensus. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:15, 6 January 2009 (UTC)

...or that it has already been discussed at the WikiProject for Geographical coordinates and the Manual of Style and the discussion page of the template being modified? It's impossible to find people more interested in this than that. Please stop wasting everyone's time. --Para (talk) 23:32, 6 January 2009 (UTC)

Complete agreement. Cush (talk) 23:51, 6 January 2009 (UTC)

• I must say that I agree with Andy on this one. The status quo for coord has been 2 options (eg 53°28′44″N 1°13′37″W or 53.479, -1.227). A few editors have expressed dissatisfaction that there is not a 3rd intermediate option (which would be 53.479N, 1.227W in this case, perhaps with degrees, possibly without a comma). My own preference is for 53.479, -1.227 which is clear and concise. I have not seen any discussion in which the removal of option 2 was overtly discussed. Occuli (talk) 09:36, 7 January 2009 (UTC)

The coor_d, coor_title_d and coor_at_d templates that were in use from 2005 to 2008 used the notation with cardinal directions. When select few people started declaring the old templates deprecated in late 2008, they ignored the complaints from people that this template is not reproducing the previous behaviour, and it was never mentioned when the deprecation was brought to wider discussion.

Now that Andy and others finally managed to make enough noise about this problem, it turned out that the majority of people commenting actually prefer the cardinal direction notation for decimal degrees over the negative numbers. They support it namely for clarity, as discussed above, to avoid confusion as to what the numbers are or which of them is latitude and which longitude, and it neatly avoids the problem of having to use dashes in place of minuses. Mathematically concise information may look clear to some people, but Wikipedia's purpose is not just to be the encyclopedia anyone can edit, but the one anyone can read as well. When the people supporting the change talk of it as a fix, the definition of fixing would be very odd indeed if it ment keeping the current notation. --Para (talk) 10:36, 7 January 2009 (UTC)

Your partisan descriptions are unhelpful and false, there was no "select few"; there was a consensus, following a widely - advertised discussion. That community consensus was not to your personal taste does not change that; and I am suggesting that it would be right and proper to hold similarly-visible discussion before you force through changes which are not visibly consensual. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:22, 7 January 2009 (UTC)

• Coord has been in use since May 2007 or so. No-one has ever complained about the choice of notation available via coord on the tens of thousands of previously unlocated articles to which coord has been added. People confused about lat and long can use the traditional dms route, or follow the link and consult the resultant map. I was assuming that those complaining wanted a 3rd option in addition to the 2 provided ... a perfectly reasonable request. There is no evidence whatever that there is support for the complete removal of the 53.479, -1.227 option. If we search on 53.479N 1.227W in google maps, the popup window gives 53.479000, -1.227000 and +53° 28' 44.40", -1° 13' 37.20" (in that order, the first bolded and enlarged) as the only options (with not an S, N, E or W in sight). Occuli (talk) 01:48, 12 January 2009 (UTC)

There have been recurring complaints of the format of the decimal coordinates ever since this template was created: see links above. Switching display to dms is not available to unregistered users, and it's not obvious for registered users, of whom very few have taken advantage of the CSS kludge. There is no reason not to fix the current notation of decimal coordinates and provide them in a more understandable format, instead of resorting to external tools. The formatting of numbers in Wikipedia is decided by the community, and Google's example with its forced false precision is irrelevant. --Para (talk) 00:14, 17 January 2009 (UTC)

Agreed with this. Orderinchaos 00:40, 17 January 2009 (UTC)

There have been a handful of people (a very small number, considering that the template is used on hundreds of thousands of articles) asking for an additional format. There have been no or near zero complaints that the existing decimal format should not be available to those who want it. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:38, 17 January 2009 (UTC)

By my count there's never been more than about 10 people participating in any discussion about the coord template. That's about as many as we have here now, usual with style related issues. The formatting of decimal coordinates has not been raised in previous discussions with as many participants. Now that it is discussed, despite the vocal ilikeit, you're failing to make a case on why the template should be preserved as it is now. --Para (talk) 12:13, 17 January 2009 (UTC)

If your figures are correct, that doesn't change the fact that the introduction of {{Coord}} was widely flagged, so that people who may have wanted to comment on the changes involved had the opportunity to do so. Please do the same with your proposal to remove the current decimal display option. And please cease your ongoing habit of misrepresenting me; nowhere have I said that the template "should be preserved as it is now". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:29, 17 January 2009 (UTC)

[8] - If you're not happy with the number of people participating – which has been enough for every geographical coordinates related discussion so far – feel free to canvass some more. --Para (talk) 13:45, 17 January 2009 (UTC)

← Your insinuation that I have been canvassing is unacceptable; and your edit summary sugegsts that you see obtaining consensus as a "waste of time". Wikipedia policy, and admins who have commented here, see things differently. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:04, 17 January 2009 (UTC)

There already is a consensus, which is that bugs should be fixed. The coord template was supposed to be a fully functional replacement for the coor templates. But now it only renders the two formats that YOU like and you dismiss every other formatting choice other editors might make. I have used the coor template ever since I came to WP but you forced me to use a template that does not work properly, just because you want it that way. Para is right and you are wrong. Cush (talk) 15:02, 17 January 2009 (UTC)

The current decimal display is not a bug. I have forced you to do nothing; and you know nothing about what I do or do not like. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:34, 17 January 2009 (UTC)

The current decimal display IS a bug since it does not render NSWE, which is in breach of the template's purpose to fully replace {{coor}}. You still could not show me the alleged consensus you claim to represent. At the moment you are the sole defender of this template. Cush (talk) 21:00, 18 January 2009 (UTC)

There are three sentences in your post. Each one is untrue. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:12, 21 January 2009 (UTC)

Wider opinions

I will ask on related fora if other people have opinions on this, and point them here. See beginning of thread for an overview of the issue, and please comment if you have an opinion on this. No need to remain and engage unless you wish to, we are mainly looking for wider input. Thanks. --GregU (talk) 17:24, 17 January 2009 (UTC)

While I appreciate your efforts, the notice you have posted says:

we seek wider opinions on whether {{coord}} should offer a N/S/E/W labeled format for decimal coordinates (example: 43.12° N 79.34° W) either as an option or by default, or if the existing unlabeled format (example:

{{Coord/display/inline|1={{Coord/input/{{#ifeq:W||dec|{{#if:{{#switch:W{{{8}}}|NE|NW|SE|SW=y}}|dms|{{#if:{{#switch:79.34{{{6}}}|NE|NW|SE|SW=y}}|dm|{{#if:{{#switch:NW|NE|NW|SE|SW=y}}|d|ERROR}}}}}}}}|1=43.12|2=N|3=79.34|4=W|5=|6=|7=|8=|9=|format=|name=}}}}<!-- 
 -->{{#ifeq:XYZ|XYZ||[[Category:Coord template needing repair|R{{PAGENAME}}]]}}<!-- 
 -->{{#ifeq:XYZ|XYZ||[[Category:Coord template needing repair|T{{PAGENAME}}]]}}<!-- 
 -->{{#ifeq:XYZ|XYZ||[[Category:Coord template needing repair|S{{PAGENAME}}]]}}<!-- 
 -->)

is sufficient.

which is not an accurate reflection of the matter. The question is whether, should the former be added, the latter should be removed, or kept as an option for those people who wish to use them. Given that {{Coord}} is specifically designed to offer the user a choice of output format, the reason for deliberately removing one such option (let us call it "pure decimal") has not been made clear. Pure decimal output is used by many on-line services and software packages, and is thus suitable for copy'n'pasting into them. Indeed, we already output it, and have done for some time, in {{GeoTemplate }}. It is the removal of this option which is disputed above,. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:21, 17 January 2009 (UTC)

I came here as a result of said request but find that I cannot understand exactly what is going on here. But my 2 pence worth is that the format of the display on screen should be user controlled and not by any form of outputting what is input into the template in an article. The content of the article can be put in what ever way the editor wishes but that should not dictate the way any particular user sees it. Obviously for non-logged in users a standard display output would need to be displayed, but logged in users should be able to have the co-ordinates display in their preferred format. Keith D (talk) 19:39, 17 January 2009 (UTC)

• In my opinion, displaying coordinates purely numerically, as "43.12, -79.34", is confusing except in rare contexts where readers expect that format. In most contexts, readers will be happier with "43.12° N 79.34° W". —AlanBarrett (talk) 19:47, 17 January 2009 (UTC)

I agree with AlanBarrett. Consistency in the project should be aimed at facilitating the readers; not at ease of copying informaiton from other software. In my opinion a full format "43.12° N 79.34° W" is best suited for most readers so we should make sure the template provides that output default, and regardless of the way the information was entered. Arnoutf (talk) 20:50, 17 January 2009 (UTC)

I agree with AlanBarrett and Arnoutf. Facilitating downstream re-users of Wikipedia by providing obscure formats is at best a secondary objective of Wikiepdia, far behind the goal of serving readers. older ≠ wiser 22:48, 17 January 2009 (UTC)

Whether we do or don't doesn't concern me- but I do object to this page hopping. How is one expected to follow an thread if it suddenly forks onto a page that is off my watch list? Quite simply any decision made can not be valid. --ClemRutter (talk) 09:41, 18 January 2009 (UTC)

I support using the N/S/E/W labels as the default as I think it looks better is generally what would be expected and then allowing the user to set a preference for the unlabeled format if they want is that would be useful for power users that want to use it for other applications. Kmusser (talk) 17:56, 18 January 2009 (UTC)

← The objection is not to the use of labels per se, but to the deliberate removal of a "pure decimal" option, an act for which there is clearly no consensus. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:03, 25 January 2009 (UTC)

Non-consensual changes

{{editprotected}}

Despite the ongoing discussion, Docu (talk · contribs), has made the disputed changes (+ [9]; ) (twice refused by other admins) and marked the discussions as closed (now reopened). Templates are now emitting broken Geo microformats and so the change needs to be urgently reverted, at least until this is fixed, if not to allow proper consensus to be reached. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:48, 25 January 2009 (UTC)

What is the problem? 16 people supported fixing this template with good reason and external essays to support discontinuing the confusing state the template was in. You and someone else you drafted[10] opposed the bug fix, but community consensus went the other way and didn't share your concern of "some people" liking the confusing format. --Para (talk) 21:23, 25 January 2009 (UTC)

However, the template does indeed not work properly now and it must be fixed fast (of course without reverting to the undesired previous state). Has this not been thoroughly tested? Cush (talk) 21:28, 25 January 2009 (UTC)

I can't see it not working anywhere, with or without microformats. Could you please point us to an article with problems? --Para (talk) 21:40, 25 January 2009 (UTC)

I am testing it right now, and I cannot reproduce the erroneous behavior I had a couple of minutes ago. Strange. When was the template changed and does it take some time to start working? Cush (talk) 21:42, 25 January 2009 (UTC)

{{coord|19.600802|-30.409731|name=Whatever}} renders a hyperlink with a parameter &params=19.600802_N_-30.409731_E_ Is that intended? Negative coords should be converted and emitted with an W. Cush (talk) 21:47, 25 January 2009 (UTC)

Well, that part of the template wasn't touched, we only fixed coordinate display in articles for now. I suspect most people are not looking at GeoHack urls, but we can look into fixing that too if it's an issue. On the template updates; the fix was applied about 11 hours ago. MediaWiki has a job queue where template changes go wait for processing, and as of writing this it's at about 1M jobs (from Special:Statistics). That seems to be common, looking at historical values from http://web.archive.org/web/*/http://en.wiki.x.io/wiki/Special:Statistics. --Para (talk) 22:30, 25 January 2009 (UTC)

Your failure to reproduce the problem does not mean that it does not exist, Great Barr, for example, is emitting <span class="geo-dec geo" title="Maps, aerial photos, and other data for 52.548 1.932">52.548°N 1.932°W</span>. That is an invalid geo microformat. Your breaking of the template aside, and as previously explained, there is no consensus to remove the "pure decimal" option. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:06, 25 January 2009 (UTC)

There was no consensus to force the "pure decimal" option while removing more readable formats in the first place. So stop bitching. Cush (talk) 22:11, 25 January 2009 (UTC)

Yes, there was. AGF. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:30, 25 January 2009 (UTC)

Prove it. Cush (talk) 22:43, 25 January 2009 (UTC)

The edit was made, the template widely implemented, and not reverted. QED. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:49, 25 January 2009 (UTC)

Or just nobody took notice. I have asked you several times to show me the discussion that resulted in the claimed consensus. But you keep failing. Combined with your ridiculous insistence on uncommon formats that makes you look like a poor conceited fellow. I do not take any of your drooling seriously. Have a nice day. Cush (talk) 23:14, 25 January 2009 (UTC)

And you have been told by another, uninvolved editor that there is no requirement for me to trawl the archives to do your bidding. If you think something was done improperly, raise an RFC. personal attack noted. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:26, 25 January 2009 (UTC)

Ah, thanks for going into specifics this time. This fix of removing the duplicate geo class didn't get into the modification. My bad, I didn't notice to copy it to the request. The template still has the correct geo class at the microformat friendly coordinates, and Docu or someone can take the duplicate one out at some point. --Para (talk) 22:30, 25 January 2009 (UTC)

• This is a matter which is still under discussion, {{editprotected}} is for edits which clearly have consensus or are uncontroversial. Since this edit is not uncontroversial, and lacks consensus, and we've not yet heard from Docu, I am removign the editprotected request. Please do not reinstate it without meeting the conditions for edits to protected pages, which are pretty clear. It would be vastly better iof the request also came form someone who does not have a long-standing dispute with the admin responsible for the change. Guy (Help!) 23:06, 25 January 2009 (UTC)
  • Since Para has conceded that his change has broken the template, the issue is no longer controversial. There is controversy over the non-consensual aspects of the change, but they are not the reason for the editprotected. The template, used on tens of thousands of articles, is broken, as has been evidenced and agreed by all sides in the latter dispute, and is emitting malformed metadata. Please do not remove the template again, until the problem has been remedied. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:16, 25 January 2009 (UTC)
    • Nothing has been broken: microformat parsers seem to find the correctly formatted elements in this template just fine, and ignore the duplicate one that for them parses to <span class="geo"></span>. The duplicate class should be removed of course, but there's no hurry doing it. --Para (talk) 23:25, 25 January 2009 (UTC)
• Andy: first, you do not ant this template edited, so this is not the place for editprotected. Second, you say that the revert has consensus, but that is obviously not the case. Do not reinstate the editprotected template. Guy (Help!) 00:01, 26 January 2009 (UTC)

Firefox's Operator extension, showing the geo microformats broken by the edits to Coord's sub-templates on 25 January 2009

Same without experimental options activated - Working as expected!

• • The request is for changes to more than one sub-templates of {{Coord}} whose talk pages redirect here. If this is not the correct place to make such a request, then why were the disputed changes, also requested here, made? Where else do you think I should make my request? You may after all be right that the change does not have consensus, since Para changed from admitting that the initial edit was erroneous, and did not include the code used in the sandbox version of the template he used to support his request; to insisting, erroneously, that nothing is broken. Wikipedia's credibility is harmed by the emission of broken metadata, and it is also harmed by the tardiness of our fixing that problem; tardiness to which you have now made a major contribution. What a farce! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:02, 26 January 2009 (UTC)
    • You are using the addon with the non-default "debug" option. If the debugging option is at its default off setting, the list works without problems. --Para (talk) 19:21, 26 January 2009 (UTC)
      • Well there's a surprise - if I turn off the debugging (not, as you misleadingly label it, "experimental") option, the bugs aren't shown. Thank you for confirming that there are bugs. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:23, 26 January 2009 (UTC)
        • Thank you for confirming that there are no practical problems with this template and that any bugs are entirely theoretical. Maybe now you could spend the five seconds it takes to request a fix to that theoretical problem only you care about, instead of mindlessly demanding reversion of features that work with no problems whatsoever. --Para (talk) 21:50, 26 January 2009 (UTC)

Is it broken?

I saw the notice about this template on WP:AN. As an outsider, I'm not familiar with this template or what it's supposed to produce. All I see are bald assertions of "It's broken!" "No it isn't!". Could someone provide the following information:

1. An example of current ("broken") output.
2. The output that the template is supposed to produce.
3. A reference to the microformat standard this template is supposed to follow.

Thanks. --Carnildo (talk) 03:03, 27 January 2009 (UTC)

Sorry, but everyone agrees that the copy&paste mistakes should be fixed, even if not fixing them doesn't lead to any concrete problems. The differences in the include section between the current template and the template tested at #test cases is all that needs to be put in sync. --Para (talk) 10:30, 27 January 2009 (UTC)

Yes, it is broken as described and illustrated graphically, above (see reference to Great Barr), and it is in breach of the microformat specification to which it is supposed to adhere. (The name parameter is also broken; as described.) Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:41, 27 January 2009 (UTC)

Funny how your extension breaks only when you activate a non-default option that would be better called "enbug", and how otherwise there are no problems at all, as demonstrated in the second screenshot above. Funny also how despite your criticism of widely used features as "broken", even people outside Wikipedia appreciate the elegance of the name parameter in this template: "I was especially intrigued by the list of Meteor impact craters as this one had vcard information with geo information - yummy hack fodder, that." (Christian Heilmann, Yahoo! developer[11]). As it happens, the coordinates and name parameter values from this template are the only vcard information on that page. But hey, old news, I guess repeated remedies aren't going to change the spots. --Para (talk) 00:53, 28 January 2009 (UTC)

It's not my extension; and it merely does what it's supposed to - it highlights bugs when the debug option is activated; such behaviour has resulted in the extension being referred to as a "microformats validator". Your screenshot merely illustrates that the bug reports and invalid microformats can be hidden; not that the bugs don't exist. Though the hCards in the example you cite happen to be created using the name parameter, that does not negate the fact that that parameter is broken, as described above. That parameter is not the only method of creating hCards; indeed, when you removed the existing hCards from that article to impose your personally-preferred and more limited model, you reduced the amount of useful information included, thereby harming Wikipedia and reducing the level of service provided to our users. The earlier version would have worked better in Mr Heliman's experiment, supplying him with the region names and crater sizes which you hid from the view of his software. As usual, when you run out of arguments, you resort to the tired old ad hominem of citing others' lies. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:20, 28 January 2009 (UTC)

The second screenshot demonstrates the default behaviour of the extension, not any additional features of hiding empty elements. This is not the Semantic Wikipedia and there are limits to how much abuse HTML and wikitext can take from markup experiments without any software support, while still keeping the articles of the encyclopedia easy for anyone to edit. It is amusing seeing you dig yourself deeper by calling the arbcom's findings of fact as lies, and it makes one wonder why you continue with it, and why you continue this here. Removing the duplicate geo class name from the template is easy and uncontroversial, and while nobody else cares whether it's there or not, your current approach here isn't getting any closer to fixing it. --Para (talk) 02:05, 28 January 2009 (UTC)

The only reason my current approach is not working is because you and others seem to refuse to acknowleged the fact that the template is currently broken. Your bad. There has been no "abuse" (other than the implementation of a broken change to this template, without consThat ensus and contrary to the test examples provided). I have not "[called] the arbcom's findings of fact as lies"; please do not put words into my mouth. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 07:54, 28 January 2009 (UTC)

I repeat: All I see are bald assertions of "It's broken!" "No it isn't!". Could someone provide the following information:

1. An example of current ("broken") output.
2. The output that the template is supposed to produce.
3. A reference to the microformat standard this template is supposed to follow.

Thanks. --Carnildo (talk) 03:03, 27 January 2009 (UTC)

I suppose my "sorry" should have been "thanks for the help, but the community has already tested the modification, the edit just didn't go through as planned". If you'd still like to take a look yourself, I'll elaborate: 1: #test cases current output column, 2: #test cases second proposed column, 3: no clue, but the diff between the current and proposed template fixes all errors from "enbug" options. --Para (talk) 02:00, 28 January 2009 (UTC)

The community tested a modification; but that was not the modification made, which is broken, and should therefore be reverted. Your claim that this template is not broken, while admitting to having "no clue" as to the specification with which it is supposed to adhere, is peculiar, to say the least. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 07:54, 28 January 2009 (UTC)

Ah, that answered my question above of your motivation: by continuing this farce as you aptly put it, you are trying to find a backdoor to reverting all the changes to get your way against what the community decided, instead of fixing the minor issue you're complaining about here. It's like the arbcom case consensus evidence all over again! How about spending all this energy on CSS errors someone might actually have a problem with? --Para (talk) 11:53, 28 January 2009 (UTC)

There you go again: failing to assume good faith to the point of dishonesty. I answered no such question, and have no such intention. The very first line of my first post asking for the revert said (emphasis changed): "the change needs to be urgently reverted, at least until this is fixed" and my ANI/ AN posts said (new emphasis): "The change was non-consensual, but I'll be taking that up separately; the more pressing matter is to repair damage". Nonetheless, the community did not decide to do what has been done; and you are again reduced to ad hominem. I'd be delighted if you took up CSS fixes, instead of breaking things. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:43, 28 January 2009 (UTC)

In my answer to you above, I cite an earlier section of this page which gives you evidence and example code showing that this template is currently broken, thereby answering your first point; and the external microformat spec which answers your third point, and which contains the code which answers your second point. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 07:54, 28 January 2009 (UTC)

You provided a diff of part of the template code, but my understanding is that the output of the template is what's broken, and I'm not too good at parsing complex templates like this one in my head. Could you provide an example of the actual HTML produced by this template, and the same HTML corrected to how you think it should look? --Carnildo (talk)

You're confusing me with someone else. I provided you with directions to a sample of the broken code; see the reference to Great Barr. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:43, 28 January 2009 (UTC)

Here you go:

HTML

Test cases, current, first row:
<span class="plainlinksneverexpand"><a href="http://stable.toolserver.org/geohack/geohack.php?pagename=Template_talk:Coord&params=1_N_2_E_" class="external text" title="http://stable.toolserver.org/geohack/geohack.php?pagename=Template_talk:Coord&params=1_N_2_E_" rel="nofollow"><span class="geo-nondefault"><span class="geo-dms" title="Maps, aerial photos, and other data for 1°N 2°E"><span class="latitude">1°N</span> <span class="longitude">2°E</span></span></span><span class="geo-multi-punct"> / </span><span class="geo-default"><span class="geo-dec geo" title="Maps, aerial photos, and other data for 1 2">1°N 2°E</span><span style="display:none"> / <span class="geo">1; 2</span></span></span></a></span>

Test cases, proposed, first row:
<span class="plainlinksneverexpand"><a href="http://stable.toolserver.org/geohack/geohack.php?pagename=Template_talk:Coord&params=1_N_2_E_" class="external text" title="http://stable.toolserver.org/geohack/geohack.php?pagename=Template_talk:Coord&params=1_N_2_E_" rel="nofollow"><span class="geo-nondefault"><span class="geo-dms" title="Maps, aerial photos, and other data for 1°N 2°E"><span class="latitude">1°N</span> <span class="longitude">2°E</span></span></span><span class="geo-multi-punct"> / </span><span class="geo-default"><span class="geo-dec" title="Maps, aerial photos, and other data for 1 2">1°N 2°E</span><span style="display:none"> / <span class="geo">1; 2</span></span></span></a></span>

The xfeffs in the diff were a workaround to a MediaWiki parser problem, but I can't find off hand when the issue actually occurs. --Para (talk) 12:47, 28 January 2009 (UTC)

Thank's, Para, I appreciate your work. I especially agree with you in keeping out non-human readable CSS like this vCard geo-microformat 'class' stuff inside Wiki text (although loving microformats in Semantic Web and in machine readable code). --Geonick (talk) 00:50, 3 February 2009 (UTC)

Precision glitch

Resolved

 – Bug fixed with patch for previous bug

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.10°N 79.00°W / 43.10; -79.00
• {{coord|43.10|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|-1.10|1.1}}

. 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 ^chi? 22:51, 14 December 2008 (UTC)

Globe	12°24′46″N
	47°55′28″E

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 ^chi? 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. [12]) --Dschwen 17:57, 30 December 2008 (UTC)

Bug in this template

Resolved

 – Use "-" instead.

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 Wikipedia: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 Wikipedia coordinates would need a similar fix.

However, I think it's still premature to make Wikipedia 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 Wikipedia coordinates in a way that's not obvious to fix. There's still some unicode evangelism to be done outside Wikipedia. --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)

Parser function errors (Antelope_Valley_College)

The above article ends up in the Category:ParserFunction errors, possibly due to a problem with this template. The link from the coordinates to the toolserver includes "%E2%80%8E" in its URL. The coordinates as such seem to work.

The problem is possibly the same as the one mentioned at User_talk:Dispenser#Coordinates log (Warning: UTF8params). -- User:Docu

I retyped the link and it worked. See [13] - very odd, and note the 3 char drop in the edit. The original also wouldn't convert to format=dms when I tried it in preview, and complained of an unusual character when I did so. Orderinchaos 09:11, 25 January 2009 (UTC)

Thank you for fixing it. The following may have the same problem:

Samples

• Malibu,_British_Columbia
• Manjunatha_Vidyalaya
• Mara_Mountain
• Menlo_Park_Mall
• Pelham_Bridge
• Roland_Reisley_House
• Sambalpur_University
• Alonzo_Gesner
• Centrepointe_Theatre
• Collège_Canado-Haïtien
• Edward_E._Boynton_House
• Edward_Serlin_House
• Hooley_Hill_railway_station

They are all in the parser function error category and showed up with UTF warnings in the coord-enwiki log. -- User:Docu

Yeah it seems retyping the longitude after the decimal point and the following | fixes it. I'd love to know what is there that we can't see that the server obviously does, though. Orderinchaos 09:26, 25 January 2009 (UTC)

These additional characters come from various applications when copying and pasting coordinates. Most often they are UTF-8 encoded Unicode control characters, which on normal display are invisible and go unnoticed. They become visible in urls for example, where everything outside a few common characters needs to be encoded. If you're interested of what the odd character sequences mean, the three byte ones work like so:

%E2      %80      %8E
11100010 10000000 10001110
    aaaa   aaaabb   bbbbbb

a = 00100000 = 0x20
b = 00001110 = 0x0E
ab = 0x200E

0x200E is otherwise known as U+200E or the left-to-right mark. Another way to find these is to just google the sequence to find a list page somewhere. They are never needed with coordinates, but some parameters may need some odd characters, I'm not sure. Anyway, even though some tools may ignore them, we should remove the characters from coordinates in articles, with AWB or something. They are the UTF8params error type in coord-enwiki.log, and s/[^\dNSEW._-]//g before the first colon (if any) should get rid of them. --Para (talk) 15:36, 25 January 2009 (UTC)

Thanks for your reply. My bot fixed some of them even if I haven't found the ideal python regex yet. -- User:Docu

The following python regex got rid of most of them:

regex

        (u"(\u200E|\uFEFF|\u200B)", r""),

Thanks for your help. -- User:Docu