Template talk:Infobox mapframe

MOS:INFOBOXNAME states to represent spaces using an underscore, e.g., |birth_place= not |birth-place= or |birth place=. Is there a reason that this template/module was implemented using dashes for all the parameters instead of underscores? Given that this is used on over 1.1 million pages, I realize that a change now would be an enormous undertaking but wanted to at least raise the issue... —Zackmann (^{Talk to me} /_{What I been doing} ) 07:51, 24 September 2025 (UTC) [reply ]

@Hike395 and Evad37: any thoughts? - Zackmann (^{Talk to me} /_{What I been doing} ) 01:47, 25 September 2025 (UTC) [reply ]

Back in May 2018, when this template was created, there was no such guidance about dashes or underscores in parameter names [1]. Making a heap of cosmetic edits doesn't seem very productive to me. - Evad 37 [talk] 13:56, 25 September 2025 (UTC) [reply ]

It appears that the guidance was added on 8 September 2020 by ProcrastinatingReader. I found a discussion from a week later, but I don't see a discussion that led to the change. I may have missed it. – Jonesey95 (talk) 18:07, 25 September 2025 (UTC) [reply ]

@Evad37: to be clear did NOT mean to imply you had done anything wrong! I was more looking for information. I agree that making cosmetic edits to literally over a million pages does NOT seem like a good approach. That being said, I’m wondering if we can update the template to allow for the properly formatted parameters to ALSO work? Then we can slowly update the documentation indicating that the underscored parameters should/can be used, without removing support for the hyphenated parameters. I would imagine that a simple mw.ustring.gsub(param,'_','-') would minimize the necessary changes to the excellent code written at Module:Infobox mapframe? Thoughts on this middle ground approach? Zackmann (^{Talk to me} /_{What I been doing} ) 19:13, 25 September 2025 (UTC) [reply ]

@Evad37 and Jonesey95: I have mocked up a solution which requires very few overall changes. See a comparison . While I technically am able to edit Module:Infobox mapframe I am VERY wary of making a change to such a widely used template. Can you take a look and tell me if it is a possible change?

For context, part of the motivation here is that I have overhauled a few infoboxes to comply with MOS:INFOBOXNAME, removing SnakeCased or params with spaces and hyphens in favor of those with underscores. If I do such an overhaul but have to leave 20 or so hyphenated params for this module to work that just complicates matters. Hence my suggested change. — Zackmann (^{Talk to me} /_{What I been doing} ) 07:42, 26 September 2025 (UTC) [reply ]

A few notes:

1. I can't tell if your mock-up code allows for |mapframe-marker-colour= (note the second hyphen).
2. Every template that uses mapframes and has an unknown parameter check has a list of mapframe parameters in the parameter check. It looks like that's at least 80 infoboxes so far, and the number is growing as people slowly work on Wikipedia:Mapframe maps in infoboxes. That list of parameters to check for will have to be doubled, or modified to use regexes; either way, it will be pretty noisy.
3. And just to be perverse: would your mock-up code allow for junk like |mapframe_marker-colour= (mixed hyphens and underscores)? If so, the parameter check will get even noisier.

I like your ambition, but this one might be one to let go. – Jonesey95 (talk) 12:55, 26 September 2025 (UTC) [reply ]

Jonesey95 so my change basically replaces all underscores in params with hyphens EXCEPT those that precede km or mi so that |mapframe-length_km= will work as well as |mapframe_length_km=. So points 1 and 3 are not a problem, though I appreciate you pointing them out. Point 2 on the other hand is absolutely one that I thought about. This will essentially double the number of unknown params needing to be checked. Now I can easily construct regexes to simplify matters, but that will still create some noise. That point absolutely warrants further discussion. IF this change gets pushed through in the end, I will gladly take on the responsibility of updating templates as needed. Zackmann (^{Talk to me} /_{What I been doing} ) 18:12, 26 September 2025 (UTC) [reply ]

D55 road doesn't show me a mapframe. Its wikidata:Q1995576 has an OSM relation ID, and that relation in turn links back to WD. What's wrong? --Joy (talk) 20:50, 26 September 2025 (UTC) [reply ]

Coordinates should be specified in either the WD or the infobox template. Regs, The Equalizer (talk) 23:01, 26 September 2025 (UTC) [reply ]

Wait, why do we have that as a strict requirement? A road is feature represented by a line, not a single point, so picking a point seems fairly arbitrary. Do we use that point for something? --Joy (talk) 06:53, 27 September 2025 (UTC) [reply ]

It's by design, explained at the notes for the mapframe template, presumably to cater for all the use case scenarios for the template - Template:Infobox_mapframe#Usage The Equalizer (talk) 09:44, 27 September 2025 (UTC) [reply ]

@The Equalizer I don't see any explanation there, only a statement of fact. I agree with Joy – I find this requirement totally arbitrary. I do wonder what the rationale for it is. If it's coming from our Lua code (as opposed to Kartographer) it should be removed. This, that and the other (talk) 10:12, 27 September 2025 (UTC) [reply ]

The explanation is probably in the code comment https://en.wikipedia.org/wiki/Module:Infobox_mapframe#L-183:

Require coords (specified or from wikidata), so that map will be centred somewhere

The centering makes sense for points, but with shapes, Kartographer is doing the centering. So the alternative would be to look up either coordinates/P625 or relation/P402 etc.

I'll see if I can rearrange it in the sandbox. --Joy (talk) 10:10, 28 September 2025 (UTC) [reply ]

I think this proposal will need some thought, as most shapes in WD or in the article now have coordinates attached to allow them to be shown. I would border on suggesting coordinate details are maintained in some way so that WD continues to provide that data for wider research purposes.

GeoJson coding allows a single point to position the shape as well as the shape coords, OSM uses a similar facility, and certainly I've seen suppliers of boundary data such as ONS in the UK supply centre points. Just a bit uneasy with shape data associated to a WD but having no visible coord claim and that the shape has to be extracted to get one.

I understand WikiVoyage and Commons use the detail too and they show maps displaying the point. I feel the coord req could be made more obvious in the template notes or a bot account on WD add a P625 claim more consistently when the shape is uploaded? Could be asked via Phabricator (or may have already been).

Regs, The Equalizer (talk) 12:05, 28 September 2025 (UTC) [reply ]

A shape necessarily contains embedded points, so whoever wants to do research on them can just extract one wherever it's not explicitly specified? In other words, both a P625 and a P402 are effectively a visible coord claim?

Thinking about it, there may be cases where this single set of coordinates would be the centre point, while not being a good marker point, but I think we also default on rendering a marker there. --Joy (talk) 16:59, 28 September 2025 (UTC) [reply ]

@Hike395 and Evad37: So I might have found a bug. After some research I don't think it is an issue with {{infobox settlement }}. Basically it looks like the module is just ignoring |mapframe-caption=. Or (and this is definitely possible) I am doing something stupid. Any help would be greatly appreciated!! Note this was found during the attempted conversion of {{Infobox Australian place }}. Zackmann (^{Talk to me} /_{What I been doing} ) 17:38, 5 October 2025 (UTC) [reply ]

Definitely mysterious. Will investigate. Good job on {{Infobox Australian place }}, btw! — hike395 (talk) 17:44, 5 October 2025 (UTC) [reply ]

Much appreciated. As always, let me know if I can help! Thanks for the kudos... Just hoping it happens. Feel free to chime in at the TFD. -- Zackmann (^{Talk to me} /_{What I been doing} ) 17:45, 5 October 2025 (UTC) [reply ]

Fixed. It was a bug in {{Infobox settlement }}. Mapframe captions were never turned on. Fixed now, but will take a while to propagate to the 500K+ articles. — hike395 (talk) 18:06, 5 October 2025 (UTC) [reply ]

You don't want to personally null edit half a million pages?^{[sarcasm ]}. Thanks a ton for getting right on that! - Zackmann (^{Talk to me} /_{What I been doing} ) 18:13, 5 October 2025 (UTC) [reply ]

Sorry, that one's on me. I hadn't been aware of autocaption also needing onByDefault at the time. I realized it in the meantime and documented it, but didn't go through all the call sites yet to make sure it's fixed everywhere. --Joy (talk) 20:11, 5 October 2025 (UTC) [reply ]

All good! Just glad it was found. -- Zackmann (^{Talk to me} /_{What I been doing} ) 20:12, 5 October 2025 (UTC) [reply ]

I've gone through a search of possibly affected templates and fixed ten more of them. --Joy (talk) 12:28, 6 October 2025 (UTC) [reply ]

Joy thank you!!! -Zackmann (^{Talk to me} /_{What I been doing} ) 17:08, 6 October 2025 (UTC) [reply ]

@Hike395: (or anyone else able to help) I've run into an issue with the attempt to convert {{Infobox Australian place/sandbox }} to use {{Infobox settlement }} as a wrapper. I'm getting a mapframe JSON error and I can't figure out what is going wrong. Any help running this down would be greatly appreciated!

• Template: {{Infobox Australian place/sandbox }}
• Testcase with error: User:Zackmann08/australia

Thanks in advance. --Zackmann (^{Talk to me} /_{What I been doing} ) 18:12, 11 October 2025 (UTC) [reply ]

The code expects a Wikidata number to be passed through to create a map as part of the call. It normally defaults said number from the article page the template code is placed on. As your sandbox has no Q number associated it errors. If you add |mapframe-id = Q820318 the error goes away. It's therefore not an error per se and by design. Regs, The Equalizer (talk) 19:28, 11 October 2025 (UTC) [reply ]

@The Equalizer: thank you! To be clear when I said an error I meant with my implementation, not the code here... --Zackmann (^{Talk to me} /_{What I been doing} ) 00:14, 12 October 2025 (UTC) [reply ]

@The Equalizer: can I trouble you for one more? I'm getting a weird issue with the map displaying, but showing as a point instead of showing a boundary. The testcase is avaliable at User:Zackmann08/australia as well (feel free to edit that if you need to test).

@Zackmann08: add | mapframe-wikidata = yes. Regs, The Equalizer (talk) 08:52, 12 October 2025 (UTC) [reply ]

Or better | mapframe-point = none. Regs, The Equalizer (talk) 08:58, 12 October 2025 (UTC) [reply ]

@The Equalizer: thank you! Much appreciated. Zackmann (^{Talk to me} /_{What I been doing} ) 08:59, 12 October 2025 (UTC) [reply ]

@The Equalizer: this may be a wikidata question... But is there anyway to detect IF the boundary is present? I.E. set |mapframe-point=none IF and ONLY IF there is no boundary provided by wikidata? I'm still learning wikidata... I do see that it is property P3896 but I'm not sure how to make that call to Wikidata... Zackmann (^{Talk to me} /_{What I been doing} ) 09:08, 12 October 2025 (UTC) [reply ]

P3896 entry references a Commons map shape file which can only be called by using its filename. Place boundaries are usually from Open Street Map, that route doesn't use P3896. In fact, the shape on OSM needs the Wikidata number there to import the shape to Wiki. The automation for mapframe only uses a point marker if coords but no shape exists, else a point and shape together which would need the above point to none parmeter adding manually. Regs, The Equalizer (talk) 15:18, 12 October 2025 (UTC) [reply ]

