Template talk:Coord/Archive 13

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Proposal to limit "malformed coordinates" category to article space

I propose to limit the population of Category:Pages with malformed coordinate tags to article space by modifying the module to check the namespace of the page before applying the category. Comments? – Jonesey95 (talk) 04:14, 3 May 2019 (UTC)

I have attempted to limit the namespace, but it appears that the category is sometimes assigned by MediaWiki. I have started a new discussion. – Jonesey95 (talk) 07:54, 7 May 2019 (UTC)

@Jonesey95: I noticed that this edit both suppressed the category and also turned off the error message, for non-article pages. Was that the intent? This broke the testcases. —hike395 (talk) 14:13, 5 July 2019 (UTC)

@hike395: Following up to your query at my talk, my edit to Module:Coordinates had edit summary "update from sandbox per Template talk:Coord#Support for qid: do not require current page to have an entity so qid=Qxxx will work on any page; the only pages in the category are due to mw:Extension:GeoData which cannot be controlled by the module". The background was discussed at #Support for qid above where I pinged Jonesey95—see "reason for the revert" in that comment to see why I removed Jonesey95's edit. That edit also includes links to the module, its sandbox, and their difference. An additional point regarding the category is that while I have not checked each of the 52 pages listed there, I think none of them were added by the module. In other words, the module's check apparently only catches extreme problems that are very rare. It would be useful to see what those problems are, if any, regardless of the namespace. The only reason to exclude non-articles is due to the clutter of broken drafts, but that clutter is not affected by the module. I explained above about the testcases—search for "The testcases are broken because". I recommend reverting your edit to the module although it doesn't particularly matter. Johnuniq (talk) 01:50, 6 July 2019 (UTC)

Support for qid

I just added support for |qid= for {{infobox observatory}} for Paul G. Comba. this parameter is optional, so should cause no changes for any existing non-qid-using transclusions. let me know if this causes any problems. Frietjes (talk) 14:51, 16 November 2018 (UTC)

@Frietjes: I'm not sure it's working? Trying {{Coord|qid=Q5814115}} gives 28.36656°N 16.72222°W / 28.36656; -16.72222. Thanks. Mike Peel (talk) 18:20, 20 April 2019 (UTC)

@Mike Peel: The reason that does not work here is that this talk page does not have a Wikidata entity. If you try replacing all the wikitext at A with the coord and previewing the result you will see it works. I don't know why, but it also needs |nosave=1 so try {{coord|qid=Q1861728|nosave=1}}. Johnuniq (talk) 23:55, 20 April 2019 (UTC)

Stopping to think about it, there appears to be no reason to require that the current page have an entity. I edited Module:Coordinates/sandbox to remove that requirement.

• {{coord/sandbox|qid=Q1861728|nosave=1}} → 34.5125°N 112.49°W / 34.5125; -112.49

@Frietjes: My edit should be ok? If I get a chance I'll check why Module talk:Coordinates/testcases shows a bunch of differences. Johnuniq (talk) 01:52, 21 April 2019 (UTC)

The testcases are broken because the module uses:

return mw.getCurrentFrame():callParserFunction('#coordinates', in_args) or ''

When an invalid argument is used, the above generates a message like the following:

