Module talk:Coordinates

Coordinates
Coordinates
Coordinates	45°11′30.0″N 67°17′0.2″W / 45.191667°N 67.283389°W
Location

Coordinates
Coordinates
Coordinates	45°11′30.0″N 67°17′0.2″W / 45.191667°N 67.283389°W
Location

Examples

https://geohack.toolforge.org/geohack.php?pagename=Module_talk:Coordinates&params=

Archives

Archive 1

Archive 2

This page has archives. Sections older than 90 days may be automatically archived by when more than 4 sections are present.

coordinsert feature broken

This edit by Izno (talk · contribs) has broken the |coordinsert feature. Go to a page like Didcot, and compare the coords link at the bottom of the infobox (inline) with the one in the indicator slot at the top of the page (title). The inline one has the query string parameter params=51.606_N_1.241_W_region:GB_type:city(26920) whereas the title one has only params=51.606_N_1.241_W_. This tells me that the |coordinsert feature is broken. It worked just fine yesterday, when both links had the same query string. --Redrose64 🌹 (talk) 10:59, 5 February 2022 (UTC)[reply]

I've reverted and can confirm that it worked yesterday (TemplateSandbox). I have no idea what's going on or why.

The revert is also because of MediaWiki talk:Vector-2022.css#Interface-protected edit request on 5 February 2022. Izno (talk) 21:10, 5 February 2022 (UTC)[reply]

Thank you --Redrose64 🌹 (talk) 00:12, 6 February 2022 (UTC)[reply]

Izno, it looks like the coordinsert does some really hacky string parsing, so I think that's why your last change didn't work.

What do you think about keeping the existing markup but also adding the indicator (e.g retain the existing function body in addition to the new code. We'd use a different ID e.g. #coordinates-indicator instead of #coordinates for the newly added code.

I think having a separate ID for the indicator version would be useful, and it could then be hidden in older skins such as Monobook if we find that there are problems displaying the indicator there.

What do you think?

An alternative approach would be to refactor that coordinsert code to be more prone to HTML change, but I've read through that a few times now and am none the wiser. Jdlrobson (talk) 22:44, 10 June 2022 (UTC)[reply]

Starting to look. Again. Izno (talk) 22:15, 26 June 2022 (UTC)[reply]

Alternatively, since there are only ideas here that have been tried before, coord2text and coordinsert could be changed so they require a single invoke, instead of two right now. That would allow them to be called prior to the indicator being made and work that way. The main issue with that I can see is that would require changing probably around a million pages from two invokes (one inside the other) to one invoke.

Another option with coordinsert is to either require display=inline or a plain=yes parameter in the inner invoke. In both cases the indicator would not be added and coordinsert would work just fine. The benefit here over the former suggestion is that it would require less edits. (anyway, I have an headache, so probably wont answer anything until monday)--Snævar (talk) 11:31, 1 July 2022 (UTC)[reply]

I have looked some this week and have some comments:

Basically, coordinsert is entirely incompatible with placing the coordinates in <indicator>, since the coordinates are inside a strip marker when the coordinserting module sees it. There is literally nothing to be done here which preserves the wikitext in various and sundry places as it exists today. The only way we can move to indicators without accepting a "loss of precision" in the title URL is to change the million or more pages using coordinsert via infobox to add the URL adjustments directly in the mainspace wikitext, essentially as Snævar suggests. The second suggestion, to warn/alert/require on use of display-only coords inside a coordinsert is something that could be done, but would not correct the issue of a mismatch between indicator and non-indicator versions, only alert editors that there is link with slightly more information about the place which probably should be displayed but isn't. And this likely results in a similar scale of edits.
Not being in the habit of favoring such mass changes, my preference is that we make the change here anyway, and choose not to care about this 'loss of precision' in the URL in title versions. Users are still directed to a Good Enough external location at the end of the day. Perhaps someone can enlighten as to the parameters' exact importance for the final maps provider. (I coincidentally have the opinion that we should move everything to Kartographer, but that's a different story and not particularly relevant here.)
Regarding the bad display, I think we just bear with "bad display" during the deployment, and caching, and etc. Just yank it all out of the relevant .css pages. But if someone would like to suggest appropriate CSS in the meantime, be my guest.

