Jump to content

Template talk:Coord

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Jackmcbarn (talk | contribs) at 02:07, 5 December 2020 (→‎Migrate from WikiMiniAtlas to Kartographer: re). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Related pages

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

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

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

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

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

See mw:GeoHack for details. – Jonesey95 (talk) 01:39, 1 March 2020 (UTC)[reply]
Thanks. --5.43.82.5 (talk) 22:50, 3 March 2020 (UTC)[reply]

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

You should probably ask at the Discussion page for the page linked above. – Jonesey95 (talk) 23:46, 3 March 2020 (UTC)[reply]
Done. --5.43.82.5 (talk) 01:45, 4 March 2020 (UTC)[reply]

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

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)[reply]
@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)[reply]
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)[reply]
"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)[reply]
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)[reply]
Very nice! Kaldari (talk) 15:16, 9 March 2020 (UTC)[reply]
@Kaldari: Also added support for "format" param now, which I just realised was missing before. —TheDJ (talk • contribs) 15:51, 10 March 2020 (UTC)[reply]
And there isn't client-nojs fallback yet. —TheDJ (talk • contribs) 12:38, 6 March 2020 (UTC)[reply]
Thanks Derk-Jan, that's a very helpful list! Kaldari (talk) 18:09, 6 March 2020 (UTC)[reply]

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

@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]

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

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)[reply]
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., [2]. I've recently spent many happy hours exploring Wales clicking through to the Bing Ordnance Survey maps, e.g., [3]. 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]
Who can help us figure this out? Frietjes, Jackmcbarn, Evad37? Kaldari (talk) 18:13, 4 December 2020 (UTC)[reply]
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)[reply]
@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)[reply]
@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)[reply]

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

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)[reply]
@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)[reply]
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)[reply]
Sounds good, I've moved the discussion here. — Preceding unsigned comment added by Getsnoopy (talk • contribs) 20:37, 4 April 2020 (UTC)[reply]
@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)[reply]
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)[reply]
{{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)[reply]
I agree strongly. The discussion will go nowhere without examples of the current and proposed format. – Jonesey95 (talk) 01:46, 5 June 2020 (UTC)[reply]
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)[reply]

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

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

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

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

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)[reply]
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)[reply]
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)[reply]
All fixed. Rehman 06:37, 29 May 2020 (UTC)[reply]

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

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)[reply]
How do I go about reporting this issue? WikiMaster111 (talk) 15:59, 6 June 2020 (UTC)[reply]
First port of call would be village pump. Keith D (talk) 16:19, 6 June 2020 (UTC)[reply]
Actually, the issue seems to be resolved. WikiMaster111 (talk) 16:25, 6 June 2020 (UTC)[reply]
This was reported more than an hour earlier at Wikipedia:Village pump (technical)#Coordinates. --Redrose64 🌹 (talk) 07:19, 7 June 2020 (UTC)[reply]

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

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

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://en.wikipedia.org/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)[reply]

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

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

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

  • 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)[reply]
    Bots and scripts, usually. --Redrose64 🌹 (talk) 19:24, 18 September 2020 (UTC)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • Happy to support any proposal which makes template names clearer — Martin (MSGJ · talk) 08:17, 23 September 2020 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • Support as making wiki source more human readable. --Lord Belbury (talk) 17:44, 23 September 2020 (UTC)[reply]
  • 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)[reply]
  • Oppose per The Anome, I can't see much benefit to this move. (t · c) buidhe 00:49, 4 October 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
  • 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)[reply]
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)[reply]

Questions

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.

Tag display=title doesn’t show in mobile site

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

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

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

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)[reply]
Possible solution (a free API) that does reverse geocoding: [4]. 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)[reply]

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

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

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

Moved to Wikipedia:Village pump (technical) § Trouble importing map outlines from OSM
 – {{u|Sdkb}} talk 18:38, 6 November 2020 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
Opencooper, wiwosm is pretty much unmaintained at this point —TheDJ (talk • contribs) 19:56, 17 November 2020 (UTC)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
Oops, sorry, I chose the wrong example for Scripps; thanks for fixing it up. {{u|Sdkb}} talk 20:15, 17 November 2020 (UTC)[reply]
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)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Coord&oldid=992399470"