Wikipedia talk:WikiProject Geographical coordinates

bot to add the coordinates from wikidata to enwiki article

A few weeks ago, there was a request at WP:BOTREQ for a bot to go through Category:Articles missing coordinates with coordinates on Wikidata, add the coordinates from wikidata to enwiki article, and remove the {{coord missing}} template permalink. I had created a program to do that but I was notified that there was no clear consensus for the automation of the task. So here I am, trying the gauge the waters: would it be okay to automate the process? If yes, then what should be avoided, be careful of, and what format of the coordinates should be used? I believe if planned properly, this task could be safely automated. Courtesy ping @Deor, Dawnseeker2000, and Suntooooth: —usernamekiran (talk) 02:59, 31 October 2024 (UTC)

I've previously expressed an opposition to the indiscriminate importation of coordinates from Wikidata, and my opinion has not changed. A bot's doing it is by definition indiscriminate. Deor (talk) 16:07, 31 October 2024 (UTC)

Pinging @The Anome:, who I believe has proposed bot importation of coords before. Deor (talk) 16:11, 31 October 2024 (UTC)

@Deor I am neutral about the bot run. But I think we should discuss what should be, and shouldn't be done by the bot, and what are the risks. Maybe we can find solution for problematic cases, or skip such cases. I am currently running a very simpler similar task, of removing wikidata QID from enwiki infobox, if it matches with wikidata, in case any doubt, the bot skips the removal and adds such doubtful cases to User:KiranBOT/List of mismatched QID. Maybe we can approach the coords task similarly? —usernamekiran (talk) 12:40, 1 November 2024 (UTC)

We now have more than 19,000 articles missing coordinates on enwiki that have coordinates on Wikidata. It would seem silly not to do something with that data. But what? Should we manually review all of them and add them bit by bit by hand? Or is there some way to automate the process - for example by comparison with OSM data, where available, to check if the two coordinates are close? — The Anome (talk) 16:49, 16 April 2025 (UTC)

I am under the impression that the usual way to get Wikidata coord data into a Wikipedia article is by infobox template in the article, pulling the data from the item. This suggests to me an infobox bot putting a location map into the article, thus attracting the attention of any reader who happens to know where the object is, and leading to a WD correction. Incidentally yes, adding WikiShootMe dots to an OpenStreetMaps display would also help. Jim.henderson (talk) 13:48, 20 April 2025 (UTC)

Comparing with OSM sounds workable, as I've found OSM to be generally reliable. One problem is that OSM may not have locations for individual buildings and such, and its coordinates are frequently overprecise (as are Wikidata coords). A problem with indiscriminately pulling coords from Wikidata is that they will lack type and region parameters. For that reason and others, my opinion is that coordinates almost always benefit from human review. Maybe I just don't trust bots as much as other folk seem to. Deor (talk) 16:12, 20 April 2025 (UTC)

Draft:Kitenui Knob

Any suggestions fo what to do with this subject? FloridaArmy (talk) 19:10, 10 June 2025 (UTC)

"Maximum"

@Abductive: I disagree with your addition of "maximum" - it is a significant change to the meaning of that section. Your behavior today has been inappropriate, including this rude edit summary and stalking my contributions. Please restore the previous wording until you have consensus for your change. Pi.1415926535 (talk) 20:41, 16 August 2025 (UTC)

I agree on all counts, and I have already restored status quo ante. ―Mandruss ☎ IMO. 20:45, 16 August 2025 (UTC)

As you may know, there are a number of good reasons to avoid false precision in every field of endeavor. In coordinates, we have to be aware that GPS and online mapping services have an inherent error rate of about 0.1". I just randomly chose Statue of John Carroll and the coordinates were off by 0.1", probably due to a new aerial photo. One can compare Google Maps, Bing Maps, Yahoo Maps, and Yandex and find many instances where they are off by that much or more. Additionally, some of those mapping services display the best zoom level when D°M′S″ is the input. At present, the vast majority of articles use D°M′S″ or D.dddd°, with rare exceptions such as D°M" and D.dd° for entities such as large islands or counties. The most common error is D.dddddd°, usually because users copy-and-paste. Worse yet is D°M′S.ss″ which comes from converting those six digits of false precision. Any improvement to the guidance here should be embraced. Abductive (reasoning) 20:58, 16 August 2025 (UTC)

Any improvement to the guidance here should be embraced. We can agree on that. Give me a day or two to contemplate. ―Mandruss ☎ IMO. 21:02, 16 August 2025 (UTC)