Not so much stalled as "I have lots of things I'm interested in and this one is a hack or three so it really needs some motivation and I need to gather my thoughts to boot about coordinsert since I've now looked at it". ;) Izno (talk) 06:19, 2 July 2022 (UTC)[reply]

It's nothing to do with "loss of precision" (and I don't know where that idea came from), because coordinsert does not alter the lat/long values in any way at all. It's about the mapping services that are offered - compare these two URIs:

The _region:GB_type:city in the second one is what coordinsert adds. Now try following the links - the first one has a not-very-accurate generic map in the right-hand half of the screen (which sometimes comes up as a completely blank grey rectangle), the second provides a number of useful mapping services instead. I am concerned that the intent is to force the less-useful one upon us. --Redrose64 🌹 (talk) 20:10, 2 July 2022 (UTC)[reply]

'loss of precision' referring to the added parameters. As I said, the URL in the title is more or less fine, even if less useful.

I gave my recommendation: accept the less useful title coordinate URL, and if desired, warn users for coordinsert cases that have no inline version displayed, such that at least there is one more useful URL displayed on the page somewhere. New Vector title coordinates display is broken currently and we get a complaint a week about it; I'm sure you can estimate how many complaints we'll get when New Vector goes live and title display isn't fixed by then. Izno (talk) 22:51, 2 July 2022 (UTC)[reply]

@Izno Is there a reason why you can't regenerate the <indicator> tag like what I did at Module:Sandbox/BrandonXLF/2? – BrandonXLF (talk) 23:52, 2 July 2022 (UTC)[reply]

If you think you can get that to work with any real sandbox rather than invoking the module twice, go for it. Izno (talk) 00:00, 3 July 2022 (UTC)[reply]