I just happened to notice the question at Template talk:Infobox university#Edit request mapframe. Would we have any reason not to show the relation shapes by default here? --Joy (talk) 21:07, 11 October 2025 (UTC) [reply ]

A very annoying one: the shape covers the area of interest, making some features underneath nearly invisible (what's the point of zooming in when nothing can be seen). I've been fixing this in individual articles before, just noticed it again today in Kaštela. It's as if the area outside of the shape is the only thing one is interested in. This can be fixed, though, by setting the default fill color to something lighter, and with less opacity. Ponor (talk) 21:27, 11 October 2025 (UTC) [reply ]

Oh, the default visuals of the shading? Yeah, I can't seem to find a rationale for those in the history. It seems this 2019 edit introduced #606060 for the default shape fill, and this 2020 edit introduced 0.5 for the default shape fill opacity. @Evad37 how did you arrive at those values? --Joy (talk) 02:03, 12 October 2025 (UTC) [reply ]

Oh dear, @Kozuch complained about this in August 2020 already at /Archive 1#Make default shape fill color/opacity lighter, and it went unanswered for over five years. --Joy (talk) 02:10, 12 October 2025 (UTC) [reply ]

I also couldn't find an explanation for the default stroke width, which seems to have been carried on as 3 from this 2018 edit. I've observed it to be too thick by default in a lot of cases where of a lot of indentation had to be presented. --Joy (talk) 02:17, 12 October 2025 (UTC) [reply ]

@Ponor Can use shape inverse to create a geomask. @Joy, as the notes on Wikipedia:Mapframe maps in infoboxes, there was no consensus to apply shapes to all infoboxes. Regs, The Equalizer (talk) 06:42, 12 October 2025 (UTC) [reply ]

The RFC question was about Wikidata coordinates, and I don't think everyone associates a pair of coordinates with shapes. All the actual mentions of shapes in Wikipedia:Requests for comment/Mapframe maps in infoboxes were positive. There wasn't any mention of shapes in the earlier Wikipedia:Wikidata/2018 Infobox RfC.

Most of the opposition has historically been about unreferenced data in Wikipedia, but most of the infoboxes I've fixed on Wikipedia have not had references on their coordinates, so I don't quite see what practical benefit we derive from not showing the available data on maps - be it good or bad.

In fact, recently I saw a question at Template talk:Infobox organization where it was clear that showing the coordinates on a map made it more obvious that data is sometimes bad. I understand the ease of the reaction of "just don't show it!", but I think a more helpful response is to make things even more obvious, such as by adding an automatic visible tag to a mapframe with data from Wikidata that doesn't have a reference, like a {{citation needed }} of some sort - just like we've always done with unreferenced claims on Wikipedia. --Joy (talk) 10:27, 12 October 2025 (UTC) [reply ]

The inverse mask would be a little better, I agree, but last time I checked that feature was buggy (in some examples it starts showing the map of the whole world, or something like that). Thanks for the color/opacity improvements, but I think we should be even more aggressive with it. That shading cannot be removed by the viewers, and it bears very little to no information, unlike what's left underneath. I believe I used the opacity value of 0.05. I wouldn't mind if it was zero, tbh. Ponor (talk) 12:51, 12 October 2025 (UTC) [reply ]

I actually stumbled upon a use case for it at Zagreb, where somehow it enables a distinction between two different sets of information (the narrower shape shows the area of the settlement of Zagreb within the city, and the wider shape shows the area of the other settlements within the city). I'm not sure if any of these visual indications are clear enough, but it seems like something is better than nothing in that case :) --Joy (talk) 13:03, 12 October 2025 (UTC) [reply ]

I've seen that in some other cases, and unless you know what it's showing, it's actually quite confusing, almost as if it's a bug. Maybe it is a bug lol. Like the one I mentioned in my previous answer re the inverse mask. The whole thing looks a little buggy, imo, and I'm not sure if us hiding things underneath the shade and getting these weird double shapes is an improvement. Template:Infobox mapframe/testcases shows what I'm talking about in the first few examples. Ponor (talk) 13:20, 12 October 2025 (UTC) [reply ]

I agree that the global zoom out is super weird. I'm not sure that we should eliminate the shading before fixing that, because it feels like we're missing something from the intent of the original code. --Joy (talk) 13:23, 12 October 2025 (UTC) [reply ]

Some 2 years ago I was playing with this idea, and my impression back then was that Kartographer is not ready to be enabled by default. The bug with the inverted shapes was reported many years ago, I'm not sure anyone will ever work on fixing that. Leaving that aside, the double shape feature is confusing; there are some islands in the first test case at Template:Infobox mapframe/testcases for Boston, and it's hard for me to tell whether they belong to the City of Boston or if that's a glitch. I sort of know what the shapes at Zagreb represent, but I don't expect our readers to know that too. Are the two "ears" just some shady areas of the City :)? Why is the core settlement not shaded at all (double shaded?)? I think I've seen something similar(ly confusing) at Sinj when I was playing with it. I'd ask for a button be added to the maps to show or hide these shapes, but the extension seems pretty much abandoned. Sadly, Ponor (talk) 15:29, 12 October 2025 (UTC) [reply ]

It is confusing that I can't seem to see the same shape at OSM, https://www.openstreetmap.org/relation/226224 doesn't show it, and ditto for https://www.openstreetmap.org/relation/8774953 I have to say this echoes those concerns people had in RFCs about 'magical code'. --Joy (talk) 16:06, 12 October 2025 (UTC) [reply ]

@Ponor Boston is correct. @Joy Zagreb and Sinij needed fixing, they had duplicate WDs at OSM, give it some hours to replicate. Regs, The Equalizer (talk) 17:23, 12 October 2025 (UTC) [reply ]

@The Equalizer: I don't know much about OSM (+WD), but it's likely that the contours were showing the borders of the "cities", which are 2nd order spatial and administrative divisions of the country, and their core "naseljes" (i. e. legally recognized settlements), which are 3rd order spatial divisions. They're usually eponymous, and we use same article for both. These may not be the only examples; Croatia alone has some 500 cities/municipalities and eponymous core settlements. Ponor (talk) 17:37, 12 October 2025 (UTC) [reply ]

Maybe we just need Kartographer to be conservative and stick to rendering the relation ID that is actually documented at Wikidata by default, rather than rendering every relation ID that backlinks that Wikidata QID, which could instead be like an option? --Joy (talk) 18:33, 12 October 2025 (UTC) [reply ]

If it's possible to choose (the correnct) one, sure - that's better than deleting valid data. What still bothers me is that shape fill/opacity. It makes already tiny labels and shapes on the zoomed-in map blurry and significantly lowers contrast. I don't think that'd pass any accessibility checks. The 2 px red outline alone should suffice. Ponor (talk) 01:53, 14 October 2025 (UTC) [reply ]

I don't know that the typical mapframe in the infobox is really accessible anyway, because it's so small in general.

For example, even when I browse Kaštela on my phone, the mapframe map is generally very vague. But at least it shows me 4 labels. The county map below it is all a bit of a blur, what with the base color scheme, too. So that seems good for mapframe on the face of it. When you click it and expand it, you get to an actually accessible map, one where you can easily zoom in to see things better.

It's ironic that the quality of being able to click to expand it is different in this context - this is usually intuitively true for supporting materials like images on Wikipedia, but it seems to me that the proper font labels inside the mapframe may make the reader doubt that the box is clickable. So we need to have the top right square icon, which is sort of good, though a tad unclear, too. --Joy (talk) 08:55, 16 October 2025 (UTC) [reply ]

A defining characteristic of these maps is their interactivity. If we only cared about the mini version of them, we would include static images with details of our choice, like we do with the (rather primitive) location maps. By covering the area of ​​interest with a gray shape, we lose the primary reason for adding an interactive map.

We show countries only by outlining their borders, without filling, and we can do the same with the borders of various other entities. The official city borders are usually something very artificial (see how big Gospić is), whereas the true extent of the populated area can be easily seen from the features drawn on the map. But only if we can have a clear view of them. Ponor (talk) 09:37, 16 October 2025 (UTC) [reply ]

Well, that's true, though the typical location map with political boundaries is sort of too bland when it doesn't show or shade the shape. As I mentioned before, I'd really like to understand how and why the fill was added five years ago before just dropping it. I looked around some more and found Module talk:Mapframe/Archive 1#Support for fill-opacity. @Jts1882 do you recall anything about the default values for shape fill opacity? --Joy (talk) 11:34, 16 October 2025 (UTC) [reply ]

Looking at the change in that discussion, it just adds the capability of setting the opacity through a parameter. If it is not set, it will just use the default, which I assume is set by the MediaWiki software. I suppose the module could set a default, but given the number of existing maps I'd be very wary of such a change. — Jts1882 | talk 12:10, 16 October 2025 (UTC) [reply ]

Well, that's the problem, the module does set a default, and after five years we've finally identified it to have been bad for map readability, and moderated it. If there's no actual proper rationale for the shading default, I'd moderate it further. --Joy (talk) 12:36, 16 October 2025 (UTC) [reply ]

I was referring to Module:Mapframe, which was what the linked discussion was about. But I see you are referring to Module:Infobox mapframe, which does set a default, and that you have changed it. Don't forget to change the default values in the template documentation when you have decided on the optimal values. — Jts1882 | talk 14:03, 16 October 2025 (UTC) [reply ]

Ah, good to hear. Thanks! --Joy (talk) 14:56, 16 October 2025 (UTC) [reply ]

@Joy Thanks for reducing the default opacity even further. I think we're now close to the shape Google Maps (maps.app.goo.gl/ja4q3pMYRkXudH1f6) is showing, though the features in their base layer have more contrast to begin with. Ponor (talk) 16:04, 16 October 2025 (UTC) [reply ]

In an ideal world the opacity would subtly decrease as you zoomed in. Mapbox and Google Maps do a similar thing in particular context, but I don't think Kartographer is capable of it. This, that and the other (talk) 03:29, 18 October 2025 (UTC) [reply ]

I added a test cases that illustrates how silly this looks:

