Module talk:Coordinates

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]

Addition of fallthrough coordinate to check for headquarters location on Wikidata

Noticed that University of Yangon exhibits the maintenance category of Category:Coordinates not on Wikidata, when it does have coordinates on Wikidata.

Searched for relevant discussions on Wikidata, and came across these https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2021/03#coordinate_location_(P625)_to_headquarters_location_(P159)_switch and https://www.wikidata.org/wiki/Wikidata:Project_chat#DeltaBot's_coordinate_location_(P625)_to_headquarters_location_(P159)_move.

It appears as though DeltaBot made mangled changes to Wikidata which Wikidata does not wish to revert (such as bulk converting coordinate location (P625) properties to headquarters location (P159), which have flooded the Category:Coordinates not on Wikidata page with erroneous spam). So, instead, the module check should be corrected on Wikipedia to reflect these changes. Therefore, I propose implementing here in the module a check for headquarters location (P159) after coordinate location (P625).

The code area begins on line 494. Additional checks should be added for qid, "P159" with identical parallel logic to the "P625" checks.

I will happily whip this up, but I do not have template edit rights here. Let me know, thanks. Top5a (talk) 05:31, 9 April 2022 (UTC)[reply]

Top5a, I'll shortly be poking at Module:Coordinates/sandbox, but not likely in the same place. You may make any changes necessary there. When you are done, use {{template edit request}} indicating the changes are in the sandbox. I don't see anything particularly wrong with adjusting the module to account for this issue.

It might be wise still to emit a category for the case where HQ location is present but primary coordinates are not, but I'll leave that for your consideration. Izno (talk) 22:20, 26 June 2022 (UTC)[reply]

Incompatibility between coordinsert and the name= parameter

Background: Template talk:Infobox UK place#The OS_grid_reference parameter. See this version of Hatfield Chase, the coords URI in the title is

https://geohack.toolforge.org/geohack.php?pagename=Hatfield_Chase&params=53.528_N_0.893_W_region:GB_type:city

and this is valid. However, with this edit, the coords URI in the title becomes

https://geohack.toolforge.org/geohack.php?pagename=Hatfield_Chase&params=53.528_N_0.893_W_&title=Tunnel+Pits_region:GB_type:city

which is not valid - the additional values for the params= parameter have been appended to the query string instead of being inserted at the appropriate place. This occurs because this code in Module:Coordinates:

	if args["name"] then
		uriComponents = uriComponents .. "&title=" .. mw.uri.encode(coordinateSpec["name"])
	end

is processed earlier than the

