🇮🇷 Iran Proxy | https://www.wikipedia.org/wiki/Template_talk:Infobox_settlement/testcases
Jump to content

Template talk:Infobox settlement

Page contents not supported in other languages.
Coordinates: 18°27′45″N 69°56′10″W / 18.46250°N 69.93611°W / 18.46250; -69.93611
From Wikipedia, the free encyclopedia

Why is pop density displaying?

[edit]

Working on a clean out of Category:Pages using infobox settlement with unknown parameters (0) and came upon Sterkenburg. I can’t figure out why the population density is not displaying. Can anyone help me out? What am I missing?

Sterkenburg
Area
 • Total
24 km2 (9.3 sq mi)
{{Infobox settlement
|name                   = Sterkenburg
…
|area_total_km2         = 24
|population             = 12580
|population_as_of       = 637
|population_density_km2 = auto
…
}}

—Zackmann (Talk to me/What I been doing) 21:46, 18 September 2025 (UTC)[reply]

@Zackmann08: it's |population_total= Ponor (talk) 22:11, 18 September 2025 (UTC)[reply]
Interesting. So it will display |population= but only do the calculation on |population_total=? Zackmann (Talk to me/What I been doing) 22:46, 18 September 2025 (UTC)[reply]
As far as I can tell:
IMO, adding it was a mistake, it was never integrated correctly, and it should probably be formally deprecated with a tracking category, converted to population_total or some other sensible parameter in each article, and then removed. – Jonesey95 (talk) 00:33, 19 September 2025 (UTC)[reply]
I think deprecating it and adding a tracking category sure sounds like the way to go! —Zackmann (Talk to me/What I been doing) 05:42, 19 September 2025 (UTC)[reply]
@Jonesey95: realize I never dealt with this. Still if the mindset to deprecate and convert to |population_total=? Zackmann (Talk to me/What I been doing) 03:35, 26 November 2025 (UTC)[reply]
Went ahead and created Category:Pages using infobox settlement with deprecated parameters (0) so we can at least get an idea of what we are looking at... --Zackmann (Talk to me/What I been doing) 06:47, 26 November 2025 (UTC)[reply]

Right now, the automatic computation of density only looks at |population_total=. If you want to allow other population parameters (like |population=), you could change the template at data92 (via putting {{if empty}} into |pop=, to make an ordered list). — hike395 (talk) 12:44, 27 November 2025 (UTC)[reply]

Sorry to throw in a curve ball: population density should be calculated using the land area figure, not the total area figure. Sometimes these are the same, particularly for dry inland areas. But for coastal areas or places with a lot of large inland lakes like Florida or Scotland, the total area figure and the land area figure will be very different.
The settlement infobox therefore has two relevant area fields: area_total_km2 and area_land_km2. The density figure should be calculated using the area_land_km2 figure, not total (unless the land field is empty which usually means that the land and total figures are the same). For a real life example, see Liverpool or England. Dgp4004 (talk) 12:53, 27 November 2025 (UTC)[reply]
 Fixed I noticed this a while ago, and implemented a fix as you suggest: use |area_land_km2= if available, otherwise fall back to |area_total_km2=. See data92 in the template code. — hike395 (talk) 14:05, 27 November 2025 (UTC)[reply]
Answering a question a few lines up: Yes, I still think deprecating |population= and replacing it as needed with |population_total= is the way to go. The latter is less ambiguous, and the former was never really supported. – Jonesey95 (talk) 16:53, 27 November 2025 (UTC)[reply]
Sounds good all around. Thanks folks! Also, for those who are American, Happy Turkey Day!! Zackmann (Talk to me/What I been doing) 16:56, 27 November 2025 (UTC)[reply]
 Doing... Will take a few weeks because of caching, but working on cleaning out Category:Pages using infobox settlement with deprecated parameters (0) as soon as they come up. Zackmann (Talk to me/What I been doing) 06:08, 28 November 2025 (UTC)[reply]
 Done |population= has been removed from the template. I regularly monitor the unknown params category so if any more pop up I'll fix em. --Zackmann (Talk to me/What I been doing) 22:25, 1 December 2025 (UTC)[reply]

Question about multiple images

[edit]

Hello! I have a question about the template, I hope this is the right place to ask, it’s about this segment specifically:

“For large urban areas, the template is often used in place of a single image to create a collage of the settlement's skyline and several notable landmarks.”

I was wondering if there was any guidelines about when multiple images vs. a single image can/should be used. For example I currently have an article: Capreol where I have added multiple images, but it is not a large urban area. Platttenbau (talk) 12:24, 22 September 2025 (UTC)[reply]

False positives in Category:Pages using infobox settlement with no map

[edit]

Pachi, Kerman shows a mapframe map because it has Wikidata coordinates, but it is a member of Category:Pages using infobox settlement with no map and Category:Pages using infobox settlement with no coordinates. Some ambitious person could probably update the template's code to limit the population of those categories to articles that are truly missing click-through maps that use available coordinates. It might get a little tricky: check for edge cases like Pacajá, which has Wikidata coordinates and a picture of a map (via |image_map=), but no way to get to a mapping web site because image_map may be suppressing the mapframe map (I am currently lazy and haven't checked the code to see what the logic is). – Jonesey95 (talk) 12:52, 25 September 2025 (UTC)[reply]

We could just rename those maintenance categories to "... with no specified (map|coordinates)" or "... with no explicit (map|coordinates)", too. --Joy (talk) 14:15, 25 September 2025 (UTC)[reply]
That would not address the actual issue. The difference between an article that shows a mapframe map just fine and an article that legitimately has no available coordinates and therefore can't show any map is a significant one. The categories are out of date, possibly because the template was updated since they were created (I haven't checked). – Jonesey95 (talk) 17:58, 25 September 2025 (UTC)[reply]
Well, that depends on your point of view. An article that shows unverified wikidata coordinates, maybe also on a bland base map without proper context, could well be worthy of cleanup, maybe even more so than one that doesn't show any map. Maybe the real question is do we actually expect anyone to ever parse these categories with tens of thousands of entries and start cleaning them up based on that. --Joy (talk) 21:10, 25 September 2025 (UTC)[reply]
This seems difficult to get high precision. I would suggest just dropping these tracking categories. — hike395 (talk) 00:39, 26 September 2025 (UTC)[reply]
Another idea might be to automatically subdivide them by the value of |subdivision_name=, which will split it up by about 200 and make it possible to e.g. ask members of WikiProject $Country go into their respective categories and see what they can do about it. --Joy (talk) 08:25, 26 September 2025 (UTC)[reply]

Rfc: Deprecation of the state and county name in U.S. settlement articles

[edit]

The use of state and county names inside the |name= parameter to be deprecated.--2600:1700:6180:6290:E53B:9874:8B16:1C3D (talk) 16:25, 13 October 2025 (UTC)[reply]

The addition of the state and county name in U.S. settlement articles field is a tendency for settlement articles across the United States. The case to be made to deprecate such usage should be considered within WP:INFOBOXGEO:

Infoboxes for geographical items (e.g. cities and countries) should generally be headed with the article title, although the formal version of a name (e.g., Republic of Montenegro at Montenegro) can be substituted. Where the article title is disambiguated, the plain name can head the infobox, as long as the topic is clear (e.g., São Paulo at São Paulo (state)). Alternative or native names can appear beneath this if beneficial. Extensive historic names are often better in a second infobox, as at Augsburg.

There is a good case to deprecate the use of state and county name in U.S. settlement articles per WP:INFOBOXGEO. --2600:1700:6180:6290:E53B:9874:8B16:1C3D (talk) 16:25, 13 October 2025 (UTC)[reply]

Some examples: Bloomington, California; Midway, Calloway County, Kentucky; Spring Valley, San Diego County, California; Lincoln, Illinois; Champaign, Illinois; Victoria, Texas; and Normal, Illinois. --2600:1700:6180:6290:E53B:9874:8B16:1C3D (talk) 16:25, 13 October 2025 (UTC)[reply]

Wut? The first part of the first sentence of WP:INFOBOXGEO says "Infoboxes for geographical items (e.g. cities and countries) should generally be headed with the article title", which would mean the article Bloomington, California should have the text Bloomington, California above the infobox. • Sbmeirow • Talk • 05:42, 14 October 2025 (UTC)[reply]
I agree that the proposer appears to be misreading, or failing to read, WP:INFOBOXGEO. Putting the article title at the top of the infobox appears to be the MOS guideline. – Jonesey95 (talk) 14:08, 14 October 2025 (UTC)[reply]
Perhaps you are failing to read the second sentence of that guideline: "Where the article title is disambiguated, the plain name can head the infobox ..." Deor (talk) 15:18, 14 October 2025 (UTC)[reply]

NOTE: A random IP editor proposing changes with this much information smells extremely fishy to me!! Notice how O.P. only made edits on only one day. I'm almost 100% sure this is the same person that is jumping between numerous IP addresses in 2025 from the Augusta, Georgia region. I wouldn't doubt this person had a banned account and/or was a sock puppet too. • Sbmeirow • Talk • 06:00, 14 October 2025 (UTC)[reply]

Wikipedia:Casting aspersions — HTGS (talk) 20:19, 25 October 2025 (UTC)[reply]