<span class="error"><nowiki>{{#coordinates:}}</nowiki>: invalid latitude</span>

Module:UnitTests then sees strip markers for the nowiki stuff and the UNIQ id is different for every occurrence on the page. That means the expected and actual results will differ. I could fix Module:UnitTests to skip that difference, or someone could try a phab request to have the curly braces replaced by HTML entities rather than use nowiki. Another day. Johnuniq (talk) 02:10, 21 April 2019 (UTC)

Thanks, that looks like a good improvement. :-) Why is the "nosave" parameter needed here, though? And please could that parameter be documented somewhere? Thanks. Mike Peel (talk) 20:03, 21 April 2019 (UTC)

A quick look at the module makes me think that nosave stops the module from calling {{#coordinates|...}} which Help:Magic words says would "Save the GeoData coordinates of the subject to the page's database." With nosave, the module just returns the coordinates for display. Johnuniq (talk) 05:44, 22 April 2019 (UTC)

@Johnuniq: Could the sandbox changes be merged in with the main version, please? Thanks. Mike Peel (talk) 20:16, 3 July 2019 (UTC)

@Frietjes: Are the changes in the module sandbox ok by you? The sandbox cleans whitespace and does not require the current page to have an entity so qid=Q5814115 will work on any page. It also reverts Jonesey95's change to only add Category:Pages with malformed coordinate tags for articles. The reason for the revert is that the module has not placed any pages in the category—the pages in the category are due to mw:Extension:GeoData which cannot be controlled by the module.

• Module:Coordinates • Module:Coordinates/sandbox • same content

Johnuniq (talk) 05:14, 4 July 2019 (UTC)

Johnuniq, looks reasonable to me since the only serious changes are when args[1] is not a valid number and when args[2] isn't specified, the impact should be to only a small subset of all the uses. we can always roll it back if there is a problem. Frietjes (talk) 14:30, 4 July 2019 (UTC)

Thanks, done. Johnuniq (talk) 07:49, 5 July 2019 (UTC)

Johnuniq, I like this. Nice improvement. I would note that it is probably not intended to have coordinated title mode enabled for the observatory on the page Paul G. Comba, as the coordinates are not of the primary subject. —TheDJ (talk • contribs) 08:17, 5 July 2019 (UTC)

Hmm, that is a problem which is due to Paul G. Comba containing

{{Infobox observatory|name=Prescott Observatory|qid=Q1861728}}

The infobox is already complex but perhaps it should have a parameter to suppress the title in |display=inline,title. Or, maybe do that if the name does not match the article title (except, there would be cases where the article title has some disambiguation which is not wanted in the name). Johnuniq (talk) 10:09, 5 July 2019 (UTC)

There shouldn't be multiple infoboxes in one article! So I'd suggest either splitting the article into separate ones about the person and the observatory, or removing the observatory infobox. Thanks. Mike Peel (talk) 10:26, 5 July 2019 (UTC)

Mike Peel, TheDJ, see Wikipedia:Articles for deletion/Prescott Observatory, so creating a new article would require DRV or some bold actions. Frietjes (talk) 13:16, 6 July 2019 (UTC)

Inconsistent behavior?

At Pacific DC Intertie, the first {{coord}} reference doesn't have a globe; it offers a WikiMiniAtlas button when you hover over it. Other apparently identical references on the same page have a globe. Huh? Jordan Brown (talk) 18:07, 15 October 2019 (UTC)

coord Doesn't Match Markup Between format=dms and format=dec

When a coordinate is entered as dms the outputted different compared to the outputted markup for decimal.

{{coord|41.9925|-70.7265|region:US-MA_type:city|display=inline,title|format=dms}}

produces

<span class="geo-default"><span class="geo-dms" title="Maps, aerial photos, and other data for this location"><span class="latitude">41°59′33″N</span> <span class="longitude">70°43′35″W</span></span></span>

{{coord|41.9925|-70.7265|region:US-MA_type:city|display=inline,title|format=dec}}

produces

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

you can see that the decimal format doesn't split the lat/lng into separate spans and doesn't have class names to specify latitude and longitude. Is there a reason latitude/longitude in the dms format is marked up but not for the dec format? And if there is/isn't should the output match for both formats?

Vermiceli (talk) 18:49, 22 December 2019 (UTC)

Coordinates not displayed on mobile page

I went to edit a page that seemed to be missing coordinates (Bermeja), but I see that it already has {{coord|22|33|N|91|22|W|display=title}}. The coordinates are displayed as expected on a desktop browser, but not on a mobile browser (see [1]). —AlanBarrett (talk) 10:56, 18 January 2020 (UTC)

This is the code for coordinates in the title area:

<span id="coordinates">[[Geographic coordinate system|Coordinates]]: <span class="plainlinks nourlexpansion">[//tools.wmflabs.org/geohack/geohack.php?pagename=Special:ExpandTemplates&params=22_33_N_91_22_W_ <span class="geo-default"><span class="geo-dms" title="Maps, aerial photos, and other data for this location"><span class="latitude">22°33′N</span> <span class="longitude">91°22′W</span></span></span>

I am guessing that one of those CSS classes is not displayed on mobile, but I have been unable to find documentation with an explanation. – Jonesey95 (talk) 15:40, 18 January 2020 (UTC)

Zoom and translation

What controls initial zoom when map is opened on Wikipedia article? --5.43.82.5 (talk) 23:26, 29 February 2020 (UTC)

See mw:GeoHack for details. – Jonesey95 (talk) 01:39, 1 March 2020 (UTC)

Thanks. --5.43.82.5 (talk) 22:50, 3 March 2020 (UTC)

Why is not translation of the map textual notes such as "Hold Ctrl or ? and hover over a link to read an article summary" applied for sr.wikipedia? I guess translations have been already entered at the proper place. --5.43.82.5 (talk) 22:50, 3 March 2020 (UTC)

You should probably ask at the Discussion page for the page linked above. – Jonesey95 (talk) 23:46, 3 March 2020 (UTC)

Done. --5.43.82.5 (talk) 01:45, 4 March 2020 (UTC)

Discussion at Wikipedia talk:Manual of Style/Layout#Nothing should go between navboxes and authority control

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Layout#Nothing should go between navboxes and authority control. —⁠andrybak (talk) 22:40, 1 April 2020 (UTC)

Expansion of type parameter

Any room for expansion of the type parameter? Could 'port' be added as a type?Fob.schools (talk) 14:37, 27 April 2020 (UTC)

Port would fall under landmark, as far as I can tell. Rehman 07:15, 27 May 2020 (UTC)

Malformed coordinates

Hello. Could someone assist me in figuring out why this edit adds articles to Category:Pages with malformed coordinate tags? Is it because those articles (examples: 1, 2) have a separate {{Coord}} parameter outside the infobox? And if so, any suggestions on how I could go about fixing this? AWB them inside the infobox? Courtesy ping to User:Deor (thanks for reverting that edit!) Rehman 07:19, 27 May 2020 (UTC)

I looked at a couple of the articles before reverting your edit. Yes, some of them already had {{coord}} templates outside the infobox. In the examples you've linked, I assume that the infobox coords are coming from Wikidata, since they're certainly not there in the infobox parameters here, and I'm frankly not sure why your edit should have caused multiple title displays in the articles. (I know nothing about template coding, but the expression "If first display both" looks possibly problematic.) I'm in general very leery of importing Wikidata coords into en.wp; and I don't see why your edit was desirable to begin with, since I'll bet that there are very few articles using {{Infobox power station}} that have coords in Wikidata but lack coords in our articles. I'll leave the technicalities to people familiar with the niceties of templates. Deor (talk) 08:31, 27 May 2020 (UTC)

Wd coords are only shown if local values are missing. After a deeper look, it seems like that is indeed the cause. Those separate parameters should in fact be within the infobox's coord parameter, with display=inline,title. I will start making those fixes, but I may have to redo my edit so I can track those particular occurrences and fix. Unless anyone knows another way how I could find articles that uses {{Infobox power station}} but also has a separate {{Coord}} template outside the infobox. Rehman 10:14, 27 May 2020 (UTC)

I'm going ahead with redoing that edit. Will start fixing those occurrences through articles that show up on Category:Pages with malformed coordinate tags. Hence please don't revert the template edit. Thanks! Rehman 03:46, 29 May 2020 (UTC)

All fixed. Rehman 06:37, 29 May 2020 (UTC)

The template seems broken.

Clicking on a generated link on any page where this template is used brings up a 404 error. Tested on East Wing. WikiMaster111 (talk) 14:29, 6 June 2020 (UTC)

Think there is a problem wider than just the template as you get the same from Commons coordinate links. Keith D (talk) 15:56, 6 June 2020 (UTC)

How do I go about reporting this issue? WikiMaster111 (talk) 15:59, 6 June 2020 (UTC)

First port of call would be village pump. Keith D (talk) 16:19, 6 June 2020 (UTC)

Actually, the issue seems to be resolved. WikiMaster111 (talk) 16:25, 6 June 2020 (UTC)

This was reported more than an hour earlier at Wikipedia:Village pump (technical)#Coordinates. --Redrose64 🌹 (talk) 07:19, 7 June 2020 (UTC)

Spaces between measurements

When formatting the coordinates, there should be (non-breaking) spaces between the measurements, as per the SI and even the website/tool the coordinates link to. For example, {{coord|41|17|20|S|174|46|38|E}} produces 41°17′20″S 174°46′38″E instead of 41° 17′ 20″ S 174° 46′ 38″ E or 41° 17′ 20″ S, 174° 46′ 38″ E. Getsnoopy (talk) 00:06, 20 March 2020 (UTC)

The format is determined by Wikipedia's Manual of Style. See MOS:COORDS. The right place for a discussion about spacing is the talk page for that MOS page. – Jonesey95 (talk) 03:24, 20 March 2020 (UTC)

@Jonesey95: Interesting. It seems like the MoS text itself is following the format correct (e.g., For the city of Oslo, located at 59° 55′ N, 10° 44′ E), but most of the rest of the text just refers editors to the template to do it "automatically". So this should be fixed in this template then. Getsnoopy (talk) 06:13, 28 March 2020 (UTC)

That is one occurrence where ordinary spaces are used, possibly to emphasize the separate components to show how they correspond to the template parameters. At any rate, further discussion should be at MOS talk. Johnuniq (talk) 06:46, 28 March 2020 (UTC)

Sounds good, I've moved the discussion here. — Preceding unsigned comment added by Getsnoopy (talk • contribs) 20:37, 4 April 2020 (UTC)

@Jonesey95 and Johnuniq: I should have seen this before, but MOS actually uses spaces (in the "Numeric values" section of the table). It seems like the discussion didn't yield any objections either. Could this be updated? Getsnoopy (talk) 18:00, 4 June 2020 (UTC)

It's OK with me to experiment with adding non-breaking spaces between the numbers. The place to do it is Module:Coordinates/sandbox, which is beyond my skills. – Jonesey95 (talk) 18:49, 4 June 2020 (UTC)

{{coord}} has 1,221,808 transclusions and a change to how it works needs positive assent, not an absence of discussion. Johnuniq (talk) 23:21, 4 June 2020 (UTC)

I agree strongly. The discussion will go nowhere without examples of the current and proposed format. – Jonesey95 (talk) 01:46, 5 June 2020 (UTC)

I specified the current and proposed formats in the OP already: 41°17′20″S 174°46′38″E is the current one, and 41° 17′ 20″ S, 174° 46′ 38″ E is the proposed. Basically, add (non-breaking) spaces after the unit symbols, and a comma to separate latitude and longitude coordinates. Getsnoopy (talk) 22:34, 15 June 2020 (UTC)

div inside span

On Camp Atlanta, this template is used inline. Looking at the generated HTML, the WikiMiniAtlas button is a <div> inside the template's <span>. However, this is improper HTML, as divs are block elements while spans are inline elements. Opencooper (talk) 10:00, 11 July 2020 (UTC)

Is this the coordinates top right? There is no <div>...</div> that I can find. --Redrose64 🌹 (talk) 10:11, 11 July 2020 (UTC)

No, it's the one in parenthesis right after the title in the lead. Here's the corresponding HTML (simplified):

<p><b>Camp Atlanta</b> (<span class="plainlinks"><span><div style="background-color: white...><span style="cursor: pointer;"><img>...

It's the code for the button that shows up when you hover over the coordinates. Opencooper (talk) 10:48, 11 July 2020 (UTC)

D'oh, I think I just answered my own question. The div is there for the popup... Not sure if it can be done with a span, but I see why it was done that way, even if it's kinda wonky HTML-wise. Opencooper (talk) 10:54, 11 July 2020 (UTC)

fwiw, you can make pretty much any HTML element behave like a div by manipulating its display property, either through CSS or JavaScript, depending on context. Given WikiMiniAtlas (aiui) requires JS anyway, that's probably the easiest way to do it. Notionally block elements inside inline elements cause wonky behaviour in some contexts (despite html5's attempt to nullify the difference) and in MediaWiki even the instances that don't cause direct problems cause noise in the linter lists that makes other issues (that do cause direct problems) harder to find and fix. --Xover (talk) 11:37, 11 July 2020 (UTC)

Tag display=title doesn’t show in mobile site

Code {{Coord|19.123|75.123|display=title}} shows coordinates in desktop version wiki.riteme.site of the page at top right, but doesnt display anything anywhere in mobile version m.wiki.riteme.site . Crashed greek (talk) 15:31, 6 October 2020 (UTC)

I have updated the documentation. Thanks for pointing this out. – Jonesey95 (talk) 17:03, 6 October 2020 (UTC)

Region parameter

Question regarding the region parameter, Template:Coord#region:R. The GeoHack documentation, mw:GeoHack#params, says: region:(deprecated) The ISO 3166 code with an optional subdivision to highlight region specific services, see Section codes below. If not supplied GeoHack will attempt to find the region using the coordinates. Does anyone know why it is deprecated? Further, please see this URL which is a {{Infobox GB station}} testcase without "region" parameter being supplied. The region is not being automatically determined (it remains blank). Although the Google map shows a UK address, GeoHack itself doesn't seem to understand this is in the UK? Are we doing something wrong here? Also pinging maintainers: @Dispenser and Magnus Manske:. Thank you! ProcrastinatingReader (talk) 14:38, 22 October 2020 (UTC)

Possibly relevant GeoHack region.php/worldadmin98 outputs. worldadmin98 GeoHack. Seems to output nothing. Tried with other coords like The White House, same output. Looks like this part of the code isn't being ran? ProcrastinatingReader (talk) 15:35, 22 October 2020 (UTC)

Possible solution (a free API) that does reverse geocoding: [2]. Data looks like "{"codes":[{"code":"CA","level":"1","type":"ISO3166-2"}],"adminCode1":"CA","distance":0,"countryCode":"US","countryName":"United States","adminName1":"California"}" (Apple Campus) ProcrastinatingReader (talk) 15:59, 22 October 2020 (UTC)

Requested move 18 September 2020

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

No consensus to move, after much-extended time for discussion. BD2412 T 17:26, 24 October 2020 (UTC)

Template:Coord → Template:Coordinates – Expand name, match name with module. * Pppery * _{it has begun...} 15:09, 18 September 2020 (UTC)

• Comment: I guess this makes sense, as long as we keep "Coord" as a redirect and as long as the new name does not break anything. It seems like a risk for limited benefit. Having a shorthand redirect that is easier for editors to spell is always helpful. I wonder, since this template is so widespread, if there is code that depends on its current name and will break if {{Coordinates}} (currently only 371 transclusions) is used as the default. – Jonesey95 (talk) 15:53, 18 September 2020 (UTC)

  Bots and scripts, usually. --Redrose64 🌹 (talk) 19:24, 18 September 2020 (UTC)

• Support change to match the module. I'm pretty sure most usages of this template are directly via the infoboxes. Since it's a static usage I'd support changing those usages to the new title, which would then also allow finding any problematic usages, if any, that Jonesey95 was concerned about. --Gonnym (talk) 07:50, 19 September 2020 (UTC)

There are a huge number of direct calls to the {{coord}} template still out there. Sure, a lot of it is bound up in Infoboxes, but even in those, the {{coord}} is called inline. Fob.schools (talk) 10:10, 23 September 2020 (UTC)

• Support the current title is an abbreviation, although the article is at Coordinate system, "Coordinates" seems appropriate for an individual place though maybe it should be singular, namely Template:Coordinate? Crouch, Swale (talk) 10:00, 19 September 2020 (UTC)
• Weak oppose Seems like a needless change and yet more typing for no good purpose. It's common enough in speech and writing (though probably not publishing) to just call them "coords". BTW, you can have one ordinate (eg a x-axis y-axis position), but two or more coordinates (x/y or lat/long). Martin of Sheffield (talk) 14:29, 19 September 2020 (UTC)

  When I was at school doing my maths A-level, we were taught that the ordinate is the position along the y-axis; the corresponding position along the x-axis being the abscissa. See Abscissa and ordinate. --Redrose64 🌹 (talk) 20:32, 19 September 2020 (UTC)

  I stand corrected. I was thinking just about the singular/plural and not the ordinate/mantissa. Mea culpa. Martin of Sheffield (talk) 20:41, 19 September 2020 (UTC)

• Happy to support any proposal which makes template names clearer — Martin (MSGJ · talk) 08:17, 23 September 2020 (UTC)
• Oppose unless a bot is created to convert all usage throughout the site to the new name in a matter of hours. What we do not need is yet another instance of multiple names for the same thing, continuing for the life of the project, with new editors required to learn that they are in fact the same thing. This adds unnecessary complexity, raising the barriers to entry. While there is no way to prevent the creation and use of template redirects (unfortunately), we needn't create them without better reasons than those presented here. If it's important for the template and the module to have the same name, rename the module, not the template. ―Mandruss ☎ 14:18, 23 September 2020 (UTC)

  Why is a bot needed, see Wikipedia:Bot requests/Frequently denied bots#Bots to make trivial wikicode improvements. Crouch, Swale (talk) 16:32, 23 September 2020 (UTC)

  Reducing barriers to entry is never "trivial", although it seems so when one looks only at individual isolated cases like this one. That's in fact the problem: For 19 years editors have seen no problem with adding thousands of bits of unnecessary complexity, one bit at a time, without considering the cumulative effect. If anybody was thinking long-term or "big picture", they were in a small minority and easily outvoted. ―Mandruss ☎ 17:25, 23 September 2020 (UTC)

  This isn't adding any more redirects than already exist, {{coordinates}} is currently redirecting to {{coord}}. --Lord Belbury (talk) 17:44, 23 September 2020 (UTC)

  Despite working with coordinates frequently for seven years, I wasn't aware of that redirect because (1) I have never seen it used and (2) being quite happy using template names in my coding, I don't bother investigating available redirects. If we perform this move, many average editors will prefer the longer name because that's the template name. After some passage of time, we will have a significant mix of the two names in coding, and new editors seeing that mix will have to learn that "coord" is merely an "alias" for "coordinates". That, combined with the thousands of cases like it, is neither a good use of editors' finite time and brain power nor conducive to editor retention. The project should not only stop this trend but start working to reverse it; in the meantime I will continue to oppose things like this when I see them. ―Mandruss ☎ 18:50, 23 September 2020 (UTC)

• Support per above. But I would like to echo Mandruss. It would be really great if [the more active] bots could be programmed to make this change together with another edit (I wouldn't really support a mass bot sweep simply to make this change alone). It will be annoying if both versions remain in use for years to come. Rehman 15:40, 23 September 2020 (UTC)

Comment: It will require over a million page edits to make this happen. This seems to me to be a ludicrous amount of effort for bot operators (mostly in programming, testing and debugging, but also in bot operation and supervision time) to devote to making a relatively tiny improvement in readability. -- The Anome (talk) 09:26, 30 September 2020 (UTC)

Thanks for the comment. I agree. Hence the reason that I do not support mass editing (of millions of pages) for this trivial change alone, but instead support gradually making the change together with other bot edits. Rehman 04:31, 5 October 2020 (UTC)

• Support as making wiki source more human readable. --Lord Belbury (talk) 17:44, 23 September 2020 (UTC)
• Strong oppose, as this will require all coordinate maintenance bot/tool maintainers to jump through hoops re-writing lots of tools, for very little gain to human editors. Please note: Whatever you decide, please keep bot/tool operators in the loop, and give us at least a few weeks to make necessary preparations for the transition before any significant changes are made to articles, or there will be chaos as everything breaks. -- The Anome (talk) 08:54, 30 September 2020 (UTC)
• Oppose per The Anome, I can't see much benefit to this move. (t · c) buidhe 00:49, 4 October 2020 (UTC)
• Oppose I don't see the benefit either. The abbreviation "coord" seems widely understood in the English language and it's been used on en.WP for many years withough confusion. Kerry (talk) 01:58, 5 October 2020 (UTC)
• Oppose I don't see the benefit. The abbreviation "coord" seems to be more widely used in real life than its parent. A far more useful change would be to make this work. {{coord|51.41166,-0.07682|type:edu_region:GB_dim:100|format=dms|display=inline,title}}. As an editor I often will c&p a coord from a pdf- where the separator is invariably a comma. Programming wise the first unnamed parameter could be parsed and if a comma was found, the tail could be stripped,and placed in the second unnamed parameter and the parse started afreshClemRutter (talk) 10:43, 5 October 2020 (UTC)
• Support - "Coord" is nothing more than an unnecessary use of a colloquial term used in western countries. Also, "coordinates" is very significantly more common in real life: Google Trends (@ClemRutter: per your !vote). ItsPugle (please ping on reply) 23:20, 19 October 2020 (UTC)

For "western countries" read "anglophone countries". This is the English language Wiki and therefore needs to follow English language usage. Martin of Sheffield (talk) 08:11, 20 October 2020 (UTC)

@Martin of Sheffield: Absolutely. Based off List of countries by English-speaking population, the three largest English-speaking countries more commonly use "coordinates" than "coord": United States, India, and Pakistan. ItsPugle (please ping on reply) 01:34, 21 October 2020 (UTC)

@ItsPugle: – Ah a case of "lies, damn lies and statistics"! If you sort the table on the list on "As a first language" you get quite a different set. For fun also have a look at the percentage column, it's radically different again. I'd also treat your data with a pinch of salt (no make that a bucketful). What you are showing is a count of search terms recorded by Google in the last year. This raises a number of questions: do people search on the familiar or on the unfamiliar? Do people try for fomality when searching? Google is not the only search engine out there. Is just a single year's data really meaningful? In short, an interesting excercise, but a long way from being any sort of definitive answer, sorry. Martin of Sheffield (talk) 07:32, 21 October 2020 (UTC)

@Martin of Sheffield: We are the English-language Wikipedia, not the English-as-the-first-language Wikipedia. The prominence or order in which someone uses English is of literally no relevance, and only perpetuates the detrimental American and Eurocentric biases that plague this Wikipedia. Also, Google Trends is a well-tested and well-used test for commonality; to suggest otherwise undermines the convention that is the cornerstone of pretty much every single requested move that's based on the common name policy. Of course Google Trends is not a definitive answer, but it's extremely effective in assessing commonality, and it's absurd that you're trying to minimise the clear-cut evidence about common terms because of statements like "Google is not the only search engine out there" - of course not, but it accounts for 92.3% of the market. We do not need to have an in-depth analysis of search engine query trends to see the simple fact that "coordinates" is searched more often. ItsPugle (please ping on reply) 05:00, 22 October 2020 (UTC

@ItsPugle: – We're never going to agree on this one are we? Let's try and keep in mind though that this is a discussion about a template name, not an entry in main space. You may have an obsession about "American and Eurocentric biases" (what about Canada, Australia and New Zealand?) but most people employing templates in writing articles are likely to be anglophone-first. In passing, "Eurocentric" is a bit odd, the European continent has its own mix of languages, related to but distinct from English. Anyhow to return to the point, I still seriously doubt the relevance of general internet searches to the small specific case of a template name. Can we both agree to WP:JUSTDROPIT? Martin of Sheffield (talk) 07:43, 22 October 2020 (UTC)

@Martin of Sheffield: I don't see why we can't come to any agreement here? Haven't we already, by both of us saying that we should be following English language usage? The principle, using the most common name (and therefore the most predictable name) is not exclusive to the main namespace. And to quote our very own article on it, Eurocentrism is not exclusively about modern European nations, it's the broader set of western countries. Just because we have a systematic overrepresentation of native English speakers versus all English speakers, that doesn't mean that we should be perpetuating that Eurocentric systematic bias. And as I mentioned, these statistics are evidence about what English language looks like in the real world - it shows that "coordinates" is expansively more common than "coords". ItsPugle (please ping on reply) 10:50, 22 October 2020 (UTC)

• Oppose a far more fundamental restructuring of the template is required. The template with its positional based parameters is practically incompatible with the Visual Editor and Template Data (just look at the very convolved nature of Template:Coord#Template Data). If we are going to do a fundamental and wide-ranging change to the template we should do it fully, using a more modern syntax, with named parameters. We could have {{Coordinates}} with a modern syntax and keep {{coord}} with its archaic syntax.--Salix alba (talk): 11:27, 22 October 2020 (UTC)

Now that is a good idea. It keeps a nice short name with minimal typing for those of us who prefer text entry, and allows the WYSISYG users to do their own thing. Martin of Sheffield (talk) 14:49, 22 October 2020 (UTC)

Questions

• Question - what is the "coordinate" module that has been referrred to multiple times above? Fob.schools (talk) 15:45, 23 September 2020 (UTC)

  As shown in the doc for Template:Coord, it is Module:Coordinates. --Redrose64 🌹 (talk) 20:39, 23 September 2020 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Visual clash with Template:Attached KML

When {{Attached KML}} is called with "display=title" it adds a "Route map" dropdown link to the top right of the article, but passes nothing to the API (eg. https://wiki.riteme.site/w/api.php?action=query&prop=coordinates&titles=Wall%20Street shows that Wikipedia's API can't say where Wall Street is). Adding a display-title {{coord}} to the same article will help the API out, but the coordinate display will overlap the dropdown link, and seems enough reason not to do it.

Is there a way around this? Is there a method of including a {{coord}} template so that it passes the coordinates to the API but doesn't attempt to display coordinates in the title strip? Could {{Attached KML}} include an additional parameter of a single coordinate point that it can pass to the API as the article's single-point location? --Lord Belbury (talk) 15:37, 27 August 2020 (UTC)

Lord Belbury, "Is there a method of including a {{coord}} template so that it passes the coordinates to the API but doesn't attempt to display coordinates in the title strip?" no.

"Could {{Attached KML}} include an additional parameter of a single coordinate point that it can pass to the API as the article's single-point location?" That should not be hard to implement, anyone is welcome to do so. Although i'd say perhaps it should fork out to the Module:Coordinates template instead, which would do this for it. —TheDJ (talk • contribs) 14:28, 16 November 2020 (UTC)

Clarification of what "=title" achieves

I've found a user removing the "title" from coord tags on military conflict articles because it "doesn't need to be in two places", and telling me that they recommended this practice as standard for Infobox military conflict back in January because they believe title to be "now redundant especially on mobile and tablet formats/browsers".

This documentation should be clearer about what effect the title option has: anyone reading it would be forgiven for thinking it was just about whether the coordinates were displayed at the top of the article. But it's also (and arguably much more importantly) about specifying a single, definitive set of coordinates for an article, for the purposes of API queries and services like Special:Nearby. If an editor removes the title coordinates from an article for aesthetic reasons, a basic API query about that article can no longer say where it is. --Lord Belbury (talk) 17:05, 28 October 2020 (UTC)

Lord Belbury, i've added a small note on this to the docs page. Improve on it if you so desire. —TheDJ (talk • contribs) 14:23, 16 November 2020 (UTC)

Thanks. I've added it to {{Coord how-to}} as well, since this is acting as an overview. --Lord Belbury (talk) 14:37, 16 November 2020 (UTC)

Shape overlays of places with an area?

At Georgetown University, clicking on the coordinates displays not just a point, but an overlay of the area occupied by the university. I don't see anything different in the code at the page, though. Does anyone know how this is happening and how to replicate it for other pages? {{u|Sdkb}} ^talk 03:01, 2 November 2020 (UTC)

Moved to Wikipedia:Village pump (technical)/Archive 185 § Trouble importing map outlines from OSM

 – {{u|Sdkb}} ^talk 18:38, 6 November 2020 (UTC)

@Sdkb: I see you managed to get overlays using Kartographer, but to answer your original question, WikiMiniAtlas says that "Some shape overlays are extracted from the OSM database and obtained through the WIWOSM project." So I imagine you'd have needed to add the Wikidata item to the relevant object at OpenStreetMap. Opencooper (talk) 16:24, 17 November 2020 (UTC)

I can't replicate the instance, but the description reminded me of the description we are trying to improve at The schools infobox template, and the maplink, mapframe discussed there. which may give a few leads! ClemRutter (talk) 17:26, 17 November 2020 (UTC)

ClemRutter and Opencooper, thanks both for replying. The outlines eventually started showing up at Claremont Colleges#Colleges, but I'm still unable to get the coordinates to work. To replicate the issue:

1. Go to Georgetown University on desktop, and click on the globe icon either at the top right or in the infobox. Notice that it displays the campus borders, not just a dot.
2. Go to Scripps College and try the same thing, and it does not, even though Scripps also has its borders marked on OSM.

{{u|Sdkb}} ^talk 18:41, 17 November 2020 (UTC)

While the Scripps page didn't have any coordinates, I tried the same at Pomona College, and you're right, the outline doesn't show despite OSM having the outline as well as the Wikidata ID linked. It seems the problem is at the WIWOSM end, as Georgetown shows, but Pomona doesn't neither by page title nor Wikidata ID. According to the documentation, WIWOSM does a partial update nightly and a full update every Wednesday, so I'm not sure why it's not being picked up. Opencooper (talk) 19:44, 17 November 2020 (UTC)

Opencooper, wiwosm is pretty much unmaintained at this point —TheDJ (talk • contribs) 19:56, 17 November 2020 (UTC)

Hmm, apparently my IP address is blocked on WIWOSM and there's no way to appeal. Would someone mind dropping a note at https://wiki.openstreetmap.org/wiki/Talk:Wiki to see if anyone there can help? It's becoming more common for colleges at OSM to be linked to WIkidata, so this issue is presumably affecting quite a few pages. {{u|Sdkb}} ^talk 20:24, 17 November 2020 (UTC)

"Unmaintained" is certainly one way to put it. "Has a 2.8 GB error.log file that was created a month ago" is another. It looks like it hasn't been working correctly for at least a month, so I wouldn't expect it to have processed any OSM data from before then. Kolossos appears to have made some changes to the error-spouting code on July 21 2020, so I'd guess that's when the problem started. Your best bet would be to contact them or one of the other maintainers. --AntiCompositeNumber (talk) 23:09, 17 November 2020 (UTC)

AntiCompositeNumber, there has also been a reimport of all OSM data over the last weeks, so that probably possibly didn't help either. —TheDJ (talk • contribs) 09:17, 19 November 2020 (UTC)

AntiCompositeNumber and TheDJ, I pinged the maintainers I could find but it looks like there haven't been any updates. I finally managed to create an account on OpenStreetMap and dropped an invite there, so maybe that'll get some attention on this. {{u|Sdkb}} ^talk 21:20, 3 December 2020 (UTC)

I have added the line | coordinates = {{Coord|34.102|-117.712|display=inline|type:edu}} into the infobox at Scripps College, the page has to display this infomation or wait until someone adds it to Wikidata (another chamber of mysteries). This at least displays the tiny globe, but when clicked the map is at the wrong zoom.ClemRutter (talk) 19:51, 17 November 2020 (UTC)

Oops, sorry, I chose the wrong example for Scripps; thanks for fixing it up. {{u|Sdkb}} ^talk 20:15, 17 November 2020 (UTC)

I have had a look at Pomona College, I found coord, removed type:edu and forced the dimension with dim:1000.

| coordinates ={{Coord|34|05|53|N|117|42|50|W|dim:1000|display=inline,title}}

We are partially there- workable but not exactly what you wanted. I have reached the limit of my expertise, so will bow out now. Let us know what happens. ClemRutter (talk) 20:57, 17 November 2020 (UTC)

Decimal degree formats

Template:Coord currently supports only dms and dec display formats. The United States Geological Survey and the National Geodetic Survey provide degree coordinates with seven decimal places. If a user enters degree data with seven decimal places, Template:Coord can only display all seven decimal places or convert to dms format. Either of these display options implies greater accuracy than normally desired. The user can hyphenate truncate the data to fewer degree decimal places, but this creates a mapping offset and creates some difficulty checking source data. If Template:Coord could provide decimal degree display hyphenation truncation format options, this problem could be eliminated. I suggest that in addition to the dms and dec format options, Template:Coord provide dec0, dec1, dec2, dec3, dec4, dec5, and dec6 format options to limit the implied accuracy of decimal degree displays without requiring user hyphenation truncation. Yours aye,  Buaidh  talk contribs 08:46, 19 February 2021 (UTC)

What exactly do you mean by the terms "hyphenate" and "hyphenation"? Presumably, you mean that a hyphen is inserted into the figure, as in 12.1234-567 but this looks very odd (and I don't think that it can sensibly be parsed); so please give examples of what you mean precisely. --Redrose64 🌹 (talk) 13:21, 19 February 2021 (UTC)

I'm guessing that Buaidh meant "truncate", not hyphenate. Truncating or rounding is the appropriate solution, based on the guidance provided at Wikipedia:WikiProject Geographical coordinates#Precision guidelines, which is linked from the documentation for this template. 0.00001°, for example, gives a location to within one meter; it is rare that greater precision would be necessary. Editors should follow the guidance. – Jonesey95 (talk) 16:19, 19 February 2021 (UTC)

I am so sorry. I meant truncation rather than hyphenation. I was apparently afflicted by a brain cloud.

I feel that Template:Coord should be doing any required display truncation rather than imposing this on the user. I also feel that dms is a rather archaic way to display latitude and longitude that Wikipedia should generally avoid. The dec4 display format is more concise and should be preferred for many applications. Yours aye,  Buaidh  talk contribs 16:50, 19 February 2021 (UTC)

I don't think the template can know how precisely to give coordinates. There are two considerations: how precisely are the coordinates stated in the source, and how precisely should they be stated, considering what the article is about. If the article is about a large country, a precision of 1 degree would be sufficient. If an article is about a lighthouse, which by it's very nature is a navigational aid, and its location is an essential feature, a precision of 10 m might be appropriate. And even if a high precision coordinate would be appropriate, we shouldn't give more precision than is available from the source. Jc3s5h (talk) 17:28, 19 February 2021 (UTC)

If Buaidh has a proposal to make about a preferred format for coordinates in Wikipedia, this template's talk page is not the place to make that proposal. I suggest starting at the talk page for the WikiProject linked above. As for providing precision limits via this template, please make a more detailed proposal about how to do that and how it would interact with things like maps, infoboxes, and links to GeoHack, all of which use the coordinates for mapping. It gets pretty complex pretty fast. – Jonesey95 (talk) 18:04, 19 February 2021 (UTC)

Template:Coord currently creates a GeoHack hyperlink with whatever location precision the user provides. For mapping, the greater the location precision the better, so it is not a good idea for the user to truncate location data. The user should be able to choose a preferred display format per the Geographical coordinates precision guidelines without having to truncate location data. Yours aye,  Buaidh  talk contribs 18:50, 19 February 2021 (UTC)

Migrate from WikiMiniAtlas to Kartographer

@Xaosflux, Mike Peel, and TheDJ: It's been two years since the last discussion about migrating the coord template from WikiMiniAtlas to Kartographer. Is there anything standing in the way of this happening other than just someone taking the time to implement it? The community is pretty familiar with Kartographer at this point, and WMA feels like an anachronism (not to mention the privacy and uptime issues). Kaldari (talk) 00:45, 6 March 2020 (UTC)

Also, I just noticed that all 3 of you have been editing Wikipedia for 14 years! Weird. Kaldari (talk) 01:09, 6 March 2020 (UTC)

@Kaldari: I suspect that just getting implementation ready, announcing it for feedback, and doing it is needed. Not sure how many odd edge cases may be impacted (Well my MSIE 4.0 browser worked before!, This doesn't work on my 1999 Blackberry now!, etc). — xaosflux ^Talk 01:18, 6 March 2020 (UTC)

Kaldari, i personally think we can switch tomorrow, but I also think the community will find 10 things they don't like about the change and I don't want to be having that debate. Last time (somewhere on VPT/T, can't find it atm) some of the objections raised were:

1. No support for object highlighting (see New_York_City with WMA). (should be doable with qid, but existing uses often don't pass qid, while WMA does auto lookup based on article title against WIWOSM)
2. Its slower
3. It takes me longer to open google maps this way
4. We lose the link to geohack (some people don't want the link to open the map directly). I think we since added it to External maps section because of that.. .
5. We lose the flexibility of geohack, because external maps in Kartographer are in the source repo instead of on {{GeoTemplate}}. See also: phab:T152971 —TheDJ (talk • contribs) 09:49, 6 March 2020 (UTC)

"object highlighting" i think this actually is sort of supported, it's just untested and only works for display title transclusions of it. —TheDJ (talk • contribs) 10:45, 6 March 2020 (UTC)

I think I fixed this. Check Template:Coord/testcases#Tests_of_qid. Would be nice if we did auto marker symbol matching for QID instance of. —TheDJ (talk • contribs) 13:43, 9 March 2020 (UTC)

Very nice! Kaldari (talk) 15:16, 9 March 2020 (UTC)

@Kaldari: Also added support for "format" param now, which I just realised was missing before. —TheDJ (talk • contribs) 15:51, 10 March 2020 (UTC)

And there isn't client-nojs fallback yet. —TheDJ (talk • contribs) 12:38, 6 March 2020 (UTC)

Thanks Derk-Jan, that's a very helpful list! Kaldari (talk) 18:09, 6 March 2020 (UTC)

So as some might have noticed, I invested some more time in this possible transition. I think biggest open question left from the template point of view (aside from some potential issues in Kartographer) are the microformat and the CSS support to always show Decimal or always show DMS. We have had discussions before about getting rid of the latter as very few people seem to be using it and it adds quite some bytes and complexity. The microformat however... not so much.. but do will still want it ? I feel microformat has been losing ground considerably... I'm also not even sure what a 'valid' format is supposed to look like these days. Ours seems to be the 'pre-standardization' one and well.. even in 2009 people said it wasn't valid geo microformat... —TheDJ (talk • contribs) 00:19, 11 March 2020 (UTC)

@TheDJ: In case it wasn't noticed, if the module is transitioned to Kartographer then the coordinsert and coord2text functions will have to be dealt with. I don't really know how these functions should be handled post-transition, especially since both of them rely heavily on the format of {{Coord}} output strings. Particularly since Kartographer only handles Earth coordinates, I suspect both of them might actually have to be retained to avoid breaking things. Jc86035 (talk) 13:26, 12 March 2020 (UTC)

Jc86035, yeah still trying to figure out how that works. But it's part of why I said people shouldn't do that kind of 'trickery' in the first place. —TheDJ (talk • contribs) 15:53, 12 March 2020 (UTC)

Checked it out, as predicted not doable to support that hack. rewriting geojson etc, i'm not implementing that.. Why don't we run a bot to make sure the content has the right parameters (like it should in the first place), instead of rewriting it ? —TheDJ (talk • contribs) 16:31, 12 March 2020 (UTC)

@TheDJ: I think it would be a good approach (both for the Kartographer coordinates and the remaining celestial coordinates using GeoHack). It should have been done to begin with, but I think at the time WP:COSMETICBOT was the main factor in the injection being implemented instead (though the bot ultimately ended up making hundreds of thousands of edits anyway). Alternatively, injection could be allowed for simple cases like a single marker. I think what happens could depend on how much of the current metadata gets kept – considering that it predates Wikidata and no one really seems to care about it all that much, it could potentially be eliminated entirely following community consensus.

In retrospect it would probably have made more sense to implement a coordinates format that could be easily entered in one template parameter, e.g. DD.xx/DD.xx or DD/MM/SS.xx/DD/MM/SS.xx. I think if a lot of pages are going to have to be modified anyway it could potentially make sense to further reduce the amount of complexity by invoking Module:Coordinates directly from the infobox templates without going through {{Coord}}, but this would be a lot of additional work and it would probably be rendered moot in some years anyway. Jc86035 (talk) 17:40, 12 March 2020 (UTC)

I think we need to output a geohacks link somewhere, because otherwise all kinds of geo tools break because they in turn depend on Wikipedia-World, which apparently uses gehack links to built its database (can't that thing be rewritten to use the GeoData tables) ? —TheDJ (talk • contribs) 12:01, 13 March 2020 (UTC)

I have a dumb question: why does replacing WMA with Kartographer get rid of geohack? I thought WMA was accessed by clicking on the little globe, while geohack was accessed by clicking on the coordinate string itself. What am I missing? — hike395 (talk) 14:18, 14 March 2020 (UTC)

Hike395, the little globe will not be present on kartographer links, as Kartographer already presents its own map and already has an icon. Personally I really don't see the need to confuse people with a gazillion options and i'd like people to put more effort in the core software so that EVERYONE can benefit, not just the few privileged language versions that had a few volunteers that built something 10 years ago. And it would require adaptations to WMA to make it work. I don't think it is needed. —TheDJ (talk • contribs) 11:23, 23 March 2020 (UTC)

TheDJ --- speaking as an avid reader of geographic articles, I never click through on the WMA globe, so if that goes away, I won't care. However, I would be unhappy if the geohack links go away. For US Mountain articles, I often look at the CalTopo links, e.g., [3]. I've recently spent many happy hours exploring Wales clicking through to the Bing Ordnance Survey maps, e.g., [4]. The large number of options in geohack serve a lot of different information needs --- I would be careful of deactivating that without understanding its broad usage. — hike395 (talk) 15:41, 23 March 2020 (UTC)

Hike395, you can reach geohack from the "External services" menu of Kartographer. And we can always make a gadget for 'the select few' who need it at their fingertips. don't you think? —TheDJ (talk • contribs) 16:22, 23 March 2020 (UTC)

Personally I'd hate to loose the options provided by GeoHack. More importantly the new system doesn't seem to handle decimal minutes. I've added the official position of the Old Head of Kinsale lighthouse, 51°36.287′N 8°32.018′W (as tested on Template:Coord/doc) and get sent to 1°60'S 2°3'W. Martin of Sheffield (talk) 16:45, 23 March 2020 (UTC)

Martin of Sheffield, you are not losing them, they would move.. I'll give you a gadget with a nice big "Take me to geohack button" right in the page if you want. —TheDJ (talk • contribs) 19:51, 23 March 2020 (UTC)

Martin of Sheffield, "More importantly the new system doesn't seem to handle decimal minutes." I didn't even know the format existed. Thanks for adding it to the testcases.. It seems to work fine for me however... is this only in the kartographer dialog that it is sending you to the wrong place, or with a particular external service ? —TheDJ (talk • contribs) 19:58, 23 March 2020 (UTC)

FYI decimal minutes are standard for navigation. 1 minute of latitude is one nautical mile (let's not go down the BIPM vs sailors argument) so a tenth of a minute is one cable. Charts have the latitude scale on the sides in degrees and decimal minutes which makes both plotting and measuring simple. Even the French use the system, and they're home to the BIPM! I've just retested the Old Head and it now seems to be working, strange. I've also added the other decimal minute example which is in the eastern hemisphere and was sent to 1°-1'S 2°3'W. However, that was in preview, once submitted it seems to be OK. Martin of Sheffield (talk) 20:28, 23 March 2020 (UTC)

@Kaldari: I have added microformat and geohack fallback support for old scraping services. I also fixed a few problems with QID detection and autozoom. The last issues to deal with would be coord2text and coordinsert. —TheDJ (talk • contribs) 15:30, 13 November 2020 (UTC)

@Evad37: I know you have been working a bit on getting input from coord templates for the purpose of template:maplink. Maybe you have some ideas how we can improve the ideas of coord2text and especially coordinsert ? I was thinking preserving in the output the original input and then reparsing the template (with nosave option to avoid duplicate #coordinates registration) to modify it... But maybe you have better ideas ? —TheDJ (talk • contribs) 10:17, 17 November 2020 (UTC)

@TheDJ: It looks like there's an issue with {{coord/sandbox}} passing coordinate data to Module:Location map via {{Infobox settlement}}. I added an example at Template:Coord/testcases#Infobox. Thanks for your work on this! Kaldari (talk) 18:24, 3 December 2020 (UTC)

Kaldari, yeah the output format changed, so things depending on that, specifically coordinsert and coord2text subroutines by some infoboxes need to be fixed, which is basically the final holdup. But im unsure about the best approach to fix this yet. Its why i was so against such constructs being introduced, because it make template changes so hard. —TheDJ (talk • contribs) 19:54, 3 December 2020 (UTC)

Who can help us figure this out? Frietjes, Jackmcbarn, Evad37? Kaldari (talk) 18:13, 4 December 2020 (UTC)

What I've done for Module:Mapframe is to extract and parse the latitude and longitude from the geohack url itself, so it doesn't depend on the displayed output (which is important for making the module easy to reuse across different wikis). See the function util.parseCoords there. So that could fix coord2text, assuming we're keep the geohack url around for a while yet. - Evad37 [talk] 00:40, 5 December 2020 (UTC)

@Evad37: The entire point of this new version of {{coord}} is to migrate away from geohack. Surely there must be a better way to extract the latitude and longitude. Kaldari (talk) 01:19, 5 December 2020 (UTC)

@Kaldari: Here's what the module sees: <span class="plainlinks nourlexpansion" data-coord-values="coord|17.168|N|89.111|W|region:BZ|display=inline">?'"`UNIQ--maplink-00000002-QINU`"'?<span class="h-geo geo" style="display:none;"><span class="p-latitude latitude">17.168</span><span class="p-longitude longitude">-89.111</span></span><span class="coord-geohack" style="display:none">[//tools.wmflabs.org/geohack/geohack.php?pagename=Template:Coord/testcases&params=17.168_N_89.111_W_region:BZ]</span></span>Could we just leverage data-coord-values? Jackmcbarn (talk) 02:07, 5 December 2020 (UTC)

Actually, I think I like the spans better. I put a possible solution in Module:Location map/sandbox. To try it out with User:Jackmcbarn/advancedtemplatesandbox.js, edit Module:Location map/sandbox, set "Template name" to "Module:Location map", "Page title" to "Template:Coord/testcases#Infobox", and hit "Show preview". Jackmcbarn (talk) 02:21, 5 December 2020 (UTC)

@Jackmcbarn: I did some testing of your sandbox version and it seems to work well. Can we put that in place? Kaldari (talk) 18:05, 7 December 2020 (UTC)

@Kaldari:  Done Jackmcbarn (talk) 23:58, 7 December 2020 (UTC)

Jackmcbarn, I recently reworked that data-coord-values to output the input variables of the template. I was thinking of maybe using that for coordinsert. Haven't been able to work on actually making use of it however. —TheDJ (talk • contribs) 12:05, 10 December 2020 (UTC)

Kaldari, i had put the geohack link back into the sandbox as a hidden span already, because I know that some wmflabs tools are apparently also scraping that url from pages. It's not ideal, but it probably also wont' hurt too much to make use of that I guess. —TheDJ (talk • contribs) 12:04, 10 December 2020 (UTC)

@TheDJ: Now that all the major issues with switching to Kartographer have been fixed (AFAICT), what do you think about having an RFC to switch the templates/modules to the sandbox versions? Kaldari (talk) 01:45, 28 February 2021 (UTC)

Some questions on coordinates and sources

I'm working on San Félix–San Ambrosio Islands temperate forests and the related page Desventuradas Islands, and I'm having some trouble with the coordinates. I was trying to think about how to find the coordinate midpoint between San Felix and San Ambrosio, and I noticed Desventuradas Islands has a coordinate for the center of the archipelago. However, I have no idea how they sourced that information so that led me to a few questions:

1. What's the best way to flag coordinate in the {{coord}} template as needing a source? I tried using the Citation needed template, which caused a "citation needed" ref warning to float where the template was located in the markup (not in the title where the coords appear). I then tried writing text into the "source:S" parameter ("source:Source needed"), but that caused a template error.
   1. If there is already a way to use the template to indicate a source is needed can I propose that the documentation show how to do this?
   2. If there is not a way to do this, can I propose that we add a way to flag coords that need sourcing? May be mistaken here, but it seems like it could help with general data quality.
2. Also how to insert a reference to a non-wiki source that's not osgb or GNIS? No matter what we decide about (1), I think there needs to be more documentation and samples for the source tag, globe has quite a few nice examples with markup and output.
3. Is there a built-in way for Coord to calculate the midpoint of two (or more?) coordinates? I'm not suggesting it needs it, but if the capability exists, I'll probably leverage it for my use case here.

Thanks in advance for the help and answers! -Furicorn (talk) 00:32, 27 April 2021 (UTC)

Concerning the midpoint: {{coord}} can't do this, but this website can. --Redrose64 🌹 (talk) 12:04, 27 April 2021 (UTC)

@Redrose64: thanks, how would I cite that website as the source using the "source:" parameter? Or even better, cite the original coordinates of the individual islands to the Desventuradas Islands page, as well as citing the website for the midpoint calculation - is this sort of citation even possible? -Furicorn (talk) 19:57, 27 April 2021 (UTC)

I'm not saying to cite it - just that if you have the coords of two different locations, you can use that website to find the midpoint of those measured along a great circle. Coords rarely need to be sourced, except for features not visible on a map - such as shipwrecks. Island groups, being marked on most maps, shouldn't need sourcing since it's merely necessary to follow the coords link to a mapping site - it's self-evident. --Redrose64 🌹 (talk) 20:39, 27 April 2021 (UTC)

Thanks for explaining all that to me, I didn't take you to be saying to cite it, but all things being equal I'd prefer to cite. While I'll grant there's a case to be made that the locations of the islands are self-evident (although looking at the individual coordinates provided for each island, I couldn't tell you what they are in reference to because they don't always seem to be the centers of the island), I don't think it's necessarily self-evident how I derived the midpoint - and if the website turns out to have been wrong about the calculation, there's not some mystery about why the islands are listed with a weird coordinate. All that being said, on re-reading the docs for this template, I have found the preferred syntax for references is apparently the note parameter, as illustrated in this example

{{coord|52|28|N|1|55|W|region:GB_type:city|notes=<ref>{{cite web|url=http://www.fallingrain.com/world/UK/0/Birmingham.html|title=Birmingham}}</ref>|display=inline,title}}

If this is the preferred syntax for references, ok, but then I really think the source: coordinate parameter documentation should note this distinction, and somewhere in the docs there should be an explanation about when you would use source: instead of note=. And I still think the source: docs should be fleshed out and should include at least a couple usage examples. -Furicorn (talk) 04:42, 28 April 2021 (UTC)

The unthinkable- an additional input parameter to represent both lat and long

Can we consider having parameter where we can copy directly from OpenStreetMap-Address, the geotag which is in the format 51.37935,0.50727, into this template using CTRL-C-CTRL-V, and avoiding all the rigmarole of splitting it manually first.

My problem is that schools move, or require multiple sites on a maplink. Looking at an infobox -See the code.

{{Coord|51.37741|0.51693|type:edu_region:GB_dim:100|format=dms|display=inline,title}} | mapframe-custom = {{Maplink |frame=yes |plain=yes |frame-align=center |frame-width=270 |zoom=13 |type=point |coord={{Coord|51.3775|0.5174}} |marker=school |title=Main Campus |description= |type2=point |coord2={{Coord|51.372559|0.521114}} |marker2=school |title2=Lower School |description2=}}

I want to use the the first instance of coord to open a map- then walk the streets till I get the locations, and type {{Coord|51.3775,0.5174}} and {{Coord|51.372559,0.521114}} to add subsequent coords. Hunting and pecking for the comma, and replacing it with a pipe is a task more suited to a computer than me. Yes I want to use the first unnamed parameter for a different purpose! Yes it will affect millions of pages.

Question: Is there a need? Discuss.

Can it be done? If I type {{Coord|51.372559,0.521114}} I get a powerful error message. So no change needs to be made to the current template, we just need to trap the error- and parse the input string for the comma and either subst in a pipe instead of the comma and iterate the procedure. Or we split on comma. The internal variable lat = substring1, and long =substring2. All of this is far simpler than doing decimal to base 60 conversions!

Question: So can it be done? Discuss. ClemRutter (talk) 19:52, 14 May 2021 (UTC)

Question about adding parameters to existing templates

Greetings and felicitations. I've started adding "region" and "type" parameters to existing "Coord" templates in articles (e.g., here), but I am wondering: Is this desirable and useful? (A quick perusal of this talk page's archives didn't turn up anything that seemed germane.) —DocWatson42 (talk) 08:49, 14 May 2021 (UTC)

@DocWatson42: The type is a nice-to-have, but the region makes a big positive difference. If you follow the resultant links (42°14′5″N 87°51′3″W vs 42°14′5″N 87°51′3″W) you will see that the right-hand side of the page is very different - the one which specifies the reguion has a table giving a number of mapping services that are specific to the United States (such as National Weather Service), if not to Illinois. --Redrose64 🌹 (talk) 18:14, 14 May 2021 (UTC)

@Redrose64: Thank you. ^_^ How much difference does adding the population to the type help (where appropriate, and given that type is not very important)? Also, is it appropriate to reduce the precision of the data? I've seen coordinates to six decimal places after the integer for a municipality, when I know from playing around with Google Maps that four decimal places is sufficient to place a house. —DocWatson42 (talk) 03:23, 18 May 2021 (UTC)

The population basically determines the initial zoom level, as described at Template:Coord#type:T You can also reduce the precision to something that makes sense yes, but this is more delicate, as sometimes coordinates are retrieved from an official source and that can have an official precision. So it kinda depends. —TheDJ (talk • contribs) 09:15, 18 May 2021 (UTC)

@DocWatson42: I didn't mean that type is not very important, but that it's not essential. Having reached your chosen mapping service, the map is presented at a scale that is derived from the scale: parameter, and if that is absent it is related to the type: value, which itself could be modified by the population figure - but even if none of these are specified, the map will be at some default scale or other which will be chosen by the service concerned. Whether the scale was set by the scale:, by type:, or a default was used, virtually all of the mapping services offer a means by which you can zoom in or out, which may be by clicking on +− buttons, dragging a slider, or rolling your mouse wheel. --Redrose64 🌹 (talk) 17:17, 18 May 2021 (UTC)

@TheDJ and Redrose64: Understood. —DocWatson42 (talk) 01:48, 19 May 2021 (UTC)

Display changed?

Tracked in Phabricator
Task T281974

Why does this template now display lower in article titles? It used to well above any content, but now it appears to conflict with infoboxes in multiple articles, logged in and off. Anyone else noticing this? ɱ (talk) 04:09, 21 May 2021 (UTC)

Ditto. It seems like some site layout stuff was changed across the platform, e.g. text sizes for Categories and the font used in the code edit dialog (from what i can see). Something changed between yesterday today (between May 19 and 20 ish) that broke coord display in the title. -MJ (talk) 05:57, 21 May 2021 (UTC)

I just checked out a page using Chrome and it seems to be working there. Might be only broken in Firefox... -MJ (talk) 06:04, 21 May 2021 (UTC)

I use Chrome, definitely displays bad for me with it. ɱ (talk) 13:29, 21 May 2021 (UTC)

Here's a sample page, it seems to interfere with the top of infoboxes now. Narsingdi-5. I've seen it on many pages, and it's the same on Chrome and Edge, so it's not a browser issue. Canterbury Tail talk 13:24, 22 May 2021 (UTC)

@Canterbury Tail: Did you follow the link in the post below? --Redrose64 🌹 (talk) 19:20, 22 May 2021 (UTC)

Lots of other technical glitches at present, likely all related, see also Wikipedia:Village pump (technical)#Coordinates in title dropped down. -- P 1 9 9  ✉ 13:31, 21 May 2021 (UTC)

Use page indicators?

A couple times in the past (right after rollout in fact), there's been discussion about using the page indicators system for title displayed coordinates (see Template_talk:Coord/Archive_11#Use_page_status_indicator_for_coord?). This would have preempted the issue this past deployment regarding coordinates in title display.

I honestly don't know what it would take to do so, and haven't done any testing myself, but in that original discussion it seems like it's something that could be done. Is there any interest in doing so? I was asked at phab:T281974#7108371. Izno (talk) 19:09, 24 May 2021 (UTC)

Reasons i have heard were mostly: "we like how article badges and coordinates are on different lines". This issue might get a bit more weight on en.wp where article badges are relatively common (as the most developed wiki), so the header lines becomes cluttered more quickly. But is shouldn't be hard to change in principal. —TheDJ (talk • contribs) 14:06, 26 May 2021 (UTC)

Added it to both sandbox versions of the module. Shouldn't be much of a problem, though the fontsize might need some double checking (also why is there a span for the fontsize around that thing to begin with ? :P ) —TheDJ (talk • contribs) 14:29, 26 May 2021 (UTC)

@TheDJ: I know nothing. :^) If we're wrapping it in an indicator, the fact this module outputs Tstyles may be relevant regarding phab:T188443. I haven't checked to see if that's relevant... Izno (talk) 00:06, 30 May 2021 (UTC)

I changed {{coord/sandbox}} to use Module:Coordinates/sandbox rather than Module:Coordinates/sandbox2. That allows testing of the indicator procedure. I have put a test in my sandbox4 (permalink). The test shows the same problem that I have been battling at bnwiki, namely that coord2text does not work because {{coord/sandbox}} (when used with display=title) returns only a strip marker. The strip marker contains 37 characters as can be seen by previewing an edit of a sandbox containing only the following:

• {{#invoke:string|len|{{coord/sandbox|57|18|22|N|4|27|32|E|display=title}}}}

I say "only the following" because if you use display=title twice on the one page the output of the second occurrence includes an error message. It looks like the following which shows some work is needed (I replaced the 127 rubout character with ◆).

◆'"`UNIQ--indicator-00000004-QINU`"'◆<span class="error">◆'"`UNIQ--nowiki-00000005-QINU`"'◆: cannot have more than one primary tag per page</span>

At bnwiki I speculated that the problem shown in sandbox4 could be avoided if {{coord}} returned some hidden text with the coordinates that coord2text looks for. Izno could say what the preferred procedure to output hidden text is now.

• <span class="visualhide">40.1952500°N 44.5248167°E</span>

The problem can be seen by editing Mother Armenia and replacing all the content with the following

{{Infobox historic site
| locmapin = Armenia
| coordinates = {{coord/sandbox|40|11|42.90|N|44|31|29.34|E|type:landmark_region:AM|display=title}}
}}

Previewing shows "Lua error in Module:Location_map at line 408: Malformed coordinates value." If you delete /sandbox and preview again, a pushpin map is displayed with no error. Johnuniq (talk) 10:29, 8 June 2021 (UTC)

Module:Coordinates/sandbox2 does that already I think (basically relying on hidden geohack style data in the output). Since I changed both sandboxes to use indicators, that should be easy to compare. —TheDJ (talk • contribs) 13:16, 8 June 2021 (UTC)

Honestly, we should really switch to sandbox2 anyways. Even if it is in the geohack mode instead of the Kartographer mode (the default can be switched). —TheDJ (talk • contribs) 13:17, 8 June 2021 (UTC)

There is a massive difference between Module:Coordinates and Module:Coordinates/sandbox2 and I have no idea about the background. However, both Module:Coordinates/sandbox and sandbox2 show errors with my above Mother Armenia test. By the way, previewing <indicator name="coordinates">Hello</indicator> shows "Hello" in the indicator area, that is, in the title line at the right-hand edge, above the horizontal rule. However, {{coord/sandbox}} puts the coordinates below the horizontal rule. Is that intentional? Johnuniq (talk) 05:25, 9 June 2021 (UTC)

I'd like to avoid being ambitious with this change; I expect a negative reaction regardless, and throwing a Kartographer way of doing things might be too much at one time. Izno (talk) 17:38, 8 August 2021 (UTC)

(sr-only, and you would need to access the relevant TemplateStyles from its current home.) Izno (talk) 18:30, 8 June 2021 (UTC)

Ok, looking at this since there's been some pushing from Phabricator, I speculated that the problem shown in sandbox4 could be avoided if {{coord}} returned some hidden text with the coordinates that coord2text looks for. Izno could say what the preferred procedure to output hidden text is now. I think this approach is reasonable. No, it does not need sr-only, because it's being presented in two ways: one provided by the indicator and a second provided by the display:none span/div. (It's obviously not terribly clean but we're not going to get 'clean' here if we move these into indicators. #ohwell) We might even be kinder to whatever parser is in place and mark up the display none as if it were e.g. inline e.g. <span class=lat>Lat</span><span class=long>Long</span>. The sky's the limit when things are invisible. :D Izno (talk) 17:37, 8 August 2021 (UTC)

I have forgotten what this is about except that I responded to a request from bnwiki where something was broken and I see that I put a "Mother Armenia test" above. If you get closer to implementing something, and if wanted, let me know and I'll remind myself. Johnuniq (talk) 05:16, 9 August 2021 (UTC)

Summary of status quo: Coordinates display is broken in new Vector because of our current CSS. One possible way to fix it is to put the coordinates inside <indicator>. Without an adjustment to the module in concert with changing it to use an indicator, getting the coordinates from a certain page is not possible. Izno (talk) 13:14, 9 August 2021 (UTC)

Ah, how could I forget. So are you hinting that someone should investigate that? I'm busy but could look in a few days. Is your comment about Kartographer saying that the changes in Module:Coordinates/sandbox2 can be ignored for now? Johnuniq (talk) 00:11, 10 August 2021 (UTC)

Yes to the latter.

I was also reminded on Discord about bn.wiki's separate issue with the TemplateStyles not applying because indicators don't have a wrapping mw-parser-output due to phab:T188443 which we have to consider. Izno (talk) 04:01, 10 August 2021 (UTC)

As for investigating, I will look into it (too?). Izno (talk) 04:01, 10 August 2021 (UTC)

I have looked into this and have made the Johnuniq sandbox work along the lines presented. I just don't understand why it works. The entire display: none HTML element containing the coords for coord2text to consume isn't in the source HTML at all. What else needs to be tested to see if that screws anything else up? Consumption from a different page (if that's possible today?)? Izno (talk) 18:14, 10 August 2021 (UTC)

I haven't yet looked at the code or what should happen, but for what it's worth, the following is the expansion of {{coord/sandbox|57|18|22|N|4|27|32|E|display=title}} (about 1700 bytes!).

<indicator name="coordinates">
  <span class="mw-parser-output">
    <span class="coords-display" style="font-size: smaller">[[Geographic coordinate system|Coordinates]]: 
      <span class="plainlinks nourlexpansion">[//geohack.toolforge.org/geohack.php?pagename=A&params=57_18_22_N_4_27_32_E_
        <span class="geo-default">
          <span class="geo-dms" title="Maps, aerial photos, and other data for this location">
            <span class="latitude">57°18′22″N</span>
            <span class="longitude">4°27′32″E</span>
          </span>
        </span>
        <span class="geo-multi-punct">&#xfeff; / &#xfeff;</span>
        <span class="geo-nondefault">
          <span class="geo-dec" title="Maps, aerial photos, and other data for this location">57.30611°N 4.45889°E</span>
          <span style="display:none">&#xfeff; /
            <span class="geo">57.30611; 4.45889</span>
          </span>
        </span>]
      </span>
    </span>
  </span>
</indicator>
<span class="coords-for-coord2text" style="display: none">
  <span class="plainlinks nourlexpansion">[//geohack.toolforge.org/geohack.php?pagename=A&params=57_18_22_N_4_27_32_E_
    <span class="geo-default">
      <span class="geo-dms" title="Maps, aerial photos, and other data for this location">
        <span class="latitude">57°18′22″N</span>
        <span class="longitude">4°27′32″E</span>
      </span>
    </span>
    <span class="geo-multi-punct">&#xfeff; / &#xfeff;</span>
    <span class="geo-nondefault">
      <span class="geo-dec" title="Maps, aerial photos, and other data for this location">57.30611°N 4.45889°E</span>
      <span style="display:none">&#xfeff; /
        <span class="geo">57.30611; 4.45889</span>
      </span>
    </span>]
  </span>
</span>[[Category:Coordinates not on Wikidata]]

Johnuniq (talk) 03:56, 11 August 2021 (UTC)

I didn't say optimized ;). Probably will want to move the TStyles invocation to the display functions.

Cool, interesting that it shows up when it's output to ExpandTemplates. Izno (talk) 13:00, 11 August 2021 (UTC)

Merger impacted by template

Hi! Sorry if this is an incomplete question, I'm not 100% clear on what I'm asking. There's an open merger on Talk:Florida Agricultural Museum where The Grid mentioned that the geocodes might be an issue. I don't think this is a cancvass issue as it seems that the issue needs to be addressed regardless of whether the pages are merged since Old Florida Museum moved locations. This is a tech element I'm unfamiliar with. Is there a TPS here who can look into that? Thanks! Star Mississippi 19:38, 7 December 2021 (UTC)

I responded there. I don't see any problems. – Jonesey95 (talk) 02:24, 8 December 2021 (UTC)

Template data not working in Visual Editor following vandalism on the /doc page

I noticed that the coord template was not working in the Visual Editor, which usually means there is something wrong with the TemplateData in the /doc page. This was the case; some vandal had overwritten the page. I reverted the edit, but the template data is still not working in the visual editor. This is usually because a purge is needed. I purged both the /doc page and the template itself but still no joy. As the template is protected, does this purge need to be done to a template editor? Not being able to add coords in Visual Editor is a problem! Should the /doc page is protected just as the template page is, as vandalism can have a significant impact where there is TemplateData involved? Kerry (talk) 09:25, 3 January 2022 (UTC)

@Kerry Raymond: Great questions but without good answers. Re the purge, no, a template editor is not needed but I did it anyway (both Template:Coord and Template:Coord/doc). Sometimes a delay occurs, so if you try it again it may work. If it doesn't, I would ask at WP:VPT. Re protection: that's not something to be resolved for one template (although I would protect if problems are repeated). I guess that should be discussed at WP:AN to see if some definition of "high risk" could be established (number of transclusions > 1000?) for which indefinite semi-protection of the doc page was warranted. It's likely that such a discussion would conclude that there was no need yet. That is, wait until more problems occur. Johnuniq (talk) 09:56, 3 January 2022 (UTC)

TemplateData is programming code that should not live in the unprotected documentation page, IMO. It can (and probably should) be transcluded from a separate subpage, which can be protected. That would not require a site-wide discussion for this template, but a site-wide RFC leading to adoption of this structure as a universal practice would be worth pursuing. – Jonesey95 (talk) 14:33, 3 January 2022 (UTC)

That's a good idea. Kerry (talk) 08:21, 12 January 2022 (UTC)