I got it working at Module:Coordinates/sandbox. See the example at the top of this page. {{#invoke:Coordinates/sandbox|coordinsert|{{Coord/sandbox|53.528|N|0.893|W|display=inline,title}}|region:GB|type:city}} --> 53°31′41″N 0°53′35″W / 53.528°N 0.893°W – BrandonXLF (talk) 00:42, 3 July 2022 (UTC)[reply]

Test all the way, like in Template:Infobox UK place/sandbox and arbitrary other page. Izno (talk) 00:54, 3 July 2022 (UTC)[reply]

I edited Template:Infobox UK place/sandbox and moved the infobox from Totnes to User:BrandonXLF/B and changed the call from {{coord}} to {{coord/sandbox}}. It's working as expected. – BrandonXLF (talk) 01:05, 3 July 2022 (UTC)[reply]

Way to go, that's one issue down. I think we should stick a :not(.mw-indicators) #coordinates or something in front of the current CSS definitions with the intent to remove all the skin-specific styles at a later date. It will display in a somewhat different place in old Vector, but in new Vector the indicators are on the same line as siteSub without any CSS needed. Izno (talk) 04:06, 3 July 2022 (UTC)[reply]

Thinking about this problem and this problem now. Increasingly leaves me feeling like the :not solution is better than changing what is emitted on this point. Izno (talk) 05:29, 3 July 2022 (UTC)[reply]

And also thinking about Module:Attached KML which references the ID. Izno (talk) 17:10, 7 July 2022 (UTC)[reply]

Module:Attached KML should also be updated to use an indicator to be consistent with this module.

For the first problem, #coordinates { display: none; } will still work. Even if the coordinate indicator is the only indicator, the indicator container element gets a height of 0 when the coordinate indicator is hidden and it takes up no space at all.

For the second problem, it doesn't look like the custom CSS rules add any position rules, so once the position rules are removed, the top rules will just stop working, leaving the coordinates in the default position, which is fine. – BrandonXLF (talk) 04:39, 8 July 2022 (UTC)[reply]

Outstanding problems for indicators

√ Verify the solution proposed by BrandonXLF
√ Fix Module:Attached KML see sandbox
We need to apply :not( .mw-indicator ) to the current #coordinates CSS statements of the various skins
The font size for coordinates in indicators seems pinned to 85% now. As already come with their own font-size definition, it seems this now makes them smaller than before in monobook and vector-legacy. I favour just dropping the font-size line, I think that the coord were plenty small to begin with.
√ Move skin styles into Module:Coordinates/styles.css see sandbox
- Timeless: Positioning of this is open question, as we can't easily pin to the right of it's container due to not being within a relative content container.
- Minerva: Keep hidden for now
- Monobook: Keep in same spot as original
- Vector Legacy: Keep in same spot as original
- Vector 2022: Get rid of the absolute positioning and just put it left of other indicators
Deploy Module:Attached KML/sandbox
Deploy new Module:Coordinates/styles.css
Deploy new Module:Coordinates

Did I miss anything ? —TheDJ (talk • contribs) 13:45, 28 July 2022 (UTC)[reply]

As I've suggested above, we should remove the skin CSS entirely after the job queue works through the million transclusions. I don't really think we need to preserve current looks, and if we do, there probably should be a new consensus discussion, because from what I can see, the current look is based on a discussion of "oh it looks nice" and not necessarily considering CSS expectations from today (see from 15 years ago) when we also did not have the indicator extension. This also puts it inline with e.g. Template:Sky and the other adjustments I've recently made to remove the dozen #coordinates users broadly (though I think I've said basically none were using it appropriately somewhere since they weren't coordinates). Izno (talk) 17:00, 28 July 2022 (UTC)[reply]

Shall we move all CSS styling into templatestyles first or last ? —TheDJ (talk • contribs) 18:14, 28 July 2022 (UTC)[reply]

Looked into Attached KML a bit. First of all; half the functionality is gone, because there used to be links to open the kml in bing and/or google, but neither of that works any longer. So the only thing placed in the #coordinates is really a label. And then WMA hooks into #coordinates and somehow finds the kml in the page. So i switched it to make use of indicator, but i still need the #coordinates because otherwise WMA can't hook into it. :( but that shouldn't really a blocker for us I think. At least after the skin css has been fixed as proposed. —TheDJ (talk • contribs) 19:35, 28 July 2022 (UTC)[reply]

If I understand @BrandonXLF's solution correctly, we copy the output of the title element generation and store it in an HTML comment in the generated page, so that coordinsert can then find that comment and use the same html to generate its own element right ? The comment is then stripped from the final HTML by the parser after the template expansion stage ? It's a bit wasteful in terms of generated bytes by the template (probably counts toward total template expansion limit), but since this is only once a page, i guess for now it will do. —TheDJ (talk • contribs) 19:48, 28 July 2022 (UTC)[reply]

Checked, indicators do not show in VEs preview, so we don't have to account that into the styling statements. —TheDJ (talk • contribs) 19:54, 28 July 2022 (UTC)[reply]

Have all of the technical options for this been explored, esp related to vector-2022? The general community should be able to pick what they think is best for the readers, and they won't really care how it is accomplished technically. Some people are already unhapppy about tech people pushing reader layout, especially about that go-to-another-project language control being so prominent. Ideally, I'd like to see a few options that are technically supportable that can reviewed by the community. — xaosflux ^Talk 13:28, 29 July 2022 (UTC)[reply]

I've been asked again what the progress on this is (none). My advice is that we should simply hide them altogether, until the community figures out what they want to do with coordinates. —TheDJ (talk • contribs) 15:00, 23 August 2022 (UTC)[reply]

@TheDJ: I like this checklist. (What's needed to decide on positioning in Timeless? Is that holding other things up?) @Xaosflux: this seems by far the cleanest solution + is used by other large wikipedias; the alternate solution used on eu.wp also seems to be causing them challenges).– SJ + 14:33, 29 April 2023 (UTC)[reply]

If you are referring to the suggestion to remove content that editors have specifically added to pages "...hide them altogether", I don't think that's a great idea without more input. Quite sure local editors won't be happy with that as a solution. — xaosflux ^Talk 16:20, 29 April 2023 (UTC)[reply]

@Xaosflux: certainly not! I mean the checklist that started this subsection, for tagging coords as indicators. – SJ + 02:45, 30 April 2023 (UTC)[reply]

Think I've said this before, but the main part that should get some community input is for vector-2022: where do you want to see these coordinates on a page. A couple of options with mockups should make for an easy poll. — xaosflux ^Talk 04:36, 30 April 2023 (UTC)[reply]

I'd say 'to the left of the other indicators, on the same line as the sitesub' which is what fr.wp and other Wikipedias do. I don't care particularly, just want to protect us from having overlapping geodata again. – SJ + 23:08, 30 April 2023 (UTC)[reply]

Yeah, I like how frwp does their coordinates. Galobtter (talk) 10:04, 1 May 2023 (UTC)[reply]

I revived the indicator change in the sandbox. Some changes were made to the css to ensure 100% similar positioning. CSS for original however is still in place. This means we can do the template change without making a CSS cache mess and we can postpone actual CSS rework to when this change settles. —TheDJ (talk • contribs) 09:36, 21 May 2023 (UTC)[reply]

The Template:Coord template intersects articles' infoboxes/main text on Vector 2022 (default skin)

This request for help from administrators has been answered. If you need more help or have additional questions, please reapply the {{admin help}} template, or contact the responding user(s) directly on their own user talk page.

It appears as though the position of the template, when used under the display=title parameter, is absolute and cares little about neighboring infoboxes, images, or suspected article text. This issue has far reaching implications, as seen in articles such as Andaman_Islands, Operation Rheinübung, Aegadian Islands, Arabian Sea, or even the United States articles, particularly when page width is at its slim default. The issue is mitigated when other minimal templates such as Template:Main are used, but this may be more rare than common. I request administrator help as the Module in question is Fully Protected, in addition to my inability to suggest a concrete improvement/Template:Edit fully-protected to solve this objective issue. I already have slight troubles editing Templates, but a Module is out of my expertise. I suspect it has to do with adding margin/changing the CSS display type somewhere but I'll leave the details to whomever picks this up. ZaptorZap (talk) 02:14, 28 April 2023 (UTC)[reply]

Please see #Coordinsert feature broken up above, which already discusses this problem. —TheDJ (talk • contribs) 08:46, 28 April 2023 (UTC)[reply]

Oh, my bad. Sorry for the inapproproiate use of that template. ZaptorZap (talk) 10:16, 28 April 2023 (UTC)[reply]

I've noticed this a lot in the last two days. Coincidence, or has something changed lately? Any solution that avoids the overlapping would be an improvement. @Izno and TheDJ: the list of steps to fix indicators seems reasonable, are these waiting on new people to jump in or is there pushback elsewhere? – SJ + 14:03, 29 April 2023 (UTC)[reply]

No coincidence. The sitesub header (with From wikipedia the free encyclopedia) has accidentally disappeared in last weeks' release, further aggravating this problem. —TheDJ (talk • contribs) 14:27, 29 April 2023 (UTC)[reply]

I see, didn't notice that at first. Thanks to Izno for the hackaround. We can pray for better release testing + reversion for regressions... but this seems another mark in favor of the indicator switch. – SJ + 14:40, 29 April 2023 (UTC), 02:47, 30 April 2023 (UTC)[reply]

Updating this module to use Kartographer

Please see Wikipedia:Village pump (proposals)#RfC: Updating Template:Coord to use Kartographer. Galobtter (talk) 06:24, 10 May 2023 (UTC)[reply]

Lua errors

Recent edits to this module seem to have caused Lua errors to appear at a bunch of articles, such as Ferry Point International Bridge and Calvert Marine Museum * Pppery * _{it has begun...} 14:55, 21 May 2023 (UTC)[reply]

I think it's due to switching to use the indicator tag. If coord is just using "display=title" then Module:Mapframe isn't seeing the the geohack url to parse. You can get the same error if you just used "coordinates=x" in the infobox. The article can be fixed by changing the coord params to "display=inline,title" but the Module:Mapframe should be improved to fail more gracefully when it can't find a coord value. -- WOSlinker (talk) 15:22, 21 May 2023 (UTC)[reply]

Error handling aside, shouldn't that use case be supported? Presumably the same fix that worked for coordinsert above (which I don't fully understand) should work for this case too. * Pppery * _{it has begun...} 18:23, 21 May 2023 (UTC)[reply]

There does seem to be a row in the infobox though with just Coordinates as a title and a blank area to the right of that if just the display=title option is used. So another option is to move the coords outside of the infobox if just the title option is desired. -- WOSlinker (talk) 18:43, 21 May 2023 (UTC)[reply]

@BrandonXLF: in case you are interested in this. * Pppery * _{it has begun...} 18:24, 21 May 2023 (UTC)[reply]

@Pppery The error is caused by the call to frame:preprocess at Module:Mapframe#L-599, but I'm not sure why it's there in the first place. @Evad37 Do you know if it would be safe to remove the call to frame:preprocess? – BrandonXLF (talk) 10:00, 22 May 2023 (UTC)[reply]

This problem appears to occur in general when the rare |display=title is used rather than the much more common |display=inline,title. I set German Museum of Technology, which uses {{Infobox museum}}, to use |display=title, and it displays the error in preview. – Jonesey95 (talk) 14:21, 23 May 2023 (UTC)[reply]

LDS temples

I wrote the following before noticing this section, I guess this is the same issue?
A recent edit has led to "Lua error in Module:Mapframe at line 384: attempt to perform arithmetic on local 'lat_d' (a nil value)" in many articles (list), for example Helsinki Finland Temple which uses {{LDS Temple/Helsinki Finland Temple}} as in:

{{ LDS Temple/Helsinki Finland Temple |format= Infobox LDS Temple }}

I guess the problem is that {{Infobox LDS Temple}} includes {{coord|...|display=title}}. The article is somehow pulling the coordinates from Helsinki Finland Temple (Q2603891). I'm dropping this here as a start for others to continue an investigation. Johnuniq (talk) 08:02, 22 May 2023 (UTC)[reply]

Are you sure that the article is pulling "60°13'30"N, 24°46'54"E" from Wikidata and then displaying "Coordinates: 60°13′30.69479″N 24°46′54.42599″E", the value from {{LDS Temple/Helsinki Finland Temple}}? That seems like it is not happening. Regardless, removing |display=title from {{LDS Temple/Helsinki Finland Temple}} makes the Lua error go away, but then the coordinates do not appear at the top of Helsinki Finland Temple. – Jonesey95 (talk) 14:08, 23 May 2023 (UTC)[reply]

Yes, you are right. I didn't look hard enough. Pretty weird situation but it's not really satisfactory to leave 150 articles with a big red error due to the recent change to this module. Johnuniq (talk) 03:16, 24 May 2023 (UTC)[reply]

I've fixed those. I made sure all the "Template:LDS Temple/" subpages has type:landmark in their coords params, then removed coordinsert from Template:Infobox LDS Temple and then updated those that just had display=title to also have inline. -- WOSlinker (talk) 06:38, 24 May 2023 (UTC)[reply]

Thanks. I don't know how coordinsert works but you have probably seen my comment at 05:06, 24 May 2023 below where I mention that it receives an indicator strip marker rather than coordinates. I guess that some of its usages involve coordinates being directly passed to the function, while attempts to pass what Module:Coordinates produces will now fail. Johnuniq (talk) 07:18, 24 May 2023 (UTC)[reply]

Coord2text

I would like to call the function coord2text from another module. Can I make this change? — Martin (MSGJ · talk) 11:02, 22 May 2023 (UTC)[reply]

Seems like pretty straightforward change. —TheDJ (talk • contribs) 13:04, 22 May 2023 (UTC)[reply]

What purpose is there to being able to call that function in another module? Izno (talk) 21:45, 24 May 2023 (UTC)[reply]

I am using it to parse wikitext to extract coordinates which can then be imported into wikidata - want more details? — Martin (MSGJ · talk) 21:50, 24 May 2023 (UTC)[reply]

That's cool, but how is that useful onwiki? I can't see how that would be useful here. And I mean that in the sense of "what are you even doing" and not "oh, Wikidata, go away". :P Izno (talk) 22:07, 24 May 2023 (UTC)[reply]

Protected edit request on 24 May 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please revert to the previous version, per the above "Lua errors" discussion. Something in the most recent change appears to have broken the coord template's ability to accept |display=title, at least in some circumstances, leaving big red error messages in 100+ previously working articles. Since a fix has not been forthcoming, the module change should be reverted until the problem can be fixed in the sandbox. – Jonesey95 (talk) 03:43, 24 May 2023 (UTC)[reply]

Per our discussion at #LDS temples above, I agree that something needs to happen soon to remove those problems but I would like to see that there is a reasonable way to debug the situation if the module change is reverted. I've just spent 20 minutes staring at the changes. There are several good style fixes (that is, improvements to the Lua style of arranging the code) and only a couple of significant changes which I haven't yet digested. Johnuniq (talk) 04:06, 24 May 2023 (UTC)[reply]

I don't know enough about this module and Module:Mapframe to understand what is going on. Some poking around shows that the problem (Module:Mapframe at line 384...lat_d is nil) is due to the coords parameter which function util.parseCoords receives. Instead of being coordinates that it can parse, parseCoords receives an "indicator" strip marker and a category. That's because the new function displaytitle in Module:Coordinates puts the coordinates in an indicator although I don't know how Module:Mapframe gets that as its parameter. Something like the gsub code at function coordinates.coordinsert in Module:Coordinates is needed, somewhere. Johnuniq (talk) 05:06, 24 May 2023 (UTC)[reply]

WOSlinker's amazing edit (see 06:38, 24 May 2023 above) has fixed the problems so I disabled the edit request. The current list of articles with script errors shows six titles and none of them seem related to coordinates. Johnuniq (talk) 07:34, 24 May 2023 (UTC)[reply]

Groan. Now that I look more carefully, I see there are three problems:

These need investigation. Johnuniq (talk) 07:37, 24 May 2023 (UTC)[reply]

The first one uses {{WikidataCoord}}, which sets |display=title by default. I suspect that there are more articles with errors out there, but the job queue hasn't refreshed them so that they appear in the error category. Again, I recommend reverting the most recent change until this problem is fixed. Is there a downside to going back to the previous stable version? – Jonesey95 (talk) 14:44, 24 May 2023 (UTC)[reply]

@Jon (WMF) and @TheDJ for the above.

The two changes made to this module and to Module:Attached KML help fix the issue where the other icons near the coordinates (such as featured article icon) collide with the coordinates using the Vector 2022 skin. This is detailed at T281974. Reverting this change would cause the collision again on the skin used by most readers (being the default skin). IMO the previous state was not a great look, especially on the featured article for the day I made the edits where the coordinate text collided with the featured article star and was not centred with it.

Ideally I'd like to see the remaining templates be fixed as the errors are seen, especially as this would require reverting the changes here and also to Module:Attached KML. Plus the other changes to modules to support the changes here might have to be reverted. From what I can tell the three examples are now fixed based on the page history. Dreamy Jazz ^{talk to me | my contributions} 17:30, 24 May 2023 (UTC)[reply]

Sigh. Yes, I fixed those issues. But this edit has been objected to multiple times so should still be reverted, and I find the fait accompli WOSlinker did of adding inline coordinates to thousands of articles to work around the problem inappropriate. * Pppery * _{it has begun...} 18:48, 24 May 2023 (UTC)[reply]

I've made an edit to the sandbox (Module:Coordinates/sandbox and Module:Coordinates/sandbox/styles.css) with a version that fixes the Lua errors. The only downside is that it sends some more HTML to clients, but that isn't a big concern since there's only at most one coordinate with display title per page.

Code:

{{Infobox bridge
| coordinates = {{coord|45|11|30.0|N|67|17|0.2|W|type:landmark|display=title}}
}}

Current:

Fixed:

– BrandonXLF (talk) 19:45, 24 May 2023 (UTC)[reply]

Done I've made the fix Brandon suggested. Izno (talk) 21:33, 24 May 2023 (UTC)[reply]

Thanks for doing that. Hopefully this addresses the remaining issues. If there are future issues that need fixing, please feel free to ping me. Dreamy Jazz ^{talk to me | my contributions} 21:39, 24 May 2023 (UTC)[reply]