The purpose of coordinates on Wikipedia and its sister sites is to allow users to go from articles to mapping services, and vice versa, in various forms (geohack, mapframes, etc). The purpose is not to act as scientific/numerical data. To best serve the user, the coordinates should be within (and ideally close to the center of) the object. If they're within the object, excessively precise coordinates are essentially invisible to the user. For an object spanning 45.12341° to 45.12349°, the difference between a marked point at 45.123456789° and one at 45.12345° will not be perceptible on a mapping service. (Conversely, it will be obvious when a marked point at 45.1235° misses the object entirely.)

The result is that false precision is not actually an inherent problem for the purpose that coordinates are used for. Yes, it's mildly misleading/confusing if there are significantly more digits than needed, but five decimal digits versus four is not the issue you make it out to be. Even with the inherent error rate of about 0.1" or 0.00003°, coords with precision of d°m's.s" or d.ddddd° will still end up closer on average to the exact location than d°m's" or d.dddd° will. Pi.1415926535 (talk) 05:49, 17 August 2025 (UTC)

Looks like Pi has a better grasp of this than I do, and I created WP:COORDPREC. All I did was convert the tables at WP:OPCOORD to a format accessible to/usable by the average editor. I don't think it needs to get more complicated than that. And I've been out of the coordinates business for years. I'll probably sit out the rest of this unless one of the parties says something to convince me to take a firmer position (or someone addresses me directly). ―Mandruss ☎ IMO. 11:58, 17 August 2025 (UTC)

Coordinates in articles with no infobox so will show on mobile

Is there a preferred way to put coordinates in an article which has no infobox? Putting the template at the bottom of the article with just display=title doesn’t allow them to appear on mobile, but adding display=title,inline just puts a bare coordinates string, unexplained at the bottom of the article. Should the template be preceded with “Coordinates:” in those cases or is there a convention? Regards, TransporterMan (TALK) 20:04, 17 September 2025 (UTC)

This is an issue with mobile rendering, rather than article content. Presumably the template needs to be marked in some way that will let it display on mobile pages. This might also be a CSS issue.

I really don't understand any of the mobile rendering pipeline, but Wikipedia:TemplateStyles might be a place to start. — The Anome (talk) 09:34, 17 October 2025 (UTC)

Warham railway station

A puzzle for anyone who might be interested: when inspecting over-precise coordinates in the Warham railway station article, I saw that they do not actually point to a place on the railway line, nor is the immediately adjacent point on the line a plausible place for a stop, as no pathway leads away from it. Would anyone be interested in tracking down the station's exact position? — The Anome (talk) 09:31, 17 October 2025 (UTC)