Survey

[edit]
I would also agree… since the standard is to include state names in the article title, there is no need to also include them in the infobox header. Blueboar (talk) 17:26, 13 October 2025 (UTC)[reply]
There's no reason just "Caernarvon Township" shouldn't be the header in both infoboxes: "Where the article title is disambiguated, the plain name can head the infobox, as long as the topic is clear." Deor (talk) 15:18, 14 October 2025 (UTC)[reply]
Nothing is clear about two townships in Pennsylvania with the same name. The dab is needed there to avoid confusion. – Jonesey95 (talk) 17:46, 15 October 2025 (UTC)[reply]
Needed in the article's title, certainly. But not in the infobox header. Deor (talk) 21:58, 15 October 2025 (UTC)[reply]
but then why have a settlement_type parameter in the infobox at all? An infobox is a panel that summarizes key facts about the page's subject. – The Grid (talk) 01:08, 17 October 2025 (UTC)[reply]
I don't see what |settlement_type= has to do with the subject of this RfC. In Ada, Nolan County, Texas, for example, the infobox header is just "Ada" and the settlement type is "Ghost town". How would having the header be "Ada, Nolan County, Texas" improve matters, and how does the "Ghost town" designation affect the question? Could you explain? Deor (talk) 14:24, 17 October 2025 (UTC)[reply]
It's because Ada, Lampasas County, Texas exists too. Typically, when you see the county in the title of a community article, it means there is another community with the same name in the same state. There far more conflicts with unincorporated communites and ghost towns. Other than states, the railroads and post offices often helped resolved community naming conflicts by saying they wouldn't put a depot or post office in a community unless you changed their name (or railroads would pick another name for the depot), because they didn't want to deal with confusion problems associated with 2 or more communities with the same name in the same state. • Sbmeirow • Talk • 01:22, 18 October 2025 (UTC)[reply]
I understand all that, but I still don't see what it has to do with infobox headers. Deor (talk) 01:49, 18 October 2025 (UTC)[reply]
  • The current guideline suggests disambiguation is not needed in the infobox, and given the infobox includes other administrative divisions it certainly reads strange. However, is a formal rule needed? Are there previous discussions about this? CMD (talk) 16:51, 14 October 2025 (UTC)[reply]
This is basically beating a dead horse, because there has been discussions in the past about the name above the infobox. Search the archives in: this talk section, in talk section at Wikipedia:USCITY, and maybe need to search in talk section in one of the articles meant for article tiles in general. • Sbmeirow • Talk • 01:41, 18 October 2025 (UTC)[reply]
Can you cite these discussions? Deor (talk) 01:49, 18 October 2025 (UTC)[reply]
I really don't feel like wasting my time on an "Rfc" that was likely requested by an IP sock puppet. • Sbmeirow • Talk • 02:02, 18 October 2025 (UTC)[reply]
Obviously, when two or more places have the same name, we need to disambiguate the article title - and adding the state (and even the county) name is the most appropriate way to do this. The question is: do we ALSO need to include that disambiguation in the header of the infobox?
For the moment, forget what “the rules” currently say (we can always change the rules if there is consensus to do so). Go back to first principles: those who want the disambiguation repeated in the infobox need to explain WHY it needs repetition. And those who disagree need to explain WHY NOT. Blueboar (talk) 12:54, 27 October 2025 (UTC)[reply]
Thinking about it this way, I start to wonder why infoboxes have titles at all. — HTGS (talk) 18:03, 27 October 2025 (UTC)[reply]
That's actually a much better question. Let's stop worrying about how it should be formatted and just get rid of it. Nikkimaria (talk) 03:40, 28 October 2025 (UTC)[reply]
Since all infoboxes are supposed to have "a large, bold title line", I don't think we could dispense with one in this infobox. Deor (talk) 13:20, 28 October 2025 (UTC)[reply]
That ignores Blueboar’s point: stop appealing to the rules.
I’m truly not sure if Nikkimaria is joking or not. While my question was genuine, I’m still quite far from considering abolishing titles from infoboxes all together. — HTGS (talk) 23:17, 28 October 2025 (UTC)[reply]

Max size

[edit]

I was going to modify the call to Module:InfoboxImage to set image_skyline's |maxsize=300px. Just came across a page where a user had set the image size to 450px. Terrible user experience and no reason to have an image that large. Any objections? Zackmann (Talk to me/What I been doing) 22:09, 15 October 2025 (UTC)[reply]

Can you link that article so we can all see? --Joy (talk) 07:23, 16 October 2025 (UTC)[reply]
@Joy: ahh sorry I should have made note of the article. Sadly it was a few thousand edits ago at this point. Obviously any article that has a single image (not {{Multiple images}}) for |image_skyline= will work for a test case. I just reproduced on Rosslyn, Virginia for example (didn't save the edit for obvious reasons but if you just add |image_size=450px you'll see essentially what I saw). Happy to throw up an example on the testcases if that would be helpful? To be clear I don't think is happening often, most editors know better than to set an infobox image to anything much larger than 300px... But since Module:InfoboxImage does have that maxsize parameter, I figure we might as well make use of it. Zackmann (Talk to me/What I been doing) 07:34, 16 October 2025 (UTC)[reply]
I added |maxsize=300px to the sandbox and added a testcase with a |image_size=450px just to show what the difference would be. Worth noting that the same issue exists with the other images parameters... Flag, seal, shield, emblem, map and pushpin_map all have the ability to set whatever size you want to... Ideally those should have a reasonable |maxsize= as well. Zackmann (Talk to me/What I been doing) 07:44, 16 October 2025 (UTC)[reply]
I think it would be good if you copy&paste the rest of the LA infobox content in that test case, so it becomes more obvious what this width does to the rest of it, how much empty space appears. --Joy (talk) 08:36, 16 October 2025 (UTC)[reply]
Good point! I was focused on just the impact of the image. I'll do that now. --Zackmann (Talk to me/What I been doing) 08:38, 16 October 2025 (UTC)[reply]
That's interesting, I actually expected it to be far more horrible.
On desktop, there's a lot of whitespace, though it's only slightly wider than the label "Highest elevation (Mount Lukens)". So I'd say skyline width 450px is too much, but I wouldn't necessarily ban skyline width 400px because it's plausible someone could make that work.
Whereas, on mobile, it seems to be clamped down already by something else, so there's no difference anyway.
For flag_size, 400px seems bad, except if I think of a use case where there is no seal - in which case it's fine to let it go up to 300 or even 400. And it's weird that the 110px flag has unreadable text on it, but the 400px one allows me to read "City of Los Angeles" and "Founded 1781". Can we somehow clamp down the combination of flag_size and seal_size to 400px? --Joy (talk) 12:05, 16 October 2025 (UTC)[reply]

Could we be a bit more conservative and set |max_size=320 for the main image? — hike395 (talk) 12:47, 16 October 2025 (UTC)[reply]

