Template talk:Infobox mapframe/Archive 1
This is an archive of past discussions about Template:Infobox mapframe. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Individual coordinate parameters are not allowed in Infobox templates
Please adjust this template to use |coordinates=
instead of individual latitude and longitude parameters, per this RFC. See also Wikipedia:Coordinates in infoboxes. – Jonesey95 (talk) 12:53, 1 January 2019 (UTC)
- This really needs to be fixed upstream in Module:Mapframe / {{Maplink}} first, since this passes parameters through to that module. (And the parameter name should really be
|frame-coordinates=
, for consistency with frame parameters using the frame- prefix). - Evad37 [talk] 13:24, 1 January 2019 (UTC)- The documentation for {{Maplink}} says
If frame latitude and longitude are not set by parameters, then coordinates in |coord= will be used (if set), or coordinates will be retrieved from Wikidata (if available, for either the item specified in |id= parameter or for the page the template is placed on)
. Module:Mapframe already takes the parameter|coord=
. It looks like coordinates are already supported by the upstream templates. – Jonesey95 (talk) 14:13, 1 January 2019 (UTC)- The
|coord=
parameter is for adding a point feature to be shown on the map, and so won't work here where we just want to adjust the initial placement of the map (not add another point). - Evad37 [talk] 14:41, 1 January 2019 (UTC)- Then why does the {{Maplink}} documentation say
If frame latitude and longitude are not set by parameters, then coordinates in |coord= will be used (if set)
? That looks pretty clear to me. Perhaps that documentation is not quite correct. – Jonesey95 (talk) 14:47, 1 January 2019 (UTC)- The main purpose of
|coord=
is to add a point feature to the map. Frame coordinates can be automatically determined from that point, but if a user wants a different, custom frame coordinates (WITHOUT adding a new point feature), they have to be specified in|frame-lat=
or|frame-long=
, or now|frame-coord=
since I've updated Module:Mapframe (or aliases of these parameters). - Evad37 [talk] 15:34, 1 January 2019 (UTC) - I've adjusted the documentation [1]; does that clarify things? - Evad37 [talk] 15:44, 1 January 2019 (UTC)
- The main purpose of
- Then why does the {{Maplink}} documentation say
- The
- Also, since this is a template for use in infoboxes, the correct parameter name per the RFC is
|coordinates=
. – Jonesey95 (talk) 14:30, 1 January 2019 (UTC)- This isn't a parameter for displaying a point though, and having it be different to {{maplink}} just seems confusing - Evad37 [talk] 14:41, 1 January 2019 (UTC)
- We can have an alias of "coord", but "coordinates" must be supported for all infobox templates that use coordinates, per the RFC. – Jonesey95 (talk) 14:44, 1 January 2019 (UTC)
- This template is a bit different to those considered by the RFC, since the coordinates are not those of the actual page subject itself, just some convenient point so that the initial display of the dynamic map looks better. Consistency with the other template that generates
<mapframe>
maps seems like it would reduce confusion – i.e. wouldn't a user expect that a plain|coordinates=
parameter to be for the point displayed on the map (as in other infobox coordinate templates), rather than where the map centre point is located? - Evad37 [talk] 15:04, 1 January 2019 (UTC)- Is there a page of test cases showing the difference between how coordinates work in this template versus how it would work in a normal infobox map? I looked at the existing testcases page, but the difference is not clear to me. Thanks for working with me to try to make this template work in a way that both makes sense and conforms with the Infobox coordinates-related RFC. I think we have made good progress so far. – Jonesey95 (talk) 17:17, 1 January 2019 (UTC)
- This template is a bit different to those considered by the RFC, since the coordinates are not those of the actual page subject itself, just some convenient point so that the initial display of the dynamic map looks better. Consistency with the other template that generates
- We can have an alias of "coord", but "coordinates" must be supported for all infobox templates that use coordinates, per the RFC. – Jonesey95 (talk) 14:44, 1 January 2019 (UTC)
- This isn't a parameter for displaying a point though, and having it be different to {{maplink}} just seems confusing - Evad37 [talk] 14:41, 1 January 2019 (UTC)
- The documentation for {{Maplink}} says
Here are some examples (you can move them to another page if you want).
For a standard location map, the coords passed in define the marker shown on the map, e.g.
{{Location map|Australia Melbourne |coordinates={{coord|37|48|38.5|S|144|57|56.5|E}} }}
For {{infobox mapframe}}, the coords passed in are for the centre point of the map frame, and the coords for the marker (37°48'38.5"S, 144°57'56.5"E) come from Wikidata
{{infobox mapframe|id=Q7270550|frame-coord={{Coord|38|0|S|144|52|E}}|zoom=8}}
For a {{maplink}} map, you get to define both the coords for both the marker and the (initial) centre point of the map frame, e.g.
{{maplink|frame=yes|plain=yes|type=point|coord={{coord|37|48|38.5|S|144|57|56.5|E}}|frame-coord={{Coord|38|0|S|144|52|E}}|zoom=8}}
For both {{maplink}} and {{infobox mapframe}}, if you don't specify coordinates for the frame, then the centre point of the map frame will be determined automatically:
{{maplink|frame=yes|plain=yes|type=point|coord={{coord|37|48|38.5|S|144|57|56.5|E}}|zoom=8}} {{infobox mapframe|id=Q7270550|zoom=8}}
- Evad37 [talk] 17:56, 1 January 2019 (UTC)
- Thanks for posting these. The more I think about it, the more it seems to me that
|coordinates=
/|coord=
should not be used for the alignment or display of the frame, which is probably what you have been trying to tell me. I think|frame-coordinates=
should be used for alignment/display, and I think it would be good to deprecate and remove frame-lat/frame-long. If it is ever supported,|coordinates=
should be used to override the wikidata values for the latitude and longitude of the point being displayed.
- It's OK with me if you remove those two parameters from the module and the documentation, and perhaps add a comment in the module to the effect that those two parameter names are reserved for override values, if they are ever added to the module. – Jonesey95 (talk) 17:27, 2 January 2019 (UTC)
Parameter disabling the display of OSM relation borders?
Is there a parameter that allows us to disable the display of the OSM relation borders even though the said relation ID is saved in the Wikidata item? This will allow us to avoid displaying inaccurate/erroneous relation borders. —Sanglahi86 (talk) 06:34, 4 February 2019 (UTC)
- @Sanglahi86: I don't think this is currently possible. Wouldn't it be better to fix the data in OSM, if you know that it's incorrect? Also, with which articles are you having this issue? Jc86035 (talk) 10:08, 4 February 2019 (UTC)
- @Jc86035: I am trying to add the OSM map to Cebu City. Its Wikidata item does not have an
OSM relation ID
statement, but strangely shows a large border covering the entire Cebu province:
- @Jc86035: I am trying to add the OSM map to Cebu City. Its Wikidata item does not have an
I do not know which is causing it, but later discovered that the borders of the Cebu City relation in OSM should be for (and is currently a duplicate of) Cebu province. I am not familiar with the intricacies of OSM relations, and I might break something if I merely delete the Cebu City relation. Could you kindly look into this? Thanks. —Sanglahi86 (talk) 23:05, 4 February 2019 (UTC)
- @Sanglahi86: The relation doesn't seem to have anything dependent on it (and is clearly erroneous anyway), so I've deleted it. Jc86035 (talk) 05:22, 5 February 2019 (UTC)
Zoom to country-level and country boundaries
Hello. I've added mapframe to {{Infobox power station}}, but one of our WikiProject members has raised a valid point. I want to know if it is possible to set the zoom level to country-level (maybe based on P17 or a local parameter, or both), instead of a static number which its usefulness varies greatly depending on which country the article/item relates to.
Also, in addition to the above, another concern is that the mapframe does not clearly distinguish countries for more zoomed out items, as opposed to the older static location maps which show neighbouring countries in a slightly different shade (example). Is it possible to create an option where the mapframe could either change shade or show a border (for the country of subject, not subject itself)? — Preceding unsigned comment added by Rehman (talk • contribs) 08:27, 20 March 2019 (UTC)
- @Rehman: Is
|location_map_zoom=
insufficient for the zoom level? I don't think it would be possible to set "country" level automatically without new Lua code, as well as special handling for exclaves like French Guiana and former countries. (Most other infoboxes with mapframes also use default zoom levels around 13 or 14, whereas {{Infobox power station}} uses a default of 5.) - I think it could be possible to indicate countries using a geoshape (this would also require more Lua code), but this could be visually distracting depending on implementation.
- Is there any particular reason that {{Infobox power station}}'s maps should be different from other mapframes in these ways? Jc86035 (talk) 09:20, 20 March 2019 (UTC)
location_map_zoom
is definitely useful when we need to set the zoom of a particular article. The default zoom is set per the consensus of WikiProject Energy, and hence of course can be changed as needed. As per the concern raised (which I linked above), two reasons for not using mapframe are:- Mapframe does not yet have a way of setting the default zoom to include the outline of a country.
- Mapframe does not yet support highlighting the country in which the marker is in.
- While I personally am happy with how the mapframe is currently, these are valid points raised by the community, that IMHO must be addressed if we wish to see mapframe being the default norm in the future. I believe raising these points here is the best route, as these are feature requests which only promote the replacement of older maps, with mapframe. Rehman 09:57, 20 March 2019 (UTC)
- What you are asking for would be possible with a bit of Lua. I think a geomask would be a good display option, so everything outside of the country is darker. And I think a parameter should specify the relationship property -- e.g. sometimes one might want to use located in the administrative territorial entity (P131) instead of country (P17). Maybe also allow specifying an individual item (Q-number) to use as a geomask - Evad37 [talk] 13:28, 20 March 2019 (UTC)
- Yes, that could work. Now only if someone familiar with the code can take up the task of implementing it :) Rehman 14:20, 20 March 2019 (UTC)
- @Rehman: Done, you can now use
|geomask=
to specify a wikidata item directly (i.e. a Q-number), or via a property (i.e. a P-number, likeP17
for country – this requires the wikidata item for the page to actually have that property specified, but P17 is already very widely used in my experience). Frame coordinates are determined automatically (unless specified by parameter). Zoom level will be determined automatically if the geomask item has an area (P2046) specified (in square kilometers or square miles). - Evad37 [talk] 14:12, 21 March 2019 (UTC)- Thanks Evad37. It seems to function perfectly, but needs a few adjustments (based on a random test on Lam Takhong Dam - replace contents in preview with
{{Infobox power station/sandbox}}
). Your views for/against the below points are welcome:- Comparing with older static location maps, it seems like the border is too thick, and surrounding countries are too dark. Can we adjust that? A 1px line (or maybe even no line) would also do, since the surrounding is darkened anyway.
- Testing the same in other random articles (like this) shows that it is somewhat execcessively zoomed out. I understand that could probably be due to small islands around. Do we have a way of adjusting that? And if not:
- Can we make
geomask=
work withzoom
? It seems like the geomask gets disabled when a manual zoom is stated. - Testing on this article, the border seems to include the offshore boundaries of the country as well. Do we have an option to switch to terrestrial borders, or is this something that we have no control of at this point?
- Thank you for helping. Rehman 06:44, 22 March 2019 (UTC)
- Thanks Evad37. It seems to function perfectly, but needs a few adjustments (based on a random test on Lam Takhong Dam - replace contents in preview with
- @Rehman: Done, you can now use
- Yes, that could work. Now only if someone familiar with the code can take up the task of implementing it :) Rehman 14:20, 20 March 2019 (UTC)
- What you are asking for would be possible with a bit of Lua. I think a geomask would be a good display option, so everything outside of the country is darker. And I think a parameter should specify the relationship property -- e.g. sometimes one might want to use located in the administrative territorial entity (P131) instead of country (P17). Maybe also allow specifying an individual item (Q-number) to use as a geomask - Evad37 [talk] 13:28, 20 March 2019 (UTC)
Thanks for the feedback Rehman.
- Border thickness and colour can be adjusted. Currently this template uses a default of width 2 and colour #555555, but those can be changed to other values. The parameters
|geomask-stroke-width=
and|geomask-stroke-color=
(or|geomask-stroke-colour=
) can also be used to override the default values.
The fill colour for the surrounding area should be adjustable, but I first need to get it working in {{maplink}}/Module:Mapframe (I seem to have overlooked that property when creating the template&module) - Zoom is really tricky, because the map doesn't automatically stet the zoom – the module has to calculate the zoom based on a property like area – which may result in some cases being too zoomed out or too zoomed in if the shape is very irregular (e.g. thin in the middle with bulges at the ends, or if it includes far-off islands) or very regular (e.g. precisely square, or circular).
- I'll look into getting that working – specifying a zoom shouldn't be disabling the geomask
- We can only use features that exist in OpenStreetMap, and are tagged with a wikidata item. If such a feature exists, and is linked to a Wikidata item (which would have to be different from the country item, as each item can only be linked with one OSM feature), then you could set
|geomask=
to that item instead of P17.
- Evad37 [talk] 00:46, 23 March 2019 (UTC)
- @Rehman: Done. Fill colour options added; fixed the zoom (parameter value used if present, otherwise will be automatically calculated from geomask area); adjusted the default style values (which are now declared at the top of the Module:Infobox mapframe code) - Evad37 [talk] 05:01, 23 March 2019 (UTC)
- Many thanks, Evad. It seems to work perfectly. I will message here again if there are any issues not spotted before, or contact you directly if this thread gets archived by then. Again, thank you so much for understanding the importance of these, and helping write the code for these new featured. Best wishes, Rehman 03:17, 26 March 2019 (UTC)
Help
Sorry - I'm too stupid to get this to work on Nostrana (restaurant), which now has a coord. Would someone please make it so, so that I can see what I'm missing. thx. --Tagishsimon (talk) 10:58, 5 April 2019 (UTC)
- @Tagishsimon: The infobox in that article, {{Infobox restaurant}}, does not currently use mapframe maps. If you want mapframe maps, you can see if there's consensus at Template talk:Infobox restaurant, and then I can help with the implementation. - Evad37 [talk] 01:18, 6 April 2019 (UTC)
- @Evad37: Thanks ... and no thanks. I just couldn't figure out why I was getting no map output. Someone else has implemented a more traditional map on that page, so we're good. So am I right in thinking that for an enabled template, simple providing a {{coord}} causes the map to appear? --Tagishsimon (talk) 02:03, 6 April 2019 (UTC)
- It really depends on how the individual template is set up, but in most cases adding coordinates to the article or the linked Wikidata item would make the map appear - Evad37 [talk] 02:25, 6 April 2019 (UTC)
- @Evad37: Thanks ... and no thanks. I just couldn't figure out why I was getting no map output. Someone else has implemented a more traditional map on that page, so we're good. So am I right in thinking that for an enabled template, simple providing a {{coord}} causes the map to appear? --Tagishsimon (talk) 02:03, 6 April 2019 (UTC)
Region boundary not being shown test case
Please help, to get the region boundary displayed. Arjunaraoc (talk) 12:20, 27 April 2019 (UTC)
- The feature on OpenStreetMap is just a single point, https://www.openstreetmap.org/node/2885001475 and not a boundary. - Evad37 [talk] 12:56, 27 April 2019 (UTC)
- I found that Wikidata id in OSM relation is not correct. I have updated it. Hope, the problem will be resolved soon, when the mapdata gets updated in a day.Arjunaraoc (talk) 00:17, 28 April 2019 (UTC)
Default width
Since this module is used in Infobox settlement, which is one of the most widely used templates and which has a default width of 250px, this template should also have a default width of 250px (instead of 270px). Can someone make this change please? Thanks. -- P 1 9 9 ✉ 00:58, 4 May 2019 (UTC)
- Drive-by comment: At {{Infobox power station}}, we set the image width and mapframe width to the same parameter, so that it always stays perfectly synchronised even if the image size is changed. Not too sure how practical it is, but you may want to consider that. Regards, Rehman 01:45, 4 May 2019 (UTC)
- The default is just that, a default. No default value is going to be perfect for every usage. If it isn't working well for a particular infobox, that infobox can specify a different value like {{Infobox power station}} does. - Evad37 [talk] 06:01, 4 May 2019 (UTC)
- The compelling reason to change the default value to 250px is that {{Infobox settlement}} is probably used far more than any other that may use this template. It is hardly practical to add an override value to 100's of thousands of instances of Infobox settlement. On the other hand, if 250px is not working well for say {{Infobox power station}}, it will be a lot less work to add override values. In other words, lets set the default value to a value that will be most common and/or practical. -- P 1 9 9 ✉ 02:54, 6 May 2019 (UTC)
- P199, I think you misunderstood. You can set such a default value, but that should be done at {{Infobox settlement}}, and not here in {{Infobox mapframe}}. Look at the source code of {{Infobox power station}} to better understand how this works. Rehman 15:50, 6 May 2019 (UTC)
- It is not used in the same way: {{Infobox settlement}} itself doesn't call for this template, but it is done at the article, see for example Manila. -- P 1 9 9 ✉ 18:41, 6 May 2019 (UTC)
- Thank you, I hadn't noticed that. Manila uses {{Maplink}}, not {{Infobox mapframe}} which is used only through infobox templates. Anyway, to put is simply, {{Infobox settlement}} must use {{Infobox mapframe}} if you want to set a global default for all Infobox settlement uses. Have you considered doing that? I'm not sure if there are any alternatives, maybe someone else could share some thoughts. Rehman 02:24, 7 May 2019 (UTC)
- It is not used in the same way: {{Infobox settlement}} itself doesn't call for this template, but it is done at the article, see for example Manila. -- P 1 9 9 ✉ 18:41, 6 May 2019 (UTC)
- P199, I think you misunderstood. You can set such a default value, but that should be done at {{Infobox settlement}}, and not here in {{Infobox mapframe}}. Look at the source code of {{Infobox power station}} to better understand how this works. Rehman 15:50, 6 May 2019 (UTC)
- The compelling reason to change the default value to 250px is that {{Infobox settlement}} is probably used far more than any other that may use this template. It is hardly practical to add an override value to 100's of thousands of instances of Infobox settlement. On the other hand, if 250px is not working well for say {{Infobox power station}}, it will be a lot less work to add override values. In other words, lets set the default value to a value that will be most common and/or practical. -- P 1 9 9 ✉ 02:54, 6 May 2019 (UTC)
Garbage tiles at zoom level 9
Outdated documentation?
Template:Infobox mapframe/doc currently says that an OpenStreetMap relation ID (P402) needs to be specified on Wikidata in order for an outline of a feature to be displayed, as opposed to just a marker for a coordinate location. From what I can tell, however, Wikidata items need to be linked from their corresponding OpenStreetMap pages to generate an outline, not the other way around. Plenty of items I've come across—such as Northgate Park (Q65554696)—are able to generate outline maps without an OSM relation ID. Is the documentation outdated or am I just missing something? – Lord Bolingbroke (talk) 16:25, 31 July 2019 (UTC)
- @Lord Bolingbroke: The description refers to the marker, which is separate from the outline. If an OpenStreetMap shape (way/multipolygon/admin_boundary) links to a Wikidata item, the shape is automatically used for the outline, but point features in OSM are not used (...I think). I agree that it would be sensible to make this clearer in the documentation. Jc86035 (talk) 08:21, 3 August 2019 (UTC)
Highlighting a river based on OSM
Hello. I'm trying to use mapframe in an infobox, to highlight entire rivers.
- Template code: Template:Infobox river/sandbox
- Article used to trial: Mahaweli River / Mahaweli River (Q1518007)
- OSM ID: 6232547
But previewing the sandbox on the article does not show anything. What am I missing? Thanks for any help, Rehman 11:05, 9 March 2020 (UTC)
- @Rehman: This is a limitation of mapframe maps, phab:T156433: Only certain OSM relations (those with type=multipolygon, type=route, and type=boundary) can be used, and not others like rivers or other waterways. Evad37 [talk] 12:35, 9 March 2020 (UTC)
- Thanks for the reply, Evad. That is very unfortunate :( Rehman 12:49, 9 March 2020 (UTC)
Bridge outline not showing up on dynamic map
Somehow the outline is not shown on the dynamic map in the article for Saloma Link bridge. I added the Wikidata tags in OSM. Used to work in other instances without a problem, e.g. for the Bicycle Snake. Any ideas what went wrong? Thanks!--Renek78 (talk) 02:18, 15 March 2020 (UTC)
- Sounds like phab:T218097 - Evad37 [talk] 13:21, 15 March 2020 (UTC)
- Thank you, Evad. This ticket is 1 year old already. Hope they are able to fix the issue soon.--Renek78 (talk) 15:36, 15 March 2020 (UTC)
You are invited to join the discussion at Wikipedia:Requests for comment/Mapframe maps in infoboxes. Evad37 [talk] 03:25, 24 June 2020 (UTC)
Another strange error
for some reason, I had to do this to fix the map frame script error? I tried using those coordinates in a direct call to infobox mapframe here, and they work, so no idea what is going on here. Frietjes (talk) 16:21, 20 July 2020 (UTC)
Make default shape fill color/opacity lighter
Currently the fill color for shape or shape-inverse is too dark I think - the map is hardly readable under the fill. I guess the default (at least for standard Maplink template) fill color is black and opacity is 0.5 which results in very dark fill. Many infoboxes are locked for editing and use the this template's default settings. I propose to make the fill lighter - maybe black with 0.25 opacity or even 0.125 opacity?--Kozuch (talk) 11:09, 30 August 2020 (UTC)
Zoom error
The default zoom of Template:Infobox building is supposed to be 13, but when I used it here the zoom was so large I had to change it manually to 14 which was fine. — Martin (MSGJ · talk) 22:13, 13 November 2020 (UTC)
- Never mind. Seems to be working again now — Martin (MSGJ · talk) 12:27, 16 November 2020 (UTC)
New doc page
I have created new docpage Template:Infobox mapframe/doc/parameters/doc to document the ../parameter list. You might be interested to follow it. -DePiep (talk) 16:34, 29 November 2020 (UTC)
Just a pale blue panel displayed intermittently?
Mapframe was embedded in {{infobox station}} a few months back and I've been invoking it at GB stations following a template merge. But intermittently I get just a pale blue panel instead of a map. I see this on Android, Chrome OS and Windows (Chrome and Firefox). Is there a significant issue or is it a transient? I can't provide a reliable test case because sometimes it is evident and sometimes not, but Milton Keynes Central is as good an example as any (and right now it works as it should, so try High Wycombe which doesn't). --John Maynard Friedman (talk) 11:56, 18 November 2020 (UTC)
- I have seen it do that, especially when the edit is first saved, but it always seems to fix itself after a while. One thing I have noticed is that the blue marker dot doesn't always appear on the mini map. G-13114 (talk) 12:50, 18 November 2020 (UTC)
- Yes, just seems to be a transient lag issue. The map is showing ok in all the articles I did in the last couple of days and the station icon is displayed in all but one. Ok, give it time before escalating. --John Maynard Friedman (talk) 20:52, 19 November 2020 (UTC)
- I can confirm this bug and the screenshot shows the issue — Martin (MSGJ · talk) 21:16, 5 December 2020 (UTC)
- @Evad37: please can you look into this because it is still an issue, particularly when the template is used on a new page — Martin (MSGJ · talk) 16:57, 4 March 2021 (UTC)
- Got the same issue in Greenwich Village in Zh, but shows correctly after a few minutes.
- Yes, just seems to be a transient lag issue. The map is showing ok in all the articles I did in the last couple of days and the station icon is displayed in all but one. Ok, give it time before escalating. --John Maynard Friedman (talk) 20:52, 19 November 2020 (UTC)
Minor mystery: mislabeled city on OpenStreetMap at Heritage Plaza
(reposting in part from VPT, where I was unable to get an answer) When I go to Heritage Plaza and look at the Infobox mapframe OpenStreetMap snippet, the city is labeled "Hjuston". I don't know where that errant label lives. The same problem is visible at Spirit of the Confederacy, a nearby sculpture. I have looked at the OpenStreetMap web site and at the Wikidata entry for "Houston", and have come up empty-handed. – Jonesey95 (talk) 15:34, 15 March 2021 (UTC)
An unidentified issue with 8 out of 350 Perth suburbs
I have recently added the OSM maps to the 350 suburbs of Perth (see Category:Suburbs of Perth, Western Australia) after making the necessary links on OSM first where still required (some had already been done earlier by somebody else). This worked very well, except on the 8 suburbs of the City of Bayswater (see Category:Suburbs in the City of Bayswater), where I just end up with the blue screen on the map in edit prefiew and no proper map. Everything on OSM seems ok, as far as I can tell. I'm unable to establish what causes the issue with just those 8 suburbs of one city. Personally, I don't think the issue is on Wikipedia as I have substituted a different "local_map_id =" on the Bayswater, Western Australia article (the one for Hillman, Western Australia) and it displayed the Hillman map correctly. From past experience, raising such on issue on OSM went absolutely nowhere, so I'm wondering if anybody here has any suggestion on how to fix this, wherever the issue lays? Calistemon (talk) 08:24, 22 October 2021 (UTC)
- I had a quick look at Bedford and Morley. Both are OK today (or at least they look ok to me, I'm expecting something that looks like Bedford, England). As per discussion a few months back (above), "the system" seems to take a bit of time to catch up. Has that happened? --John Maynard Friedman (talk) 09:57, 22 October 2021 (UTC)
- I read your post from a few month ago and yes, I have come across this issue, too, where a map on an article looks good in preview, but then only displays when clicking on "Show in full screen". This indeed fixes itself after a little while. The City of Bayswater articles are different, the map never displays, as if the link on OSM to Wikidata did not exist. Calistemon (talk) 12:48, 22 October 2021 (UTC)
Automatic shapes
Hello, pinging @Evad37: who developed Infobox mapframe. Can anyone answer as to why early implementation of mapframe in infoboxes, as seen in this diff here, allows for automatic shapes and points? I cannot get "{{#invoke:Infobox mapframe|auto}}" to automatically or even manually display shapes, like was the case at Greater Columbus Convention Center. ɱ (talk) 14:38, 24 April 2022 (UTC)
Show features from more than one Wikidata item
Hi! I would like to show the position of a dam in the same map as the shape of the reservoir it creates. These are usually in different Wikidata items. Could there be an option like |shape=Q1625606
to specify an additional qid (similar to the geomask option)? — Martin (MSGJ · talk) 06:53, 29 July 2022 (UTC)
Zoom not working when using switcher
The zoom parameter is always set to 1 (zoomed all the way out) when using |switch=auto
. Is there any way to fix it? Xeror (talk) 22:29, 18 September 2022 (UTC)
"type=shape-inverse" title issue
Hello, I recently made a edit that another user found weird. I added a maplink map of Newark, New Jersey to the corresponding Wikipedia pages info box as can be seen here. Their issue with the edit was with the fact that the title (in this case Newark) only can pop up when you click somewhere that is not Newark. While using another shape type would fix this, I think that shape inverse is the best way to show these areas and would like to keep using it for infoboxes. Is there anyway to fix this issue using the code this template already has, or if not could someone pass the word to a editor that can fix the issue for good in the code of the template. The disagreement can be found on my talk page second from the bottom. Monkeylol (talk) 13:47, 30 November 2022 (UTC)
How can we scale the map size to the reader's thumbnail preference?
I see that this template has pixel-based specifications for width and height, but MOS recommends allowing images to scale based on readers' thumbnail preferences. How can we use something like |upright=
to tell this map how large to be? One specific use case is at Template:Infobox bridge/testcases, where we have set the sandbox template to display the main infobox image at |upright=1
, which scales up the image and widens the infobox for readers with thumbnail preferences set to 300px or higher, but the mapframe map currently stays the same width because it is specified at |mapframe-frame-width=250
. I looked through this template's documentation but did not find "upright" anywhere. – Jonesey95 (talk) 04:47, 10 January 2023 (UTC)
- No. Just no. It's a map, not an image. We don't scale up tables and graphs for people. This is getting silly. And a wider map is not a better map, same as how a wider graph is not a better graph. We choose carefully how to present data; this sort of user scaling would significantly mess with that and not help them any. ɱ (talk) 05:06, 10 January 2023 (UTC)
Problem with id= and infobox bridge
@Evad37 and Jonesey95: if you check this version of St. Paul Union Pacific Vertical-lift Rail Bridge you will see a Failed to serialize data. error. I was able to trace this to |id=L332
in the infobox, which is the bridge id, not the qid. as a temporary work around, I prefixed the id with <nowiki>...</nowiki>
here, but there are actually over 500 pages in the temporary tracking category, Category:Pages using infobox bridge with id. I am not sure why St. Paul Union Pacific Vertical-lift Rail Bridge was the only one that was showing up in Category:Pages with script errors. I would think it would be a good idea to be able to disable the automatic use of |id=
in Module:Infobox mapframe if some parameter were set? Frietjes (talk) 15:20, 20 July 2020 (UTC)
- The infobox mapframe module should accept only parameter names that begin with
mapframe
.|id=
and|qid=
should be deprecated. Infoboxes sometimes use those parameters for their own purposes. – Jonesey95 (talk) 21:01, 23 January 2023 (UTC)
Template-protected edit request on 4 April 2023 (add switcher functionality)
This edit request to Module:Infobox mapframe has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Is there a way to add a functionality of this template to do what Lisbon map looks now: recursively show larger area and automatically zoom and center? I currently do it manually. Xeror (talk) 05:43, 5 April 2023 (UTC)
- Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. – Jonesey95 (talk) 12:22, 6 April 2023 (UTC)
- @Jonesey95: Specifically, when using the
|switcher=auto
option, the following changes are desired:- Zoom levels are currently always set to 1 in the preview. They should be zoomed to show the geomask boundary for each switch.
- A switch only showing the current article should be added as the first switch.
- For the switch of the current article, and the one showing the immediate located in the administrative territorial entity (P131) geomask, the
type
should be set toshape
. For more zoomed out ones, it should be set topoint
. - Add an option to add the continent as the last switch without the geomask.
- Xeror (talk) 20:13, 7 April 2023 (UTC)
- @Jonesey95: Specifically, when using the
Default value for mapframe-wikidata parameter
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
Diff:Hi, by default, in the case that coordinate of a place is entered inside the Infobox of an article, then incorrectly red colored area indicator of that place is not shown in the map of that Infobox. For example, if we place coordinates of National Zoo of Malaysia inside its Infobox, the rendered map would be:
Code | Rendered Infobox |
---|---|
While if we place that coordinates outside of the Infobox (at the top), then the red colored area indicator would appear in the map, correctly. Like this:
Code | Rendered Infobox |
---|---|
You can test this coding scenario in the article National Zoo of Malaysia to clarify this default bug. So please change the default scenario for mapframe-wikidata parameter
With the parameter |mapframe-wikidata = yes
the Infobox area indicators appears, but we are talking about default scenario. If the bottom code by default does show the area indicators, then the top code by default should show them too, or the inverse default scenario should be applied.
I think in 99% of cases these red line area indicators are necessary, so the default value of mapframe-wikidata should be |mapframe-wikidata = yes
, but the user could change this parameter to no
for 1% of cases. Hooman Mallahzadeh (talk) 05:01, 9 September 2023 (UTC)
- Again, as I explained at WP:VPT, this is not a bug. The template is working as designed. I have deactivated the edit request template, since there is no uncontroversial proposed edit here. – Jonesey95 (talk) 05:08, 9 September 2023 (UTC)
- @Jonesey95 Default setting for
|mapframe-wikidata
is wrong! It is now|mapframe-wikidata=no
, and this is not the expected default behavior! Do you agree? - So I think this "default area vanishing behavior" is not the expected behavior. Although it is not a bug, it is not the "expected behavior", too. So please reactivate that. Hooman Mallahzadeh (talk) 05:19, 9 September 2023 (UTC)
- Personally, I don't agree that the expected default behaviour is the appearance of a red splotch in the centre of the minimap, but I have no idea how widely held my opinion is, nor its inverse. This definitely seems like something that would require a discussion to gauge people's opinions. Folly Mox (talk) 21:58, 9 September 2023 (UTC)
- @Folly Mox Aside from that is this the "expected behavoir" or is not, this module requires an explicit "default settings for mapframe-wikidata". Now this setting is not done well, violating fine-granularity of code. Hooman Mallahzadeh (talk) 11:28, 10 September 2023 (UTC)
- User:Hooman Mallahzadeh, placing the coordinates at the top of the article causes some things to work differently, as per this discussion, this discussion, and this phabricator task. Perhaps the behaviour here is related and should somehow become part of those discussions. It certainly doesn't seem ideal or intuitive that placing the coordinates at the top of the article (contrary to MOS:ORDER) produces in this module an effect identical to
|mapframe-wikidata=true
, but changing the default setting of that parameter should be part of a larger conversation if it's something you're wanting to pursue. For clarity, I have no idea whether or not it's desirable or "better", but I personally don't expect it.User:Jonesey95, do you have any insight as to whether this behaviour is related to those three links above? Folly Mox (talk) 16:26, 10 September 2023 (UTC)- The key, AFAICT, is whether the coordinates are placed inside or outside the infobox using
|coord=
. It has nothing to do with their placement within the article (i.e. top or bottom) or with the page preview problems. I refer the OP once again to the documentation, which explains that if|coord=
is used in the infobox, the shape is not displayed unless|wikidata=yes
is also used. – Jonesey95 (talk) 04:36, 11 September 2023 (UTC)- @Folly Mox@Jonesey95 I added this code segment
- mapframe-wikidata = {{{mapframe-wikidata|yes}}}
- to the Template:Infobox zoo and please inspect that. But the problem is that how we can hide red colored area indicator lines from map. None of these codes hide these lines from National_Zoo_of_Malaysia
- |mapframe-wikidata = no
- |mapframe-wikidata = nil
- |mapframe-wikidata = flase
- So my question is that "How we can hide red colored area indicators" by assigning a value to the parameter
mapframe-wikidata
? Hooman Mallahzadeh (talk) 07:03, 15 September 2023 (UTC)- Use |mapframe-shape = none The Equalizer (talk) 07:56, 15 September 2023 (UTC)
- @The Equalizer Thank you for your guidance, that works fine. But isn't it better to make other synonyms for "none" and make "no" and "flase" as synonym of it. Hooman Mallahzadeh (talk) 08:00, 15 September 2023 (UTC)
- @The Equalizer@Folly Mox@Jonesey95 Wrong scenario is implemented here. The current scenario is
- All values except the word "none" yield "showing"
- "none" yields "not showing"
- Empty yields "not showing"
- The correct scenario is:
- Empty and "yes" and "true" yields "showing"
- "none", "no", "nil", "false" yields "not showing"
- For other words it throws exception
- Do you agree? Hooman Mallahzadeh (talk) 12:40, 15 September 2023 (UTC)
- First, I have asked you before to please do your testing using the template's sandbox, not the live template. That said, something does seem to be a little broken. See this new testcase for
|wikidata=no
, which appears to work the same as|wikidata=yes
. It appears that any value of|wikidata=
enables the red outline or track, which should probably not happen. – Jonesey95 (talk) 13:26, 15 September 2023 (UTC)- @Jonesey95 Sure! I really think that this behavior is a bug for this module. Do you agree? Hooman Mallahzadeh (talk) 10:47, 16 September 2023 (UTC)
- First, I have asked you before to please do your testing using the template's sandbox, not the live template. That said, something does seem to be a little broken. See this new testcase for
- @The Equalizer@Folly Mox@Jonesey95 Wrong scenario is implemented here. The current scenario is
- @The Equalizer Thank you for your guidance, that works fine. But isn't it better to make other synonyms for "none" and make "no" and "flase" as synonym of it. Hooman Mallahzadeh (talk) 08:00, 15 September 2023 (UTC)
- Use |mapframe-shape = none The Equalizer (talk) 07:56, 15 September 2023 (UTC)
- @Folly Mox@Jonesey95 I added this code segment
- The key, AFAICT, is whether the coordinates are placed inside or outside the infobox using
- User:Hooman Mallahzadeh, placing the coordinates at the top of the article causes some things to work differently, as per this discussion, this discussion, and this phabricator task. Perhaps the behaviour here is related and should somehow become part of those discussions. It certainly doesn't seem ideal or intuitive that placing the coordinates at the top of the article (contrary to MOS:ORDER) produces in this module an effect identical to
- @Folly Mox Aside from that is this the "expected behavoir" or is not, this module requires an explicit "default settings for mapframe-wikidata". Now this setting is not done well, violating fine-granularity of code. Hooman Mallahzadeh (talk) 11:28, 10 September 2023 (UTC)
- Personally, I don't agree that the expected default behaviour is the appearance of a red splotch in the centre of the minimap, but I have no idea how widely held my opinion is, nor its inverse. This definitely seems like something that would require a discussion to gauge people's opinions. Folly Mox (talk) 21:58, 9 September 2023 (UTC)
- @Jonesey95 Default setting for