Template talk:GeoGroup

Template-protected edit request on 12 March 2023 (add gpx)

Hi I have written a GPX exporter on toolforge: geoexport.toolforge.org Currently it doesn't support recursion, but it does support differentiation primary and secondary coordinates.

|-

|[//geoexport.toolforge.org/gpx?titles={{#if:{{{article|}}}|{{urlencode:{{{articlee|{{{article}}}}}}}}|{{FULLPAGENAMEE}}}}{{#if:{{{level|}}}|&coprimary=primary&l={{urlencode:{{{level|}}}}}}} GPX (primary)]

|-

|[//geoexport.toolforge.org/gpx?titles={{#if:{{{article|}}}|{{urlencode:{{{articlee|{{{article}}}}}}}}|{{FULLPAGENAMEE}}}}{{#if:{{{level|}}}|&coprimary=secondary&l={{urlencode:{{{level|}}}}}}} GPX (secondary)]

|-

|[//geoexport.toolforge.org/gpx?titles={{#if:{{{article|}}}|{{urlencode:{{{articlee|{{{article}}}}}}}}|{{FULLPAGENAMEE}}}}{{#if:{{{level|}}}|&coprimary=all&l={{urlencode:{{{level|}}}}}}} GPX (all)]

Reubot (talk) 12:03, 12 March 2023 (UTC)

Your proposed changes to the {{GeoGroup}} template are unclear, editor Reubot – can you place them in the [sandbox]? and perhaps they can be tested? P.I. Ellsworth , ed. ^{put'er there} 20:51, 13 March 2023 (UTC)

Hi, sorry I was unclear - my proposal is to add GPX export into the template using the tool I wrote. I've added my proposal to the sandbox https://en.wikipedia.org/w/index.php?title=Template:GeoGroup/sandbox&oldid=1144673478

Reubot (talk) 23:50, 14 March 2023 (UTC)

Curious as to why my "Save as" screen pops in and asks me if I want to save a file named gpx (no extension) when I click any of the links on the testcases page? P.I. Ellsworth , ed. ^{put'er there} 02:38, 15 March 2023 (UTC)

Hi, I've updated the scripts to use the titles as filename also the category tests should work now. BTW the source is at https://gitlab.wikimedia.org/toolforge-repos/geoexport Reubot (talk) 12:34, 15 March 2023 (UTC)

Okay, that does seem better, so let's see how it flies. And  edited. P.I. Ellsworth , ed. ^{put'er there} 23:18, 15 March 2023 (UTC)

Thanks, I plan to add more output formats in the future if people are interested. Reubot (talk) 09:35, 16 March 2023 (UTC)

When I run it from an article, it works OK; but run from my sandbox it produces an 'empty' file - ie it has <?xml...><gpt...></gpt>, but no contents within the gpt. Is this correct (if so, why?), an error in the extract, or is my sandbox using it incorrectly? -- Verbarson  ^talk_edits 21:48, 19 March 2023 (UTC)

What's displayed at thousands of articles has changed from a 2-line display "Map all coordinates using: OpenStreetMap" and "Download coordinates as: KML" to a 5-line display adding separate lines for "GPX (primary)" and "GPX (secondary)" and "GPX (all)". This is unacceptable, IMHO. The display now drapes down across section lines or it inserts big white-space rows.

It was bad enough that the option to download coordinates has long been advertised, which I personally have never ever heard of anyone anywhere wanting to do. (I happen to be a longtime editor on lists of historic places, and I just don't happen to know of anyone ever wanting to download coordinates. [Update: now I recall there's a local historical society in California which doesn't like Wikipedia's treatment of historic sites in its area, because Wikipedia editors do not accept that any and every cemetery, no matter how new and useless, is automatically to be deemed historic and Wikipedia-notable...and the editor involved has gone off to program mapping for the historical society's independent webpage... so, they presumably did "download" a few hundred coordinates, one time. Likely not by downloading to "KML", whatever that is, but rather by editing down the source code of several list-articles. Or maybe they got them from Wikidata. --Doncram (talk,contribs) 22:40, 21 March 2023 (UTC)] That seems incompatible with readers reading Wikipedia. Wikipedia is for readers, not, I dunno, startup gaming firms wanting to acquire coordinates to use somehow in a new computer game? Sorry my ignorance is showing, if there do exist any reasons why normal readers would ever, much less frequently, want this. Are gaming firms or whomever among "normal readers", maybe that could be argued?)

Actually Doncram it is quite useful for requested photographs, eg Category:Wikipedia_requested_photographs_in_Queensland . Reubot (talk) 01:41, 23 March 2023 (UTC)

Thanks, that is interesting. That is an example of GeoGroup being used at a category page. Maybe there should be two versions of GeoGroup, or a switch "category=yes" or whatever, to give different display at a category page vs. regular mainspace article. FWIW, I think what displays at a category page does not need to be as brief and innocuous; a reader who has arrived there has knowingly gone on to choose to visit something which is not simply a regular article.

Also, now I wonder if the dropdown or separate page or whatever could now link to some outside webpage (at toolforge?) which provides a guide on how to use coordinates, e.g. how to download coordinates and use them in some mapping app or whatever you would do with the Queensland coordinates. I personally don't mind there being an external link if it is in a dropdown, i.e. if it is not presented to regular wikipedia readers who have not taken a positive step to go towards taking action on, or getting info about, downloading coordinates. --Doncram (talk,contribs) 21:39, 30 March 2023 (UTC)

Anyhow, what needs to be done is to limit the second line to display merely "Download coordinates", with the options to be offered at a longer display that can open up (or at a completely separate webpage that can be opened).

Until that programming is made to work, the recent functionality added should be immediately cancelled by rolling back to the previous version of GeoGroup template. There are millions of readers being offered various options of "GPX" downloading, whatever that is, each hour this has not been fixed. --Doncram (talk,contribs) 22:18, 21 March 2023 (UTC)

As you wish, the edit has been  reverted for now. P.I. Ellsworth , ed. ^{put'er there} 00:40, 22 March 2023 (UTC)

Just a little notification to the proposer, editor Reubot. P.I. Ellsworth , ed. ^{put'er there} 00:27, 23 March 2023 (UTC)

I've updated the sandbox to use Template:Collapse. Reubot (talk) 12:47, 30 March 2023 (UTC)

To editors Doncram and Verbarson: do the [testcases] show the needed appearance and functionality, and are your previously expressed issues okay now? P.I. Ellsworth , ed. ^{put'er there} 20:59, 30 March 2023 (UTC)

Sorry, no. When I download the KML file, it contains reasonable-looking data for the points (I have not tested its validity). But when I download any of the three GPX files from the first example, I just get this for all three downloads:

<?xml version="1.0" encoding="UTF-8"?>
<gpx xmlns="http://www.topografix.com/GPX/1/1" >
</gpx>

There is no point data in the file.

I am running Chrome on Lubuntu, but I don't see that this would affect the file contents?

OTOH, the appearance is much better! -- Verbarson  ^talk_edits 21:45, 30 March 2023 (UTC)

Hi Verbarson, I've updated the script to now treat non category namespaces the same when parsing an individual page: [1]

I'm not sure how to get a single section using api or DB queury. so it's just all the page coords for now
Reubot (talk) 12:15, 1 April 2023 (UTC)

Well, it has changed the outcome. Using the first GeoGroup in testcases, the GPX (primary coordinates) button still downloads a three-line no-point-data file; but the GPX (secondary coordinates) and GPX (all coordinates) buttons both download 2503-line apparently identical (top and tail look good, I haven't done a complete comparison) files full of point data (again, not validated). I do not know the distinction between primary and secondary coordinates, but this outcome suggests that all the coordinates are secondary? -- Verbarson  ^talk_edits 18:23, 1 April 2023 (UTC)

Primary is a single coordinate for the pages subject (from mw:Extension:GeoData#Glossary):

• Primary vs. secondary coordinates: primary coordinates define article subject's location, while secondary coordinates are other coordinates mentioned in the article. There can be only one primary coordinate per article, but as many secondaries as you like barring technical restrictions.

Reubot (talk) 00:53, 2 April 2023 (UTC)

That may be a bug. I'll have to look onto it. Reubot (talk) 01:36, 23 March 2023 (UTC)

Thank you User:Paine Ellsworth for managing this and User:Reubot for creating the alternative. Yes I see the testcases which look pretty good. I suggest changing the second line from what now comes across as mysterious, calling for the reader to puzzle what the completion of the thought would be, in showing "Download coordinates as:" followed by "[show]". With [material between brackets being a link that can be clicked upon]. The functionality is good, but change the presentation to something like "Download coordinates [here]", or "or download coordinates [here]" or just "[download coordinates]". So the thought is complete, the reader is not puzzled, and the reader if interested in getting all the coordinates can do so. I don't know if template:collapse allows an alternative to the text "show" being what it shows, so perhaps it will require using an adapted version of that template. I don't happen to think of wording right now that really works when the link is going to show "show" (e.g., would "For ways to download coordinates: [show]" is too long, so I think having the link "show" something else is better. Thank you -- Doncram (talk,contribs) 21:41, 30 March 2023 (UTC)

Hi Doncram, I've changed the sandbox text to "show links" or it could use "expand". Reubot (talk) 06:01, 13 April 2023 (UTC)

It's clearly better than before. The testcases page is impressively long and sort of interesting, BTW. Offhand I think "expand" might be better. And the original version has a normal or smaller space between its two lines of text, while the current one has an unfortunately large gap between the two lines. I am just one person (the only person?) who had any issue with the version rolled out, and you have considered and made accommodations which I do appreciate. I don't know of any editor review process to fine-tune this. To me, it's okay/good, and I don't want to be holding this up. Thanks! --Doncram (talk,contribs) 03:58, 14 April 2023 (UTC)

Since edit requests are only for uncontroversial edits, this request has been deactivated until a consensus agrees that these edits are both ready to go live and are improvements to this template. Please do not reactivate this request until consensus has been achieved. P.I. Ellsworth , ed. ^{put'er there} 20:23, 7 April 2023 (UTC)

How do we reach a consensus? Both user:Doncram and user:Verbarson seem to happy with the changes. Reubot (talk) 23:59, 1 July 2023 (UTC)

I do appreciate that my concern that not much should show in mainspace for most readers was addressed, by creating the dropdown menu.

Now, glancing at the discussion, I do have another question/issue, about what shows within the dropdown (a lesser concern for me): are the three lines for GPX really required (primary vs. secondary vs. all), in addition to the KML line? Why not just one line for GPX? Because in this discussion it was explained that "primary coordinates define article subject's location, while secondary coordinates are other coordinates mentioned in the article." I can't imagine what users just want to download one coordinate, the single primary one. As before, I am ignorant about how downloading is useful for anyone (except that I posed a California group once might have found it useful, one-time only, and I posed that maybe crazy gamer companies might... and Reubot did assert it was useful for identifying photos needed, but I am not familiar with the situation so I haven't really absorbed that). Anyhow, is there any plausible usefulness of offering a download of one data point? A user who needs the primary coordinates can just click on the coordinates, and let the GeoHack come up, and copy-paste the one set of coordinates from there. And wouldn't any user who wants the secondary coordinates also want the primary set? The primary one could probably best be provided as the first set of coordinates in the list, anyhow, and if any user really didn't want that in some gaming(?) programming or other purpose they could program the deletion of the first set. And whatever sophisticated users want just the primary coordinates could likewise just keep the first row and strip away the rest, couldn't they? [Update: I see there might or might not be a primary (a coords with "display=title") in an article, so the first row in a download could not be assumed to be one. Maybe the primary, in first row or not, is identifiable in a different way? --Doncram (talk,contribs) 19:46, 2 July 2023 (UTC) By the way, in the KML download, is the primary set of coordinates given first (or should it be), and why is a primary vs. secondary distinction not offered there?

So it's not a big deal, really, but why not just have one row in the dropdown for KML and one row for GPX, rather than primary, secondary, and total for GPX? Again, take my comments with a grain of salt because I dunno what KML is nor do I know what GPX, much less what downloads of them are useful for. My main concern was that the mainspace regular view not be too long, and that has been addressed. Thanks! --Doncram (talk,contribs) 04:04, 2 July 2023 (UTC)

1. I must state that I do not use the KML output, nor do I expect to use the GPX output; can we get opinions from readers who use these facilities
2. I am happy that the new layout, with a drop-down menu, will not disturb the look of existing articles that use GeoGroup
3. The new layout provides an easy way to add new extracts in the future
4. I agree with Doncram's point that having primary/secondary/both options is unwieldy (I also wonder what proportion of general readers would understand the distinction without testing it out - I was ignorant of this)

Support with reduction to a single GPX extract of all coords. -- Verbarson  ^talk_edits 18:18, 2 July 2023 (UTC)

I basically want to say go ahead as it is now. I was thinking I don't want to be posing Reubot unnecessary questions or ignorantly posing issues that aren't real, or aren't significant, but also wondering about...

1) at testcases I am getting just the effectively empty three line file

<?xml version="1.0" encoding="UTF-8"?> <gpx xmlns="http://www.topografix.com/GPX/1/1" > </gpx>

in some cases of one or more of the three GPX options (GPX primary, GPX secondary, and GPX all), when I try various testcases, where the KML option yields a download of many coordinates. Not sure if these empties are problems.

(EC) At first here I stated here that I was seeing empty for all three in some cases, which would be problematic, but going back I don't see that, so I revised what I was saying here.

Meanwhile, Verbarson jumped in to say:

Still working for me.

Incidentally, I note that the downloaded KML file is named doc (n).kml, whereas the GPX files are named User_Verbarson_sandbox (n).gpx, (based on the page where I tested them) which seems more useful. Would it be worth putting a better name on the KML files? -- Verbarson  ^talk_edits 19:05, 2 July 2023 (UTC)

• Specifically in the Examples section, which uses data from Netherton Tunnel Branch Canal, for "Display the coordinates from the current section (in current article) with a maplink map:", the GPX primary option is empty. Hmm, upon review I see that is because the data copied from the article to use in the testcases page is changed for the "Regent Road air vent" (the approximate canal mid-point) so that there is no datum with "display=title" in the section, i.e. it uses

{{coord|52.50697|-2.05708|region:GB_type:landmark|name=Regent Road air vent}}

instead of

|{{Coord|52.50697|-2.05708|display=inline,title|region:GB_type:landmark|name=Regent Road air vent}}

in the Netherton Tunnel Branch Canal article.

I suppose the testcases page, like all other pages, is not allowed to include more than one "primary" (display=title) coordinates. I will believe that the revised template would yield the primary one, when applied on the actual page. So this example is okay.

• Specifically for the "Display all coordinates in a category:" applied to Category:Rail transport stations in London fare zone 2, the GPX secondary option is empty (and primary and all may both give all of the data). Perhaps "primary" vs. "secondary" always would be meaningless for a category, but if so why offer the three options, rather than just "GPX"? Or, can a category have a primary? My ignorance is showing again probably. Maybe it would be too hard for the GeoGroup to function differently on a category vs. on a regular article page? I did comment before that maybe GeoGroup should be different for categories, and if i recall correctly my reason was that is because what needs to be explained is different. [Update, and this is going off-topic here: I see that the example usage of GeoGroup in a category was using template:howtoreqphotoin, where the call to GeoGroup was with some level of recursion (for searching in how many levels of subcategories) is specified. Let me just observe, I think the documentation for Geogroup about usage in categories is lacking: all that is stated at "Option for categories" section is "There is one optional parameter for display of coordinates in categories: {{GeoGroup|level=0,1,2,3,...}} level= Category recursion level, where 0 means unlimited". Which is opaque to me. Examples would be relevant, such as perhaps discussion of the template:howtoreqphotoin. And there are examples, but they are hidden far down in a subsection labelled "Other examples". The section "Examples" should be split into "Examples for coordinates in articles and sections" vs. "Examples for coordinates in categories" or something like that, instead of being split between "Netherton Tunnel Branch Canal" and "Other examples". --Doncram (talk,contribs) 20:17, 2 July 2023 (UTC)]

2) Before I review much more, Reubot could you reply about when having the primary vs. secondary distinction would be helpful? Now I am gathering that "primary" really means just any coords with "display=title". And in some/many articles that single set of coords would not have a "name=" field identified, while probably all other coords in the article would. This might occur in an article about a historic district where the primary is some central point in the district, and secondaries are locations of specific buildings which the reader would be able to see in the "Show all coordinates in linked OpenStreetMap", perhaps ideally(?) without having the central point show also.

3) Guessing at an application where "primary" might be wanted: Maybe an outside programmer would want to extract just the central points of each of a number of historic district articles, and could somehow apply the "download GPX primary only" option repeatedly (or have some staff person manually apply it repeatedly get a bunch of single-datum files that the programmer would run their program on). In this application, I wonder if the programmer would or could know the difference between the "primary" vs. "secondary" in a downloaded "GPX all" file, and therefore be perfectly happy with that.

4) Note one coordinates row in a GPX file looks like:<wpt lat="52.486" lon="-1.89"> <name>Birmingham</name> <desc>Template:GeoGroup/testcases</desc> <link href="https://en.wikipedia.org/wiki/Template:GeoGroup/testcases" >https://en.wikipedia.org/wiki/Template:GeoGroup/testcases</link> </wpt>

Could or should the row indicate primary vs. secondary?

Again I am afraid with my questions I am not being helpful. If Reubot, the only person actually understanding about KML and GPX being useful, would say they know that all these questions/potential issues are nonsense, and that the existing new GeoGroup is good as it is, then their word should be accepted.

Again, as a non-user of downloaded coordinates, I am informed enough only about what should display in mainspace for non-users, and the compact display is fine as it is now, so really if Reubot thinks the current drop-down and functionality is good, then that should be accepted. If/when in the future some actual user(s) of downloads identify some issue(s), that's when changes from the existing, functioning GeoGroup sandbox code should be considered. --Doncram (talk,contribs) 19:46, 2 July 2023 (UTC)

Reubot has already explained - see "Primary vs. secondary" above. -- Verbarson  ^talk_edits 21:21, 2 July 2023 (UTC)

Just noticed: when using the section= restriction, the KML extract respects the restriction, but the GPX extract includes all coords in the article. -- Verbarson  ^talk_edits 21:37, 2 July 2023 (UTC)

Unfortunately I am not sure how to access sections via the api. Unlike kmlexport, which parses the whole page as HTML, I use the wikitech:Wiki_Replicas and mw:Extension:GeoData. If anyone knows how to implement this the source is on Gitlab

As a stopgap, perhaps the script should return an error if section if specified?

Reubot (talk) 08:20, 3 July 2023 (UTC)

Rather than an error (which returns no information) how about putting "GPX (all article coords)" on the menu when section= is present? The downloader will get the info, they'll just have to split it from the rest of the article's coords. -- Verbarson  ^talk_edits 09:05, 3 July 2023 (UTC)

Ok, well I'll just leave it, as that what it is essentially doing now.

Also regarding "Support with reduction to a single GPX extract of all coords" , Would you accept a compromise to keep all three types? Perhaps moving "all coords" to the top of the download list?
Reubot (talk) 10:20, 3 July 2023 (UTC)

Fine by me. Since I only use this to open OSM, my opinions on the file downloads should not carry too much weight. Roll it out and see what the response is, and fine tune it later if necessary. -- Verbarson  ^talk_edits 10:29, 3 July 2023 (UTC)

Hi @Paine Ellsworth, is the above conversation enough for consensus?
Reubot (talk) 14:35, 8 July 2023 (UTC)

To editor Reubot: this has been  completed. Please make any necessary changes to the template documentation. P.I. Ellsworth , ed. ^{put'er there} 16:57, 10 July 2023 (UTC)

Adding names to the coordinates list

I'm using the template on South Jasper Ranges where I pull the coordinates into the table of mountains using {{wikidata}}:
e.g. {{wikidata | property | page=Mount Edith Cavell | linked | coord}}
That works fine but when I click the OSM link, the coordinates list on the left is showing "#1", "#2", ... "#19" for the labels for each coordinate. If you call {{coord}} directly and pass the name parameter, then OSM will display that name rather than "#1". However, I don't see how can set the coord name when I'm using {{wikidata}} to extract the coordinates. RedWolf (talk) 00:28, 17 August 2023 (UTC)

What am I missing?

I used the GeoGroup function back when I was sorting Category:Central Province, Sri Lanka geography stubs about a year ago. It was dandy. Now I'd like to use it in some stub categories under Category:Pakistan geography stubs, but when I try to apply {{GeoGroup}} or {{GeoGroupTemplate}} to a category (such as Category:Populated places in Upper Kohistan District), I'm taken to an OSM page that shows "sorry, no data to show". (I get the same result on the categories I previously used it on in Category:Central Province, Sri Lanka geography stubs.) I've tried varying the parameters per the template/doc, to no avail. Is there another setting I need to use, or has the OSM URL in the code changed? Please help. Her Pegship (?) 18:32, 4 December 2023 (UTC)

You don't miss anything, this was a bug over months. --DB111 (talk) 13:11, 22 February 2024 (UTC)

GeoGroup not working

It times out with an error message starting with "Webservice request timed out". Initially it did it on an article with many coords, but further testings shows it is not working on any article no matter how few coords. Kerry (talk) 01:51, 6 January 2024 (UTC)

Antarctica

I have been expanding articles on mountain ranges and major glaciers in Antarctica to include lists of smaller features such as mountains, cliffs and tributary glaciers. The idea is to get rid of trivial little stubs, and put the information they hold into the context of a larger feature. Worcester Range is an example. I usually remember to add {{geogroup}}, which I find helpful to check for anomalies in the coordinates. But at first glance, what displays is just a scatter of pointers on a plain, pale blue background. The reader has to look very carefully to see there are some light grey regions where the mountains are. And they have to zoom in, zoom in further. and zoom in more to find a little red triangle where OpenStreetMap thinks the peak is, and zoom in further again to find the OpenStreetMap name.

Is there any way to add a parameter or parameters to {{GeoGroup}} to ask for greater contrast and more prominent feature symbols and names? Aymatth2 (talk) 14:08, 12 February 2024 (UTC)

GeoGroup doesn't seem to be working

Clicking on the GeoGroup box in the rendered article isn't launching Open Street Map. However, Open Street Map itself seems to be working as normal. Not sure where to report this problem. Kerry (talk) 02:28, 15 February 2024 (UTC)

OSM4Wiki (the tool behind) isn't maintained very well anymore, so maybe replace (or complement) by WikiMap (which doesn't have "section" support), e.g. https://wikimap.toolforge.org/?lang=en&page=Paris

WikiMap has working "level" support (showing subcategories), broken in osm4wiki for years: {{#if: {{{level|}}}|&subcats=true&subcatdepth={{{level|}}}}} --DB111 (talk) 13:03, 22 February 2024 (UTC)

Having GeoGroup not working is quite a big loss. Where should that be reported in the hope that someone can work out a solution? Thanks! Underwaterbuffalo (talk) 14:56, 22 February 2024 (UTC)

Unfortunately (resp. with good reason) not everybody could change the template to switch the tool. --DB111 (talk) 16:07, 22 February 2024 (UTC)

Replace [https://tools.wmflabs.org/osm4wiki/cgi-bin/wiki/wiki-osm.pl?project=en&article={{urlencode:{{{articlee|{{{article|{{FULLPAGENAMEE}}}}}}}}}}{{#if:{{{section|}}}|&section={{urlencode:{{{section|}}}}}}}{{#if:{{{level|}}}|&l={{urlencode:{{{level|}}}}}}} OpenStreetMap] with

[https://wikimap.toolforge.org/?lang=en&page={{urlencode:{{{articlee|{{{article|{{FULLPAGENAMEE}}}}}}}}}}{{#if:{{{level|}}}|&subcats=true&subcatdepth={{urlencode:{{{level|}}}}}}} OpenStreetMap] --DB111 (talk) 16:19, 22 February 2024 (UTC)

That does not work for me. See https://wikimap.toolforge.org/?lang=en&page=Saint+Johns+Range. But it seems as though GeoGroup works some of the time, just not all the time. Aymatth2 (talk) 17:20, 22 February 2024 (UTC)

Geogroup Screenshot from w:en:Saint Johns Range

Now GeoGroup is working. Maybe it is just running on an antique server that cannot handle the load. Aymatth2 (talk) 19:57, 22 February 2024 (UTC)

Not working for me. Try it on Indooroopilly, Queensland or [2] Kerry (talk) 23:39, 22 February 2024 (UTC)

Now it's working again! Hurrah! Thanks to anyone who helped make it happen! Kerry (talk) 07:24, 24 February 2024 (UTC)

Stopped working again. After a long delay, I see "Wikimedia Toolforge Error: Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again later." Aymatth2 (talk) 15:29, 12 March 2024 (UTC)