I tweaked the coordinates a bit to the point where OpenStreetMap shows the stop (it's labeled Warham St Mary Halt on the OS map). At least there's a dirt road leading to the place. Deor (talk) 14:01, 17 October 2025 (UTC)

That's great! It's amazing how often over-precise coordinates are signs of inaccurate geocoding - your correction is exactly what was needed. — The Anome (talk) 11:18, 19 October 2025 (UTC)

Discussion of default rendering of shapes/lines in Template:Infobox mapframe

We're discussing how to handle the rendering of shapes/lines in Template:Infobox mapframe, given that OSM data is unreliable. This will likely affect a number of geographical infoboxes. You're welcome to join in the discussion. — hike395 (talk) 09:49, 8 November 2025 (UTC)

The Anomebot2

The Anomebot2 is on a temporary hiatus while I adjust it to deal with a recent database schema change. If anyone wants it back urgently, ping me and I'll push it up my priority list. — The Anome (talk) 12:23, 14 November 2025 (UTC)

@The Anome: I pretty much rely on the bot's (roughly monthly) runs to identify articles needing coords, so any interruption usually results in a backlog so large that when it finally makes a run, the number of new articles tagged is too great for me (and others) to deal with effectively. Because it's last full run was on Sept. 18 (it apparently made only a partial run in October), I expect a huge number of articles to be tagged when it's finally active again. That doesn't, however, mean that you should rush; it's just something I thought worth pointing out. Deor (talk) 13:06, 14 November 2025 (UTC)

I will work on it some time this week. — The Anome (talk) 14:04, 16 November 2025 (UTC)

@Deor: Following the Christmas and New Year hiatus, I found some time to work on it, and after finding and fixing a few new bugs caused by changes in the Wikipedia interface, the bot is back again, and normal service resumed. The latest run should catch up with the multi-month backlog over the next day or so. — The Anome (talk) 22:23, 5 January 2026 (UTC)

Discussion at Template talk:MergedMap

 You are invited to join the discussion at Template talk:MergedMap. -- Joy (talk) 12:35, 27 November 2025 (UTC)

Pushing the button with Wikidata coordinate transclusion

We have around 21,000 articles in the category Category:Articles missing coordinates with coordinates on Wikidata. With the conversion of {{coord}} to transclude Wikidata coordinates automatically, and with the addition of better display of those coordinates (see Template talk:Coord), I can't see any reason why we shouldn't start to convert the {{coord missing}} tags on those articles to {{coord|display=title}} as soon as possible, with the result that 21,000 articles would have coordinates where previously there were none. If we have consensus for this, I can do it with my bot as a trivial batch run.

Does this make sense to other editors here? If so, I would suggest doing an initial batch of 1000 to see if there are any problems, and after a week or so doing the rest of them in a single batch. I would then re-run this process in the monthly bot run in the future. — The Anome (talk) 16:45, 7 January 2026 (UTC)

I'm against this. I'd say that more than 75% of the coordinates I see on Wikidata are blatantly overprecise or otherwise unsuitable for direct importation here (occasionally they're downright incorrect). I don't think we should be bot-importing them; each case needs human oversight. Deor (talk) 17:22, 7 January 2026 (UTC)

I don't think overprecision is that much of a problem if we keep the precision to say 4 decimal places on display. Inaccuracy is a different matter. Perhaps we could have a 'reviewed' parameter for these, to flag them for human review? For example, {{coord|display=title|reviewed=no}}. Then I could perhaps use the bot to them at a rate of, say, 50 a month at first to see whether human reviewers could keep pace with them? Although at that rate it would take 35 years to add them all...

Another possibility would be only to add coordinates that were already on display on at least one high-reputation Wikipedia language version (eg out of the set {en, pl, zh, jp, de, ru, es, it, pt}), and can thus be regarded as having had some sort of human review.

Yet another possibility is to use OSM data, not to source coordinates (something explicitly prohibited by OSM's license), but to validate the Wikidata coordinates as being in the general neighborhood of the OSM coordinates, which I think should not have any licensing problems as it does not involve copying any data, just answering a yes/no question (and one which can be fuzzed to prevent triangulation if needed). It would also let us detect coordinates cribbed directly from OSM so we can remove them from the dataset.

Finally, I'm also looking at using LLMs to act as a validation engine, of which more later if it seems promising... — The Anome (talk) 17:41, 7 January 2026 (UTC)

Mapframe vs. Coord

We now have two different and incompatible map display systems, {{infobox mapframe}} and {{coord}}. One links to the geohack page, the other to its own in-built mapping system. The two seem to be completely divergent, and I think this is a bad thing.

Can we please work on re-integrating the user experience so that, for example, the mapframe view will allow navigation to geohack, and the geohack page allow navigation to the mapframe view? — The Anome (talk) 11:25, 8 January 2026 (UTC)

This seems extremely difficult. Kartographer is an extension to MediaWiki, beyond the control of en-WP editors. I'm not sure where one would put a geohack link on that map, in any event. Geohack is run on toolserver, so cannot use {{Infobox mapframe}}. — hike395 (talk) 15:25, 22 January 2026 (UTC)

Mapframes can be changed to display coordinates under them, and the coordinates can link both to geohack, and to an edit link that leads to the Wikidata page where they are stored. This restores the wiki principle, where anyone who sees a coordinate can correct it or remove it if necessary. — The Anome (talk) 13:11, 25 January 2026 (UTC)

Kartographer vs. coord missing

Following on from the above, pages marked as missing coordinates that also have coordinates on Wikidata and use the Kartographer extension, should not be marked with {{coord missing}}, as they actually have visible geolocations, just not via {{coord}}.

Here's a PetScan query to find them: [1]

I will be running a bot pass to remove these in the next few days. This will be a substantial win, removing some 8000+ pages from the backlog.

This should obviously be followed by the Kartographer / {{coord}} re-integration mentioned above. — The Anome (talk) 14:38, 22 January 2026 (UTC)

The PetScan query isn't quite right: Kartographer is used on some category pages, which should not be expanded. I believe the correct query is [2]

— hike395 (talk) 15:20, 22 January 2026 (UTC)

Don't worry, there's a post-filter in the bot that should already take care of this; it looks at both the source and rendered version of every page at runtime and performs extra checks before editing, and - crucially - limits its edits to only removing {{coord missing}} templates, and won't touch the page unless one is present. Thanks for the corrected version: I'll take a look now. — The Anome (talk) 16:09, 22 January 2026 (UTC)

Yes - after checking, I can confirm that both the post-processing of the PetScan query (using grep and sed) and the item-by-item runtime checking of the bot reject any page with a prefix in its name, which would definitely catch category pages. There are a lot of checks in this process: negative checks, which are deliberately made loose, and positive checks, which are tight, and must all be passed for a change to be made. — The Anome (talk) 16:42, 22 January 2026 (UTC)

After running this around 8000 spurious {{coord missing}} tags have been removed, and the size of Category:Articles missing coordinates with coordinates on Wikidata is down to about 13,000 articles. The fraction of articles eligible for coordinates that have coordinates is now almost 95%, with the backlog down to about 70,000. Progress. — The Anome (talk) 16:37, 23 January 2026 (UTC)

I admit that I don't really understand what's going on. What do you mean by "spurious {{coord missing}} tags"? As near as I can tell, The Anomebot2 has been going around and removing {{coord missing}} tags, but the articles still lack {{coord}} templates; so what we have is a whole lot of articles that lack coordinates but are not identified as lacking them. Deor (talk) 18:26, 23 January 2026 (UTC)

Vast numbers of articles now contain automatic maps, with their coordinates not editable from enwiki, which I think (and I think you would agree with me) undermines the wiki process. The damage is already done, and this is part of a plan to reverse it. I have a cunning plan, which is to automatically put coordinates under the maps, not only in these cases, but in every other mapframe that pulls its coordinates from Wikidata, with automatic links to the Wikidata pages that contain the source coordinates, making them editable and reviewable. Which is I think the same goal as yours; explicit human-editable coordinates on every page for which they are appropriate. — The Anome (talk) 13:08, 25 January 2026 (UTC)

So this will, in effect, involve bot-importation of Wikidata coords into en.wp? Over the past couple of days, I've been looking at a few of the articles that have had {{coord missing}} removed. Do you think that wildly overprecise coordinates like those here and here or coordinates that are a few kilometers off like this and this can be successfully imported without human intervention"? What about cases in which Wikidata has more than one set of coordinates, as here (or for some rivers, where Wikidata has both source and mouth coordinates)? How will the bot decide which coordinates to use?

These are not isolated cases; the more I look at coordinates on Wikidata, the more I become dissatisfied with the idea of direct importation of them. Haven't there been RfCs where that idea has been rejected? I realize that we poor human beings are not keeping up with the creation of new articles needing coordinates, but I still think that adding {{coord missing}} and allowing actual people to deal with adding coordinates was the way to go. That way, at least, there was categorization of articles needing attention; this way, how will we know which articles need human review?

I guess I'm just being a Dame Partington here, trying to hold back the Atlantic Ocean with her mop. Or perhaps I just fail to understand what you're envisioning. Deor (talk) 14:27, 25 January 2026 (UTC)

My point is that these coordinates have already been "imported", in vast numbers, by putting them automatically into these infobox mapframes, and there's no way the mapframe people are going to stop doing that. There are literally hundreds of thousands of pages with mapframes (I'm working on counting how many are missing {{coord}} right now.) What is missing is the ability of Wikipedians to edit these coordinates from enwiki, which is what breaks the wiki model of crowdsourced editing, and allows bad coordinates to go unquestioned.

This is not about importing new Wikidata coordinates, it's about making the existing ones easy for editors at large to correct, and if necessary remove them when they are garbage. And once we have that, we have the whole enwiki readership available to cast their eyes over the coordinates and fix them, not just me and you. Otherwise, we risk having two entirely different mapping/coordinates system on Wikipedia: the {{coord}} sytem, and another one which has effectively no human oversight. Which I think we can agree is a bad thing. (By the way: I only intend this for mapframes with exactly one coordinate point, which is the vast majority of them.)

What is good about {{coord}} (a system I've worked to maintain for years) is that it is transparent, editable, and machine parsable, and those are the principles I wish to preserve. — The Anome (talk) 15:19, 25 January 2026 (UTC)

Integrating Wikidata and enwiki coordinate maintenance systems

We currently have two entirely different and incompatible coordinate maintenance systems: the in-wiki {{coord}} system, driven by human-editable text in enwiki, and the automatic transclusion of coordinates from Wikidata, which is, whether we like it or not, now used in hundreds of thousands [?] of articles. We urgently need to integrate these two systems.

I agree with Deor that we cannot currently afford to mass-import Wikidata coordinates into the {{coord}} system, but we are stuck with the existing tacit mass-importation of coordinates via mapframes.

Goals:

• discoverability of coordinates as editable items (so they are not just 'magically' part of the page)
• on-wiki (or at the very least, from-wiki) editing of coordinates to allow human supervision of coordinates

I can think of two ways of doing this: one is to copy Wikidata coordinates for mapframe pages that lack explicit on-wiki coordinates into the {{coord}} ecosystem, so they can be edited by humans on enwiki. The other, which I prefer, is to "humanize" the mapframe coordinates by making them human-editable from enwiki.

The first still ends up with two competing and un-reconcilable coordinate maintenance systems, since it breaks the link between the wiki and wikidata, but the second allows a single source of truth to exist. I think this transition can be done smoothly, if we work carefully.

There are two sub-projects in this. One is the copying of all current enwiki {{coord}} values into Wikidata where none exist. The other is 'humanizing' mapframe, with the aid of a JS widget if necessary, to allow Wikidata coordinates (where used) to be edited as easily as they are in enwiki.

The system is broken, to a large part because we didn't do this integration several years ago. We need to fix the broken system, not ignore it. — The Anome (talk) 15:39, 25 January 2026 (UTC)

Regarding brokenness: after some test edits of Elkins-Randolph County Airport, it looks like the infoboxes simply swallow the {{coord}} wikitext, without any transclusion anywhere! This breaks the maintenance category model for {{coord}} entirely. Fortunately, run-time checks of rendered page text have so far stopped my bot from causing errors on enwiki. This is horrible, and further demonstrates the brokenness of the entire system. — The Anome (talk) 15:57, 25 January 2026 (UTC)

OK, now I think I see better what you're trying to do. One question: You speak of "'humanizing' mapframe, with the aid of a JS widget if necessary, to allow Wikidata coordinates (where used) to be edited as easily as they are in enwiki". Will that involve a run of The Anomebot2, so that one can see, by looking at the bot's contributions, what articles this has been done to? (I guess I have another question, too: What's a JS widget?) Deor (talk) 16:29, 25 January 2026 (UTC)

@The Anome: Mapframes/Kartographer are a bit more complex than what you may be thinking of (at least, judging from what you're saying, above). What is shown in a mapframe depends on the following:

• Center coordinates for the map
• Zoom level for the map
• A location to draw an (optional) marker
• Optional geometry (such as a squiggly line or polygonal outline)

You are correct that currently a mapframe is only displayed if either a {{coord}} is supplied to it, or there are coordinates stored in the Wikidata item. But the geometry that displays usually comes from OpenStreetMap. Currently, when that geometry is imported, and there is no zoom manually specified by a WP editor, the mapframe center and zoom is set by Kartographer in order to nicely frame the geometry.

In other words, you may be able to make it easy for an WP editor to edit the coordinates for a mapframe at Wikidata, but that may not affect the displayed map at all.

I think about it analogously to human-created maps at Commons. Someone with graphical design tools may make a map, e.g., File:Biome map 11.png. As a Wikipedia editor, I found that map to be factually incorrect. But I don't have an on-wiki way of fixing or changing that map, myself. All I can do as a "pure" WP editor is turn off the map or substitute a different map from Commons. The analogy for mapframe/Kartographer is to set |mapframe=off or to use a Commons map that will override the Kartographer mapframe.

Upon reflection, I think part of your objection may be due to the automatic use of mapframes in many infoboxes. This has been discussed recently without consensus or any resolution.

I don't have a suggestion of how to fix your concerns, but just wanted to talk about the complexity and the analogy and point to a recent discussion. Hope this helps. — hike395 (talk) 06:10, 27 January 2026 (UTC)

Pinging @Joy, Zackmann08 who have spent a lot of effort in making mapframes show up in infoboxes. — hike395 (talk) 06:15, 27 January 2026 (UTC)

The case of Elkins-Randolph County Airport seems to be a bit bothersome. In this test version, where the coordinates parameter has a blank value, no coordinates are displayed, which is appropriate. Nevertheless, a mapframe map is displayed, using the coordinates from Wikidata. This is a problem, because the Wikidata RFC regarding infoboxes determined that only reliably sourced data from Wikidata can be imported into infoboxes. The Wikidata entry for Elkins-Randolph County Airport contains no reliable source for its coordinate data, so that data should not be used in the infobox. It looks like a change may be needed to Module:Infobox mapframe's retrieval of coordinates to limit it to only sourced data. Module:WikidataIB does a good job of limiting such data retrieval; there may be some reusable code there. – Jonesey95 (talk) 17:53, 27 January 2026 (UTC)

Coords are complicated because we don't normally cite them locally; in most cases, there's not going to be a reliable source explicitly giving the coordinates even if they're trivial to confirm with the geohack links. Pi.1415926535 (talk) 19:38, 27 January 2026 (UTC)

Strangely, in the case of most Kartographer maps, the map itself functions as a reference for the airport. You can see the map marker positioned on an obvious airport, in the location described by the rest of the article. So OSM acts as a reference; but if you select any other map provider from the Kartographer big map, or via the Geohack page, they will show the same. So the map is the reference. But at the same time, the marker isn't - at least should not - be taken directly from OSM, which would be a breach of the OSM license; and we need to be careful about accepting wholesale data imports from there, or from any other non-license-compatible data source. — The Anome (talk) 14:05, 28 January 2026 (UTC)

Well, the rest of the map elements in OSM, as well as e.g. Google Maps, are crowdsourced, too. Only the easy availability of satellite map tiles could be considered a sort of a reference, but it's possible this is too much for the average reader. Depends on the interpretation of WP:ORMEDIA.

I didn't hear about license issues until now - surely whoever implemented Kartographer on Wikimedia servers considered the interaction between ODbL and GFDL? Do we have any documentation for that matter? --Joy (talk) 14:22, 28 January 2026 (UTC)

On this note, I think mapframes provide a valuable service with regard to the original research policy - they help the average reader with the straightforward reading of map sources. They drop the requirement of calculating coordinates in favor of just observing the pre-calculated values in concert with other pre-calculated map elements nearby.

And then the possibility of observing the same area in other map systems, with satellite map tiles and own map elements, is a backstop against just everything being fake. --Joy (talk) 14:31, 28 January 2026 (UTC)

I was not involved in this apparent merge of wikidatacoord into coord. I don't think this should have been done without the visibility fixes that we already know are needed - based on bug reports on infobox mapframe, cf. Template talk:Infobox mapframe#mapframe-wikidata implicitly on, instead of off?

Truth be told, the usage of coord has also been very messy, with a lot of inherent OR risks. Its notes parameter is used even less commonly than infobox coordinate_ref and similar parameters, and the internal source parameter is very opaque for the average reader and editor. Essentially the same visibility issues should be fixed there, too. --Joy (talk) 08:02, 27 January 2026 (UTC)

Despite all of the above (which is valid), it is worth saying that mapframes in infoboxes are a net benefit. Most geographical infoboxes have a fixed regional map whereas mapframe gives a reader-friendly 'local context' map in the infobox which can be expanded to full screen and zoomed. I saw the value of this recently when, after adding mapframe, it was immediately obvious that [on wiki!] coordinates were wrong, in one case placing the settlement a few hundred metres offshore and in another placing the eponymous settlement in the next parish. So we have to fix the underlying fault, not brush it under the carpet by banning mapframe in infoboxes. 𝕁𝕄𝔽 (talk) 19:36, 27 January 2026 (UTC)

Absolutely. Just like visibility of a lack of references, the visibility of the outcome is an overall benefit for the readers, some of whom will become editors and attend to various issues that might otherwise go unnoticed. --Joy (talk) 22:14, 27 January 2026 (UTC)

Changing Infobox mapframe

Jonesey95 brings up a good point, above. The 2018 Wikidata RfC governs the "use" of Wikidata in Wikipedia, and the consensus for the last 7 years is to only use reliably sourced statements (excluding statements that are imported from Wikipedia itself).

Changing Module:Infobox mapframe to only use reliably-sourced statements is a relatively simple software change, but its effect on the maps on 1 million articles would be profound. The example use of the template is

{{Infobox mapframe|id=Q100}}

which currently yields the following map

This behavior has been stable since Evad37 created the module in 2018. If we only use reliably-sourced statements, this example returns nothing (because the Wikidata item Q100 for Boston does not have a source. This is a big change, because I think the large majority of coordinates on Wikidata are unsourced. Before I implement the change, I want to make sure there is consensus for this.

My interpretation of the unhappiness of several editors is not that the Wikidata statements used are unsourced, but that the map is showing up automatically by default, and that they don't know how to turn it off. I worry that if we only use sourced statements, the unhappiness will increase because the code that decides whether the map shows up is even more obscure (i.e., whether the coordinates are sourced). I'm also unsure whether "use" from the 2018 is actually displaying the value in an infobox, or does it cover any use (i.e., even in software to make decisions of how to draw maps).

It really depends on how you think about what is the purpose of Template:Infobox mapframe: is it the job of that template to figure out whether a map should be displayed? Or is the job of the template to draw the best possible map (based on Wikidata and OpenStreetMap) and it's the infobox code that should decide whether the map should be drawn?

There is related RfC that we should consider: in 2020, there was a RfC about mapframes in infoboxes. In Q2 of that RfC, editors discussed whether the mapframes should be (a) on by default, (b) off by default, or (c) on when no other map is shown. There was no consensus for Q2, so the closer declared "off by default". Since then, Joy and Zackmann08 have implemented strategy (c), infobox-by-infobox, responding to minor pushback. Given the recent discontent, I cannot tell whether other editors are objecting to the default use of mapframe (because they cannot figure out how to turn it off), because the mapframes turn on when {{coord}} is not used (per The Anome), or because of the use of unsourced Wikidata statements (per Jonesey95) or some combination of these.

I'm happy to change Module:Infobox mapframe if needed to follow consensus. It seems to be that this is a major change to 1 million articles, so creating a carefully-crafted well-publicized RfC would be helpful. I'm busy IRL and am going to be on wikibreak for the next 2 weeks, so it would be good if someone else could take the lead on such an RfC. — hike395 (talk) 08:45, 28 January 2026 (UTC)

We should definitely not break the simple template functionality - all the explicit calls to {{infobox mapframe}} have been done with the expectation of |mapframe-wikidata=on because that's how it's been done from day one. This should be maintained regardless of whether we set |mapframe-wikidata=off as the default in the #invoke: use cases.

In general, I don't think we have anything resembling a negative consensus on the latter issue. The main thing I think we need to figure out to make sure a new RFC would result in consensus is the method by which we make things more obvious, because it affects readers regardless of the defaults. --Joy (talk) 08:59, 28 January 2026 (UTC)

I think there are two issues here: the first is data quality and connection to reliable sources, and the second is the wiki principle.

Geodata entered on Wikipedia is largely hand-curated, does not have explicit references to a reliable source, but is of high quality thanks to both the diligence of its curators and the public visibility of that data and the existence of a discoverable way to edit it.

Geodata on Wikidata is sometimes sourced, sometimes not, and is often of mysterious provenance.

A problem arises when you have Wikidata geodata displayed on Wikipedia with no discoverable way to edit it, breaking the wiki principle that, against all conventional reason, allows Wikipedia to accumulate high-quality data through mere crowdsourcing. This, I think is the fundamental problem here.

Let's consider the common case of articles with a single-point geolocation. In my ideal world, we would have a system which combines the effectiveness of the {{coord}} system with the single source of truth of the Wikidata system that allows geodata to be shared between multiple wikis and with other data providers and consumers. Wikidata clearly has advantages in terms of a more nuanced data model, but lacks the ecosystem gains (and quite a lot of the special functionality) of the {{coord}} system.

My ideal system for such article would look like this: dynamic map in mapframe, visible coordinate below it with a link to something like geohack, and -- most importantly of all -- a link that would take you to Wikidata to edit that coordinate.

However, this would wreak havoc on the current {{coord}} ecosystem if there was not a way of integrating this with wikitext somehow.

What's the way forward? I can think of some possible options:

• We could pare back the Wikidata implementation to only showing referenced coordinates as before.
• We could do bidirectional copying between the {{coord}} system and the Wikidata system, with bots keeping the two in sync.
• We could somehow create a combined system that uses, say, the visual editor to implement a hybrid system.
• We could do nothing and let the current mess get worse and worse.
  None of these are wholly satisfactory.

Before we start working on a solution, I think the first thing we should decide on what our goals are, and that's the discussion I think we should be having here. We clearly have some of the prime movers of both systems in this discussion now, so we are in an ideal position to work this out now, before any more changes are made that could make things worse. — The Anome (talk) 11:14, 28 January 2026 (UTC)

I'm not sure how the coordinates on Wikidata / OSM are any more or less mysterious compared to those on Wikipedia. Most editors are anonymous and did not cite a source for them. The Kartographer method of retrieval may introduce an element of obfuscation, but fundamentally it's all crowdsourced.

The Wikipedia method of challenging verifiability is applicable to the imported bad data just like it is for 'homegrown' bad data - but we definitely could improve the methods to do that, to be far more obvious, similar to how it's reasonably obvious how and where to place a {{citation needed}} tag for the text.

We currently don't make it explicit where the map data came from when we embed it into infoboxes because we only add a bland static text caption. We also don't convey any helpful message to editors in the yellow box about it, either.

Sadly, the conventional methods of formatting notes like using {{efn}} don't work, because the note list isn't actually automatically shown to readers. Do you maybe know if there's a way around that?

I also don't know the mechanism of feeding data into the yellow edit box right now. Do you happen to know where this is documented? --Joy (talk) 11:31, 28 January 2026 (UTC)

Crowdsourcing is great, whether on Wikipedia or Wikidata; it's an intermediate level of assurance between data-dumped data with no provenance and data that explicitly references reliable sources. But what's important is discoverability and editability, without which the wisdom of the crowd through the wiki principle stops working. If the Kartographer system would enable that, and also maintain the tracking categories used in the {{coord}} system, we'd be a lot closer to a solution. {{coord}} does a lot that Kartographer can't, and vice versa. In the long run I'd like to see the systems merge into one system with all the capabilities of both. But in the short term, re-establishing the wiki principle and making sure the two systems don't clash with one another technically is vital. — The Anome (talk) 11:42, 28 January 2026 (UTC)

The first thought that came to me as I read this was - what are the tracking categories used in the coord template system? :)

I wanted to reproduce the journey of a reader who would try to tell us that a set of coordinates is broken, so I checked in {{coord/doc}}, but not a whole lot about it seems to be mentioned there. I suppose they could just type out a text message within the template parameters saying it's broken, and then we'd pick it up through some sort of syntax tracking? That seems... suboptimal.

I went clicking some more and found this list which sounds useful. To find that, one has to click a see-also link in {{coord/doc}} and then go through two pages of table of contents - too complex. Still, in that list, there doesn't seem to be an obvious place to be listing broken coordinates. Is it "Coord template needing repair"? Maybe "Coordinates templates needing maintenance"?

I think we need help in this area, too :) --Joy (talk) 12:06, 28 January 2026 (UTC)

You might also want to look in Category:Coordinates Wikidata tracking categories and Category:Articles needing coordinates. {{coord}} is actually quite a big sprawling system that has grown organically over the years through the work of many hands, and it could do with being tidied up. — The Anome (talk) 14:42, 28 January 2026 (UTC)

Oh, I saw those, but again in my experiment of trying to think like an average reader trying to get a problem fixed, I didn't think they would understand them.

In other words, if the reader trying to tell us a set of coordinates is bad sees "Wikidata tracking", they have to research what we mean by that, and even after that, I'm not sure how that would help them tag the problem. If they see "articles needing coordinates", presumably the reaction would be yeah, they have some already, but they need *the right ones*? --Joy (talk) 14:51, 28 January 2026 (UTC)

If an article contains a {{coord}} template, readers—any who don't want to try to fix them themselves—can report that "a set of coordinates is bad" by clicking on them and then on "report inaccuracies" on the GeoHack page (under "Article" at the top of the page). I admit that's far from obvious, but it does get some use, even from readers without accounts, so some folks are noticing it. Deor (talk) 15:42, 28 January 2026 (UTC)

We really have three sets of users to consider for both systems: 'power users' who know their way around the system, bot operators, and naive users, who outnumber both and should be our focus. Simple things like adding, editing or removing coordinates, should be easily discoverable and simple for them to do. If it also leads them toward being able to access the more complex parts of the system, that's good too, but not for me the primary goal. — The Anome (talk) 15:39, 28 January 2026 (UTC)

Agreed. Deor, thank you for mentioning the report inaccuracies link - something as prominent as that would be very good to have for mapframe and coord rendering inside Wikipedia, too.

On that note, I like how we at some point got the WikiMiniAtlas (though I don't really like its current map tile output). That popup modal window should also have more of this source-related information, too. --Joy (talk) 16:27, 28 January 2026 (UTC)

BTW, I tried clicking the button on that airport article, and noticed that the navbar (view talk edit) links in the top right are broken, they link to {{Geodata-chOverview.htmleck/report editintro}} instead of presumably {{Geodata-check/report editintro}}. Who do we report that Overview.html injection to? :) --Joy (talk) 16:31, 28 January 2026 (UTC)

Never mind, found the edit that broke it. --Joy (talk) 16:36, 28 January 2026 (UTC)

Proposal for Module:Location map: Make it so clicking on a location map opens an interactive Kartographer map

You are invited to join the discussion at Wikipedia:Village pump (proposals)#Make it so clicking on a location map opens an interactive Kartographer map. —⁠andrybak (talk) 23:26, 4 February 2026 (UTC)