This is an archive of past discussions about Module: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.
I am not sure its a good idea to promote identical names in Data and here. Lets try to keep the data a bit organized by storing it in a "fake subpage" - e.g. Data:naturalearth.com/something.map ? So basically the template should probably not have a default at all? --Yurik (talk) 05:00, 24 December 2016 (UTC)
Singular points
Can the maplink template be adjusted to show singular points (using Wikidata IDs) and latitude/longitude coordinates? There are quite a few article pages that are using template:maplink but they're showing maps that don't make any sense, because they are singular points. Easy examples are: National Museum of Australia and National Institute of Dramatic Art--they both show a (map) link but it goes to a map in the ocean. :( DTankersley (WMF) (talk) 19:38, 13 October 2017 (UTC)
I was the one that added those maps. Checking now, my experience is that maps that use shape work correctly but those that use shape-inverse display the target area correctly but with the map zoomed all the way out. I can confirm that this regression also affects the native <mapframe> and <maplink> functions. I've filed https://phabricator.wikimedia.org/T178370. Gareth (talk) 12:06, 17 October 2017 (UTC)
Thanks for confirming what I saw as well, Evad37, because that's the same error I was getting when I tried using a point or lat/lng in the maplink template. :( Unfortunately, this makes it hard to get more usage of maps on articles if the average editor can't easily add a link. DTankersley (WMF) (talk) 13:17, 15 October 2017 (UTC)
I've added in a phabricator ticket to see if adding in the ability to use a Wikidata Qid for a single point and using a lat/lng can be added to the Template:Maplink and Template:Mapbox templates: https://phabricator.wikimedia.org/T178321. Maybe one of our fantastic community volunteers can help out! :) Thanks, DTankersley (WMF) (talk) 18:28, 16 October 2017 (UTC)
I tried using the above at Bugun liocichla - which is a species known from (how nice) just three point locations. Now it would be nice to have simple round spot markers without shadows and it would be nice not to have to set the width and height parameters but to use the taxobox/infobox settings. Would all this be easy to have? Shyamal (talk) 09:12, 2 May 2018 (UTC)
@Shyamal: If you use this template instead of using the tag directly, then a default width and height (currently 300/200) is used unless otherwise specified. At the moment this template can only handle a single feature, but I'm rewriting it as a Lua module that should be able to display multiple features. As mw:Maps/Icons are the only icons currently available, the closest you can get to "simple round spot" would be the small sized marker.
@Shyamal: As an alternative, {{OSM Location map}} (implemented below) does allow round markers (but hasn't yet got the internationalised place names implemented). To allow the three dots to be resolved, in the example below I have increased the zoom and added a smaller locator map. Like Maplink it can't auto-resize to fit the infobox, but centring it will help the appearance. RobinLeicester (talk) 23:54, 23 May 2018 (UTC)
Its not yet possible without heavily modifying the module code. But storing alternate parameter names in a table is a good idea, I just need to make a helper function so the lua code knows what to do with them. - Evad37[talk]01:19, 27 May 2018 (UTC)
@আফতাব: Done here [1], you can make a similar edit on bnwiki and then it should work - Evad37[talk]
Hi @Evad37: just let you know that coord parameter does not support aliases. coord = { "coord", "anything" }, (line 20) gives error. --আফতাব (talk) 18:50, 29 May 2018 (UTC)
There seems to be an error at The Simpsons house in Module:Mapframe/sandbox. That should not be happening, not just the error but in particular the transclusion of the sandbox, as the sandbox or a template or module is normally an unprotected page that anyone can edit, and that editors are encouraged to try things out in even if they break things. Any code in there therefore is especially vulnerable and should not be used in articles, especially in templates that are already used in a large number of articles. Pinging Evad37 who seems to be the one working on this.--JohnBlackburnewordsdeeds02:32, 31 July 2018 (UTC)
Thanks for alerting me. I've turned off the mapframe in that article with |mapframe=no, and fixed the code that was loading the sandbox version of the module by mistake (in Module:Infobox mapframe). The error itself comes from this module not being prepared for the coordinates property on a Wikidata item being set to 'no value'. I'm looking into fixing this now. - Evad37[talk]02:54, 31 July 2018 (UTC)
Thanks. I noticed your changes already to the Simpsons house article. An interesting test case as there can’t be many other articles for wholly fictional buildings.--JohnBlackburnewordsdeeds03:35, 31 July 2018 (UTC)
Error
@Evad37:{{coord|32|S|116|E}} works but {{Coord|57|18|22|N|4|27|32|E}} doesn't.
{{Maplink|frame=yes|type=point|coord={{coord|32|S|116|E}}|title=Point|description=Description of point}} →
Map
but
{{Maplink|frame=yes|type=point|coord={{Coord|57|18|22|N|4|27|32|E}}|title=Point|description=Description of point}} →
Multiple separate OSM relations with the same wikidata tag
Is there a way to refer to separate OSM relations using separate rendering styles when they both have the same Wikidata tag? For example, to have completed sections of a road render in red, and incomplete sections to render in blue, when the two segments have different route relations, but with only one Wikidata tag for the road. Is this possible with the current system? Roadsguy (talk) 01:20, 15 August 2018 (UTC)
No, the maps can only use a Wikidata id to refer to an OSM relation. Different items would be required to refer to different OSM relations, but such items (referring to only part of a thing) would quite possibly fail d:Wikidata:Notability. - Evad37[talk]01:43, 15 August 2018 (UTC)
Hmm, that's too bad. Is the Maplink feature being maintained by anyone in particular? How might I go about suggesting that? Referring to OSM relations individually would allow for a lot of versatility in certain applications. Roadsguy (talk) 03:02, 15 August 2018 (UTC)
@Roadsguy: OSM relations are a bit brittle though. They aren't really made to be permanently identifiers, which technology like this wants. There is also no feature work being planned for wikimedia maps for the foreseeable future. —TheDJ (talk • contribs) 08:15, 15 August 2018 (UTC)
New York State Route 22, a featured article, is currently in Category:Pages with script errors due to The time allocated for running scripts has expired. errors, six of which appear at the end. Looking at the page source I see this for the template etc. usage:
Almost all of the time is due to this template (ignore the infoboxes, which include it so also have a high cost). I don’t see why as the template does not seem as it should be expensive, and is widely used so any problems would have shown up already. Perhaps there is something about this article that causes particular problems for it.--JohnBlackburnewordsdeeds13:53, 7 October 2018 (UTC)
The article problem now seems fixed – it’s not just reduced the cost but eliminated it as best I can tell. The commons page takes a few seconds to render but I guess that’s not a problem. I have no experience of this sort of map, but whatever you did seems to have resolved it.--JohnBlackburnewordsdeeds14:26, 7 October 2018 (UTC)
Error using decimal format
Using DD format: 37.7891838, -122.4033522
Using DMS: 37° 47′ 21.06″ N, 122° 24′ 12.07″ W
@Evad37: or someone else watching this module: Could you take at look at this? There currently seems to be an error when computing the latitude using the decimal format. In this example right here, when entering 37.7891838, -122.4033522 (the coordinates for the Wikimedia Foundation headquarters), the map currently displays instead 37.8212, -122.4033. The DMS equivalent seems fine. Thanks. Zzyzx11 (talk) 05:51, 28 August 2018 (UTC)
Wind farms are essentially a collection of point features (each wind turbine tower). Open Street Map has a node for each turbine. I have created a few OSM Relation entities consisting of the collection of all the towers in the farm, with attributes that apply to the farm as a whole (power output, wikidata ID etc). Is it possible to render this OSM multipoint relation in Wikipedia? An example is Snowtown Wind Farm. If this cannot work as currently set up, is there a better way of doing it, and what should that look like (in Wikipedia, Wikidata and OSM)? --Scott DavisTalk01:26, 22 November 2018 (UTC)
Inconsistent behavior of when using inverse-shape
Today I noticed that when you enlarge the interactive map on Washington, D.C., it doesn't show the shape at all.
Map
If you copy the code ({{maplink|frame=yes|plain=y|frame-width=285|frame-height=285|zoom=8|id=Q61|type=shape-inverse}}) somewhere else (see right), it's getting worse there: it doesn't even show the shape in the frame. Keep in mind I kept the id= part, so it's supposed to work.
Part 2
I can't seem to reproduce this bug with other data, but found another inconsistency:
{{maplink|type=shape-inverse|id=Q1094308|text=Inverted shape (no frame)}}
As you can see I have two exactly same maplink, but only the second one has frame.
When you click the first one (link), the enlarged interactive map zooms out all the way to global;
When you click on the second one (frame), however, the enlarged interactive maps zooms in to the area selected (better behavior) The frame itself still shows global, though. --fireattack (talk) 20:18, 1 February 2019 (UTC)
Map 1: The "land layer" for Entire Åland is missing on the Wikimedia map.
Map 2: Some roads and names appear when zoomed, but the land is still missing.
Sorry if this is the wrong place to report this.
It seems that the island Åland, more than 1,500 km2, is missing on the Wikimedia map used by the Maplink template, see Map 1. Some roads and places are displayed when you zoom in, but the "layer" for land is completely missing, see Map 2. Compare this to OpenStreetMap.
--Larske (talk) 06:14, 18 February 2019 (UTC)
Hello. Can someone help me figure out what is causing this error? I can't seem to figure it out... Basically, I'm trying to instate these functions, but I don't know which part is causing the errors:
If coordinates are not set locally, it should fetch from wikidata
If coordinates are set locally, wikidata values should be ignored
If |location_map = no the display of location map (i.e. mapframe) should be suppressed (all other values are to be ignored)
If no coordinates are set locally nor on wikidata, the display of location map (i.e. mapframe) should be suppressed, and the respective caption parameter should not be displayed.
Evad: Yes exactly, it is missing the local override option. I'm unable to add myself as Lua is not something I'm good at. Would you be able to add that feature please? Rehman01:51, 10 March 2019 (UTC)
The shape of the district is not being displayed, even though the QID is linked to the OSM shape
Some geoshapes selected through the query function of this template are not being displayed, even though the Wikidata item is correctly linked to the OSM relation and the item shows up on the Wikidata query itself. Antropovsky District is but one example of this (notice how it is not shown on the location map). I can't figure out the cause of this, and would be grateful for any help.--eh bien mon prince (talk) 19:27, 8 March 2019 (UTC)
@eh bien mon prince: The shape is showing up for me in this maplink transclusion. Not sure why you didn't see it – perhaps a caching issue? It can take some time (up to 24 hours I think) for changes to map relations/features to show up on wikimedia maps. (Also, note that in order to be displayed on maps it's actually the OSM relation/feature that has to be tagged with the wikidata QID – the link to OSM from the wikidata item is merely for convenience.) One other thing you can try is using <mapframe>...</mapframe> tags directly per mw:Help:Extension:Kartographer#GeoShapes via Wikidata Query – if it doesn't work like that, then the problem is with the MediaWiki extension. Or if it does work, then we can try to figure out why it doesn't work with this template. - Evad37[talk]00:54, 9 March 2019 (UTC)
Thanks for the reply. I tried to clear the cache, and open this page on different browsers (Firefox/Chrome), and I still cannot see the shape. If you go to Antropovsky District, do you see the district highlighted in red within the location map? Curiously enough, trying to use <mapframe>...</mapframe> directly fails to display anything at all, at least in this sandbox attempt.--eh bien mon prince (talk) 11:01, 9 March 2019 (UTC)
Not showing for me here - I see a world map in saved view, and a zoomed in in edit-preview. On Antropovsky District neither, where additionally the area north of it is not marked as part of Kostroma Oblast. Sandbox shows nothing. 77.183.233.64 (talk) 08:46, 11 March 2019 (UTC)
→ This is what I see for Antropovsky District, the mapframe map seems to be working as expected. Not sure what's happening with the sandbox, that's showing up blank for me too. - Evad37[talk]09:34, 11 March 2019 (UTC)
Hi. Is it just me, or has the in-article zoom buttons disappeared from the maps? I remember a + and - on the top-left corner of mapframes, but now they are gone. Strangely, the buttons are still there in the edit-preview mode. See here for example. Rehman03:55, 15 March 2019 (UTC)
Thanks User:Evad37. I could swear I saw the zoom buttons in normal live mode a few months back... Strange. I guess these limitations were put in place to reduce stress on the servers? I noticed the "full" version is live on Meta and Wikidata (example: Lakvijaya Power Station (Q6479997)), so it is technically possible. Rehman01:31, 16 March 2019 (UTC)
So what I thought was the bug is a deliberate choice and the bug is edit mode showing the documented behaviour? The description at mw:Help:Extension:Kartographer describes interactive maps embedded on the page and makes one expect an embedded interactive map, as you see in editor mode or on the test wikipedia. Why and when was it chosen to disable this behaviour? It's annoying and makes these maps less desirable. I thought the behaviour had changed and was a bug that would be resolved when the newer software on the test wiki became active. Jts1882 | talk08:23, 16 March 2019 (UTC)
Jts1882, I'm not entirely positive, but the reason that we have static images, as I remember it from that time it was launched, was partly for performance reasons (it's a lot of dynamic content to deliver etc. especially on mobile) as well as to have the ability to present some content for people who disabled javascript, for printing etc. The edit mode is registered as a bug, but there too it is actually a performance issue (static rendering is expensive, so doing it for a single user reduces the performance of the preview action too much.)
My personal question is.. why NOT click the mapframe to open fullscreen ? Why would you use a stamp sized frame to interact with a map ? —TheDJ (talk • contribs) 14:56, 25 March 2019 (UTC)
To keep everything on the same page. Sometimes it is useful to be able to move in the map while comparing with an adjacent information (in infobox or table). To be honest, I can't remember exactly why it struck me as so irritating, just that I remember it that way. I was also surprised by the behaviour as it deviated from the documentation (now changed) and from the behaviour I was seeing while developing a module using the maps. I must have being doing nearly everything in preview mode as I didn't notice the different behaviour on the published page until months later (or was the behaviour changed after it was introduced). In general I think it is possible to find an alternative static image map that is better than the map provided in mapframe, with the interactive nature of the latter making the difference. If it needs to be expanded to get the benefits, the advantage is lessened in some cases. Well, if it is a performance issue, then that must be how it is. It is good to know the reason, so thanks for the explanation. Jts1882 | talk15:28, 25 March 2019 (UTC)
Maps don't load on initial page load
What User:Fredddie sees on I-64
Something I've noticed lately is that quite often, map previews won't load on the initial page load. Specifically, maps embedded in {{Infobox road}}. For instance, the map I created for Interstate 64 in Indiana will not load for me in the infobox. If I click where the map should be, the map will load and I can see what's supposed to be there, when I close the full screen map, there is nothing in the infobox. I'm not sure what the problem is or if it's just on my end. –Fredddie™20:19, 23 March 2019 (UTC)
@Fredddie: I've noticed that often a WP:NULL edit is required to make the thumbnail map display, after a mapframe map is first added to the page or is edited. Or sometimes several null edits. It's probably something like a job queue for generating the static thumbnail images being busy, or getting stuck, or something. Anyway, at the moment the thumbnail map in Interstate 64 in Indiana is displaying for me. - Evad37[talk]23:58, 23 March 2019 (UTC)
Map rendering as a static image, with full screen button not working
Hi all, I've been trying to create a maplink template to show rail lines in Melbourne, you can see the map on my user page or here: https://en.wikipedia.org/wiki/Railways_in_Melbourne#Infrastructure
The interactive map works well on previewing edits, but when I publish it renders as a static image. This isn't a huge issue except the full-screen button seems to not work either, and is just a static unclickable image too. Does anyone know why this is happening? Did I mess up the template or is the map just too complex? Thanks. Gracchus250 (talk) 02:54, 20 April 2019 (UTC)
The mapframe maps do behave differently in preview and in the published main namespace. The interactive element in the non-expanded map is disabled (because it is resource heavy, iirc), so the static image is normal, although disappointing. But the inactive full-screen button isn't usual. Have you tried reducing the number of elements in the map, say with just one line? [edit: not this] Jts1882 | talk13:05, 20 April 2019 (UTC)
It seems to me that the interactive element of the map has been disabled in most namespaces (main, user). They seem to still work in template namespace, but not when transluded to the main namespace. Jts1882 | talk17:15, 20 April 2019 (UTC)
@Gracchus250:. The interactive maps appear to have been disabled. Some maps I created in the past in template space still work interactively in template space but not when transcluded. New maps in template space also don't work. Moreover, edits to functioning maps seem to disable them. I can't find anything to explain the chenged policy, although I assume it must be the computer overhead. Jts1882 | talk09:52, 21 April 2019 (UTC)
Thanks for your help, my different tests have found a similar thing: maps sometimes working interactively on preview but changing on publish. Removing elements doesn't seem to work, though I might test this again. The behaviour does seem to be a bit inconsistent. I don't mind if it's a static image it's just a huge shame if the expand button doesn't work, because that negates the whole point of the map. Hopefully it's just a bug and not a policy change. Do you know if there's anyone to report this to? Thanks Gracchus250 (talk) 11:07, 21 April 2019 (UTC)
Ah, thank-you. It's good to know this is a temporary issue rather than another performances related restriction on the interactive functionality. Jts1882 | talk15:53, 21 April 2019 (UTC)
For articles where the Wikimedia map is placed, I can't click the dashed square button to expand the map, zoom around, or pan. I also noticed that I can't click the blue links to Wikimedia or to OpenStreetMap from these maps. I checked this using Firefox and Chrome. However, if I were to edit the article/section in which the mapframe map appears, I hit preview to preview my edit/null edit and I can expand the map and click the links. —Mr. Matté (Talk/Contrib) 16:29, 23 April 2019 (UTC)
Sorry to be a bother again. Patience solved the above issue. Could anyone tell me where this one is falling down? OSM relation is 7715239 and the wikidata QId is Q42791306. All data is 12 months or so old. Thanks --Tagishsimon (talk) 23:48, 26 April 2019 (UTC)
Map
For relations, only those with type multipolygon, route, or boundary will display on maps. This is a known issue, phab:T156433, which unfortunately the developers are unlikely to fix anytime soon. - Evad37[talk]00:35, 27 April 2019 (UTC)
Looking at this article right now one sees only a box icon where the map should be in the infobox. Someone happened to do a GA review on 25 April and at that point the map did appear. So I'm thinking the problem is not local to the article, but in the templates. That is, the breakage is external to the article? Help? Shenme (talk) 04:05, 24 May 2019 (UTC)
In discussing with Bsoyka I just noticed something that has me freaked out. The map does not display when bringing up the article. But then, click edit, then click "Show Preview" without having changed anything. For me, the map displays in preview! To me, that implies strange interactions and timing with respect to Javascript imports. Youch! Shenme (talk) 05:37, 24 May 2019 (UTC)
@Shenme: I think this might be an issue on your end. I've checked with my PC and phone (both running Chrome) and everything seems to be in working order (with the expansion button appearing in the top right and the expanded view able to scroll around). SounderBruce05:57, 24 May 2019 (UTC)
Always a possibility, which is why I checked after disabling AdblockPlus and NoScript in Chrome 74, and then tried Microsoft Edge, with same results. Now have tried my Win10 with MS IE, FireFox 66, and updated to FireFox 67, and FireFox developer edition 64, and updated to 68. And partner's separate PC running Win7 FireFox 66, updated to FireFox 67, Chrome 74. All with same results, just a boxy icon. And logged in and not logged in. I will be very interested in the answer to all this. Shenme (talk) 06:34, 24 May 2019 (UTC)
I also only saw the box. This blank map issue comes up time to time with mapframe for some reason, but is usually temporary. I did a null edit and the map is now visible for me. Jts1882 | talk06:53, 24 May 2019 (UTC)
Hmm, still happening to me (no map) today, trying different browsers and clearing cache, etc. Even tried a "?action=purge". Haven't tried a reboot... :) Shenme (talk) 20:42, 31 May 2019 (UTC)
Interstate 75 is displaying error messages of "The time allocated for running scripts has expired." I have traced the error to the maplink template. The code currently in the article is {{maplink|frame=yes|plain=yes|frame-align=center|frame-width=290|frame-height=240|frame-lat=37.00|frame-long=-84.29|zoom=3|type=line|raw={{Wikipedia:Map data/Wikipedia KML/Interstate 75}}}}, which renders thus: but after Fredddie's changes, it now looks like this:
I don't know the KML format enough to debug. Can somebody take a look at this and assist? Again, it was working until recently, but old versions of the page aren't rendering correctly, so all I can think of is a change to this template broke it? —C.Fred (talk) 18:12, 31 May 2019 (UTC) revised 00:23, 1 June 2019 (UTC)
It's not the template per se, it's the amount of data the template is trying to process. I have moved the data over to Commons at commons:Data:Interstate 75.map and changed the instance on the I-75 page, so it now displays. –Fredddie™20:33, 31 May 2019 (UTC)
I wondered if that was the case, because the road is so long with so many curves. Thank you for fixing it! —C.Fred (talk) 00:23, 1 June 2019 (UTC)
Automatic zoom for highlighted areas not working
I added the template to Pinelands National Reserve. When I delete zoom parameter from the template, I guess it should fall back to some kind of default or automatic zoom. But what happens is only a blank white map is shown with a red dot in the middle. Is this a bug?--Kozuch (talk) 12:18, 15 June 2019 (UTC)
Too few points returned when using Wikidata
I think this module should return more geopoints for a given object when using Wikidata as point source. Talking about usage via Template:Maplink. If you look at Interstate 70 in Pennsylvania and zoom the map a bit then the route is very simplified and does not trace the original very good. Can something be done with this? See the example here below. It is interesting that the WIWOSM tool does not seem to have such problems on the same object (see example here) and maybe renders even faster. So where is the problem? PS: ping User:Evad37 --Kozuch (talk) 10:07, 21 June 2019 (UTC)
@Evad37: I think I identified a bug - the module does not ignore wikidata's "coordinate location" property (P625) for type=line which results in broken both the thumbnail map and the big map. I opened a ticket on Phabricator: T227402. My findings are simply when there is no P625 on wikidata the thumbnails/map/zooming etc. works ok. But when there is P625 these are broken, but I only tested type=line which is the only type that interests me. Can you fix it please? Thanks! --Kozuch (talk) 10:03, 27 July 2019 (UTC)
@Evad37: I set up a testing page at this link. The problem on simple line objects like D52 motorway (Czech Republic) or interstates sections within states is fixed. For type=shape this seems also fixed (Pinelands National Reserve, Wharton State Forest). I recently discovered that type=line also works for type=shape (on some pages) as I do not want the infill on type=shape as the map inside is darker and can not be seen both in thumbnail and full screen map. Interestingly the fix works for Austria when type=line is used but it does not for Pinelands National Reserve and Wharton State Forest with type=line - do you know what is the issue? Also a long Interstate 5 does not work - I think this is because the master relation on OSM (https://www.openstreetmap.org/relation/2329642) has sub-relations and that simply does not work with Mapframe/Kartographer (but WIWOSM can show master relation! - I would appreciate that to work here too). I think you can push the Module from sandbox to production if you want. The "new" issues I raised (I will update the bug) are kind of additional in the context of the original bug. If you move it to production I can at least use what is working now and not need to use my module clone. --Kozuch (talk) 11:29, 3 August 2019 (UTC)
Updated the live module. As I wrote on Phabricator, not working with sub-relations is phab:T156433, and I'm not sure what's up with type=line not working when type=shape does – that may be another new bug. - Evad37[talk]09:28, 4 August 2019 (UTC)
Problem seems reproducible in above right map (try preview vs. saved page) which seems to imply something other than a caching issue with the FM 812 article itself. Please advise if I've done something different/wrong on the corresponding relation #2538184 vs. #2534475 over on OSM. ―cobaltcigs11:40, 2 August 2019 (UTC)
The map in Farm to Market Road 812 is displaying for me on the saved page, but not in the above map (as of now). The difference between preview and the saved page would be because preview uses dynamic thumbnails (you can drag the map around with your mouse, and change zoom levels), whereas the saved page uses a static thumbnail image... so it could very well be a caching-related issue. Sometimes WP:NULL edits (or other subsequent edits) can help. - Evad37[talk]02:12, 3 August 2019 (UTC)
I can tell you what is happenning but not why. The map is not picking up the correct coordinates. I've added the coordinates to the maplink template in the infobox of Bintulu and the map displays correctly. The coordinates at Wikidata seem correct so I can't explain why the default is getting the wrong coordinates. Jts1882 | talk10:27, 16 August 2019 (UTC)
I see.. I also wondered if someone changed something in Wikidata but can't see something different in the history log. Anyway, thanks for the fix in Bintulu! Night Lanternhalo?10:32, 16 August 2019 (UTC)
@Evad37:Can support for |fill-opacity= be added for geoshape and geomask. I think the following code should do it, applying opacity only when fill is explicitly set.
-- insert after line 20
opacity = "fill-opacity",
--insert after line 277
local opacity = getParameterValue(contentArgs, 'opacity')
if opacity then
data.properties['fill-opacity'] = tonumber(opacity)
end
It works on the infobox at London using, but I'm reluctant to make the change myself as I don't have a comperhensive set of examples to test generally. I don't see why it should cause problems elsewhere, but I'm not familiar enough with the module use to be sure. Jts1882 | talk06:47, 27 September 2019 (UTC)
I just added support for |marker-size= with valid values of "small", "medium" or "large". it doesn't look like I broke anything, but let me know if I did. Frietjes (talk) 14:46, 24 October 2019 (UTC)
@Frietjes: The module now refers to L10n.defaults.markerSize on line 254, but markerSize wasn't added to the L10n.defaults table (lines 98-106), so it evaluates to nil. I think that probably wasn't your intention, but in any case, the code would be clearer if either a default markerSize was added to the L10n.defaults table, or if nil was used directly rather than a non-existent table key. - Evad37[talk]15:23, 24 October 2019 (UTC)
@Evad37: that was my intention, since the default was to not set that value, but we can explicitly set the default value to nil if you like that better. Frietjes (talk) 19:03, 24 October 2019 (UTC)
Done here [1], you can make a similar edit on bnwiki and then it should work - Evad37 [talk]
Fixed here with this edit - Evad37 [talk] 02:25, 30 May 2018 (UTC)
Inverted shape (has frame)
Map
--Kozuch (talk) 18:58, 4 August 2019 (UTC)