{{#invoke:Coordinates|coordinsert|{{{coordinates}}}|region:{{#ifeq:{{{crown_dependency|}}}|Isle of Man|IM|GB}}|type:city{{#iferror:{{#expr:{{formatnum:{{{population}}}|R}}*1}}||({{formatnum:{{{population}}}|R}})}}}}

line that is in Template:Infobox UK place. Is it possible to either (a) amend coordinsert so that the extra code is inserted (as per its name) rather than appended (as per what it actually does), producing this URI:

https://geohack.toolforge.org/geohack.php?pagename=Hatfield_Chase&params=53.528_N_0.893_W_region:GB_type:city&title=Tunnel+Pits

or (b) alter line 109 and anything dependent upon that so that the URI seen by coordinsert has the previous value of uriComponents last rather than first, producing this URI:

https://geohack.toolforge.org/geohack.php?pagename=Hatfield_Chase&title=Tunnel+Pits&params=53.528_N_0.893_W_region:GB_type:city

I am no Lua expert; I don't trust myself to write the proper patch. --Redrose64 🌹 (talk) 19:25, 8 June 2022 (UTC)[reply]

Redrose64 Should the name come last always? Or are there other URI parts that can come after? Izno (talk) 22:26, 26 June 2022 (UTC)[reply]

Hmm, according to our documentation

name= can be used to annotate inline coordinates for display in map services such as the WikiMiniAtlas. If omitted, the article's title (PAGENAME) is assumed. Note: a name= parameter causes {{Coord}} to emit an hCard microformat using that name, even if used within an existing hCard. Do not use when the name is that of a person (e.g for a gravesite), as the generated hCard would be invalid. Also, do not use square brackets in names.

Neither link is as expected if this is a true statement. Izno (talk) 22:43, 26 June 2022 (UTC)[reply]

And then the "do not use" instruction essentially contradicts that there is a default assumed. Izno (talk) 22:44, 26 June 2022 (UTC)[reply]

(edit conflict) In a URI, a query string begins with a question mark and ends with a hash character, or at the end of the URI if there is no fragment. The query string is made up of zero or more parameters separated by ampersands. A parameter is a name/value pair separated by an equals sign; an empty value is valid. So in my final example above there are three query parameters:

pagename=Hatfield_Chase
title=Tunnel+Pits
params=53.528_N_0.893_W_region:GB_type:city

and they may occur in any order. It is up to the server to interpret the value of each parameter, and the geohack server expects the value of a title parameter to be literal text, which is why for the second URI given above it's displaying "Tunnel+Pits_region:GB_type:city" - it doesn't know to do any different. --Redrose64 🌹 (talk) 22:47, 26 June 2022 (UTC)[reply]

they may occur in any order is sufficient. The |name= parameter seems to be functioning fine e.g. on Template:Prime meridian, so this may be something that cannot be fixed if it is not working on that page, but I will take a look. Izno (talk) 23:58, 26 June 2022 (UTC)[reply]

(b) is not possible (at least without a dramatic rearchitecting of how coordinsert does its work and wiki-wide scale change): Like templates, modules are expanded inside out, so coordinsert cannot be run before the content inside it is expanded.

Regarding (a), I think I can do this. However, that function also provides a totally separate parameter |name= to hold the name someone intends to add e.g. code similar to {{#invoke:coordinates|coordinsert|{{coord}}|key:value|name=Ipsum lorem}}. Consider if providing a passthrough parameter in the infobox instead will fix this problem satisfactorily. Izno (talk) 06:44, 27 June 2022 (UTC)[reply]

What could be done instead of (b) might be to move the title query parameter to the left rather than have it come last. Izno (talk) 06:46, 27 June 2022 (UTC)[reply]

I thought that's what I said - the URI seen by coordinsert has the previous value of uriComponents last rather than first, that is to say, coordinsert would see

https://geohack.toolforge.org/geohack.php?pagename=Hatfield_Chase&title=Tunnel+Pits&params=53.528_N_0.893_W

and amend that to become:

https://geohack.toolforge.org/geohack.php?pagename=Hatfield_Chase&title=Tunnel+Pits&params=53.528_N_0.893_W_region:GB_type:city

Was this not clear? --Redrose64 🌹 (talk) 20:28, 27 June 2022 (UTC)[reply]

It was not. Izno (talk) 21:28, 27 June 2022 (UTC)[reply]

city() is broken

The city(9,999) parameter seems to be broken now, currently rendering everything after the "(" inline; e.g., as "7,456)_dim:3875&title=Mount+Pleasant 32°01′42″S 115°50′56″E" instead of just "32°01′42″S 115°50′56″E"; see Mount Pleasant, Western Australia. Betterkeks (talk) 09:31, 3 July 2022 (UTC)[reply]

No it's not. Its because {{wikidata |properties |current |P1082}} on that page returns multiplevalues for thecity parameter. —TheDJ (talk • contribs) 09:39, 3 July 2022 (UTC)[reply]

@TheDJ: 🤦‍♂️ Thank you! Sorry to waste your time. Betterkeks (talk) 18:21, 3 July 2022 (UTC)[reply]

Allow custom error on empty coordinates

At the moment, when using {{Coord}}, if the coordinates are not available in Wikidata, it explodes with this red error message:

Coordinates: Missing latitude
Invalid arguments have been passed to the {{#coordinates:}} function

Instead, it could be nice to add an extra parameter to just silently ignore this error message. Something like {{Coord|error_message_no_coordinates=}}.

This will be very useful on use cases like {{Coord|error_message_no_coordinates=[[:Category:Bad coordinates]]}} since it allows easy embedding in templates and easy Wikidata integration.

Is it something that could be useful? --Valerio Bozzolan (talk) 15:54, 20 August 2022 (UTC)[reply]

@Valerio Bozzolan: Why would anyone use the {{coord}} template without including actual coordinates in it? (When one wants to draw on Wikidata for coords, one usually uses {{WikidataCoord}}, which produces the message "{{WikidataCoord}} – missing coordinate data" if coordinates are not present in Wikidata.) Deor (talk) 22:24, 20 August 2022 (UTC)[reply]

@Deor: I was interested in {{WikidataCoord}} but I think it has the same problem: it always generates a big red error when coordinates are missing (instead of being able to silently do nothing in that case, or just add a category), so at the moment it's not possible to add this template into an infobox, since it does not give backward-compatibility and will just spawn lot of errors in the encyclopedia. --Valerio Bozzolan (talk) 08:03, 21 August 2022 (UTC)[reply]

Valerio Bozzolan, maybe I misunderstand, but if you want to include {{coord}} directly in an infobox, you could test for the existence of the wikidata coordinates before attempting to display the template. See {{Infobox telescope}} for an example implementation. – Jonesey95 (talk) 11:05, 21 August 2022 (UTC)[reply]

@Valerio Bozzolan: If Wikidata doesn't have the coordinates for something and you can't manage to find them yourself, just refrain from adding any coordinate template to the article. The Anomebot2 will add a {{coord missing}} template to the article, and someone who patrols the relevant hidden categories (as I do) will eventually get around to adding them if they can be determined. Deor (talk) 14:12, 21 August 2022 (UTC)[reply]

OK. I think it could be very convenient to be able to have "universities without coordinates" in a category (instead of showing a fatal error). If this small feature is not acceptable here, no problem. I understand this point of view and another template can be made to do what I suggest. Valerio Bozzolan (talk) 19:37, 22 August 2022 (UTC)[reply]