I set it to add up to 350px in the sandbox, see how you like it now: Template:Infobox settlement/testcases#Case 19: Very large image. --Joy (talk) 13:16, 16 October 2025 (UTC)[reply]
Full disclosure I'm editing on an iPad in desktop mode these days, so I'm on a VERY small screen. My experience may not be reflective of the most common use case.... That being said it sounds like there is general consensus thus far that some form of a maxsize is good (does anybody want a 900px image???) ... More of a question of what that should be. Zackmann (Talk to me/What I been doing) 18:50, 16 October 2025 (UTC)[reply]
Why are we not implementing what the MOS recommends MOS:IMAGESIZE Lead images should usually use upright 1.2 at most.....and what our policy recommends WP:IMGSIZELEAD The lead image in an infobox should not impinge on the default size.of the infobox. Therefore, it should be no wider than upright 0.9 (equivalent to 228px). Moxy🍁 19:07, 16 October 2025 (UTC)[reply]
@Moxy: So a couple of things. I'm wary of making a change that FORCES people to use an image that is too small. I think we can all agree you never want an infobox image that is 500px... But is there a case where a 300px image is warranted? Maybe there is (I can't actually think of one though). That being said, if the MOS says it should never be wider than 228px... I don't have an objection to making that the maxsize. I just worry that there might be pushback from those who prefer a slightly larger image. Zackmann (Talk to me/What I been doing) 19:18, 16 October 2025 (UTC)[reply]
In my view if there is to be an exception to our community consensus - that is what deserves a discussion. Implementing the community consensus should take place over concerns of pushback..... if push back occurs we can revert and have a talk. City articles have a huge problem with image spam in the lead ..... for example Los Angeles has 15 files for four paragraphs of text.... simply crazy my view. The least we can do is reduce the size of these so they're not as intrusive for readers...... text inside the box will still be the same we're just reducing the sizes of the images to make the prose lead paragraphs more readable/accessible..... as in not sandwich for some devices and formats. Moxy🍁 19:29, 16 October 2025 (UTC)[reply]
Sounds pretty reasonable to me! - Zackmann (Talk to me/What I been doing) 19:30, 16 October 2025 (UTC)[reply]
That 228px was added in this April '25 edit whose edit summary said This is not intended as a permanent change; discussion is still ongoing at talk and we should continue working out a new consensus there. The wording can be adjusted after this happens. It's related to Wikipedia talk:Image use policy/Archive 16#Lead image size which isn't particularly clear. --Joy (talk) 19:31, 16 October 2025 (UTC)[reply]
Not sure what your trying to say here? To me it seems like our recommendations were changed and have not been reverted.... and the so-called ongoing discussion has been dead for months and it's about to be archived. Is there a new chat about the changes to our protocols? Moxy🍁 19:39, 16 October 2025 (UTC)[reply]
I think Joy's point (and correct me if I'm wrong) is that this is still a work in progress and consensus on it is fluid. That being said, I don't see anything in the discussion they linked to that should prevent this change from being made. I think it should be WP:BOLDly done, and if there is pushback, then we can discuss it further. Zackmann (Talk to me/What I been doing) 19:43, 16 October 2025 (UTC)[reply]
I don't think infobox template code, which can't be edited by everyone, should try to enforce a manual of style change that isn't backed by strong consensus. The manual of style is not a policy, but a guideline. --Joy (talk) 19:50, 16 October 2025 (UTC)[reply]
In particular I'm referring to the fact that nobody really disputed the comment by @User:Pi.1415926535:
15 or so years ago, a typical infobox occupied 1/5 of screen width (200px infobox on a 1024px screen, the most common size in 2010). Since then, screens have approximately doubled in pixel size but stayed similar in physical size, so a 200px infobox occupies only half the screen width that it once did. No one is suggesting infoboxes that infoboxes take up half the screen, just that they are scaled to keep a roughly constant width (on a given physical screen size) over time. Infoboxes are for the most important information and the most representative image - and are typically where readers look first - so why should they get narrower and narrower as screen resolution increases?
There was an answer from @Fyunck(click) but it didn't seem to address this question well. What does seem instructive from the later comment was the mention of infobox pictures as large as when happened a couple days ago - but I don't know what that was specifically referring to. Had there been some sort of a change in April that was then backed out? --Joy (talk) 19:48, 16 October 2025 (UTC)[reply]
In my view we should implement what our protocols say and if they change it changes here. Moxy🍁 19:56, 16 October 2025 (UTC)[reply]
That entirely depends on what you mean by "protocols", though. Please see Wikipedia:Policies and guidelines. --Joy (talk) 20:01, 16 October 2025 (UTC)[reply]
What are the thoughts on a more conservative initial approach? The current maxsize in the sandbox is 320px. How about we start there. I think we all agree that it is an improvement... If down there road there is more clear consensus on 228px (or another number) that can easily be changed. But how about we start with 320px and go from there? Zackmann (Talk to me/What I been doing) 20:16, 16 October 2025 (UTC)[reply]
Yes both are policy and guideline pages make this recommendation.... I consider these to be our protocols as outlined at WP:GOV. I should be transparent and explain I help write both the policy guideline page and our administration page. Moxy🍁 20:21, 16 October 2025 (UTC)[reply]
A guideline is not a policy. Considering the spirit and letter of their definitions, we're not supposed to prevent any exceptions to the guideline by hardcoding numbers. We're especially not supposed to do that without verifying that we have proper consensus about it. --Joy (talk) 21:25, 16 October 2025 (UTC)[reply]
sorry my bad I thought I was linking the policy the whole time Wikipedia:Image use policy.... just regurgitates the guidelines WP:IMAGESIZE and WP:IMGSIZELEAD. My bad this is why there's so much confusion..... was wondering why you were discussing the difference between policies and guidelines here.Moxy🍁 21:36, 16 October 2025 (UTC)[reply]
Oh yeah, that was confusing. But still, the argument about unclear consensus about the changes to the image use policy stands. Sure, we've collectively let @David Eppstein's edit from April stand for months now, and the discussion died out to the extent that the bot archived it, but did the consensus-building process actually complete, or did we just lose interest? :)
Besides, we didn't even bring up what seems to be a major point of the same policy - using relative units instead of absolute. If that's so important, why would we be using these template parameters which are still with pixels? --Joy (talk) 04:44, 17 October 2025 (UTC)[reply]
Researching this matter further, I found that this April edit by @Jonesey95 had been reverted. What was this default thumbnail size change from 220px to 250px? --Joy (talk) 04:48, 17 October 2025 (UTC)[reply]
So one thing I will say to hopefully get this conversation a little back on track, the change I am proposing is to limit the MAX size, not to make any change to the default size... Enforcing a default size is a much more involved discussion. I'm just trying to limit the extremes. Zackmann (Talk to me/What I been doing) 05:01, 17 October 2025 (UTC)[reply]
My strong preference would be to follow MOS:IMAGE in using relative sizes (multipliers of the user's default size from their preferences) not absolute sizes (pixels). That way if someone has a big screen and wants to take advantage of it they don't have to squint at tiny thumbnail-sized images sized for people reading on their phones, or vice versa. Beyond that I don't have a strong preference for what the multiplier should be. —David Eppstein (talk) 05:31, 17 October 2025 (UTC)[reply]
Agreed, but even that max isn't clear, if the preferences are allowing users to select 300px and 400px, but then infobox code clamps this down without telling them, that looks like it's going to produce weird results at best. --Joy (talk) 10:25, 17 October 2025 (UTC)[reply]
The default size (Using |thumb| with no specified size) in the underlying software was changed from 220px to 250px. Not sure where it is documented though. CMD (talk) 05:11, 17 October 2025 (UTC)[reply]
Oh, like a Mediawiki systemwide default? Interesting.
https://en.wikipedia.org/wiki/Module:InfoboxImage#L-218 still has a hardcoded reference to the magic number 220. Maybe we need to move this there so it's more consistently addressed in all infoboxes, not just this one.
And having said that, I just realized Module talk:InfoboxImage#Default maxsize to 250px already exists :) --Joy (talk) 10:14, 17 October 2025 (UTC)[reply]
@Joy: full disclosure, the thread you linked to was started by me to address this same issue... Zackmann (Talk to me/What I been doing) 17:34, 17 October 2025 (UTC)[reply]

Too many maps

[edit]

So recently came across Vancouver which has FIVE maps in the infobox. 1 mapframe, 1 image map and 3 pushpins. To me this is way too much, particularly since the mapframe duplicates what the image map shows. Was thinking to address this I would do add the following to the Infobox. 

{{if all|{{{mapframe|}}}|{{{image_map|}}}{{{image_map2|}}}|{{{pushpin_map|}}}
 | n = 3
 | then = [[Category:Pages using infobox settlement with potentially too many maps]]
}}

Would be helpful to at least know how often this happens? Anyone have any thoughts? --Zackmann (Talk to me/What I been doing) 00:13, 31 October 2025 (UTC)[reply]

Makes sense to me, let's investigate. Please add image_map1 to the list as well.
It should be noted that in that case the 3 pushpins don't occupy 3x the space by default. Likewise in that case the image_map1 has a value, but visually it's hidden. But it's still a lot overall, and a situation worthy of tracking. --Joy (talk) 00:39, 31 October 2025 (UTC)[reply]
Yes I have to actually look at the code to make sure I'm getting the param names correct. Also Joy is 100% correct, while there are 5 maps on Vancouver, only 3 of them occupy space (as the pushpins switch out). --Zackmann (Talk to me/What I been doing) 01:20, 31 October 2025 (UTC)[reply]
In general city articles are the example used of what not to do for an infobox - mass file/image spam. New York city has 17 images being rendered... including teeny little flag icons.Moxy🍁 02:34, 31 October 2025 (UTC)[reply]
So I've BOLDly gone ahead and done this... Category:Pages using infobox settlement with potentially too many maps (15,674) should populate in the next few hours/days. We definitely need further discussion on what to do with these pages, but I want to at least see how big of a problem this really is... --Zackmann (Talk to me/What I been doing) 03:58, 31 October 2025 (UTC)[reply]
That's a separate problem from this one, because that's usually within the image_skyline parameter. To track that, we'd have to recurse into the value and try to find something like {{multiple image}} and in turn check that. I don't know how much more expensive such a check would be compared to {{if all}} used here (4 #ifexpr:'s), but it sounds like something to ponder first.
Tracking here could be done in a similar manner to maps if we e.g. concluded that having something inside all of image_skyline, image_flag, image_seal and image_blank_emblem is suspect. Judging by the totals at [1] the possible lower bound to that would be the 3880 image_blank_emblems. --Joy (talk) 11:42, 31 October 2025 (UTC)[reply]
Pushpin maps are far inferior when it comes to zoomability (click on the map, lose the marker), so only one should be used to show the position within a well-recognizable larger entity. Ponor (talk) 12:16, 31 October 2025 (UTC)[reply]
Thanks to the tracking category, I started reviewing these. The first case for me was this:
  • [2] - rm extra map of a higher level subdivision, it doesn't point out the topic of this article so it's unlikely to be very helpful to readers, just explain and link it in the caption instead
I'm not sure how easily this sort of an edit can be automated. It required detecting the extra subdivision map which I did visually, dropping it in favor of a caption linking the subdivision name, and shifting the more useful map up from image_map1 into image_map. Possibly the detection could be done using filenames, but it requires parsing an intricate pattern ("Map NL - Veere - Aagtekerke.png") that probably isn't global. --Joy (talk) 10:14, 4 November 2025 (UTC)[reply]
My next case was simpler:
  • [3] rm excessive map of a higher level subdivision, already part of pushpin_map
But then I came across Agoo, which has:
  • File:Ph locator la union agoo.png, which is sort of okay WRT scope for local viewers, and has some labels
  • Mapframe hidden behind a label saying OpenStreetMap, showing a zoom level slightly higher than the map above
  • Pushpin map of the country, which is sort of okay WRT scope for international viewers, but has no labels
An ideal fix in my mind would be to implement the same thing as Minneapolis to replace all three of these, but OSM doesn't have the shape from the static map at the top (or Wikidata doesn't have it linked). Plus the current implementation monstrosity of the Minneapolis solution. --Joy (talk) 10:21, 4 November 2025 (UTC)[reply]

I agree that many infoboxes are cluttered with too many maps. The problem is that because all these options exist, people think that they must be used. Well, just because we can doesn't mean we should. It would be better if we roll back some of these features, or come up with some guidelines for their use. -- P 1 9 9  ✉ 15:35, 4 November 2025 (UTC)[reply]

Relief

[edit]

Can | pushpin_relief = be added to the various sub-templates of {{Infobox settlement}}? {{Infobox Greece place}}, {{Infobox Turkey place}}, and {{Infobox Russian inhabited locality}}, among others, do not let me add maps in relief to their infoboxes. Antiquistik (talk) 17:53, 3 November 2025 (UTC)[reply]

 Doing... @Antiquistik: This has been on my todo list... I'm going to convert these all to use Module:Template wrapper so that all params from {{Infobox settlement}} will work as expected. This is going to take a little while but I'll get started on it now. You can track the progress here:
--Zackmann (Talk to me/What I been doing) 17:59, 3 November 2025 (UTC)[reply]
@Zackmann08 Thanks. How do I change the map to the one in relief on the templates which have already been converted? Antiquistik (talk) 21:22, 3 November 2025 (UTC)[reply]
@Antiquistik: short answer, |pushpin_relief=yes. Turkey and Greece are done. Working on Russian inhabited locality right now.
Longer answer, see the documentation for {{Infobox settlement}}. Any parameter not hardcoded or overridden by the wrapper code will work exactly as described in the documentation for settlement. If you run into any issues, if you can provide me with a link to a specific page I'll be happy to help ya out! Zackmann (Talk to me/What I been doing) 22:23, 3 November 2025 (UTC)[reply]
Thanks! Antiquistik (talk) 22:32, 3 November 2025 (UTC)[reply]
Ooh I had noticed that issue, but didn't have the time to invest into dealing with it. Happy to see progress on that front. --Joy (talk) 21:48, 3 November 2025 (UTC)[reply]

Why does everyone on WP want relief maps now??? I don't think that is a good idea. We should use relief maps only for rivers, lakes, and such, not human places and jurisdictions, because borders and subdivisions are not or barely visible on the relief maps. There was some consensus or best practice for this at one time, but I don't remember where I read that. But it was briefly discussed at Wikipedia:Help desk/Archives/2025 January 28#Relief on City Pushpin Maps? Maybe another centralized discussion should be started to adopt some standard/guideline on this. -- P 1 9 9  ✉ 03:07, 4 November 2025 (UTC)[reply]

@P199: FWIW I agree with you. I would be in favor of removing support for relief in Infobox settlement and all its subsidiaries... But that would def require consensus. Zackmann (Talk to me/What I been doing) 03:10, 4 November 2025 (UTC)[reply]
I don't quite understand this argument. The linked discussion was about Santo Domingo, a capital city.
I can't say that seeing the internal borders of the Dominican Republic on these two maps is particularly useful for the average reader. It's a lot of lines, but no apparent value, because it's not explained, there is no legend. There's elements of physical geography on both maps, like bodies of water and coast indentation, but one shows the internal subdivision lines more while not showing elevation.
For a reader, knowing that a place is close or far away from a sea or a mountain is similarly general information compared to knowing that it's close or far away from the nearest national border. These are everyday things that affect basic orientation of a reader about a place, like how far from another such place it might be, or how hard it might be to travel around there.
For borders of lower-level administrative subdivisions, it's much more specific information, probably too specific for the average reader who isn't from the area.
Map
For comparison, here's how the infobox mapframe map would look like there. At this similar zoom level, it has a lot of these unexplained lines, but over them it also has basic labels, country and big cities. It also has a basic scale, for distance comparison.
And once you click it, you can zoom in and out, and see more labels. At higher zoom levels, green blocks start to appear for areas of nature, which isn't a direct replacement for the placement of mountains, but it's often a reasonably close approximation.
If we're thinking of making changes, it's probably good to think in terms of our entire mapping arsenal. --Joy (talk) 06:09, 4 November 2025 (UTC)[reply]
The lines don't need a legend, because the maps are consistent in showing internal borders. For large countries especially, those lines are far more helpful then the green and brown shades, because it also shows its location relative to province/state boundaries. A good example is the USA - many, if not most readers, will be familiar with the individual states. So I disagree with the statement that political maps are "probably too specific for the average reader who isn't from the area".
Ultimately, all your arguments can also be said about the relief map: just a field of green and browns without explanation, giving a bit of basic orientation. Political maps do the same AND are more helpful to those who do know the political geography of a place.
As for "making changes of our entire mapping arsenal", that's too big a step for now (getting consensus for that would be near impossible). Maybe a good start would be removing support for relief in Infobox settlement, which I would support. -- P 1 9 9  ✉ 14:16, 4 November 2025 (UTC)[reply]
I'm sorry, that's a hard disagree from me on your first claim. When I look at a map of a large country, let's say the biggest one, Russia, most of the time I have no idea what the internal lines mean. Is it the Krasnoyarsk Krai or is it the Republic of Bashkortostan - I'd be hard pressed to answer. Likewise for the US. I am interested in geography and the US is a superpower so a matter of above average interest, so I may claim the ability to make sense of most of those American lines, but the average English reader is not a geography enthusiast. I'm pretty sure most of our readers can't figure out what most of the internal lines mean to save their life.
This is a general encyclopedia, this is not a scientific journal. Let's not ignore accepted policy just so casually.
Elementary schools teach people how to read maps in general, so they can know the meaning of a line being a border and the color scheme being topography, but labels are still beyond useful to know which county or mountain a map is displaying. Knowing the fine details of political geography beyond one's own country is just not part of the average curriculum and we should not design maps based on any such wishful thinking.
The idea that we're going to improve anything for the readers by making it impossible to present vague relief maps, but keep presenting political maps that are no less vague - is misguided. ---Joy (talk) 16:42, 4 November 2025 (UTC)[reply]
I think probably the best map type depends on the country doesn't it? Maybe for vast nations with a varied geography like the US, Russia or Australia, a relief map might be helpful. But in smaller densely populated places like England, a little dot in an expanse of green doesn't help much and can actually be misleading, hiding quite how built up an area is. The best map choice there is usually a mix of political and man-made structures such as motorways. Like York, for example. Dgp4004 (talk) 17:18, 4 November 2025 (UTC)[reply]
And London's pushpin map of England uses a combination of relief and political. That sort of combination might be a good compromise. Dgp4004 (talk) 17:27, 4 November 2025 (UTC)[reply]
The UK pushpin basemaps are of markedly better quality than the average, agreed. --Joy (talk) 21:14, 4 November 2025 (UTC)[reply]
Disagree with you on all points too. It's so dismissive to claim that "most of our readers can't figure out what most of the internal lines mean". Anyway, the entire discussion boils down to different points-of-view and subjective criteria. We won't reach consensus on this. -- P 1 9 9  ✉ 03:56, 5 November 2025 (UTC)[reply]
It's not dismissive, it's just recognizing the reality that this is a general encyclopedia with a broad readership. There's nothing subjective about being cognizant that people who may read an article may come from Adelaide, El Paso, Newfoundland, Gujarat, Merseyside, Cape Town... --Joy (talk) 06:31, 5 November 2025 (UTC)[reply]

Mapframe wikidata

[edit]

@Joy: (and anyone else) can you think of a reason we don't have |mapframe-wikidata=yes in the template? It seems like that is what is missing from the desire to convert from the Template version of the mapframe to the Module version. The template seems to pull from wikidata automatically, the module does not. Zackmann (Talk to me/What I been doing) 19:49, 7 November 2025 (UTC)[reply]

I think it's because Wikipedia:Requests for comment/Mapframe maps in infoboxes#Q4. Wikidata coordinates - whenever there's local data here, it should override data from Wikidata by default.
The problem is, our local method of using shapes clearly doesn't scale as well as Wikidata references to OSM. I for one never used it, editing OSM with the default web editor just seemed too easy. --Joy (talk) 20:04, 7 November 2025 (UTC)[reply]
I thought that if {{infobox settlement}} had {{{coordinates}}} that would override the wikidata call.. I've just found that the shape doesn't show up without |mapframe-wikidata=yes. See this revision. If you remove the |mapframe-wikidata=yes call, you won't get the red border around the city. It would seem that the best solution is to have that be built in. I've seen it on numerous other Infoboxes I've recently converted. Zackmann (Talk to me/What I been doing) 20:13, 7 November 2025 (UTC)[reply]
I think it's more subtle than that - the red shape you can get with |mapframe-shape=yes. You don't need the entire override from wikidata. At least that's how I think it should work. --Joy (talk) 20:25, 7 November 2025 (UTC)[reply]
Facepalm Facepalm Didn't know that |mapframe-shape=yes would do the samething... Why is this SO confusing?!?! lol. Ok so what do we think about adding |mapframe-shape=yes to the code for {{infobox settlement}}? You can always override it on individual transclusions if needed, but I have yet to see or think of a case where on a settlement page you would be disappointed to see the boundary lines. Zackmann (Talk to me/What I been doing) 20:28, 7 November 2025 (UTC)[reply]
I would agree with that, yes. The usage of local map shapes seems comparatively tiny and doesn't seem likely to grow. That is, we're not really be impeding any local development by doing this. Seeing the shapes linked from Wikidata seems safe enough.
Worst case we show some bad ones and this visibility helps get them fixed faster - the same as what happens with bad coordinates (and we do have a fair few of those, usually hiding in plain sight without mapframe rendering). --Joy (talk) 20:46, 7 November 2025 (UTC)[reply]
I'm going to go ahead and add it. Obviously if it causes any issues we can revert. - Zackmann (Talk to me/What I been doing) 20:49, 7 November 2025 (UTC)[reply]

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

[edit]

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

Default postal code type

[edit]

Right now if you supply a |postal_code= but no |postal_code_type=, the postal_code does not display.... I was going to change that and make the default postal_code_type be "Postal code". To be clear this would not change pages that use (for example) |postal_code_type=Zip code. It would just mean that on pages where a postal_code IS being supplied without a type, that value would no longer be suppressed. With how many values are displayed in this infobox, I have found quite a few pages where there is a code but no code type and people just don't realize that value isn't being displayed (or don't understand why).

Before I perform this refactor (which is rather complicated) I want to make sure there is no objection to it... --Zackmann (Talk to me/What I been doing) 16:18, 21 November 2025 (UTC)[reply]

Proposal: Adjust default flag size for Infobox U.S. state

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I’d like to propose a small formatting update to the Infobox U.S. state template regarding the default display size of state flags. Currently, the size is inherited from Template:Infobox settlement, but in practice the flags on U.S. state pages appear noticeably smaller compared to similar infoboxes (e.g., country infoboxes). A slightly larger flag improves visibility and readability, especially on desktop view.

I propose an increase of the default flag size in Infobox U.S. state from the inherited value to a slightly larger, fixed size (125px), seen in the lower example infobox displayed. If possible this change can be implemented locally for the U.S State template as not to affect the overall settlement template.

California
State
Flag of California
Flag
Official seal of California
Seal
CountryUnited States
Largest city{{{LargestCity}}}
 • Upper house{{{Upperhouse}}}
 • Lower house{{{Lowerhouse}}}
U.S. senators{{{Senators}}}
Language
California
State
Flag of California
Flag
Official seal of California
Seal
CountryUnited States
Largest city{{{LargestCity}}}
 • Upper house{{{Upperhouse}}}
 • Lower house{{{Lowerhouse}}}
U.S. senators{{{Senators}}}
Language
Bokmanrocks01 (talk) 02:56, 24 November 2025 (UTC)[reply]
This sounds reasonable let's see what others have to say. Moxy🍁 03:25, 24 November 2025 (UTC)[reply]
@Bokmanrocks01: I'm the one who made that change when I converted it to a wrapper yesterday (or today? can't remember)... In any case, it seemed that it was more appropriate to use the default sizing as it adjusts based on whether a seal is present. That being said, I think given that all U.S. states use the same size ratio for their flags, and the prexisiting setup was 125px I will revert that portion of my change. If someone else feels strongly it should NOT be 125 px we can discuss further but given that I'm the one who made the change, I feel comfortable undoing my change without any need for further discussion. Sorry I initially undid your change and appreciate you coming with an explanation and an example! - Zackmann (Talk to me/What I been doing) 03:37, 24 November 2025 (UTC)[reply]
Thanks, I appreciate it Bokmanrocks01 (talk) 03:48, 24 November 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

wrapping of Infobox UK place

[edit]

There's currently a discussion at Template talk:Infobox UK place#Conversion to use Infobox settlement as a wrapper about whether and how to make that template a wraper of Infobox settlement.

There are some potential changes that we could do here to facilitate that migration, and potentially improve things for other settlements out there, too. There's already two main use cases it seems - distances and public emergency services. I'll start separate subthreads for each.

Just a few common links first:

--Joy (talk) 14:43, 25 November 2025 (UTC)[reply]

something for distances

[edit]

A place to include distances from the topic settlement to other points of interest.

This is ostensibly a geographical field, similar to coordinates and maps. Zackmann08 has recently complained about how this is redundant with various maps. I don't think it's inherently redundant, because different readers absorb different types of information better, but the risk of overkill is real. We don't have a mechanism of preventing geography/location overkill, just like we don't have it for the various flags and seals and images. I don't think this risk should impede trying this out. It's easy enough to just pull the plug on it later if it truly gets out of hand, by just removing the rendering of any such new fields.

The UK infobox specifically uses this concept for four types of distances to capital settlements, and their standard seems to be a single entry in that list, with a length that is passed through {{convert}} etc.
A use case like this is already also improvized by WP:IAUP through |subdivision_type6=+|subdivision_name6=. That is a bit of a kludge, but seems to have worked out. It comes after the block of parameters described as Location by the documentation here, so it seems to make a modicum of sense. They use it for a list of up to 5 other locations, with some formatting.
Historically there doesn't seem to have been much acrimony about the concept at the UK place talk page, the last signs of it are in Template talk:Infobox UK place/Archive 9 from 2010. The later discussions seem to be about implementation details. In the recent discussion, people actually started discussing about how the distance expressed in kilometers/miles isn't informative enough.
Current UK usage of these parameters:
  • london_direction 1,885
  • london_distance 1,402
  • london_distance_km 283
  • london_distance_mi 2,354
  • cardiff_direction 12
  • cardiff_distance 47
  • cardiff_distance_km 260
  • cardiff_distance_mi 314
  • edinburgh_direction 26
  • edinburgh_distance 138
  • edinburgh_distance_km 5
  • edinburgh_distance_mi 211
  • charingX_direction 202
  • charingX_distance 2
  • charingX_distance_km 1
  • charingX_distance_mi 206
  • belfast_direction 3
  • belfast_distance 65
  • belfast_distance_km 3
  • belfast_distance_mi 97
  • douglas_distance 8
  • dublin_direction 4
  • dublin_distance 3
  • dublin_distance_mi 30
Likewise, at the Australian place talk page, the last question about this was in Template talk:Infobox Australian place/Archive 9 from 2022 where an editor asked about more flexibility, just to be able to indicate remoteness structure (which seems to be a statistical category in that country). Others before that also asked about whether to use lengths by straight line or by road (like the recent discussion at the UK place infobox talk).
Current Australian usage for these parameters:
  • location1 10,769
  • location2 7,578
  • location3 5,432
  • location4 3,001
  • location5 903

I can envision editors wanting to use different distance indication/measurement methods depending on settlement type. It's reasonable to assume that for certain places they may want to include conventional time of travel, esp. for far away places, like islands in the ocean, oases in huge deserts, etc. Some readers may appreciate a distance in length units, some maybe in flight time. A predictable time of transport to some conventional point of interest like a far-away regional capital is plausibly useful to the average reader. Elsewhere, they may just want to have some other, not terribly specific or even numeric distance indication.

Because of this, I don't think we should import any implementation complexity here, rather, just give people a free-form option to include something in the first place, and later reassess if we need to provide more guardrails.

We could start by adding an optional |distances_label=Location and |distances_list= here. This would allow for a technical cleanup in the Australian template and remove one conversion blocker for the UK template. --Joy (talk) 13:22, 25 November 2025 (UTC)[reply]

something for emergency services

[edit]

A place to include more basic public services information, for emergency/rescue.

This is ostensibly an administrative field, similar to time zones, postal codes, etc.

The UK infobox specifically uses it for three types of services retrieved through Template:Infobox UK place/local:

That approach seems fairly useful to maintain shared information in one place, instead of having a lot of copy&paste everywhere.

Given that we already summarize other regional properties like time zones, ISO codes, registration plates, this seems like a fair request. In some settlements it'll just be national service links (reminds me of time zones), which we could probably optimize, but somewhere else it'll require a bit of nuance.

We had an initial thread about this at Template talk:Infobox settlement/Archive 33#Edit request 1 June 2024 but it wasn't formatted right and no discussion followed. There doesn't seem to have been a whole lot of discussion in this regard before, only one inquiry about police and fire departments in Template talk:Infobox settlement/Archive 24 in 2014.

I'm not sure immediately about how to organize new fields for this, suggestions welcome.

  • |emergency_services_label= and |emergency_services_list=?
  • |police_service_label= and |police_service_list=, |fire_service_label= and |fire_service_list=, |emergency_medical_service_label= and |emergency_medical_service_list=?

Or something else?

I wouldn't add specialized emergency services yet, that seems like a slippery slope. --Joy (talk) 13:39, 25 November 2025 (UTC)[reply]

Discussion

[edit]

I will just voice my 100% opposition to adding either one of these to {{Infobox settlement}} and reiterate some of what I have already said at {{Infobox UK place}}

  • Wikipedia is not a directory, and per MOS:INFOBOXPURPOSE The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article. Listing of Fire/Police/Medical services in an Infobox is way overkill. Put that in the article, NOT in the Infobox.
  • We already have maps (multiple of them) in the Infobox, we do not need a list of distances to random cities that may or may not be nearby. What purpose does this serve that cannot be achieved with a mapframe? Unless my desire is to know EXACTLY how far city X is from one of the 6 or 7 arbitrarily chosen cities, this information does not help at all. Additionally if my primary goal of looking at the page for Princetown (for example) is to find out exactly how far it is from London, I'm sorry but Wikipedia is the wrong place for that. Google it.
  • I believe that the goal of the "distance to city x" parameters is to give the user some idea of where a place is. That goal is already well achieved by the pushpin maps and the relatively newer mapframe. We do not need a list of distances as well.

Adding these values to {{Infobox settlement}} to make users of UK place happy is a mistake. These values do NOT belong in an Infobox and should be removed from UK place. Nothing against including them as needed in the body of the article. --Zackmann (Talk to me/What I been doing) 16:41, 25 November 2025 (UTC)[reply]

I'm not sure how the Wikipedia is not a directory of everything in the universe that exists or has existed. policy really speaks to the quality of what's the best infobox summary of an article.
The obvious arguments would be by comparison to existing optional fields - how is the time zone or some random code of a place a key fact for it, one we have to make room for, but their basic public emergency services are not, and we must not make room for them? Or why is listing a village's 2nd or 1st level country subdivision a key fact, while saying what their local fire department would not be?
I agree with the basic summarization argument - the articles on settlements should describe these matters in detail, and then the infoboxes should summarize them. But I don't see how preventing or dissuading editors from summarizing this by restricting infobox formatting accomplishes this purpose, or really any other.
The purpose of showing a distance would be to assist readers who understand distances better than maps. I don't see why the possibility of readers who do not like to do multiple clicks, pans and zooms on a maps in order to understand where a place is - would be inconceivable. I myself like browsing maps, yet I find the thought of just seeing:
  • "[That town is] 47 miles east of Dallas", or
  • "[That village is] 22 km south of Pretoria", or even
  • "[That island village is a] 25 minute ferry ride from Suva", or maybe even
  • "[That hamlet in the tundra is] 92 km by air or 103 km by river from Irkutsk" (the thought being - no airfields are actually nearby)
...very useful to summarize geography sections of settlement articles, because they can provide orientation in a few simple words as opposed to requiring analysis.
Fundamentally, as we already support a variety of free-form fields, including completely blank ones, the idea that we would really need to try to artificially restrict named fields strikes me as strange. --Joy (talk) 17:36, 25 November 2025 (UTC)[reply]
@Joy: Just to clarify my comment that Wikipedia is not a directory was directed specifically at the inclusion of Fire/Poice/Medical services, not about the distances to locations. If we are including Fire/Police/Medical, why are we stopping there? What about including all the public transport of a place? What about listing the airports in a settlement? Should we list all the hospitals in a settlement along with who provides EMS? What about the public radio stations that serve a given area? Pretty soon we have the entire article crammed into the infobox. We need to remember MOS:INFOBOXPURPOSE and not try to cram every piece of information about a place into the infobox. THAT is my point.
I will reiterate that I have no problem with including this information in the body of the article... But the idea that we need to list the name of the fire department in the infobox doesn't hold water in my opinion... Zackmann (Talk to me/What I been doing) 03:29, 26 November 2025 (UTC)[reply]
I agree, it can be a slippery slope. But that doesn't change the fact these emergency services can be key pieces of information to summarize in an article, much as anything else that we already have in this infobox.
I think we need to consider this based on what would practically be affected. For instance, if we have a village that has a firehouse that is located in the center next to the main church, and the article explains the 150-year-old history of the local fire brigade, then that's something we shouldn't prevent noting in the infobox.
It does leave us with a risk someone will list a fire service from the nearby town, which maybe doesn't have a strict connection to the settlement described, it could just be by and large not key info. But it's no worse a problem than the risk that someone will list a pointless time zone, the ISO code for the wider region, the registration plate for the municipality, etc.
For instance, if we have a remote town in Alaska whose main lifeline is the local airfield, its article would presumably tell us that, and its infobox would probably be right to include the same. In a town in a more densely populated area, where the closest airport is 12 other places away and/or 50 miles away, and the main mode of transport is roads, it probably makes no sense to talk about the airport. At the same time, if there's one or two main highways connecting the place, it may well make sense to list these.
And we also can't ignore the possibilities of a disconnect between editors and readers with the status quo. Editors can list 4 different area statistics, 3 different population stats, the current mayor and all the local council members, and the flag and the shield and the postal codes, the works. For a lot of readers, a substantial portion of these will just not be key facts about the article topic, even if the infobox syntax allowed for it and they are key for some other readers. They might have wanted a single area stat and a single inhabitant stat, the insignia may have been pointless visual distractions, and in turn something they might consider a key fact was missing. Like the link to the primary emergency service provider, or a distance to the closest big city :)
The key thing here is context - is the context of the infobox syntax the right place to decide these matters, or is the context of the article the right place to decide these matters?
With over half a million transclusions, I think we've outgrown the possibility of doing a lot in the former context (of the infobox), because the variety out there is so large. If we were to remove a field for e.g. leader_name4 or image_blank_emblem or code2_name or timezone5_DST, we'll easily find a lot of articles where this was key info and it was actually appropriate to have it.
We may be able to decide to try to actively dissuade listing e.g. radio stations or hospitals or timezones or similar, but we'd need to develop some sort of coherent criteria for this, because key facts just seems too vague when it's based on articles that are free-form, and not fair given the status quo assortment of fields. --Joy (talk) 10:03, 26 November 2025 (UTC)[reply]
I also agree that the distance to x does not belong in the infobox. Do articles that use that information in the infobox, have that information also in the article prose? I'd be very surprised if they do. That doesn't mean that information isn't interesting to some people, but that information is much more WP:TRIVIA and belongs more at tourist destinations. Gonnym (talk) 21:03, 25 November 2025 (UTC)[reply]
Reading this, it occurs to me that this sort of logic could also be used to try to remove locations and maps from infoboxes altogether.
If you are surprised to see "The place is [X distance] away from another place" in the article prose - and that actually happens in settlement articles, quite often - how easy would it then be to say: why do we need a map?
Also, a map will typically contain some geographic features between and around that place and those other mentioned places. But all these map features are not in the article prose, so the infobox actually adds more information rather than just summarizing, right?
Besides, if the prose says a place is in country X, does that actually justify drawing a map of this country? The article doesn't talk about the entirety of the country, therefore that country's whole map is not a summary of the article, right?
Suffice it to say that I don't think any of this is actually a useful line of reasoning.
The location of a settlement is not miscellaneous information, because locations are defining characteristics of places. A reader who arrives at an article about a settlement will habitually ask - where is this place? That is a common question, so an article should not be artificially restricted in answering that up front, in the infobox or otherwise.
Because it's common sense to not treat readers as if they're just some pesky tourists.
And because Wikipedia combines many features of general and specialized encyclopedias, almanacs, and gazetteers. The common element of gazetteers is that the geographical location is an important attribute of the features listed. A location of a settlement is normally presented in relation to other places, so showing distances, on a map or in a list or whatever other way is conventionally useful to readers, is not something out of the ordinary. --Joy (talk) 22:39, 25 November 2025 (UTC)[reply]
I hold several of the sentiments listed by Joy. I added on the UK page that Wiki is firstly and foremost an educational resource, and there has to be an element of breaking down the article for those less knowledgeable or where English isn't a primary language. Giving a semblance of where a place is is key detail, and the distance from a well-known place starts to help build up that picture. I'd go as far to say that mentioning political features such as the district or state it is in does not relay any idea where a place is, yet no one questions having those in the box.
It is yes harder for a polycentric country such as the US to use a capital when other cities are more well-known, but most countries have one main city. People with special accessibility issues would also appreciate getting a location idea quickly from the box, even automated tools can use the infobox detail to build a profile on a place. Same with the services, they are key ecosystems which allow a place to essentially exist and they deserve a mention in said infobox. Regs, The Equalizer (talk) 00:04, 26 November 2025 (UTC)[reply]

Unreliable maps automatically imported from OpenStreetMap

[edit]

There is a general problem in letting an infobox template automatically import in Wikipedia information from another wiki (such as Wikidata), because a wiki is, by definition, an unreliable source by itself, and because such an automatic importation cannot be individually challenged by a « citation needed » requirement.

One such wiki is OpenStreetMap which is not backed by any official national office of topography or cartography. It is liable to contain mistakes, and it does. This has come to my attention through pages using Template:Infobox Switzerland municipality The particular problem there is that the maps imported (« location of … ») represent all the municipalities that are located on the shores of a lake as containing within their borders a portion of this lake. To my knowledge this is never true in Switzerland: the portions of lakes within the borders of some canton are under its direct jurisdiction, and never belong to any smaller municipality. For the Canton of Geneva this is specified by the « Constitution de la République et Canton de Genève (art. 159 al.2) and by the « Loi sur les eaux (LEaux-GE) (art. 3 al. 4 et 5 al. 2) ». An additional unfortunate consequence of this is the incorrect indication as « neighboring municipalities », in the infobox, of municipalities located on the opposite shore of the lake.

This is just an example, and a number of other mistakes are very likely. I think it it imperative that this automatic importation by various templates of potentially erroneous maps from OpenStreetMap be altogether stopped, and I am aiming to reach a consensus on this. It could be replaced by another automatic importation, which would have to be very strongly reliable: I doubt there is any possibility. I favor instead a new entry in the infobox template such as «  | location map = » to be filled individually (and in which a new entry could always be challenged by a « cn » template). There might be other solutions, as still authorizing automatic importation, but only if it is with the possibility of individually challenging it (and eventually suppressing it). Sapphorain (talk) 21:31, 29 November 2025 (UTC)[reply]

What do you mean it can't be challenged? Just add:
| mapframe-caption = {{citation needed}}
?
I'd say it's we shouldn't make rash conclusions about a global data source based on a sample of up to 117. --Joy (talk) 21:35, 29 November 2025 (UTC)[reply]
Thanks for the tip, this could be useful. However, only for the particular example I mentioned, this would mean individually challenging several dozens of maps, maybe more. Not very practical. There must be an easier way to correct a general error. --Sapphorain (talk) 21:58, 29 November 2025 (UTC)[reply]
Mapframe has been in use for years on wikipedia. This is the nature of the beast with ALL open source wiki's. The information can technically be edited by anyone and is thus not always reliable. To suggest that we remove it from at least a half million pages is not backed by any real data other than one user's dislike of the system. Zackmann (::::Talk to me/What I been doing) 01:43, 30 November 2025 (UTC)[reply]
« The information can technically be edited by anyone and is thus not always reliable. » This is precisely the description of an unreliable source, and Wikipedia normally aims to avoid unreliable sources. Claiming that we shouldn’t do anything about one particular unreliable source simply because it has been widely in use for many years appears to me to be a rather poor argument.
There should at least be an easy way to suppress an individual map from an infobox (or replace it by a correct one if available) if it turns out to be inaccurate.--Sapphorain (talk) 09:54, 30 November 2025 (UTC)[reply]
Background of OpenSteetMaps are extracted from reliable satellite maps, so background is always true, but the unreliable part is the labels and roads that are added to this background.
Even though it is likely that these meta-background add-ons be subject to vandalism, its likelihood is low. But other maps (like satellite map, and custom map) can provide a reliable proof for that unreliable OSM map. Using Template:MergedMap, there would be a nice way to validate these unreliable OSM maps. Hooman Mallahzadeh (talk) 10:27, 30 November 2025 (UTC)[reply]
@Sapphorain I really propose to add an instruction for "Template:MergedMap" that claims "Try to provide image type maps to validite OSM". Thanks, Hooman Mallahzadeh (talk) 10:48, 30 November 2025 (UTC)[reply]
@Hooman Mallahzadeh. I don't quite understand what you propose to do, but if it can solve the problem, please do it! Thank you. --Sapphorain (talk) 13:00, 30 November 2025 (UTC)[reply]

@Sapphorain: I mean the second and third maps of this switcher element are validators of the first unreliable map:

Map
Tehran is located in Iran
TehranHHH
Tehran
Tehran in Iran
Tehran is located in Asia
TehranHHH
Tehran
Tehran in Asia
Map
Map

And we ask users to provide map validators for OSM maps. Do you agree? Thanks, Hooman Mallahzadeh (talk) 13:08, 30 November 2025 (UTC)[reply]

Thank you very much for your involvement Hooman Mallahzadeh. This would be better than nothing of course. But if the main issue is about borders (or other labels), if the first map appearing in the infobox shows the challenged labels whereas the validators don't show any label, this will not solve the problem. It would be better if the first map appearing in the infobox contained no labels of any sort. In fact it would be even better if all imported maps were satellite maps without any added on potentially subjective labels.--Sapphorain (talk) 21:02, 30 November 2025 (UTC)[reply]
@Sapphorain - The boundaries uploaded at OSM have their sources named. I have also checked the Swiss federal geoportal site at https://map.geo.admin.ch - the municipalities boundaries are reflective of what is at OSM, namely that they extend into the lake. Where are you understanding that the boundaries should follow the coastline. Regs, The Equalizer (talk) 10:47, 1 December 2025 (UTC)[reply]
@The Equalizer Once again, for the Canton of Geneva this is specified by the « Constitution de la République et Canton de Genève (art. 159 al.2) ["Sous réserve des droits privés valablement constitués, le lac, les cours d’eau, les nappes d’eau principales et profondes, tels que définis par la loi, sont des biens du domaine public et doivent être sauvegardés"] and by the « Loi sur les eaux (LEaux-GE) (art. 3 al. 4) ["Les dispositions de la présente loi s'appliquent au lac"] and 5 al. 2 ["Les tronçons des cours d'eau formant frontière nationale et les nappes d'eau souterraine principales et profondes font partie du domaine public cantonal"] ». There are similar specifications for the cantons of Vaud and Valais but I didn't look them up. The portions of the lake belonging to the Canton of Geneva are under the direct jurisdiction of the canton, and don't belong to any particular smaller municipality.--Sapphorain (talk) 15:35, 1 December 2025 (UTC)[reply]
If there is a separate arrangement for management of the lake with higher level authorities that wouldn't be reflected in the map as it only shows the boundary of the municipalities and cantons separately. Those responsibilities aren't typically mapped as primary boundaries.
In the UK multiple 1st tier 'parishes' handle basic functions (gardens, bus shelters etc), the 2nd and 3rd tiers municipalities (districts and counties) cover higher level and more strategic responsibilities and a physically wider area across such as environmental matters (including bodies of water), trunk road upkeep, building code etc.
Therefore, a Swiss 1st tier municipality might cover a certain type of land area, they ultimately have no say with how it is managed - it is normally accepted that the canton area covers that responsibility (see Municipalities of Switzerland#Structure and responsibilities) and the Water Law you quote reads as such to me. Regs, The Equalizer (talk) 16:46, 1 December 2025 (UTC)[reply]
I think you didn’t read correctly. « Les tronçons des cours d’eau formant frontière nationale […] font partie du domaine public cantonal ». And « Les dispositions de la présente loi s’appliquent au lac ». This means a municipal boundary cannot possibly extend within the lake (i.e., not even as a « secondary » boundary), if the municipality is located on its shore, simply because the portion of the lake belonging to the canton of Geneva is limited by a national boundary (with France). And because the portions of watercourses and of the lake limited by a national boundary « belong to the cantonal public domain ». This is not contradicted by the Wikipedia section for which you provide a link, which by the way is rather vague and not backed by any inline source. (And there certainly is no possible comparison with UK municipal boundaries, which never coincide with a national boundary…).--Sapphorain (talk) 23:03, 1 December 2025 (UTC)[reply]
Those legislative quotes mean nothing until formally logged at, maps updated at, and shape files provided by the Swiss national mapping authority which when uploaded to OSM will update here. I recommend it is taken up with this authority, if it is such a fundamental mistake they will update it quickly...
But I doubt it as the mapping link I gave earlier clearly showed the Céligny municipality exclaves as part of the Geneva canton into the lake. Until then no maps should be updated and certainly shouldn't be adding validations to maps here @Hooman Mallahzadeh - it should be done at the OSM end, which as said before has the Swiss authority referenced. Regs, The Equalizer (talk) 02:38, 2 December 2025 (UTC)[reply]
Céligny is particular, as it is one single isolated municipality surrounded by the canton of Vaud. So of course there is an extension of the municipal borders within the lake, which as soon as in the lake are not anymore here in order to indicate the limits of the municipality, but the limits of the cantonal domain (of the canton of Geneva).
The laws specifying cantonal and municipal jurisdictions and borders are cantonal, and cartography/topography is federal. I’ve checked on their (paper) printed map I own, and even those with 1:25 000 resolution show nothing else than the national and cantonal borders on the surface of the lake, which is correct.
Anyway, I give up. I am not going to spend more time on this. So the infoboxes will contain both the incorrect maps automatically imported, and reliable references to the cantonal laws from which the correct maps could and should be drawn. This is rather clumsy but better than nothing.--Sapphorain (talk) 15:27, 2 December 2025 (UTC)[reply]

Testing Template:MergedMap

[edit]

@Joy@The Equalizer@Zackmann08 Hi, and sorry for pinging again. After about one week of testing Template:MergedMap, I created a sandbox version of Infobox settlement in Template:Infobox settlement/sandbox which has this code: 

| data27 = {{MergedMap|{{{mapQuery|}}}| mapframe-marker = {{{mapframe-marker|town}}}|customMap1 = {{{customMap1|}}}}}

It is tested successfully in Sadra, Fars article.

It works by only one line of mapQuery argument, i.e., 

| mapQuery = Iran#OSM

If it is good, please apply that to start Infobox testing process of this template. Thanks. Hooman Mallahzadeh (talk) 08:43, 3 December 2025 (UTC)[reply]

I don't think we should use it here until the basic implementation questions have been resolved at Template talk:MergedMap, such as the query label format. It's bad enough that changing the labels will already break a few articles that already use it, we should not make it even worse. --Joy (talk) 09:39, 3 December 2025 (UTC)[reply]
@Joy Ok. Thank you for your response. I propose to create a "request for comment" for deciding about labels of this template. I am ready to implement final decisions. I think merging maps is such a good idea that should be implemented as soon as possible. Nowadays, many of existing infobox of articles have 2 maps (both OSM and pushpin) which is not good at all and makes infoboxes ugly. Thanks again. Hooman Mallahzadeh (talk) 09:50, 3 December 2025 (UTC)[reply]
They've been like that for decades, let's make sure we do things right before we commit too many volunteer hours to it :) --Joy (talk) 10:00, 3 December 2025 (UTC)[reply]
Ok. I think, these decision should be made:
  1. Template name
  2. Label for OSM map
  3. Lable for pushpin map
  4. Lable for satellite map
  5. Label for jpg map
I think using more than 4 maps in infobox radio button is not rationale. So these decisions also should be made:
  1. Number maps and Type of maps
  2. Order of maps (Which one should be the first one and so on)
Thanks agian. Hooman Mallahzadeh (talk) 10:07, 3 December 2025 (UTC)[reply]
User:Hooman Mallahzadeh I want to be careful here because I do not want to WP:BITE...
I will reiterate what I have told you previously, I think what you are working on is a wonderful idea that has a lot of potential, but you are moving too fast. This is NOT ready for the most used Infobox on the English Wikipedia...
I speak with major experience here. When I recently wrote Module:Person date, the LAST infobox I added it to was {{Infobox person}}, not the first.
I get and understand the inclination to push forward code that you think is an improvement but you need to start small and build. I flat out guarantee you that when you insert this into the first few infoboxes you are going to find bugs and areas for improvement. You want that to happen with an infobox with as few uses as possible. Not {{Infobox settlement}} with well over half a million.
I don't have time to give specific feedback for your code right now (I will do my best to later today as I do have a few thoughts) but my STRONG advice to you is to find an infobox with fewer than 100 uses and start there instead of here.
Again, I like what you are doing and will reiterate that I think it has great potential... But also to be clear, I will object to an insertion of this to {{Infobox settlement}} at this point. Zackmann (Talk to me/What I been doing) 16:29, 3 December 2025 (UTC)[reply]
Thanks for your response. Certainly after consensus about its labels, I will start from small ones, and I will inform you about results. Best regards. Hooman Mallahzadeh (talk) 16:51, 3 December 2025 (UTC)[reply]
Good plan. I'll give more specific feedback tonight when I'm off work. Again, keep up the good work. Don't let the feedback get you down, keep chugging away and feel free to continue to ping me with updates. Zackmann (Talk to me/What I been doing) 16:55, 3 December 2025 (UTC)[reply]

Capital distance measure

[edit]

@Zackmann08, @Joy, @Redrose64 and any other interested parties:

Off the back of the UK place infobox talk and the continued discussion above with adding distances to the infobox, I thought best to open a new section to flesh this out some more. I have created a demo template which when placed on a place (or general location) page can generate an automated approximate distance from it to its country capital. It can be tested in preview mode without saving a page, but I have also provided an optional parameter to customise the place by using the Wikidata ID so it can be tried out in a sandbox. The template does need coordinates in WD for the page.

{{User:The Equalizer/sandbox/Template:Capital Distance}}

can be used standalone on a page. Adding |qid=Q100 for Boston

{{User:The Equalizer/sandbox/Template:Capital Distance | qid=Q100}}

creates this output:

-->

Article - Boston

Capital - Washington, D.C.

Country - United States

Distance from article place to capital: 390 miles (634 km)

-->

Let me know if this has some merit for further development.

Regs, The Equalizer (talk) 02:35, 4 December 2025 (UTC)[reply]

So while I applaud the effort, I respectfully, don't see the use for this. As I have stated elsewhere, if I am looking at the article for Boston (using your example), I really don't care how far it is from the Washington D.C.. This tells me nothing of note about Boston and certainly nothing that I feel belongs in the infobox, and that is the key point here. Now if you were to convert this into an inline type template that could produce a sentence like: "Boston is located 390 miles (634 km) NNE of Washington D.C." that is an entirely different discussion. Not sure how useful that would be, but I certainly would not object to it being used in articles.
At the moment, I maintain my objection that this information does not belong in the infobox. If my goal of logging on to the internet is to find out "how far city X is from its nation's capital", I'm not turning to an encyclopedia. I'm turning to either Google or ChatGPT/Siri/Alexa/etc. Now looking at the Infobox for Boston or "Tiny Town in middle of Wisconsin" I may well want to know where the heck it is... But that is what the Mapframe/Pushpin Map is for. Telling me that it is 390 miles from DC doesn't really tell me anything of use other than how far from the capital it is. It doesn't help me understand where in the world it is in any real way. I still don't understand the use case for how it helps anyone understand where a place is by saying it's X miles/km from another city, even if that city is the capital.
Maybe it would be useful for small countries? But when you start looking at the distance of Sacramento, CA from Washington, the distance between cities in Russia, India, Australia, Argentina, etc. I just don't see how knowing you are hundreds or thousands of miles from a city helps anyone with anything besides that specific trivia fact that is so much easier to obtain with a Google/AI query. Zackmann (Talk to me/What I been doing) 03:01, 4 December 2025 (UTC)[reply]
It's completely fine if you don't care how far it is from somewhere. You just have to fathom that in the body of readers of an article like Boston, which is... 130 thousand people a month, there are some readers who do care for that and consider this key information that tells them something important about Boston. --Joy (talk) 11:42, 4 December 2025 (UTC)[reply]
Virtually nobody needs this feature. From MOS:INFOBOXPURPOSE: The less information that an infobox contains, the more effectively it serves its purpose, allowing readers to identify key facts at a glance. Does any encyclopedia, atlas, or other reference work about places prominently state each place's distance from a capital? Joe vom Titan (talk) 17:06, 6 December 2025 (UTC)[reply]
So, you speak for everybody? :) The first thing that popped into my mind was to check what does the Britannica say about Perth. At https://www.britannica.com/place/Perth-Western-Australia there's no infobox, but there is a map with a scale immediately next to the first paragraph. The first mention of distances is in the second paragraph, where it says It was linked to Adelaide (in South Australia) by telegraph in 1877 and received strong impetus for growth from the discovery (1890) of gold at Coolgardie-Kalgoorlie (374 miles [602 km] east). Compared to noting the distance to Coolgardie-Kalgoorlie exact to a mile/kilometer (!), I think listing general distances to other major places is entirely mundane. --Joy (talk) 19:25, 6 December 2025 (UTC)[reply]
I then checked Boston there. Same thing about the map and scale. This one showed me "Top Questions" between the heading and the first paragraph, and the #2 item is "Where is Boston located in the United States". Sadly the AI answer didn't list distances, just directions (northeastern). The third paragraph is after the "Landscape" heading, where it goes into a large amount of detail about the geographical location. --Joy (talk) 19:32, 6 December 2025 (UTC)[reply]
So for use in an infobox, we could just use the variables 2 and 4 from your draft?
For example, the Perth article now has these parameters:
:| dist4 = 3632 :| dir4 = WNW :| location4 = [[Canberra]]<ref name="Distance"/> :
This could be changed to have the value of location4 looked up by a prospective {{geographic distance|capital|name}} call?
And the value of dist4 could be looked up by a prospective {{geographic distance|capital|value}} call?
That seems quite useful already.
It could also be further integrated into infobox syntax if the template would provide a prospective syntax such as:
{{geographic distance|capital|nameandvalue|WNW|of}}
which would then show some sort of a simple, standard rendering like "$distance $3 $4 $name"? --Joy (talk) 11:40, 4 December 2025 (UTC)[reply]
Also, obviously, if we could have argument $1 of the prospective {{geographic distance}} template parsed for a special string like capital but also for an arbitrary string, which could be looked up as a Wikidata entry name of some type, then this would allow for distances to other major points of interest as well (and in the case of Perth, we could use it to replace the hardcoded values for Adelaide, Brisbane, Melbourne and Sydney, too). --Joy (talk) 11:45, 4 December 2025 (UTC)[reply]
Problem with Perth is that it is using the Infobox Aus Place so the template pulling in distances for all the main cities would have to be customised. I like the passing of the cardinal into the template to allow it to show. The text certainly is adjustable, my solution was just to prove the distance from the capital could be obtained with automation using very little coding efforts from a template editor as Zackm was reluctant to have to code it in with the UK infobox migration, how we integrate with the infobox would have to be determined once we get a consensus. Regs, The Equalizer (talk) 13:36, 4 December 2025 (UTC)[reply]
Oh, we're in agreement there. I just mean there's many ways to integrate this functionality at various points of rendering infoboxes. It can happen in the articles calling the infoboxes, in the wrappers, or in the infobox settlement, depending on circumstances and consensus about where it's best. --Joy (talk) 14:05, 4 December 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_settlement&oldid=1326042661"