Infobox mapframe is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Wikipedia. If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.Geographical coordinatesWikipedia:WikiProject Geographical coordinatesTemplate:WikiProject Geographical coordinatesGeographical coordinates
This template is within the scope of WikiProject Geography, a collaborative effort to improve the coverage of geography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.GeographyWikipedia:WikiProject GeographyTemplate:WikiProject Geographygeography
Q1: Where to file a bug report when there is a problem with the base map? (e.g. a missing lake)
A1: If the problem also occurs on OpenStreetMap, it needs to be fixed there. If the problem is only on Wikimedia's maps, it can be reported on Phabricator (you can log in with you Wikipedia account). See mw:How to report a bug for instructions (for the tags, use Maps). (Alternatively, you can try mw:Help talk:Extension:Kartographer)
Q2: Where to report other bugs or problems with the maps?
A2: This may be a problem with the Wikipedia module, or it may be an underlying software bug (there are lots of those).
If the problem also occurs when using plain <mapframe>...</mapframe> tags, then it should be reported on Phabricator (you can log in with you Wikipedia account). See mw:How to report a bug for instructions (for the tags, use Maps). (Alternatively, you can try mw:Help talk:Extension:Kartographer)
If the problem only occurs with Wikipedia's template/module, or you're not sure, report it here. (Alternatively, you can try Wikipedia:Village pump (technical))
Q3: Why does the thumbnail map render as a static image when viewing pages, but is interactive when editing pages?
A3: On Wikipedia, and most wikis other than Wikivoyage, the emdeded thumbnail is a static map, and the full screen map needs to be opened before the map can be zoomed or panned. This is for for performance reasons, and to present some content if javascript is disabled, and for printing. That preview mode shows an interactive map is a bug, phab:T203863 (and also a performance issue). Further explanation can be found in the comments on phab:T202793.
Q4: Why is a line or shape feature from OpenStreetMap not being shown?
Only certain OSM relations (those with type=multipolygon, type=route, type=waterway and type=boundary) can be used, and not others like buildings and public transport master routes. See mw:Help:Extension:Kartographer/OSM#Limitation and phab:T156433.
It can take 1 or 2 days after tagging on OSM before the data is available here.
Wikimedia occasionally has problems replicating OSM data (e.g. phab:T218097), or intentionally disables replication due to other problems (e.g. phab:T243609)
Q5: Why are line, shape, or point features are not shown after editing or adding a map, even though they were shown in the page preview?
A5: This is a bug related to generating thumbnail map images. It should fix itself in an hour or two. See phab:T269984 for details.
Q6: A page using mapframe's |raw= parameter (within the |mapframe-custom= parameter of an infobox that uses Module:Infobox mapframe) is showing error messages of "The time allocated for running scripts has expired." What can be done?
A6: If the amount of raw data to be processed is too large, that timeout message may be shown. You can try moving the raw data to Commons (example) or replacing the mapframe template with the equivalent wikitext using Special:ExpandTemplates (example)
This page has archives. Sections older than 365 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present.
No access to wikidata?
Is it possible to use this template on a MediaWiki install with no access to wikidata? I attempted to do it by specifying coordinates in the coord parameter but I still get Lua error in Module:Infobox_mapframe at line 185: attempt to index field ‘wikibase’ (a nil value). Redheadkelly (talk) 07:29, 17 February 2024 (UTC)[reply]
Thanks for your reply. I've been busy with other things. I think this extension is to add Wikibase to my install of Mediawiki, which I do not want to do. I'm using Semantic MediaWiki. But I do copy templates & modules from Wikipedia and many of them contain code that queries Wikibase. Sometimes it's easy to rewrite them so that it's not an issue, but sometimes it's not. If this extension gives me the ability to contact the same Wikibase that Wikipedia is using, that's great. But I do see that it does that. Do I have this right? Redheadkelly (talk) 20:58, 14 May 2024 (UTC)[reply]
You are using the embedded parameter in the mountain template to add the mapframe, but it is a bit of a hack to directly add a caption like that. A full integration which creates an automatic map and allows the caption parameter would need the mountain template editing by a template editor - the full way to do this is described here: Module:Infobox mapframe. Regards, The Equalizer (talk) 22:46, 14 July 2024 (UTC)[reply]
New bug for masking in preview and full screen modes
For anyone else reading, there's a followup there still about how to format the default zoom, and some Lua error. --Joy (talk) 08:30, 2 October 2024 (UTC)[reply]
Use Infobox dim to compute zoom?
In the sandbox, I changed Module:Infobox mapframe/sandbox at line 216 so that it calls _zoom from Module:Infobox dim to compute the zoom level from an object size. By default, they produce almost the same results (difference in pre-rounded zoom level of about .07, due to slightly different assumptions). The benefit of using Infobox dim._zoom is that it uses the size of the mapframe to compute the zoom. Infobox dim._zoom selects the zoom level so that the object lies fully within the map. If the frame is larger (in pixels), then a higher zoom level is selected.
Often times the passing of dimensions into the template is beneficial, but I've seen some cases where it's actually worse than the default, like Colbert River, which is zoomed in too much based on dimensions. --Joy (talk) 15:08, 12 November 2024 (UTC)[reply]
Not scientific, but measuring the length of the river as the crow flies using two freely map sources gives a length of at least 15km between source and mouth not even taking into account the meanders, so why 12.6 is stated I don't know, it needs challenging and a citation. Adding that adjusted length into the infobox sets the map to an expected zoom showing the full length of the course. Regs, The Equalizer (talk) 23:26, 12 November 2024 (UTC)[reply]
Not quite. The river template takes the length of the object and feeds that to the length parameter for the map. It doesn't take the river length parameter though, only length_mi or length_km. If it can't determine the length because it contains words, convert template included, length used etc, then it defaults to zoom level 10. You can then either use the zoom parameter of course, or use | mapframe-length_km = or | mapframe-length_mi = . Regs, The Equalizer (talk) 16:26, 30 November 2024 (UTC)[reply]
@Joy instead of recoding, couldn't we just add a note to length* parameters of the infobox river template that the mapframe-length* parameters should ideally be additionally populated with the straight line length so that the maps display properly (or use the zoom parameter). Regs, The Equalizer (talk) 11:51, 3 December 2024 (UTC)[reply]
I don't know if straight line length is a parameter typically found in sources for rivers, I never saw it myself. At the same time, now that I think about it, what happens if a river is also generally U-shaped or L-shaped, which happens reasonably often - do we still call this "straight line length", or is it actually just some sort of an approximation... maybe in those cases it would make sense to tune the basin size, at the same time I don't know the logic, does length_km2 take precedence over basin_size_km2 when deciding on zoom? --Joy (talk) 13:56, 3 December 2024 (UTC)[reply]
showing two extra relations in addition to the wikidata-attached main one
At Talk:Indus River#map frame map, @Fowler&fowler has noticed that the OSM relation for that river does not choose either of the two main headstreams, and therefore our mapframe map shows neither. Is there a syntax to add two more relations to an infobox mapframe map?
Would we be able to e.g. supply a list of two more wikidata Q* items as geomask, or something like that? The geomask example shows a shape that that envelops another shape and there's a shading, which wouldn't seem appropriate in the case of lines, so I'm not sure what to do. --Joy (talk) 23:25, 27 November 2024 (UTC)[reply]
Thanks. I wasn't aware of this, and I went to check the documentation, but couldn't find anything about it. The template doc still says: This template only works with single features (points, lines, or shapes); use {{maplink}} if more advanced options, such as displaying multiple features, are required. - so that seems quite misleading...
How do I set the mapframe width to the reader's thumb size preference?
From the documentation, it appears that the |width= of the mapframe image is specified in pixels, but per MOS:IMGSIZE, Except with very good reason, a fixed width in pixels (e.g. 17px) should not be specified, because it ignores the user's base width setting. Thus upright=scaling factor is preferred when it is desired to present an image at other than the default width. How do I set the mapframe size to match the reader's thumb size preference, as recommended by MOS? – Jonesey95 (talk) 04:40, 12 March 2025 (UTC)[reply]
Thanks for the link, but that did not help me. Also, the mapframe map is not the lead image in any infobox that I know of. Maybe I'm dense. Can you please link to an example of a page with the mapframe map specified to display at thumb size or a multiple thereof? – Jonesey95 (talk) 23:40, 12 March 2025 (UTC)[reply]
Just set it to 220px and then 250px once T355914 is done - it is currently underway and will change the default thumb size. There are two reasons why looking up that thumb size is not worth it. One is that people do actually not change it from the default. To quote DBA/SRE members of the WMF "In other words, 98.9% of users are using the default and the second most popular one is 0.33%." The other reason is that default thumb sizes, apart for the change allready mentioned, has not changed for over a decade. And no, there is not a lua function to look up this thumb size for the current user. Snævar (talk) 02:04, 15 March 2025 (UTC)[reply]
The context of MOS:IMGSIZE is clearly about stand-alone images, not ones in infoboxes. To have uniformly formatted infoboxes should be the standard. -- P 1 9 9✉18:04, 14 March 2025 (UTC)[reply]
I agree that a uniform image width should be the standard, which is why WP:IMGSIZELEAD mentions the upright parameter instead of explaining how to use pixel sizing. I am asking how to set a mapframe map to match the reader's standard thumb size preference. MOS:IMGSIZE refers to the size of a "lead image". MOS:LEADIMAGE, on the same page, explains the lead image like this: It is common for an article's lead or infobox to carry a representative image. Module:InfoboxImage, which is commonly used to display lead images in infoboxes, has frameless and upright options, which allow lead images in infoboxes to comply with both MOS:IMGSIZE and with readers' preferences. So how do we follow this standard for mapframe maps in infoboxes so that they match the infobox's lead image size? – Jonesey95 (talk) 19:27, 14 March 2025 (UTC)[reply]
Apologies that link I gave was just for images. It doesn't look like you can for the map frame. There is no upright parameter in Module:Mapframe & Module:Infobox mapframe, the width and height settings are fixed default numbers, which are the size of the displayed frame only and of course has no effect on the map scale (zoom parameter does that), while images use px size as of course you can't adjust width/height independently. The Equalizer (talk) 21:41, 14 March 2025 (UTC)[reply]
The usages are not the same. The article uses {{Infobox mapframe}} inside of the |image_map= parameter. The test case uses mapframe parameters directly. If you edit that test case, you should see red error messages explaining that many of the parameters used there are not supported. That's why those parameters are not doing anything. – Jonesey95 (talk) 15:47, 20 March 2025 (UTC)[reply]
Because mapframe was not incorporated into the military infobox template - see the table at Wikipedia:Mapframe maps in infoboxes. Some of the test cases have mapframe maps because they are subtemplating the infobox airport template which does pull in a map. However, it works on the article because mapframe is used as a subtemplate within the infobox. The Equalizer (talk) 15:48, 20 March 2025 (UTC)[reply]
Ok - fixed by using alt parameters in the sandbox. All the test cases are working well. Bear in mind that the mapframe map appears with some cases showing 'pushpin' maps - that's because those aren't actually using the parameter to display it. Your Rmanj Fortress example has a pushpin but forces the mapframe so that too is fine. The cases with airplane infoboxes should also be fine to leave. Sandbox2 will need updating though. Also, one case is showing an lua error but that is by design because it's deliberately using blank parameters. Regs, The Equalizer (talk) 01:28, 21 March 2025 (UTC)[reply]
Thanks. Why would image4 work, but not image5? I previously had a problem where I had too big of a jump between the numbers, but this is directly after and still unsupported. This seems counter-intuitive, arbitrary.
The other cases not showing are fine, that is always what I do, this way is more conservative (if there's already a map, don't touch anything).
I noticed on a few occasions that we render maps of subterranean rivers properly, so a relation doesn't have to be continuous, which is great. I then also found a weird case of Talk:Guanipa River where half the data in the middle of the river flow is just missing, and I don't think it's subterranean, but rather nobody mapped it, probably because of cloud cover in the satellite imagery. However, I couldn't connect the two mapped parts because the web editor zoom settings didn't seem to allow it. Perhaps someone could check that out with a different OSM editor? TIA. --Joy (talk) 17:19, 30 March 2025 (UTC)[reply]
Correct, the last editor only mapped the visible section, it's heavily forested and even some commercial map services don't have it fully plotted. Wouldn't use the online OSM ID editor as it is limited although had no issue adding points with it, use the apps instead as per mw:Help:Extension:Kartographer/OSM#Create a new relation. It makes more sense to create a way which joins the existing waterways and then add it to the relation. There is an OSM project at WikiProject Rivers of South America. Regs, The Equalizer (talk) 19:01, 31 March 2025 (UTC)[reply]