• {{Infobox mapframe/testcases#Seville, Spain (Q8717,Q29) }}

It works on Minneapolis with {{mapframe }} SWITCH: options, but doesn't seem to work with {{infobox mapframe }} switcher options.

The hopefully equivalent test case over there is:

• {{Maplink/testcases#Multi switcher with a single id }}

--Joy (talk) 01:29, 18 October 2025 (UTC) [reply ]

This code had been added sort of in parallel:

• Mapframe module edit 19 June '20
• Infobox mapframe module edit 21 June '20

@Evad37 help please :) --Joy (talk) 01:47, 18 October 2025 (UTC) [reply ]

I would help, but I don't know what you're trying to accomplish. Are you trying to shift the radio buttons and associated text to the left, rather than center it? — hike395 (talk) 07:32, 18 October 2025 (UTC) [reply ]

@Hike395 nono, I'm trying to get the Seville test case above to not show the entire world map by default, but zoomed onto one of the geomasks. --Joy (talk) 09:02, 19 October 2025 (UTC) [reply ]

It's a known problem reported at phab:T305121. Workaround albeit more coding involved is to use Switcher directly. Regs, The Equalizer (talk) 14:57, 19 October 2025 (UTC) [reply ]

Wait, so the trick is to add or to remove the coordinates in the code going into Kartographer?

Anyway, what explains the difference between Module:Infobox mapframe and Module:Mapframe?

Is it maybe https://en.wikipedia.org/wiki/Module:Infobox_mapframe#L-367 which tries to allow Kartographer auto zoom to work, but doesn't go through if config.switcher is set? --Joy (talk) 15:21, 19 October 2025 (UTC) [reply ]

I fiddled a bit with it, to no avail. I guess I'm at a loss as to how to understand the output of p.multi, is it just HTML that is then interpreted by Kartographer Javascript code, or is there a postprocessing step that I'm not aware of? --Joy (talk) 16:37, 19 October 2025 (UTC) [reply ]

The template parameters and module code is only part of it. There are javascript and php libraries on backend servers hosting other aspects to Karto such as the OSM data, map tiles, 3rd party apps all with lots of loadbalancing, redundancy and so on. Lots of bedtime reading here: mw:Extension:Kartographer#Implementation. Regs, The Equalizer (talk) 17:42, 19 October 2025 (UTC) [reply ]

Oh, no doubt, but I'm just interested in what's the most efficient way to actually see the <mapframe> tags generated by the Lua module code, before they get interpreted. That way we could compare the outputs of the modules in text as opposed to with all the bells and whistles, and hopefully debug their differences faster. --Joy (talk) 17:51, 19 October 2025 (UTC) [reply ]

Recently, Joy has set the opacity of the grey fill color of shapes to be 0.075. I find this to be too low -- I cannot tell at a glance what is the inside and what is the outside of a shape. I think it should be set back to 0.15 (which was the bare minimum, in my opinion). What do other editors think? — hike395 (talk) 07:32, 18 October 2025 (UTC) [reply ]

Can you show any examples where it's hard to tell what's inside of a shape? I think it's quite easy to tell what's inside of a polygon even when where's no filling. On the other hand, the filling makes it hard to see what's underneath. Google Maps have even more translucent filling (maps.app.goo.gl/vYucw5gakhubBxwp7), which goes to completely translucent at higher zoom levels, and their base layer has more contrast to begin with. We don't use filling to differentiate country borders, yet we know what's "inside". Ponor (talk) 10:01, 18 October 2025 (UTC) [reply ]

It's hard to tell what's inside when you don't see the entire polygon, but only part of it. Here's an artificial example: Map. — hike395 (talk) 13:20, 18 October 2025 (UTC) [reply ]

I'd say that, in that slightly artificial example, you have the option to unzoom or move the map and see where you are. Unlike when it's all grayed out, which cannot be removed, and you see the streets, labels, and buildings as if you have a cataract. The gray shade considerably worsens accessibility of the map underneath. Ponor (talk) 14:23, 18 October 2025 (UTC) [reply ]

I agree it needs some level of shading by default. The features in the underlying Wiki maps is quite low as WikiMaps only pulls in a limited number of them (boundaries, street outlines/names, park outlines, transit lines etc). It is only meant to be indicative as users ideally would use a better definitive source if they want detail (OSM, national cartography products, etc) same as any article, so don't think they are missing too much with high shading. Regs, The Equalizer (talk) 15:07, 18 October 2025 (UTC) [reply ]

This template has fewer than 30 watchers (active or not), so this page is probably not the best place to discuss things that, IMO, severely impact accessibility. People should be shown several options and asked to voice their educated opinion about the amount of detail they want to see when they click on the interactive map. In the following three maps, opacity is set to 0, 0.08, 0.16. Map Map Map Ponor (talk) 22:03, 18 October 2025 (UTC) [reply ]

The thumbnail is indicative, but it also invites the reader to click it or tap it, and find themselves in a whole new world of information. We want them to be able to learn as efficiently as possible in that stage, too. They should be able to actually distinguish these features inside the shape as they keep panning and zooming. The Show nearby articles button is a great tool, too.

But I guess I'm really wondering if you mean you prefer the old 0.5 shade or are we just haggling about 0.075 or 0.15 or similar :) --Joy (talk) 09:14, 19 October 2025 (UTC) [reply ]

I support the revised opacity. Higher opacity is fine at low zoom levels, but as soon as you zoom into the interactive map, features are tough to distinguish; it's as though someone turned down your screen brightness to minimum and expected you to read the street names and so forth.

For the concerns raised above:

• The boundary (an unmissable bright red colour by default) very clearly distinguishes the inside of the polygon from the outside.
• In my view, any mapframe that shows a partial polygon should be corrected so the entire polygon is visible. In the exceptional case where showing a partial polygon is necessary, the opacity (and other attributes if needed) can be manually overridden.

This, that and the other (talk) 04:19, 19 October 2025 (UTC) [reply ]

I'm generally fine with anything around 0.1, where you can still read the labels inside the shape without squinting. --Joy (talk) 09:08, 19 October 2025 (UTC) [reply ]

I was actually happy with 0.15 that Joy set. I agree that 0.25 is too high. How about 0.12, halfway between the two levels that Ponor showed, above, with stroke width 2? Map — hike395 (talk) 12:21, 19 October 2025 (UTC) [reply ]

Let's also show what plain 0.1 and current 0.075 look like for comparison: Map Map --Joy (talk) 13:07, 19 October 2025 (UTC) [reply ]

I do not see any information added by having the zoomed-out shape opacity increased from 0.08 to 0.12 or, heaven forbid, 0.16. I do see a lot of information obscured by the gray cloud on top of the zoomed-in map. Is this shape really that important that it needs double emphasis - thick red! stroke, dark fill? We only use thick gray stroke for county borders, which are definitely something more important to us irl. The Berlin map looks fine to me at 0.08, and if there are exceptions, the opacity can be changed in individual articles. My actual preference is opacity 0: show map information in all its glory. Ponor (talk) 14:57, 19 October 2025 (UTC) [reply ]

While my stance is above, but will go with consensus. But can I ask that we use some more representative examples such as some of the test cases, geomasks are one option that use that shading for focus. Regs, The Equalizer (talk) 15:26, 19 October 2025 (UTC) [reply ]

Yes, I didn't want to go further than 0.075 because I saw it used in geomask test cases. They don't seem to be not hugely common, but I did remember seeing it used at Washington, D.C. Which reminds me, let me reproduce the current level of shading there. --Joy (talk) 15:41, 19 October 2025 (UTC) [reply ]

How about opacity 0.1? Pretty please? I think it would be an mild improvement over what we have now. — hike395 (talk) 02:36, 21 October 2025 (UTC) [reply ]

Okay (it's barely perceptible for me). --Joy (talk) 19:58, 21 October 2025 (UTC) [reply ]

Hmm, it didn't seem to work. Can someone please check if I'm doing it wrong at {{Infobox settlement/testcases3#Washington, D.C. (mapframe shape inverse) }}? --Joy (talk) 15:47, 19 October 2025 (UTC) [reply ]

It's the same autozoom fault I mentioned previously in your earlier thread on geomasks. Add | mapframe-wikidata = yes if you still want to test it in fullscreen without the thumbnail working. Regs, The Equalizer (talk) 16:28, 19 October 2025 (UTC) [reply ]

Oh, that's so curious, so the wikidata option is the prerequisite for the geomask option? (But then that also triggers the zoom bug like #switcher zoom/center?) --Joy (talk) 16:35, 19 October 2025 (UTC) [reply ]

It's not, for example the Spain Switcher testcase doesn't use a Wikidata parameter because it uses this infobox mapframe template directly, yet the thumbnail still shows the world map. The Wash DC test case uses Infobox Settlement which needs that parameter then transcludes mapframe to get the shape. I believe the issue is the way Karto sees a geomask as a world map shape with a cutout, so it shows the world map. Regs, The Equalizer (talk) 16:53, 19 October 2025 (UTC) [reply ]

Ohh, right, that is indeed a practical difference I have noticed in other contexts: the default when calling {{infobox mapframe }} seems to be to show wikidata shapes, but with embedded calls from the inside of another infobox it is not use it by default. That's a separate issue I kept thinking I should raise. --Joy (talk) 17:31, 19 October 2025 (UTC) [reply ]

Yup. The parameters are just a (relatively) easy way for low-tech editors to customise the templates and hence articles to a limit. Having the templates call other templates is genius, the existing toolset is reused not rebuilt each time and a template/module creator can call them or layer them into their new functionalities. Regs, The Equalizer (talk) 18:00, 19 October 2025 (UTC) [reply ]

I tried to require this from Module:Infobox military conflict/sandbox but it just broke all of Template:Infobox military conflict/testcases, saying Lua error in Module:Infobox_mapframe at line 24: assign to undeclared variable 'trimArgs'.

Does that mean the trimArgs function needs to be p.trimArgs for this to work elsewhere? --Joy (talk) 20:41, 20 October 2025 (UTC) [reply ]

Looks like Module:Mapframe uses an explicit namespace for its trimArgs (util). This was introduced in [2] which doesn't explain it, but it sounds like that's it. --Joy (talk) 20:44, 20 October 2025 (UTC) [reply ]

There's an easier way: Wikipedia:Mapframe maps in infoboxes, in particular step #5 in the Process section that leads to Module:Infobox mapframe#Automatic maps in infoboxes. Regs, The Equalizer (talk) 21:49, 20 October 2025 (UTC) [reply ]

But Template:Infobox military conflict is entirely implemented in the Lua module...? --Joy (talk) 22:04, 20 October 2025 (UTC) [reply ]

Doing the same here helped avoid the syntax errors. (Sadly, it still didn't render the map frame.) --Joy (talk) 17:39, 22 October 2025 (UTC) [reply ]

Okay, figured it out, it does generally work.

Now the final problem I have at Module:Infobox military conflict is that I can't seem to set a new default value for mapframe-zoom. Does anyone have an idea why this would be ignoring me? --Joy (talk) 21:10, 22 October 2025 (UTC) [reply ]

Looks like you got it to work then. Well done but are there some benefits hard coding the call directly in this way. Regs, The Equalizer (talk) 08:10, 26 October 2025 (UTC) [reply ]

@The Equalizer as far as I can tell, the most common mechanism has been to manually make a copy of the args table, and then make the adjustments. But in this case, it would mean copying like a hundred values, which sounds insane. I need to see about doing this in a loop. --Joy (talk) 08:35, 26 October 2025 (UTC) [reply ]

Clarify for me - does it need a new default value? The transclusion uses the default value of mapframe which is zoom level 10 and that seems to work consistently on the test cases and other pages using military conflict. The mapframe zoom parameter can be added to individual maps of course and the mapframe only appears when there is no existing legacy map so has limited impact. The Equalizer (talk) 11:50, 27 October 2025 (UTC) [reply ]

The problem is that the context of military conflicts isn't typically zoom level 10. Wars and battles aren't typically fought in a way where that zoom level is useful, and esp. because a lot of it is history, so modern-day features aren't really that relevant. There's many thousands of them like that, so I'd really like to not have to tune them manually. --Joy (talk) 16:24, 27 October 2025 (UTC) [reply ]

BTW I asked about this at Module talk:Arguments#writing to the args table when the key contains a hyphen (-). --Joy (talk) 11:49, 26 October 2025 (UTC) [reply ]

@Zackmann08 BTW would the underscored parameters fix this, if it was .mapframe_zoom? --Joy (talk) 11:49, 26 October 2025 (UTC) [reply ]

@Joy: I'll be honest, I have no clue what's going on here. This one is a little over my head. Sorry! Zackmann (^{Talk to me} /_{What I been doing} ) 19:45, 26 October 2025 (UTC) [reply ]

@Hike395: can you help out here... I feel like I'm missing something obvious. The TemplateData for this template says that all parameters should be prefixed with mapframe-. While that works when calling the MODULE, it appears that the opposite is true when using the TEMPLATE....

With mapframe- prefix as per the TemplateParams (note nothing displays as it is not getting the coordinates)

{{infobox mapframe|mapframe-coordinates={{coord|31|56|S|115|58|E}}}}

WITHOUT mapframe- prefix

{{infobox mapframe|coordinates={{coord|31|56|S|115|58|E}}}} Map

Is the TemplateData wrong? If so can/should that be fixed in the Module? Zackmann (^{Talk to me} /_{What I been doing} ) 18:04, 27 October 2025 (UTC) [reply ]

If the TD is wrong, it should be fixed on the documentation page. – Jonesey95 (talk) 18:30, 27 October 2025 (UTC) [reply ]

Jonesey95 I 100% agree. I want to hear from someone (Hike395) who understands this Module better than I to make sure I'm not missing something... If they can confirm that the TD is wrong, I will personally update it. I'm pretty sure it is, but want to make sure I'm not missing something. Zackmann (^{Talk to me} /_{What I been doing} ) 18:31, 27 October 2025 (UTC) [reply ]

The details in TD are correct but in the right situation. Infobox mapframe can be used by

• calling the template directly in a page source code (as per your example)
• adding parameters to other infobox templates
• fully coding it into other infobox modules.

With the first only the standard parameters are needed, with the latter two parameters with the mapframe-* prefix are needed since you aren't calling mapframe directly but through another template.

It is explained elsewhere but is a bit scattered. Could do with removing from the template instructions, and explaining that if doing the above integrations go to where it is again detailed at {{Module:Infobox mapframe}}. Regs, The Equalizer (talk) 18:57, 27 October 2025 (UTC) [reply ]

@The Equalizer: Appreciate your explanation. This is a bit complicated so I want to make sure I am understanding you correct before I change anything...

The TD for TEMPLATE Infobox mapframe, is wrong. If you call {{Infobox mapframe }} you need to NOT use the prefix mapframe-.

If you are using the MODULE, for example if you are working on a transclusion of {{Infobox settlement }} which has Module:Infobox mapframe built into it, THEN you need to use the prefix mapframe-.

Based on my understand of your comments, the TD for {{Infobox mapframe }} DOES need to be updated, but we do not need to change the documentation for {{Infobox settlement }} (or other infoboxes that use the module) as those are correct. (To be clear that was never really in question, but just want to be clear). Zackmann (^{Talk to me} /_{What I been doing} ) 19:03, 27 October 2025 (UTC) [reply ]

That sounds right to me. I'm pretty sure that TemplateData is used only by the Visual Editor when inserting or editing the template directly. So that's the first bullet above, which means that the prefixed parameters would not be valid, if I am understanding correctly. It appears that the correct fix is to remove the prefixed parameters from the TemplateData so that the Visual Editor uses valid parameters.

When the prefixed template parameters are used directly in other infoboxes that show mapframe maps, the template documentation for those infobox templates should show only the prefixed parameters as valid.

This may mean that the prefixed parameters are not valid in the unknown parameter check here at Infobox mapframe, but I would want to get verification of that by someone who understands the module code and/or someone who can demonstrate on the testcases page that the prefixed parameters do or do not work. – Jonesey95 (talk) 19:07, 27 October 2025 (UTC) [reply ]

This test in my sandbox appears to prove what Jonesey95 is saying, that the |mapframe-...= versions of these parameters do NOT work when called from the TEMPLATE version. IMHO this should be changed. |mapframe-marker-color= and |marker-color= should both be acceptable parameters for consistency's sake. Zackmann (^{Talk to me} /_{What I been doing} ) 19:11, 27 October 2025 (UTC) [reply ]

So it looks like the TemplateData section should be changed to match the template documentation. As far as I can tell, the template documentation does not mention any prefixed parameter names. – Jonesey95 (talk) 19:55, 27 October 2025 (UTC) [reply ]

So for now I have gone ahead and updated the template data...

Once the new ParamReport is generate in November I plan to clean out Category:Pages using infobox mapframe with unknown parameters (96).

Ideally BEFORE than happens on Nov 1st, the unresolved question is should that parameter names in {{Infobox mapframe }} be changed to be consistent with Module:Infobox mapframe?

@Hike395 and The Equalizer: it appears the only difference in the code is that TEMPLATE {{Infobox mapframe }} calls {{#invoke:Infobox mapframe|main}} while all other templates that call the module call {{#invoke:Infobox mapframe|auto}}. Should that be changed for consistency and CAN it be done in a way that won't break the 81,000+ pages that currently use TEMPLATE {{Infobox mapframe }}. Zackmann (^{Talk to me} /_{What I been doing} ) 20:04, 27 October 2025 (UTC) [reply ]

I'll let others answer as well, but as I said on Zackmann08's talk page, I think the mapframe-xxx parameter names are assigned in order to prevent parameter namespace conflicts. If we support them here, will we cause parameter name conflicts in pages that use this template along with other infobox templates? – Jonesey95 (talk) 00:17, 28 October 2025 (UTC) [reply ]

I can't imagine that a more specific parameter name, that is prefixing with mapframe- would cause a conflict... But Jonesey is right, that needs to be considered. Zackmann (^{Talk to me} /_{What I been doing} ) 01:24, 28 October 2025 (UTC) [reply ]

The problem is also that we refer people to use this templatedata elsewhere when they integrate per Module:Infobox mapframe/doc. After this edit, the advice becomes wrong.

I think changing the code to always support parameters with the prefix is the way to go. --Joy (talk) 06:54, 28 October 2025 (UTC) [reply ]

I mean we could also just tell people to copy the TemplateData from Module:Infobox mapframe/doc instead, which remains correct. Seems bizarre to have the template data right there and then say "copy this from somewhere else". I will also point out that {{Infobox mapframe/doc/parameters }} which is transcluded on dozens of templates remains correct. The documentation is ONLY updated for direct use of the template.

But regardless of this, I agree with Joy. The best, safest, least confusing option is to make it so that when called from the template, both prefixed and non-prefixed params will work. It should be a simple one line regex... str = mw.ustring.gsub(str, 'mapframe%-', '') should do the trick I think. Zackmann (^{Talk to me} /_{What I been doing} ) 07:01, 28 October 2025 (UTC) [reply ]

Um, I'm not sure what you mean, because we don't have a separate copy of templatedata at that link? I also don't think it's a good idea to maintain two separate copies of the entire blob just because of this largely clerical distinction. It's bad enough we copy&paste the templatedata blob elsewhere. --Joy (talk) 14:18, 29 October 2025 (UTC) [reply ]

@Joy: sorry this is all confusing and I'm not doing the best job of explaining...

• {{Infobox mapframe/doc/parameters }} is what is transcluded on the documentation pages which use the module. See the large list of transclusions.
• {{Infobox mapframe/doc }} is the documentation specifically for the template. mapframe- to avoid parameter name conflicts as jonesey95 explained above. If you are using the TEMPLATE, there is no need to prefix because the parameters are contained within the template call. This goes to the intricacies of how templates differ from modules. You seem to be pretty well versed with that distinction so I don't want to patronize you by explain things you already understand... But if I can provide more clarification let me know!

All that being said, I do think it would make everyone's life easier if mapframe-... worked for both the module AND the template. We don't have to remove support for the non-prefixed parameters in the template version. But I would suggest changing the documentation to only indicate the mapframe- prefixed ones so that moving forward people use those instead and keep everything consistent.

Again, sorry I'm not doing the best job explaining. Hopefully this post makes a bit more sense but let me know if I can provide more clarification... Zackmann (^{Talk to me} /_{What I been doing} ) 23:58, 29 October 2025 (UTC) [reply ]

@Zackmann08 the problem I'm talking about is the hundreds of other infobox templates and modules that use the module. They all each may have their own TemplateData, and indeed many do, which then needs to contain the mapframe parameter definitions. Otherwise, they only get the static parameter documentation and people using VisualEditor can't modify their mapframe aspects, right? There doesn't seem to be a documented inclusion mechanism for sharing that, instead it gets copied and pasted. --Joy (talk) 07:55, 30 October 2025 (UTC) [reply ]

Joy Ah I get ya. I think the proper way to do it is to use {{Infobox mapframe/doc/parameters }} but that absolutely is not well documented. Zackmann (^{Talk to me} /_{What I been doing} ) 15:01, 30 October 2025 (UTC) [reply ]

There is no templatedata in there. Would it be possible to add it there? Is it possible to have two <templatedata> tags on the same page that get combined into the VisualEditor forms? --Joy (talk) 16:50, 30 October 2025 (UTC) [reply ]

Facepalm Facepalm @Joy: I finally understand why you and I were on different pages (kinda literally). You are correct, that template does NOT have template data. That is my error. It has parameter documentation, but NOT the TemplateData. NOW I get what you meant. I think the best way to resolve this is to just do what we both have seperately suggested... Make {{Infobox mapframe }} function with mapframe- prefixed parameters. Then all the template data will line up. Hike395 is this something you can help us make happen? I think that all we need to do is sanitize the parameters with a regex like: str = mw.ustring.gsub(str, 'mapframe%-', ''). Then both the prefixed and un-prefixed parameters will work. I'm happy to mock something up in the sandbox of the module, but with no testcases for the MODULE (I know there are template testcases) I would be very uncomfortable merging this to the Module without Hike395's input. --Zackmann (^{Talk to me} /_{What I been doing} ) 22:26, 30 October 2025 (UTC) [reply ]

@Joy: I have mocked this up in Module:Infobox mapframe/sandbox. Was a pretty straight forward change. I checked the TEMPLATE testcases and nothing seems to be broken there... The change I made is only touched when calling the main function. Templates that use the module, such as {{Infobox settlement }}, are supposed to use the auto function. If they were using the main function it wouldn't be working properly already... Based on this search I'm pretty confident that nothing beyond the template is using main so I am fairly comfortable with the change... But I still do want a second set of eyes on this. Maybe you can do a little testing and report back? Zackmann (^{Talk to me} /_{What I been doing} ) 22:58, 30 October 2025 (UTC) [reply ]

I am confused. Can someone explain to me the problem that we are solving by adding "mapframe-" parameters to {{Infobox mapframe }}? In general, you want to avoid adding redundant parameters to a template, because that can a template to be difficult to maintain in the future. That doesn't mean you should never do it, but changing documentation is preferable to adding redundant parameters. — hike395 (talk) 11:52, 31 October 2025 (UTC) [reply ]

@Hike395: the TLDR version is that the module version of Infobox mapframe requires these prefixed parameters, the template version not only doesn't require them, but doesn't work with them in place. This results in confusing/different TemplateData. For people like you, me and Joy this isn't as much of an issue as we really understand the difference between Modules and Templates. But for the average user this leads to confusion. Per the param report there are over 10,000 attempts to use mapframe- prefixed parameters. Our conclusion, based on the lengthy discussion above, is that it would make everyone's life easier to do the following:

1. Support the mapframe- prefixed parameters in both places
2. Continue to support the NON prefixed parameters in the template version
3. Only document that prefixed parameters in the TemplateData and /doc so that the documentation between the 2 stays consistent and we don't have to maintain 2 separate sets of TemplateData.

Let me know if you have any other questions! Zackmann (^{Talk to me} /_{What I been doing} ) 15:04, 31 October 2025 (UTC) [reply ]

I'm with Hike395 at this time, until real evidence of need is presented. I clicked on one of those 10,000 at random, Bakassi, which is allegedly using |mapframe-coordinates= and I don't see it trying to use |mapframe-coordinates= directly. Also, why would a module need TemplateData? Let's figure out what the actual problem is, if there is one. – Jonesey95 (talk) 02:32, 1 November 2025 (UTC) [reply ]

Hmm. I'm wondering if this has something to do with how the param report is generated... I too clicked on a random article and don't see it using the |mapframe-coordinates=. It uses |coords= which is an accepted parameter of {{Infobox mapframe }} but yet doesn't appear ONCE in the param report. I don't know how the param report is actually generated but could it be somehow replacing the prefix? I'm confused...

Jonesey95 why would a module need TemplateData. You are correct, the module doesn't. The issue is that when Module:Infobox mapframe is added to another template (say {{Infobox oil refinery }} which I'm about to add it to...) people need to go somewhere to get the TemplateData. The issue that joy identified is that if you look at the very bottom of Module:Infobox mapframe/doc you will see Parameters can also be added to the TemplateData, which can be copied and pasted from the relevant parts of Template:Infobox mapframe/doc . The problem is that the TemplateData found at that link will not work for templates using the module as it does not contain the mapframe- prefix. So if you follow the instructions (or just go to the template) and copy that TemplateData to another template (using my example, {{Infobox oil refinery }}) you will get a bunch of parameters that don't work.

Now the other solution (and I'm guessing the one you and Hike395 will go for), is to change the freaking directions. Don't tell people to copy data that won't freaking work. That is 100% valid. My (and I think Joy's thinking) was why not just unify this so that the parameters are the same whether you are using the Module incarnation OR the Template incarnation. It seems to me to be the most user-friendly approach.

Again, for the 4 of us this may not be necessary as we really do get the difference between Modules and Templates. I don't think all editors share that depth of knowledge. So my 2 cents is there is no harm with having both |mapframe-marker= & |marker= do the same thing in the template version. Particularly when (as shown by this diff) it isn't an enormous refactor. I just don't see the downside to having these aliases in the Template... But maybe I'm missing something? Zackmann (^{Talk to me} /_{What I been doing} ) 04:06, 1 November 2025 (UTC) [reply ]

If the instructions are wrong, let's change the instructions. I'm not inclined to bend over backwards to support the poorly designed world that is TemplateData. – Jonesey95 (talk) 14:53, 1 November 2025 (UTC) [reply ]

The downside to duplicate parameters in the template is that any automated downstream edits (e.g., using AWB) now are twice as complicated, because they have to handle two cases, not one. I agree with Jonesey95: I would change the instructions instead of the template. — hike395 (talk) 15:14, 1 November 2025 (UTC) [reply ]

Fair enough. Zackmann (^{Talk to me} /_{What I been doing} ) 20:05, 1 November 2025 (UTC) [reply ]

How could we best implement the way mapframe looks hidden by default at Vancouver or Florence - in the module?

Do we just open-code the gist of {{hidden begin }} and {{hidden end }}, wrapping the output into the two HTML div's with those classes? --Joy (talk) 22:43, 30 October 2025 (UTC) [reply ]

Why would we want to hide information by default? – Jonesey95 (talk) 23:22, 30 October 2025 (UTC) [reply ]

I would also argue this is bloat. Why do you need 5 different maps for Vancouver? 1 image, 1 mapframe and 3 pinpoints. Surely we can eliminate at least one of these... Mapframe is still relatively new (at least compared to the pinpoint maps) so that might be why, but really, is there any reason to have so many maps in the Infobox?! Especially since the mapframe basically duplicates what the image shows... Zackmann (^{Talk to me} /_{What I been doing} ) 23:30, 30 October 2025 (UTC) [reply ]

Mapframe ostensibly duplicates pushpin maps, but it is a much more featureful map compared to them. I've talked about this recently at e.g. Talk:Florence#map layout, please see there for an elaboration. --Joy (talk) 00:34, 31 October 2025 (UTC) [reply ]

Generally, mapframe tends to be the freshest addition of them all, so it should be a conservative migration in these cases - it treats the existing elements as primary, and mapframe as an optional addition, hence something that might be accessed infrequently enough that it can be hidden. In fact, Talk:Florence shows a case of an editor complaining even about a second map.

Additionally, in my case I specifically posted this because of the {{Infobox organization }} mapframe implementation. Apparently, folks have been adding coordinates to those infoboxes willy nilly, without an assumption that these would be rendered on a map. Now that I made them actually show up when there's no other map, someone noticed they're often given undue weight and noted it at Template talk:Infobox organization. It's a legitimate complaint in context - while it can be vaguely useful to be able to see where an organization's headquarters are on a map, there's a lot of cases where it's unhelpful by default because it's just one data point about a topic whose display on a map should really include a multitude of points. Hence, that migration also needs to be made more conservative. onByDefault=off would be too conservative in my mind. A rolled up version would seem like a reasonable compromise between these two options. --Joy (talk) 00:30, 31 October 2025 (UTC) [reply ]

I don't think it helps to hide something that is unhelpful for misleading. It should be removed instead. MOS suggests: If information in a list, infobox, or other non-navigational content seems extraneous or trivial enough to inspire pre-collapsing it, consider raising a discussion on the article (or template) talk page about whether it should be included at all. – Jonesey95 (talk) 00:55, 31 October 2025 (UTC) [reply ]

The problem is that we really don't know whether it's extraneous or trivial. We found a fair few cases where it is, but there's also some where it isn't, where the headquarters location is relevant. There's over 1k of them at this time. It's not a trivial choice of a default. --Joy (talk) 02:01, 31 October 2025 (UTC) [reply ]

I might be missing something. For those instances where it isn't helpful, it should be removed, not hidden. For those that it is helpful, it should be shown. In either case, hiding it isn't the best solution. Gonnym (talk) 16:59, 31 October 2025 (UTC) [reply ]

Okay, and how do you do that using the facilities that the template provides? Beyond a manual review of all those articles, I don't see how. --Joy (talk) 18:10, 31 October 2025 (UTC) [reply ]

The questionable TemplateData lists "caption" as a supported parameter, and I see "args.caption" in the module, but I haven't been able to make a caption appear using "caption" or "mapframe-caption". It is used on the testcases page at "Seville, Spain (Q8717,Q29)", but no caption is displayed. Does anyone have any insight? Is this a broken feature, or one that is not supposed to work, or something else? – Jonesey95 (talk) 15:04, 3 November 2025 (UTC) [reply ]

@Jonesey95: FWIW this DOES appear to work on the Module implementation... See Keijō Shrine where I was able to add a caption with |mapframe-caption=. And LITERALLY as I was typing this I figured out what is going on... When using the Module you do the following:

| image = {{#invoke:Infobox mapframe|auto}}
| caption = {{#invoke:Infobox mapframe|autocaption}}

I'll bet you money that if you trace the code, the args.caption is only used by the autocaption function. So when you use the template version of this, it just gets ignored since the template calls {{#invoke:Infobox mapframe|main}}. Now whether that is a bug? Working as designed? In need of updating? I don't really know. But I will say it's another reason for my current project which is removing calls to {{Infobox mapframe }} that can be replaced by the Infobox's builtin call to the Module. Hope that helps! --Zackmann (^{Talk to me} /_{What I been doing} ) 16:57, 3 November 2025 (UTC) [reply ]

So I'm in the process of converting a lot of pages from using |map/module/image={{Infobox mapframe}} to using the Module:Infobox mapframe call that is built into the infobox. (For example see this edit).

The issue I am running into is the following, and this is a bit hard to explain so bare with me... {{Infobox river }} has |mapframe-marker=water hardcoded. So when I convert (as I did in the diff above), I have to manually check for the presence of a shape (I think that's the technical term for the blue line that shows up on the mapframe on Vuka (river)). If that blue line is present, I don't want to show the mapframe-marker so I have to add |mapframe-point=none to override the settings in {{Infobox river }}.

My question is... Is there someway to change the call to Module:Infobox mapframe to automatically hide the marker if a shape is present? Is what I'm describing already avaliable? If not, is it feasible to add? Thanks in advance! - Zackmann (^{Talk to me} /_{What I been doing} ) 22:44, 4 November 2025 (UTC) [reply ]

mapframe-point = none should be doing that, but I'm not sure why you'd want to remove the point marker by default. In case of rivers, it usually points to some important feature like a source or a mouth, which shouldn't be a bad thing to show on the map. --Joy (talk) 21:37, 7 November 2025 (UTC) [reply ]

I setup such an example in the template sandbox, it then removes the point as seen in the testcases. Regs, The Equalizer (talk) 21:38, 7 November 2025 (UTC) [reply ]

@Joy: The issue I have found with doing that in the past is that if there is no shape AND you remove the point, the map goes nuts... Removing the point on a case by case basis definitely works. But making that the default in the infobox code would be very problematic. Zackmann (^{Talk to me} /_{What I been doing} ) 23:28, 7 November 2025 (UTC) [reply ]

Agreed, thanks. --Joy (talk) 07:45, 8 November 2025 (UTC) [reply ]

I just tried to add |mapframe=yes to {{infobox settlement }} on Brisbane, but it choked and showed null island.

At the same time, using |image_map={{infobox mapframe }} does work.

Why is this happening? --Joy (talk) 21:40, 7 November 2025 (UTC) [reply ]

Brisbane isn't using Infobox Settlement, but {{Infobox Australian place}} - Mapframe isn't fully integrated there as per Wikipedia:Mapframe maps in infoboxes, the template has different parameters to display maps, I see @User:Zackmann08 has done some edits to add mapframe functionality but doesn't look standard. Regs, The Equalizer (talk) 23:13, 7 November 2025 (UTC) [reply ]

@Joy: I think The Equalizer is onto something. The immediate issue is that Brisbane is using {{Infobox Australian place }}... Which while a wrapper for {{Infobox settlement }} still has a ton of added customizations that manipulate a lot of the parameters that are passed to settlement. I bet this has something to do with Module:Australian place map manipulating the coordinates. I really don't have the mental capacity to dive into this right now... But if I were you, as an experiment I would go to {{Infobox Australian place/sandbox }} and remove all mentions of Module:Australian place map. Then try displaying the sandbox version on Brisbane with |mapframe=yes and see what you get... That is how I would attempt to debug the issue. Zackmann (^{Talk to me} /_{What I been doing} ) 23:26, 7 November 2025 (UTC) [reply ]

Hmm. The local map module is only handling the various {{Location map }} wrapping, not mapframe.

The only main mapframe parameter that template now overrides is:

match pre-existing template behaviour by suppressing point marker on area features

|mapframe-point=none

So that's actually a similar problem as what we discussed recently - if the shape is missing in any way, that infobox will screw up normal point rendering. I'll bring this up on talk there. --Joy (talk) 07:50, 8 November 2025 (UTC) [reply ]

At Brtonigla, the mapframe is zoomed all the way in to 20m, but the input should be area_total_km2 = 32.9. @Hike395 any idea? --Joy (talk) 21:53, 7 November 2025 (UTC) [reply ]

I see a recent edit by @User:Zackmann08 adding |mapframe-shape=yes to {{Infobox settlement}}, which seems to force the zoom level to level 19. If |mapframe-shape=no is added it reverts back to zoom value 10. Regs, The Equalizer (talk) 23:43, 7 November 2025 (UTC) [reply ]

Absolutely looks to be caused by my change. But why ON EARTH does the presence of a shape change the default zoom level!? Can this be easily fixed? If not we will need to revert my change to {{infobox settlement }} as this is definitely not an intended consequence... (@The Equalizer: thank you for the ping!) Zackmann (^{Talk to me} /_{What I been doing} ) 23:46, 7 November 2025 (UTC) [reply ]

I went ahead and reverted my change for now. This affects way too many pages to leave in place, waiting on a fix... That being said, would really like to see this fixed so we can restore the change I made. Zackmann (^{Talk to me} /_{What I been doing} ) 23:54, 7 November 2025 (UTC) [reply ]

I will investigate, but I am not optimistic.

To answer Zackmann's question --- if you want mapframe to correctly display a shape or line, there is no way for any Wikipedia module or template to set the center or zoom of the map. All of the information on the line/shape is derived from OpenStreetMap (not Wikidata), and the Kartographer must "take over" the zoom to display the line or shape. Syncing of data between OpenStreetMap and Wikidata is hindered both by license incompatibility and the lack of stability of identifiers on the OpenStreetMap side. This is almost impossible to fix. — hike395 (talk) 00:57, 8 November 2025 (UTC) [reply ]

hike395 appreciate you investigating. There seems to be an inconsistency between how the Template version displays and how the Module version displays with the same parameters listed. The template autoloads the shape while the module does not. That is really what would be helpful to resolve. In any case, you understand this far better than I and I appreciate your help! Zackmann (^{Talk to me} /_{What I been doing} ) 01:15, 8 November 2025 (UTC) [reply ]

I haven't seen such a difference. I find testing with {{Infobox mapframe }} to be the same as testing with Module:Infobox mapframe main() function. — hike395 (talk) 01:54, 8 November 2025 (UTC) [reply ]

Hmm. So full disclosure Hike395 this is probably due to my not understanding stuff... But for example this edit resulted in the loss of the mapframe shape... and I don't understand why. Is it something in the way {{Infobox military installation }} calls the module? Any help greatly appreciated!

Just a follow up, I made this change to Infobox military installation which made the problem go away, but I still don't understand why the issue happened in the first place. Template:Infobox mapframe seems to be automatically getting the shape while Module:Infobox mapframe seems NOT to automatically get the shape per this edit with the previous incarnation of Infobox military installation... Again any help is greatly appreciated! --Zackmann (^{Talk to me} /_{What I been doing} ) 06:30, 8 November 2025 (UTC) [reply ]

Okay, but the shape linked from that Wikidata item is Geographic data related to 6466287 at OpenStreetMap and it did not get rendered.

Is it because there is no back link from OSM to Wikidata on the relation? --Joy (talk) 07:37, 8 November 2025 (UTC) [reply ]

It's worse than that. Kartographer doesn't use Wikidata to lookup OSM objects. It searches OSM for an object that is labeled with the Wikidata qid. In the case of Brtonigla, that's Q991426, which is connected to Geographic data related to 87267602 at OpenStreetMap, which is a point in the middle of the town. That's why you get zoom=19 when you ask for a shape -- it's just a point.

This is a big problem which we cannot fix as Wikipedia editors -- this is all in the Kartographer extension, out of our control. Starting a more general discussion about this, below. — hike395 (talk) 08:50, 8 November 2025 (UTC) [reply ]

Okay, but in this case we can definitely make the correction in the map data. Our articles, bound to the Wikidata QID, describe both the village and its surrounding municipality, so do we have to move the QID from the node 87267602 to surrounding relation 6466287. --Joy (talk) 13:14, 8 November 2025 (UTC) [reply ]

Mind, I do understand that this order of lookups in Kartographer is faulty from our perspective. It parses OSM's Wikidata references and treats them as primary the source of truth, instead of the other way around. It should definitely be fixed to parse those Wikidata references, and then recurse into them to actually determine whether they're in sync. And then when they're not, it should use Wikidata to pick the primary one. --Joy (talk) 13:24, 8 November 2025 (UTC) [reply ]

BTW, on this note, I went looking if there's other tooling that we could use to work around this deficiency in Kartographer.

I found d:OpenStreetMap#Mix'n'match catalogs, but the reports there aren't up to date.

There's a question from @Robby at d:User talk:Reinheitsgebot#Mix'n'match report pages not updated since 4th quarter 2022 but there's no answer. @Magnus Manske, can this be fixed? --Joy (talk) 15:36, 8 November 2025 (UTC) [reply ]

All of the shape/line problems editors are finding recently in mapframe (e.g., #Brisbane, #an automatic zoom failure, Template talk:Infobox road#mapframe implementation, Template talk:Infobox UK place#Mapframe, WP:VPT#Map problem at the bottom of University of Georgia Infobox, WP:VPT#Road maps seem broken) is due to the fragility of Kartographer. The extension relies on OpenStreetMap to render shapes/lines correctly. AFAICT, there is no code we can write on the Wikipedia side that can check to make sure the shape/line data is sane. Having shapes or lines on (without points) in an infobox leads to null island problems (maps being rendered at 0N 0E) or to insane zooms. Conversely, when we render a point, we can force the map to be centered on a point that is specified by an editor at either en-WP or Wikidata. The zoom for a point can also be set by WP editors.

I don't think the using default OSM shapes/lines without somehow setting center and zoom in an infobox is tenable. There are a number of ways to proceed: I'm hoping we can discuss and come to a consensus.

1. Use OSM shape/lines by default in an infobox: when we find a problem, fix it at OpenStreetMap.
2. Always render mapframe using the center and zoom specified at en-WP: if the shape or line is outside of the map, just render a map with no marker, shape, or line.
3. Allow editors to opt-out of rendering the shape/line at an article if there is a problem. An parameter to an infobox can either turn off shape/line, or turn off the mapframe entirely.
4. By default, use center/zoom from en-WP. Editors can opt-in for shape/line rendering on an article-by-article, which makes sure that it is sane.

There may be other solutions, also. What do editors think?

Pinging @Joy, Zackmann08, Jonesey95, Redrose64, The Equalizer. Will also notify VPT and WikiProjects. — hike395 (talk) 09:45, 8 November 2025 (UTC) Also @Hooman Mallahzadeh: — hike395 (talk) 09:46, 8 November 2025 (UTC) [reply ]

The capability of overriding "OSM shape" by "a collection of coordinates existing on Wikidata item" may be a good solution. That is, the shape is rendered locally from Wikipedia, even though the map is from OSM. This way, wrong OSM shape can be corrected easily on Wikipedia. The zoom and center problems can be computed easily by a few codes locally on Wikipedia. Hooman Mallahzadeh (talk) 10:09, 8 November 2025 (UTC) [reply ]

this duplicates a huge amount of effort across communities. Ppl say "a lot" but relatively, this happens not so often and it has probably caused more"bad data" to be found and corrected, than it has created. Just fix the problems and stop thinking en.wp can do everything better than anyone else.. —TheDJ (talk • contribs) 10:54, 8 November 2025 (UTC) [reply ]

To avoid

duplicates a huge amount of effort across communities.

We can apply temporary Wikidata rendering that overrides OSM for fast solution of Wikipedia, then a robot moves these coordinates from Wikidata to OSM and clears that from Wikidata after 1 day. Finally we have only OSM coordinates. Please note that OSM renders these coordinates by "Wikidata id". This is only a proposal. Hooman Mallahzadeh (talk) 12:06, 8 November 2025 (UTC) [reply ]

To avoid

it has probably caused more"bad data" to be found and corrected,

maybe this robot needs some human supervision and acceptance before this final move. A Human supervisor makes the final decision to whether 1- create a new shape by Wikidata id or 2- change the existing shape by the same Wikidata id. Hooman Mallahzadeh (talk) 12:20, 8 November 2025 (UTC) [reply ]

This is a scenario of synchronization between Wikipedia with OpenStreetMap. Hooman Mallahzadeh (talk) 12:39, 8 November 2025 (UTC) [reply ]

Synchronizing across OSM and Wikidata seems to already be a fragile process, because of licensing and lack of OSM key stability (see d:Wikidata:OpenStreetMap). That seems like an extraordinarily difficult problem: perhaps someone else is willing to try. — hike395 (talk) 14:43, 8 November 2025 (UTC) [reply ]

Overriding OSM data has already been implemented on Wikimedia Commons. For example see Interstate 19 which uses this map. Therefore this inconsistency between OSM and Wikipedia nowadays exist typically.

I propose to use the same scenario for "wrong OSM shapes", without any synchronization. Hooman Mallahzadeh (talk) 08:37, 9 November 2025 (UTC) [reply ]

I'm not sure this is all the same bug. With Brisbane, we didn't get 0/0 after we turned on the shape, we got it after we disabled point rendering and there was no shape.

Our modules do currently check for the availability of shape data, so we could conceivably make some regression checks in our code.

For example, if the caller request explicitly or implicitly requires a shape, but there is no shape and no point, we can detect that and error out nicely instead of passing bad input to Kartographer and not detecting a 0/0. --Joy (talk) 13:09, 8 November 2025 (UTC) [reply ]

This is the same bug --- if an infobox has coordinates, and a point is rendered, it passes the coordinates to Kartographer (line 431 of Module:Infobox mapframe). If you turn off the point, there is no communication of the coordinates.

Let me re-iterate. There is no way to check for a shape in OSM from a Template or Module. That requires calling the Overpass API at OSM. I believe Kartographer can do that because it is a MediaWiki extension. This is the problem.

I'm happy to attempt a bug fix on the WP side, but I'm not a Wiki developer, so I can't fix Kartographer. If someone else wants to try, they are certainly welcome. — hike395 (talk) 14:19, 8 November 2025 (UTC) [reply ]

Oh, I see the reason for the confusion now. I'm saying Brisbane Wikidata entry d:Q34932 had no d:Property:P402 at all. That's the part that we can check. --Joy (talk) 14:27, 8 November 2025 (UTC) [reply ]

We already check for P402 (it's stored as hasOsmRelationId in the Module code at line 241, and is "or"ed with P3896 at line 243, then checked at line 358). P402 is the result of a different manual process that attempts to reconcile Wikidata with OSM. But Kartographer doesn't use P402, so this is an unreliable method for telling whether there is a shape/line that can be sanely rendered. — hike395 (talk) 14:39, 8 November 2025 (UTC) [reply ]

If there is any way to check for 0' 0' being returned as the coordinates for the map, we should check for that and display an error message and a tracking category. I have no idea if that is possible. – Jonesey95 (talk) 14:43, 8 November 2025 (UTC) [reply ]

Sorry to be a naysayer, but as far as I can tell, the coordinates of the final rendered map is only known to Kartographer. Module:Infobox mapframe simply invokes Kartographer with some inputs and does not have access to Kartographer internals. — hike395 (talk) 14:45, 8 November 2025 (UTC) [reply ]

I think I now understand what Joy is saying, which is actually going beyond what the code currently does. If the map is shape/line-only and there is no P402 (and no P3896 and no coordinates) then simply refuse to render the map. That seems reasonable: I can try to mock that up at the Module sandbox. — hike395 (talk) 14:56, 8 November 2025 (UTC) [reply ]

Yes! Thank you :) --Joy (talk) 15:12, 8 November 2025 (UTC) [reply ]

I propose an additional parameter named "isOSMVerified" at Wikidata which is used to verifiy the state of OSM map shape. This parameter has "null" value by default, but can be set to "true" or "false" by editors. Then, Wikipedia shows maps only when this parameter is set to "true". Hooman Mallahzadeh (talk) 15:18, 8 November 2025 (UTC) [reply ]

It's a valid idea, but I think that's equivalent to the logical OR of P402 and P3896. If you'd like, you can propose this over at Wikidata. — hike395 (talk) 15:49, 8 November 2025 (UTC) [reply ]

Additionally, I propose to fetch "zoom" and "shape" and "size" settings of mapframe from Wikidata. Which makes it universal between all editions of Wikipedia. Hooman Mallahzadeh (talk) 15:52, 8 November 2025 (UTC) [reply ]

Please go ahead and propose this at Wikidata. If it gains acceptance and usage, we can use those settings here. — hike395 (talk) 16:01, 8 November 2025 (UTC) [reply ]

Thank you :) Hooman Mallahzadeh (talk) 16:05, 8 November 2025 (UTC) [reply ]

I proposed that here. Thanks again. Hooman Mallahzadeh (talk) 16:16, 8 November 2025 (UTC) [reply ]

Idea: I think there's an even better thing to do, that is a combination of Joy's idea and my idea (2), above. Line 200 of the module checks for coordinates (both locally and at Wikidata) and returns no map if there are no coordinates. That means there are always coordinates available. In the sandbox, if there is only shape/line being displayed and there is no OSM linked at Wikidata, I forced the center to match those coordinates. You can see that fixes at least one null island problem in the test cases. What do editors think of this? Pinging @Joy, Zackmann08, Jonesey95 — hike395 (talk) 16:04, 8 November 2025 (UTC) [reply ]

Ahhh! Woke up to ALL the notifications. Gonna be honest, this is largely over my head... I'll try to catch up on the discussion that happened overnight my time, but mostly just glad editors smarter than me are working on a solution! Zackmann (^{Talk to me} /_{What I been doing} ) 16:21, 8 November 2025 (UTC) [reply ]

I read [3] and it makes sense.

I do wonder if we should be using some form of logging more here, because even as we go through all sorts of these edge cases, we're still sort of flying blind. --Joy (talk) 16:44, 8 November 2025 (UTC) [reply ]

I can certainly add tracking to the "forced centering" and the "no coordinates" case. — hike395 (talk) 16:48, 8 November 2025 (UTC) [reply ]

Implemented I think this proposed change will make things strictly better (i.e., fix a number of null island problems), so I went ahead and promoted it to main. It may not fix all of the problems, so let's keep an eye out for more issues, and we can continue the discussion if necessary. — hike395 (talk) 19:52, 8 November 2025 (UTC) [reply ]

@Hike395 Hi, OpenStreetMap zoom level (P6592) is for OSM zoom. So if you think it is good, would you please implement zoom level like this:

if user-mapframe-zoom

elseif Wikidata-zoom

else default value.

This makes zoom settings universal and needs fewer lines for zoom setting at Wikipedia.

I requested an entry for "shape-validity" entry at Wikidata.

Thanks, Hooman Mallahzadeh (talk) 04:22, 9 November 2025 (UTC) [reply ]

The same scenario for fetching "mapframe-marker" parameter form Wikidata.

I had a look at Category:Pages using infobox mapframe with forced centering and the first one was already interesting - it's just a call to the template with point=none, but one which renders a shape. Presumably the issue here is that we don't have a relation ID at d:Q6474697 to properly reference that shape, and depend on Kartographer's inverse logic to find it? --Joy (talk) 07:05, 9 November 2025 (UTC) [reply ]

@Joy In my opinion, there is no need for using Wikidata to solve the problem. We should just use «intermediate maps» from Wikimedia Commons, such maps contain all needed settings also. I mean if OSM has wrong data, then easily and rapidly create a correct map at WikiCommons and use that. Just the same as Interstate 19 article which uses this map from WikiCommons. I should note that such maps contain all required data e.g. zoom, marker, etc. Hooman Mallahzadeh (talk) 08:44, 9 November 2025 (UTC) [reply ]

This solution has the benefit of "local data" for Wikipedia and needs no 1 day delay. So Wikipedia should encourage using local "WikiCommon maps" over outside OSM maps. Hooman Mallahzadeh (talk) 09:16, 9 November 2025 (UTC) [reply ]

That has the obvious downside of forking the data and then having to maintain that. It doesn't sound like a problem for a few cases, esp. of shapes that rarely change, but it doesn't really scale because there are shapes that do change.

Even if we reduce the issue to just one-off copy&pastes and quick fixes, it still means an editor effectively taking responsibility for a snapshot of the data generated by others. It's like PNG or SVG maps all over again. --Joy (talk) 09:40, 9 November 2025 (UTC) [reply ]

I also propose to fetch maps of all existing articles from "OSM" to "local Wikimedia commons maps". I mean all Wikipedia articles (e.g., cities, roads, shops, etc.) should have a corresponding "Wikicommons map item" in WikimediaCommons that are initially fetched from OSM, but users can manipulate them easily.

This way, a "WikiCommons map item" would automatically be created for all roads (e.g. A308 road) that is a point initially, but editors would find that item easily and make a complete road.

This reduces the inconsistencies Wikipedia and OSM.

Finally, I think updating OSM is not the duty of Wikipedia, if there is a problem at OSM, then just don't care about that. Hooman Mallahzadeh (talk) 09:51, 9 November 2025 (UTC) [reply ]

About

there are shapes that do change.

We can use fetching tool from "OSM map" to "WikiCommons map" that do this automatically, for this type of maps. Hooman Mallahzadeh (talk) 09:57, 9 November 2025 (UTC) [reply ]

Forking everything should have the result of [reducing] the inconsistencies [between] Wikipedia and OSM? I'm afraid that sounds plainly contradictory to me. --Joy (talk) 13:38, 9 November 2025 (UTC) [reply ]

Every solution might have advantages and disadvantages, we should make a trade-off between them. If changing something online is hard, then we can take a local snapshot, correct that and then render the corrected local snapshot.

Local maps of roads, rivers, buildings and cities and so on (like this map) have the advantage of fast and convenient update and drawback of inconsistency. This tradeoff should be done. Hooman Mallahzadeh (talk) 15:25, 9 November 2025 (UTC) [reply ]

@Joy: I think another problem with existing OSM scenario is that they are vulnerable against vandalism. If someone intentionally or unintentionally updates OSM of an article at site https://www.OpenStreetMap.org in a wrong way, Wikipedia would need at least 1 day to correct it. This issue can be solved by local maps. Hooman Mallahzadeh (talk) 08:06, 12 November 2025 (UTC) [reply ]

First of all, the sync isn't at least 1 day away, it varies. But more generally, being susceptible to vandalism is the case with Wikipedia as well. Please see Vandalism on Wikipedia etc. --Joy (talk) 08:36, 12 November 2025 (UTC) [reply ]

I just converted {{infobox road junction }} to invoking the module, but for some reason |mapframe-shape=yes isn't getting the shapes shown. Am I missing something? --Joy (talk) 21:03, 8 November 2025 (UTC) [reply ]

Is there an example where the shapes previously worked? Everything seems fine to me. — hike395 (talk) 21:32, 8 November 2025 (UTC) [reply ]

Piccadilly Circus used to show a shape. I think Jane Byrne Interchange did too. --Joy (talk) 21:46, 8 November 2025 (UTC) [reply ]

Are you sure? I used Piccadilly Circus as a test case and reverted your changes, and there was no shape there. — hike395 (talk) 23:20, 8 November 2025 (UTC) [reply ]

I've tried going back to the old {{Infobox road junction }} code as of May 2024, adding |coord= and |wikidata= to that old code, and reverting Module:Infobox mapframe back to that date. Nothing I've done can make a shape show up for either Piccadilly Circus or Jane Byrne Interchange. — hike395 (talk) 23:40, 8 November 2025 (UTC) [reply ]

The reason I know I saw it at Piccadilly is because it was the first item in Special:WhatLinksHere/Template:Infobox road junction and the one I checked first prior to making changes, to have a baseline.

I went looking for the shape on OSM, but I can't find one now, either, which is confusing.

On the other hand, I did find https://www.openstreetmap.org/relation/13411997 for the Jane Byrne Interchange. --Joy (talk) 06:53, 9 November 2025 (UTC) [reply ]

There is a bug in the parameter logic that I'm working on fixing. — hike395 (talk) 10:58, 9 November 2025 (UTC) [reply ]

Template:Infobox mapframe/testcases#frame-lat/frame-long vs frame-coordinates is showing the deprecated parameters functional, but the new one with an error. What's wrong there? --Joy (talk) 21:48, 8 November 2025 (UTC) [reply ]

The test case was broken: the latitude and longitude were in the wrong order, so the latitude was out of range. Fixed the test case. — hike395 (talk) 23:23, 8 November 2025 (UTC) [reply ]

Ohh, nice, so some parser that came before <mapframe>: Either both "latitude" and "longitude" parameters should be supplied or neither of them just removed the invalid latitude? Can we make that one error out instead of just pruning the bad data? --Joy (talk) 06:39, 9 November 2025 (UTC) [reply ]

Statue of Edward Colston shows that a bunch of strip markers give errors in Module:Mapframe in {{Infobox artwork }}. Is that a problem in the wikitext of the article? Johnuniq (talk) 01:58, 9 November 2025 (UTC) [reply ]

Fixed -- someone misused |coord= to hold an embedded infobox. Fixed to use |module= instead. — hike395 (talk) 02:49, 9 November 2025 (UTC) [reply ]

@Joy and Zackmann08: There was previously a bug in the argument handling that may have confused you both. The code is now fixed.

In the previous code, when you asked for |shape=on, it would sometimes shut off the shape! It would check for OSM data over at Wikidata and turn off the shape if it wasn't there. That's clearly not correct.

The current state of the default code (without asking for anything via |wikidata=, |shape=, |line=, |point= or |marker=) is the following:

• If there is a local coordinate given or if there is no OSM data in Wikidata, display a point marker
• If there is no local coordinate given or if there is OSM data in Wikidata, display shape/line

This is the simplest default that was still close to Evad37's original behavior. When you say |wikidata=yes or |shape=yes or |line=yes, the corresponding shapes will always be displayed, regardless of local coordinates or OSM data.

Notice that means that sometimes it will display both a marker and shape/lines on the same map, by default. This is a new behavior. This new behavior should mean you generally won't need to set |wikidata=, |shape=, or |line= in an infobox. If there is shape/line data available, it should generally be displayed. The only reason you would set, e.g., |wikidata=yes is if you want to display the shape/lines even if the OSM data in Wikidata is missing. Hopefully this is a rare case.

Hope this helps makes the module more comprehensible. — hike395 (talk) 11:53, 10 November 2025 (UTC) [reply ]

Good to hear!

That last sentence was a bit confusing, though. So the meaning of wikidata=yes is more akin to wikidata=ignore && kartographer-osm-lookup=yes? :) --Joy (talk) 12:23, 10 November 2025 (UTC) [reply ]

There is no direct OSM lookup, as far as I know. Here is what I mean:

• If you don't set |wikidata=, only shapes/lines that have OSM relation ID in Wikidata are shown
• If you set |wikidata=, all shapes/lines are shown, regardless of OSM relation ID (I guess "wikidata" is now a misnomer -- it means "both shapes and lines"). — hike395 (talk) 12:38, 10 November 2025 (UTC) [reply ]

Yeah, I mean the implicit letting of Kartographer to look up and draw whatever it found in OSM regardless of WD P402 value. Right?

In any case, we should definitely rename the parameter, because this is too convoluted for its own good. The parameter name needs to communicate the intent :) --Joy (talk) 13:06, 10 November 2025 (UTC) [reply ]

@Hike395: that is AWESOME news! Thanks for all your hard work on this! -Zackmann (^{Talk to me} /_{What I been doing} ) 16:34, 10 November 2025 (UTC) [reply ]

Yes, when |wikidata=yes, Kartographer will look up and draw whatever it finds in OSM regardless of WD P402 value. Perhaps can rename it |geometry= ? that implies a superset of shapes and lines. — hike395 (talk) 16:39, 10 November 2025 (UTC) [reply ]

@Hike395: still confused about something... If you go to Sovetsk, Kirov Oblast and change it to use {{Infobox Russian inhabited locality/sandbox }} the shape still disappears unless you add |mapframe-wikidata=yes. The difference between the sandbox and live version is the use of the module that comes with {{infobox settlement }} versus using {{Infobox mapframe }}. I'm probably missing something but I thought this was what you were saying was now fixed? Help me understand... - Zackmann (^{Talk to me} /_{What I been doing} ) 19:42, 10 November 2025 (UTC) [reply ]

@Zackmann08: This is working as intended, as far as I can tell:

• The infobox has |coordinates= set.
• The wikidata entry for Sovetsk (d:Q196369) does not have an OSM Relation ID set.

Therefore, the logic (described above) uses a point marker and not a shape, which is what you are seeing. If you use call to infobox mapframe with no parameters ({{Infobox mapframe}}), then you are only getting the qid. In that case,

• No |coordinates= are set.
• Still no OSM Relation ID set.
• Coordinates are available at Wikidata.

And therefore you would get both a point (because no OSM Relation ID) and a shape (because no local coordinates) and you get

Map

Local coordinates turn off shapes without OSM Relation IDs, Wikidata coordinates do not. This has been true at least since 2020. — hike395 (talk) 00:54, 11 November 2025 (UTC) [reply ]

@Hike395: Gotcha. Thank you! This is just me still not fully understanding the intricacies of this module. Zackmann (^{Talk to me} /_{What I been doing} ) 00:59, 11 November 2025 (UTC) [reply ]

Well, I don't fully understand the logic behind the original design. I was just reluctant to make major changes because it's used on so many pages. What the most recent edit did was not turn off shapes given local coordinates when there is an OSM Relation ID. It used to be that local coordinates turned off all shapes by default.

One possible different default behavior for the template is to always display a marker and always let Kartographer display shape/lines. That would be easier to use, and you could turn off markers/lines/shapes if you don't want them. We could do this: it's possible that Evad37 was being too conservative, and it's ok to always turn on shapes/lines because Kartographer will do the right thing. It's also possible that we don't understand the pitfalls and turning |wikidata=yes still generates lots of errors. I'm just not sure. — hike395 (talk) 01:32, 11 November 2025 (UTC) [reply ]

I think the code today is at least consistent/rational:

• If there is no OSM Relation ID, then there may be no shape to show, so we better turn on a marker to be sure something is in the map.
• If there is a local coordinate, then an editor may be expecting to see a marker at that location.
• If there is an OSM Relation ID, then might as well show the shape because we know it's there and is hopefully not insane.
• If there is no local coordinate, assuming we don't want to show a marker, then we should show the shape to show something.

It's all contingent on the assumption that if there's no local coordinate then we shouldn't show a marker. If we want to always show a marker, then we can always show the shape/line, too. But that's very different from what the code does today. — hike395 (talk) 03:18, 11 November 2025 (UTC) [reply ]

Yeah I think local data was supposed to always override foreign data per those RFCs from 2018 and 2020. But I doubt anybody ever wanted point data completely overriding shape data.

If we have local shape data, that should still override foreign shape data. But that's a scenario that seems to rarely ever happen, probably because it's so much more unwieldy compared to just using OSM shapes. --Joy (talk) 10:00, 11 November 2025 (UTC) [reply ]

I would say a qualifier is needed, because just "geometry" does not illustrate the mechanism at all, and that's a significant distinction.

Maybe something like |geometry-greedy= or |osm-greedy= would be more appropriate, to communicate the intent of greedily accessing more data from OSM than there is in Wikidata references. --Joy (talk) 09:54, 11 November 2025 (UTC) [reply ]

I'm not sure people will understand "greedy". How about |all-geometry= or |all_geometry=? — hike395 (talk) 13:52, 11 November 2025 (UTC) [reply ]

I don't think they will understand the implications of "all", either. We need to communicate that there's an aspect of uncertainty and risk to it, because a lot of people won't check the docs and just say "all? sure!". --Joy (talk) 15:08, 11 November 2025 (UTC) [reply ]

Whether to change the default behavior hinges on the following expectation. The canonical example for this template is

{{Infobox mapframe|id=Q100}}

What do people expect to see when they do this? The map on the left or the map on the right?

The map on the left has been the behavior for the last 7 years. It might be a surprising change to start to display the map on the right. — hike395 (talk) 13:52, 11 November 2025 (UTC) [reply ]

If it's a surprise, it's a good surprise: you do want to know where exactly downtown Boston is (meet you in Boston doesn't mean some ocean island that belongs to the City of Boston). It also correlates the position on the pushpin map with the position on this map. People put a lot of work into finding these coordinates, and they probably mean more that these artificial (official) boundaries. Now, when it comes to style and colors, I'd like to have that red outline thinner and/or somewhat translucent, and the marker color should be in the reds, if possible. These violet-blue and red colors do not go well together, imo. Ponor (talk) 14:23, 11 November 2025 (UTC) [reply ]

The trouble is that there are often smaller places where it's not clear that the point is supposed to mean something. Sometimes also it just plain doesn't - it's a point that vaguely matches the location on a higher-level pushpin map that nobody ever checked against a zoomed in map.

I agree that the line and marker color combination doesn't really make a lot of sense, but again, mostly because it's not inherently clear why they're different.

Making the default marker red would probably be the safe choice. OSM also uses the same reddish color for a small circle attached to a larger shape, I think. --Joy (talk) 15:20, 11 November 2025 (UTC) [reply ]

Counterexample to the one above:

{{Infobox mapframe|id=Q14935287}}

Yes, Skye, Victoria is no Boston, but we have a great number of articles about minor places like this, so the page views add up. Maps without and with a marker:

Hike395 said, "The map on the left has been the behavior for the last 7 years. It might be a surprising change to start to display the map on the right." Quite so. The marker location is random and there is no logical place to put it, as Skye has no town. Unless someone is volunteering to sort through all the infobox maps and turn off point display on those where it's not required, I think the only realistic solution at this stage of the game is showing the marker as opt-in behaviour.

I'm in agreement with Ponor and Joy regarding the marker's look. The soft shadowy blue is very jarring when placed against the sharp-edged red border. At least make the marker colour similar to the polygon outline. In fact, I wonder if a simple disc- or dot-type marker would suffice, although the inverted-teardrop marker style is well recognised by readers thanks to its longstanding use by Google Maps. This, that and the other (talk) 11:40, 12 November 2025 (UTC) [reply ]

It should be noted that the automatic zoom into the shape is actually working against us in these sorts of cases. I see almost nothing on that map, and on my desktop I had to click once to get into the large view where some labels appeared, which was at least better. Still, after that I had to click the zoom out button no less than 3 times to see that this is south of Melbourne. If I use the scroll wheel on my mouse to zoom out, the center of the zoomout actually depends on the (fairly random) location of the mouse pointer, and it can easily take me 4 scrolls to get to the Melbourne label. This isn't great. --Joy (talk) 12:07, 12 November 2025 (UTC) [reply ]

The Kartographer zoom in this case matches the default zoom computation. Here's what the Skye infobox map would look like without the shape:

Map

— hike395 (talk) 13:31, 12 November 2025 (UTC) [reply ]

Sorry, I didn't say that right. I didn't mean automatic zoom into the P402 shape per se, just the automatic zoom into the entity (be it point or shape or whatever), into the closely identifiable context. It doesn't have anything to do with the original marker question, but in general it's related to what people see. --Joy (talk) 13:50, 12 November 2025 (UTC) [reply ]

Hi, I set zoom level by P6592 for Tehran article at Wikidata in this https://www.wikidata.org/wiki/Q3616 page but zoom doesn't change in the OSM of article. Please inspect. Thanks, Hooman Mallahzadeh (talk) 15:47, 11 November 2025 (UTC) [reply ]

For Tehran, this template displays a shape. The zoom is set by Kartographer to nicely frame the shape, which overrides the zoom set by Wikidata. If you wish to override the Kartographer zoom, please use |zoom= directly. — hike395 (talk) 02:33, 12 November 2025 (UTC) [reply ]

Also, please do something to change mapframe-marker by Wikidata item, the same as zoom level. Thanks, Hooman Mallahzadeh (talk) 16:06, 11 November 2025 (UTC) [reply ]

As far as I know, there is no Wikidata property for mapframe marker. — hike395 (talk) 02:33, 12 November 2025 (UTC) [reply ]

@Hike395 Hi and thank you for your response. In my opinion, the correct implementation is that User and Wikidata zoom should have privilege over Kartographer zoom and override that.

Also, I think we need some new Wikidata item for mapframe-marker which overrides default one but is overridden by user one. The same should happen for Wikidata-shape.

Implementing that should not be difficult. Thanks, Hooman Mallahzadeh (talk) 04:05, 12 November 2025 (UTC) [reply ]

I disagree about Wikidata taking precedence of Kartographer-- if Wikidata zoom overrides Kartographer zoom, you will potentially get odd zooming behaviors whose cause will be non-obvious to editors.

Re: new Wikidata item -- it's not a matter of implementation difficulty. You will need to get consensus at Wikidata for your new proposed properties. Once you've done that, it will be easy to implement. — hike395 (talk) 14:24, 12 November 2025 (UTC) [reply ]