Template talk:OSM Location map

This is the talk page for discussing improvements to the OSM Location map template.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: 1, 2Auto-archiving period: 12 months

	This template does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:
Maps This template is within the scope of WikiProject Maps, a collaborative effort to improve the coverage of Maps and Cartography 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.

Template:OSM Location map is permanently protected from editing as it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories. Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.

Template-protected edit request on 10 August 2024

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Can someone please increase the mark limit from 60 - {{2024 United Kingdom riots map}} requires more, maybe increase it up to 100, or make it unlimited if possible. harrz ^talk 19:56, 10 August 2024 (UTC)[reply]

 Not done for now: to increase the present 60-mark limit in this template to 100 or more would require a large increase in code, and this template is so large already that there are subtle warnings in the documentation. For more information see H:TLIMIT. I've looked into ways to improve this template in terms of server load – ways to decrease its size, possible conversion to the LUA markup language, and so on. I'll continue to try to find ways to make it better; however, for now to increase this template's load on a page is undesirable. P.I. Ellsworth , ed. ^{put'er there} 10:27, 12 August 2024 (UTC)[reply]

You could use other Template:maplink solutions that do not have all the features such as mouse-over enabled without clicking on map. See Template:Location map many for example. ChaseKiwi (talk) 11:37, 12 August 2024 (UTC)[reply]

YUnlimited mark numbers has now been implemented, with a rewrite in Lua - Subject to wikimedia resources, which would need keeing an eye on. Some mark options create larger output code than others. A plain circle with no outline, numbers, label or links will give smallest html code, and each of those elements will increase the size. I have not yet tested large dataset maps. I imagine 100 marks will be OK, but if you have some try-outs, let me know how it goes. (nb: the fullscreen map may well be the first pressure point - it uses {{mapframe}}, and I don't know what its limits would be either). RobinLeicester (talk) 16:59, 27 March 2025 (UTC)[reply]

To editors Harrz and ChaseKiwi: just thought I'd ping you to let you know of the above recent improvement. P.I. Ellsworth , ed. ^{put'er there} 20:11, 27 March 2025 (UTC)[reply]

This is great to hear, many thanks to both of you! harrz ^talk 21:00, 27 March 2025 (UTC)[reply]

Your welcome! P.I. Ellsworth , ed. ^{put'er there} 02:01, 28 March 2025 (UTC)[reply]

Bug in code for Marker22

Discovered that the code numbered22=H or anything for that matter displays HV so a V is appended to the string. No doubt a minor cut and paste error in code as all well if you use another of the 60 markers. Reproducible always. ChaseKiwi (talk) 20:50, 5 October 2024 (UTC)[reply]

I think I may have fixed it. Please test. – Jonesey95 (talk) 00:32, 7 October 2024 (UTC)[reply]

Ta, its fixed. It was related I assume on my own further investigation of test cases without template changing powers to appending of the default code that generates for an l-shape the labels A,B,C,D...if just coordinates given. ChaseKiwi (talk) 09:55, 7 October 2024 (UTC)[reply]

Proposal: Add Custom Label Positioning Options (e.g., Southeast, Southwest, Northwest, etc.)

I would like to propose the addition of more customizable label positioning options for the {{OSM location map}} to allow for more precise label placement. Currently, the label-pos parameters (label-pos1, label-pos2, label-pos3, etc.) support only basic positions: top, bottom, left, and right, but there is no support for compass directions like northeast, northwest, southeast, or southwest.

Suggested Changes:

• Expand the label-pos parameter to support compass direction options such as:
  • northeast
  • northwest
  • southeast
  • southwest

Benefits:

• Increased flexibility: Allows for more precise control over the placement of labels on the map, making it possible to position them relative to the map in ways that better match the surrounding context.
• Enhanced user experience: This would help editors avoid overlap with other elements on the map or provide clearer context for the location.

Possible Implementation:

• Modify the label-pos parameters (label-pos1, label-pos2, label-pos3, etc.) to accept these additional values. Alternatively, adding a new parameter for directional positioning could be considered, to retain backward compatibility with existing templates.

I believe this change would improve the functionality of the template and make it more versatile for a wide range of articles. I welcome feedback and discussion on this suggestion. Abhiramakella (talk) 16:42, 14 February 2025 (UTC)[reply]

Sounds like a good suggestion to me. See below for why I have not responded until now, (somewhat pre-occupied). With the new module, it should be possible to add in 8 'compass point' label-pos options as alternatives to the 4 current ones without the need for additional parameters. RobinLeicester (talk) 23:43, 5 March 2025 (UTC)[reply]

Lua module now at Beta test

I have finally got to grips with enough of Lua/Scribuntu to convert the whole of this template to into a module, instead of the very creaky wiki-template version. The intention here is to retain complete 'functional equivalence', but for various reasons there may be tiny shifts in position of some elements. The main objectives in this rewrite are:

• Better performance/lower resource use. The maps via the module are making much lower demands on the resources and load-times.
• Enable 'notionally unlimited' amount of dots, instead of the 60 limit. Clearly there would be a point beyond which the resources will be affected, but the module has no built in limit.
• Use of Lua will make it possible to add features within more maintainable code.
• Also to develop an alternative more condensed parameter regime, to give more flexibility/control options and more concise template text (and one day, maybe external data file).

This last point will be a thing to look at in detail later on. The first task at this point is to test out any potentially troublesome maps before going live, so any help in checking maps, by such stalwarts as ChaseKiwi, Jonesey95, Fourthords, Paine Ellsworth, would be much appreciated - and anyone else as well.

{{OSM Location map/sandbox}} is now using the new module, so you can test a map 'in-situ' by simply adding '/sandbox' to the template name and preview it. (Note: don't leave it saved with the sandbox version, as it might be being used later for testing stuff). If you find errors the next step is to paste the full template code into a 'testcases table' template at {{OSM Location map/testcases}}. This allows side-by-side comparison of how it is supposed to look, so the issue can be debugged. My suggestion is that you notify about problem maps at Module talk:OSM Location map, which is also a good place to initiate any other discussions on the switch-over to using the module Thanks for any input people can make. RobinLeicester (talk) 23:36, 5 March 2025 (UTC)[reply]

Noted. Compliments on the time you must have devoted to this. ChaseKiwi (talk) 04:35, 6 March 2025 (UTC)[reply]

Overall great. A few notes:

• I notice that the numbers inside the in-map labels are not bold, but the labels in the legend present the numbers in bold. Is this intentional? See Test 5 for an example.
• I really like the new formatting of the legend bubbles. The black outline and slightly larger padding is pleasing to the eye.
• The vertical padding between the caption and the legend looks better in the live template (see Tests 1 and 2). The sandbox version looks a bit crowded.
• In Test 6, the scales appear to be the same length, but one shows 45 km and the other shows 30 km. The scale numbers doubled when I tested the sandbox at Spratly Islands OSM. Something does not seem right there.
• At Eastern League (1938–present), the scale numbers do not change. Strange.
• On my screen, the converted "19 miles" in the sandbox version is positioned too low, leaking below the map. This leakage is especially bad at {{Location of North Korea's Nuclear tests}}.
• All of the numbers in the "NewPP limit report" in page source look like significant improvements, at least at {{Spratly Islands OSM}}, which I temporarily converted to the sandbox for testing.
• At {{Spratly Islands OSM}} (see the history for the sandbox version), the labels changed from black (readable) to gray (less readable). The numbers on the scale changed from gray (less readable) to black (readable).
• {{Flushing Meadows-Corona Park map}} (and others) ends up with two scales in preview, but not when saved. Quirky.

I hope that helps. – Jonesey95 (talk) 18:02, 6 March 2025 (UTC)[reply]

The test of {{Spratly Islands OSM}} shows that some coordinate number labelling positioning is off by more than 2px . No such issues with testing {{OSM Himalaya}} and {{Karakoram OSM}} but a new issue emerged on the scales (which are different as already noted ) taking the last as example there is now a extra scale of 50 km at the bottom as well as scales positioned as before of 60km/37 miles when previously they were 75 km/50 miles. ChaseKiwi (talk) 23:37, 7 March 2025 (UTC)[reply]

I have added breaking test example to Module talk:OSM Location map as module is not presently parsing extended character sets used in labels and has probably two label positioning bugs at this time ChaseKiwi (talk) 09:07, 8 March 2025 (UTC)[reply]

670m
730yds

Item 0

39

39

38

38

37

37

36

36

35

35

NBC

34

33

33black

32

32 Navy

31

Fuschia

20

19

29Aqua

18

28olive

17

27Yellow

16

26Maroon

15

25Red

4

24Gray

3

23

22

1

Llanfechell Triangle

   

The 'Llanfechell Triangle' standing stones are north-west of Llanfechell.

---

[Show/Hide the dot-colour list]

1

Llanfechell Triangle

3

black

4

Gray

15

Red

16

Maroon

17

Yellow

18

Olive

19

Aqua

20

Teal

31

Fuchsia

32

Navy

33

13

35

soft red

36

hard red

37

dark red

38

soft blue

39

hard blue

NBC

34

Thanks Jonesey95 for useful list. The dot-number size and bolding was something I had not got back to, so thanks for the prompt on that, likeways padding the top of the captionlist, and setting the default text color to dark grey - all now done. Image on the right doesn't demonstrate any of that in particularly but is just taking the chance to show a new auto-caption feature about which I am unreasonably pleased.

I have adjusted the scale rounding in the 100-500mile range, which was rounding to nearest hundred, which was clearly too agressive. I will write a separate section to clarify some of the issues surrounding the scale representations. RobinLeicester (talk) 23:04, 11 March 2025 (UTC)[reply]

If those are the default text and background colors for labels, they may need to be adjusted for accessibility. See this output. – Jonesey95 (talk) 23:13, 11 March 2025 (UTC)[reply]

default text is now set to #333322, which gives a contrast ratio of 11.75:1, which looks to be much better. Thanks.RobinLeicester (talk) 00:00, 12 March 2025 (UTC)[reply]

Probably more on the scale mark than anyone needs to know

My starting point on the scale issue is that I think a map should have one, and one of the shortcomings of both {{mapframe}} and the many otherwise excellent locator maps is that they mostly give no clue as to the scale (Except in preview mode - more on that later). Having said that, the OSM maps use a mercator projection. This is not a fixed-distance projection. The same zoom level will have a very different scale along the equator than nearer the poles. Not only does this mean a scale has to adjust for maps at different latitudes, but anything showing a map covering multiple hundreds of miles will have a different scale at different parts of the same map. For this reason, the scale is best seen as a guide to content of the map, rather than a precise cartographical artifact. It is still extremely useful, and is not, in reality, going to be used as a surveying or measuring tool, so serves its intended purpose. But because it lacks precision, it seems important that the numbers are rounded, to give an indication of the the level of approximation being made. At large zoom-levels, there is minimal projection effect, so the numbers can be fairly exact. At global scales, anything more precise than the nearest 1000km would be a misleading indication, as the variation across the map would be multiple 100s of km.

So why are the new numbers different from on the old template? In its original incarnation as a 'graph' template, all the projection issues were handled by a vega graphics package, so all the coord to map issues were dealt with out of sight, and I knew nothing of mercator calculations. So my scale-number solution was an unholy lump of template code that produced 'decent guesses' at each zoom for a selection of latitude bands. Having had to tangle with the mercator calculations to make the template work in a post-graph world, it finally dawned on me that the scale could also be calculated. It now comes up with a 'probably acurate' value for the centre of the map, which is then rounded as described above. That is why there could be significant shifts from the old to new numbers - or in some instances they may agree exactly.

But why is there sometimes a second scale mark in view? That scalemark is generated by the mapframe module that provides the base map. However it is only displayed in preview mode - so is no use in providing scale information to readers. It is not clear why this is done, or how acurate it is. The line is longer so the values given are greater than those from this template, but look in visual terms to agree with the new calculated version. A final observation to make on the 'disappearing scalemark' issue is that when the template scalemark is shifted far enough to the left that it is past the various copyright data, it drops down to be more out of the way, and placed along the bottom edge. In preview mode this will appear to conflict with the other scalemark, but once submitted there is no conflict, and the position looks appropriate. RobinLeicester (talk) 23:50, 11 March 2025 (UTC)[reply]

Thanks Robin for the detail on scale. All consistent with my own recent scaling journey as I debugged a non wikipedia 3D map app for solely my own interest. ChaseKiwi (talk) 12:18, 12 March 2025 (UTC)[reply]

New Module-based version is now live

The Lua/Scribuntu module version of this template is now live, and will be being used by all maps that call the template. Considerable effort has been made to try and get as close to the original placements as possible, but with some substantial cleaning up of the code, as well as adding extra functionality, there may be slight shifts in how some shapes and text are placed. If you are experiencing anything more major than that, please let me know on this page. Documentation on additional features will be being added soon.

If a more detailed discussion on the module and how it works is wanted, the talk page at Module talk:OSM Location map would be the good place for that. RobinLeicester (talk) 13:03, 21 March 2025 (UTC)[reply]

Nice work. At all maps, e.g. {{Spratly Islands OSM}}, I'm still seeing the "140 km" and "87 miles" above and the below the scale rendered too low. The 140 km sits 1 px above the bar, and the 87 miles straddles the border of the image and extends halfway into the white space, just touching "StreetMap". I can post a screen shot if you are not seeing it. – Jonesey95 (talk) 13:33, 21 March 2025 (UTC)[reply]

Curious. Is this on the mobile version? It looks fine in Chrome and Edge on desktop, and is 'normal'ish on the wikipedia android app. I can see shifting going on on the mobile version on both the laptop and android phone, but can't imagine why the text would move separately from the line. I will see what I can find out. Also, I will put the 'old template' into the sandbox, so there is still a way to compare the two. RobinLeicester (talk) 14:04, 21 March 2025 (UTC)[reply]

Desktop, Vector 2022 on Firefox for Mac OS, logged in or logged out. On Brave or Safari for Mac OS, logged out, Vector 2022, it looks fine. The difference in Firefox may be that I have my default font size set to 14 and the minimum font size set to 11 so that absurdly small text is still readable for me. This limit sometimes causes display issues for me. When I inspect the font sizes in Brave, where I have not set font size restrictions, it shows me that the scale text font size is 66.67% of the normal page size, which is much too small per MOS:SMALLFONT: In no case should the resulting font size of any text drop below 85% of the page's default font size. I recommend increasing the font size of the scale text to 85% and then troubleshooting after that if there are display issues. – Jonesey95 (talk) 15:42, 21 March 2025 (UTC)[reply]

In the code, I'm seeing most font sizes set using fixed pixel sizing, including 10 px and 9.5 px. The default font size in the browser I use for checking what things look like when logged out (Brave for Mac) is 15 px, which means that 10/15 is 67%, i.e. much too small. I recommend using 85% for small font sizes in as many places as possible. I have made a couple of easy changes in the Module sandbox. – Jonesey95 (talk) 17:30, 27 March 2025 (UTC)[reply]

This accessibility issue is still present. My proposed changes to the sandbox were removed. Font sizes of 10px and 11px are being specified. Both are too small. – Jonesey95 (talk) 01:55, 28 June 2025 (UTC)[reply]

Remove boundaries and roads

This is an awesome template. Thanks for creating this.

I am trying to use this for some historical maps. This means that I do not want to see current roads and boundaries. I just want the physical data (topo, water bodies, rivers, etc.) How could I start with such a map. I shall add other elements to this basic physical layout.

Thanks, Chaipau (talk) 11:56, 18 June 2025 (UTC)[reply]

Unfortunately this template always uses the contemporary OSM basemap. You can use 'nolabels = 1' to exclude the placenames, but everything else is a fixture. You could potentially start with one of various relief maps available on Wikimedia commons, and use a graphics program to build your map to upload to commons. Not the answer I would like to give, but I think that is your best option at present. RobinLeicester (talk) 15:40, 25 June 2025 (UTC)[reply]

Thank you, this clarifies the matter for me. I am sure at some point what I am looking for will become available. But I really like the way that I can encode many locations in this template and update the locations when better information becomes available. Also, I love it that I can zoom into sections of the map. I have used it here, to great convenience! Chaipau (talk) 00:32, 26 June 2025 (UTC)[reply]

Nice work on the Assam invasion map. Where the numbers are obscured by others on top, I have added some extra 'n-line' bits to show them on little stalks. After I had done it I realised I had not noticed that No 9 is also hidden, so as practice, you could add that one in as well.RobinLeicester (talk) 20:09, 26 June 2025 (UTC)[reply]

Thank you very much indeed! I have added yet another map and I shall add No 9 after studying what you have done there. Chaipau (talk) 21:29, 26 June 2025 (UTC)[reply]

Switcher

Resolved

 – Graham11 (talk) 03:53, 2 July 2025 (UTC)[reply]

Settlement
680m 741yds C r o p s t o n R e s e r v o i r Old John Tower Hallgates Old John Car Park (Hunt's Hill) Bradgate House B R A D G A T E   P A R K War memorial     An example 350m 382yds Powys Neath Port Talbot Roman road Blast Furnaces Roman Marching Camp Roman Fort     A different example This is the map's caption
Country	Canada
Province	Ontario
City	Toronto
Government
• Mayor	Jane Doe
Population
• Total	100,000

I am attempting to use {{switcher}} to display two instances of {{OSM Location map}} in a single infobox. There are never any issues with the first map displayed; however, as in this example, the second map only partially renders. Does anyone might know what the cause of this is? Would it be an issue with this template or is the problem the underlying extension? And, if the issue can't be easily resolved, can anyone think of a workaround? Graham11 (talk) 03:33, 1 July 2025 (UTC)[reply]

I see both maps with no trouble. – Jonesey95 (talk) 17:30, 1 July 2025 (UTC)[reply]

Yes, I too have no issues, so user:graham11 is likely to have a cache problem. Its not always the browser, although this is most likely, perhaps after an incomplete initial fetch, as wikipedia does its own caching and I have sometimes had to do a vpn tunnel to a far away place to confirm its servers have not yet aligned images after all refresh cache attempts seem to have failed. To date after a few hours they sort themselves out internationally. ChaseKiwi (talk) 18:17, 1 July 2025 (UTC)[reply]

That must be the issue. Thanks for your help! Graham11 (talk) 03:53, 2 July 2025 (UTC)[reply]

Would it be possible to adjust the color of the number on each dot?

There is a map I'm working on where it would be helpful to have some of the dots enumerated (and given captions) but not others. I was hoping that I could change the color of the number to match the color of the dot so it would "disappear", but I don't believe this is possible to do. LivinAWestLife (talk) 10:14, 1 July 2025 (UTC)[reply]

Always link to an example page when reporting an issue. – Jonesey95 (talk) 17:31, 1 July 2025 (UTC)[reply]

If the default shape has been set as 'n-circle', then any (lets say set 3) that shouldn't have a number can be set to 'shape3=circle', and it will have neither a number nor a caption entry. You may then want to use label3= to indicate what the dot represents, or the main caption could explain what the unnumbered dots are. RobinLeicester (talk) 17:41, 3 July 2025 (UTC)[reply]

Thanks, that's quite helpful. LivinAWestLife (talk) 18:37, 8 August 2025 (UTC)[reply]

New OSM Location map only showing useFormatStyle

In the past when making these maps, there would be boxes for coords, labels, marks, label colors, etc. now I only see useFormatStyle. What does that mean? How do I make a map with coordinates? AnthonyBurnett25 (talk) 15:12, 12 July 2025 (UTC)[reply]

Are you referring to another mapping application aid, perhaps one in Wikipedia:Maps for Wikipedia. Few are as useful now as {{OSM Location map}} which has many ways of making maps with known coordinates as individual marks, geolines or geoshapes with examples linked to in the documentation, but there is a learning curve, best done in your personal sandbox, based on modifying working code. ChaseKiwi (talk) 20:59, 12 July 2025 (UTC)[reply]

No, I'm referring to OSM Location Map. When I open the template to edit the only box is "useFormatStyle". There's no way to make marks, geolines etc. I had no issues making these back at the beginning of the year. Idk if it's because I don't use EditSource as I find it quite confusing and the normal edit works fine for what I need to do. AnthonyBurnett25 (talk) 14:55, 13 July 2025 (UTC)[reply]

Sorry, I always use edit source now as too many pages I am interested in have visual editor disabled. However the parameter documentation needed for visual editing has presumably got mucked up in the transition to the new underlying Lua module and this is not solvable by me. ChaseKiwi (talk) 20:55, 13 July 2025 (UTC)[reply]

The documentation should be enhanced to support Wikipedia:TemplateData. This enhancement will assist VisualEditor users. Since there are many available parameters, I suggest starting with the basics like coordinates and labels. I'm willing to give this a try. Has anyone started to do this? DutchTreat (talk) 10:13, 16 July 2025 (UTC)[reply]

No one will have done this and I do not have the skill set to help. A point I will make. Users faced with such should completely clear their browser wikipedia associated cookie cache as the parameter change on conversion to the Lua solution could have completely mucked up visual editor assumptions. Can user:AnthonyBurnett25 confirm he has done this. I have now found I had to do this to get back to the working source editing interface I prefer, when I tried to understand the issue... yet another reason to stay away from visual editing for me. ChaseKiwi (talk) 11:07, 16 July 2025 (UTC)[reply]

I have created an empty TemplateData section. Someone can start the actual TemplateData. I recommend copying and pasting from another template's documentation, then copying in the text, as appropriate, from the "Blank code with comments" box on this page. That should provide a basic TD interface for editors. – Jonesey95 (talk) 17:28, 19 July 2025 (UTC)[reply]

Sorry for not noticing this discussion earlier – the /doc subpage was on my watchlist, but the main template page wasn’t. (Jonesey95, we can avoid such unnecessary revert cycles if you link to the discussion right in your first edit next time.)

I think the best way to edit TemplateData, especially for beginners, is to use the wizard that can be opened with the Edit template data button, and then cut&pasting the result wherever you want to put it if it ends up at the wrong place. (The wizard even suggests automatically adding all recognized parameters, but that’s of limited use in this case, since the problem is exactly that parameters aren’t recognized. And this is not a cache issue as ChaseKiwi suggests, but the result of the fact that parameters are accessed from Lua in a way that’s practically impossible for TemplateData to track down.) Note that some of the types are not obvious (what exactly boolean means, which values are accepted for number etc.), it’s best to consult the official documentation.

I still hold that adding the banner without actual documentation, even for the time being, is more confusing than useful, but I don’t want to get into an edit war, especially if this “time being” is short enough. —Tacsipacsi (talk) 21:03, 19 July 2025 (UTC)[reply]

Holidays (and zero experience with visual editing) meant I couldn't follow up the useful discussions above until now. I have added a starter selection of TemplateData parameters to enable a base map and a first marker with label plus a selection of options. Hopefully this will at least give a way in for visual editors. I think it will always need manual editing to make good use of multiple marks and the more obscure possibilities. Feedback on how much of the possible need this meets would be useful. (What it really wants is a full-blown map-based graphics editor - but don't hold your breath on that one). RobinLeicester (talk) 20:53, 9 August 2025 (UTC)[reply]

Bug: incorrect marker position

Just to inform that I started a discussion about this on the module talk page discussion. Fernando Trebien (talk) 04:34, 6 August 2025 (UTC)[reply]

The issue was primarily affecting dot positions near the edges of southern hemisphere maps. Now fixed in the lua module, but please post details if you are here to say there is unexpected repositioning of marks/dots. RobinLeicester (talk) 15:55, 11 August 2025 (UTC)[reply]

Avoiding a malformed coordinates error

2000km
1243miles

Tahiti United

   

Is there any way I can get the "Tahiti United" label and mark to appear in this {{OSM Location map}} (right) other than setting {{Coord}}'s longitude to 210.5101 and triggering Category:Pages with malformed coordinate tags? A fellow editor at Talk:OFC Professional League diagnosed the problem as, "the map, centered on an east longitude, can't deal with a point having a west longitude," — AFC Vixen 🦊 19:56, 29 August 2025 (UTC)[reply]

I see user:Deor has come alone and unhelpfully without comment here in talk rewritten the code that was used to generate the error probably to remove the error notification. ChaseKiwi (talk) 18:16, 30 August 2025 (UTC)[reply]

2000km
1243miles

Tahiti United

   

Like the second one? – Jonesey95 (talk) 04:17, 30 August 2025 (UTC)[reply]

This looks likely to be a very old issue (bug) with OSM maps. See phabricator:polygon reaching over meridian 180° gets cut off on large map. I have got around by using switching logic etc. ChaseKiwi (talk) 07:48, 30 August 2025 (UTC)[reply]

I have confirmed on zoom out its just a variant of well known bug so you can probably program around it. ChaseKiwi (talk) 07:58, 30 August 2025 (UTC)....I have added code that does not generate malformed coordinate error on third version of map if you comment out the two other versions that do. ChaseKiwi (talk) 08:09, 30 August 2025 (UTC)[reply]

2000km
1243miles

Tahiti United

   

user:AFC Vixen, I'm a bit late to the party with this, but there is a parameter, dateline1=1 that will use the 'normal' longitude value but shift it to the correct hemisphere. I have edited example1 to show this, with the map still centered west of the dateline and the dot to the east. You can use -1 where the opposite it required (and number the dateline parameter to match whichever dots need to be shifted). RobinLeicester (talk) 21:50, 10 September 2025 (UTC)[reply]

Testcases

The clean up of a number of old documentation pages has removed a number of useful test cases which had code that inexperienced users of this complex template could learn from. I suggest that a test cases page be created to which I can contribute some raw json examples and a few templates. ChaseKiwi (talk) 17:08, 1 September 2025 (UTC)[reply]

ChaseKiwi The deletion process was a bit abrupt, but of itself probably made sense. However I have recreated one of your raw json maps on the Template:OSM Location map/examples page (and linked to it from the relevant documentation section). Extra text/info on the topic would be an improvement, and links to articles with such maps would definitely be a big help.

RobinLeicester Had noted and will see if I can add something useful on raw json ChaseKiwi (talk) 11:30, 13 September 2025 (UTC)[reply]

Automatizing population maps

2km
1.2miles

Murgindueta

Itsasperri

Aizkorbe

Zuhatzu

Urritzola

Satrustegi

Izurdiaga

Yábar

Hiriberri Arakil

Etxeberri

Etxarren

Ekai

Eguiarreta

Errotz

   

Settlements in Arakil

Hello! I have started testing this template to create population maps with varying dot sizes according to population. I have prepared to take the information of coordinates, population of the place and overall population of the map (so the dots can be sized according to the global population shown) from Wikidata. You can see an example here (Basque Wikipedia). I was trying to find if this could be further automated, directly using template variables for inclusion (is to say, using |place1= Qxxxxx), but I can't do it, because it needs some {{#if: coding and it seems that those parser functions are solved after the template and the module is generated.

Another solution could be loading places from a wdqs query, but I doubt I can size the dot using that.

If anyone can suggest a way to further automate this, it would be a great use example of the template. Thanks! Theklan (talk) 14:52, 26 December 2025 (UTC)[reply]

Interesting concept which would be generally useful for expressing other comparative data such as GNP. As no editorial rights on Basque Wikipedia can not see your code so can not help unless you put an example of your code in say your en wikipedia sandbox. ChaseKiwi (talk) 16:26, 26 December 2025 (UTC)[reply]

Thanks! I have copied the raw code here: User:Theklan/sandbox Theklan (talk) 08:53, 27 December 2025 (UTC)[reply]

Code does not work on en:Wikipedia - once working, (I think there is more than replacing koord and Wikibase) you might considered if say Module:WikidataIB is safer for the general case in case your template should go in infoboxs willing to have a further look although others will need to help as I think you will have to do it in Lua.

Yes, I know that it doesn't work at enwiki. euwiki has a way more effective Wikidata module, that allows us easy automation of lot of templates. My idea was about simplifying it, but it is still complex, as many labels need specific positioning, and this can't be automatized. -Theklan (talk) 20:58, 27 December 2025 (UTC)[reply]

Thanks so can't help directly but will try your code with {{Wikidatacoord}} as its an interesting idea. ChaseKiwi (talk) 09:01, 28 December 2025 (UTC)[reply]

Just a note that seem to have got working mapping code with sized circles using en:Wikipedia modules so will explore your request and may end up with something useful whatever for en:Wikipedia ChaseKiwi (talk) 10:04, 28 December 2025 (UTC)[reply]

I have added an en:Wikipedia version of your map so others can look at code and perhaps answer your request.ChaseKiwi (talk) 13:12, 28 December 2025 (UTC)[reply]

I have become aware of a week old consensus that {{Wikidatacoord}} will be replaced by {{coord}} as per TFD so have updated code which gets even more concise. I also noted that there were insufficient settlements (as population census subareas) in the Arakil municipality to do more automation of data pulling ChaseKiwi (talk) 17:49, 28 December 2025 (UTC).[reply]

Looks like a great use-case. One approach would be to move all the wikidata invokes inside the Lua module. Each settlement could use a new numbered parameter, eg settlement-data3 etc to supply the Q value for the settlement. It could then auto-populate the coords (avoiding use of any coord templates), size, label names, images, descriptions etc from wikidata Pvalues. The other values (color, shape, label-pos, etc) could use defaults set within the local template, which could still be overidden (as could the auto-populated parameters) for each settlement dot in the same way it currently works. I can give that a try over the next few days if that looks like the right approach. (it might need a user-provided or auto-adjusting size scale value to get the right range of sizes, which ideally would then have a legend item of some sort to show size values, but that could be phase 2...) RobinLeicester (talk) 22:26, 28 December 2025 (UTC)[reply]

2km
1.2miles

Arakil (990)

14

Murgindueta
(5)

13

Itsasperri

12

Aizkorbe (20)

11

Zuhatzu

10

Urritzola (19)

9

Satrustegi

8

Izurdiaga (178)

7

Yábar
(136)

6

Hiriberri Arakil
(114)

5

Etxeberri (60)

4

Etxarren (157)

3

Ekai (34)

2

Eguiarreta

1

Errotz
(67)

   

Settlements in Arakil
Total Arakil population (wikidata:Q1753006) = 990

---

[Hide/show list of settlements]

1

Errotz (67 population)
wikidata:Q3057492

2

Eguiarreta (77 population)
wikidata:Q3049179

3

Ekai (34 population)
wikidata:Q3049559

4

Etxarren (157 population)
wikidata:Q3059419

5

Etxeberri (60 population)
wikidata:Q3059425

6

Hiriberri Arakil (114 population)
wikidata:Q3136229

7

Yábar (136 population)
wikidata:Q3148356

8

Izurdiaga (178 population)
wikidata:Q3156510

9

Satrustegi (53 population)
wikidata:Q3473998

10

Urritzola (19 population)
wikidata:Q3552462

11

Zuhatzu (42 population)
wikidata:Q3576238

12

Aizkorbe (20 population)
wikidata:Q5391015

13

Itsasperri (0 population)
wikidata:Q12259883

14

Murgindueta (5 population)
wikidata:Q12263903

Hi Theklan, Here is what I now have on the sandbox module. The end result looks much the same, but now each settlement just needs its Qvalue, and gets a population-sized dot, plus label, tooltip and fullscreen-extras. As you said, getting the label-pos right is not likely to work with only automatic values, but does allow any level of customising on the settlement dots and any other dot features. It uses the 'municipality' Qvalue to get the total population. Does this take your idea forward? It should work on any wiki with mw.wikibase available. I believe it will bring in the names etc in the language of the calling wiki, but it would be nice to confirm that at some point. I will need to do more checks both for this feature, and any unintended consequences, so if you spot anything untoward, please let me know. RobinLeicester (talk) 21:14, 29 December 2025 (UTC)[reply]

Wow! A lot of movement happened in the last day! I have been busy at work and I found this... which looks really nice and I think easier to use than my heavy code. I'll take a look these days, but it looks very promising. I see that for Ekai, there's a yellow label, maybe because it points to a disambiguation page instead of the real one. Theklan (talk) 21:44, 29 December 2025 (UTC)[reply]

I see two problems now. First, the link and the label can be different things, so both should be loaded. The other one is that the image in the large maps are shown full width. -Theklan (talk) 08:35, 30 December 2025 (UTC)[reply]

Yes the image problem is a bug likely specific to wikidata downloaded images that I was not able to address using templates as its almost certainly only addressable in Lua module code where user: RobinLeicester now has some expertise. He has done well for you and the general case. ChaseKiwi (talk) 12:45, 30 December 2025 (UTC)[reply]

For the images, I believe I am requesting plain commons filenames from wikidata. The module sends a 'File:' instruction with '250px' as the size. If wikidata is adding extra info that would mess this up, but they all look fine on my computer. Is the problem still there on the sandbox version above? I will run some checks.

For the link problem, I don't see a specific wikibase function to get a link rather than a label. I guess there is a separate P number for it. Any offers on what it is, or a good strategy to extract it, as that will be an easy fix if that is known. (Sorry, despite the above outcome, my wikilink knowledge is pretty marginal). RobinLeicester (talk) 15:22, 30 December 2025 (UTC)[reply]

The 250px is working fine after cache clearing in Firefox and Safari so that is likely the issue for user:Theklan. Mobile not an issue as click thru is disabled. User:Theklan will be used to using the eu:wikipedi and having link served up as say https://eu.wikipedia.org/wiki/Errotz in the title. A json dump tells me this link is hidden under P373 under "sitelinks" "euwiki" "url". I have no idea how you would program to access such as its not assigned a Q or P number and as in this case as no link yet exists on en:Wikipedia it implementation creates issues like also seen with the disambiguation link you get the en:Wikipedia and Ekai (which does not yet have an article for the census area) but has two other meanings. ChaseKiwi (talk) 16:29, 30 December 2025 (UTC)[reply]

We use {{#invoke:Wikibase|getSiteLink|Q3576238}} for that. It gets the link and it's done. However, if the link doesn't exist, there could be something like: #ifexist link, if not... don't add a link. Theklan (talk) 17:13, 30 December 2025 (UTC)[reply]

So here is the current state of play - with the new features still only in Sandbox. Thanks Theklan and ChaseKiwi for very helpful input. I will do some tests on various existing uses, looking out for anything untoward. (I have tried to leave all existing stuff unchanged, but you never know. Anything you can spot will help avoid issues when it goes live).

It is aimed at three separate scenarios: 1) using the Qvalue within a set of numbered parameters, as in the example above. Allows lots of customisation, but is not very automation friendly. 2) providing the Qvalues as a single comma-separated list. This allows hand-selection of the sites to include, but can all be done with a single parameter, so is easier to pass from, eg, an info-box. (all other features still work, but not very sensible to use on the list items as it is confusing which number they become). 3) Provide a single 'geo-region' Q value, and the program collects any sub-region Qvalues it contains. Not quite as automated as it sounds as it doesn't know what zoom or coord to use, and wikidata values are far from consistent, so releasing a huge number of bot-produced templates will probably result in lots of bad-looking maps. However, such as it is, below I will put a starter towards documenting the new parameters, so if there can be some trying out with the sandbox version any thoughts or suggestions will be extremely helpful RobinLeicester (talk) 14:03, 3 January 2026 (UTC)[reply]

Parameter	Description
geo-data-type =	default is P1082 (population). other options include number of households (P1538) per capita income (P10622) land area (P2046)
geo-data-list =	this is a comma-separated list of Q values, for a manually generated list that doesn't require nymbered parameters
geo-scalefactor =	can enlarge or shrink all the dots in proportion, depending on what the map needs (default=1)
geo-region =	needs to be a Qvalue of the larger administrative region that the settlements/sub-regions are in. If not present, or if the wikidata page doesn't include the overall total value, the total is the sum of all the shown dot values.
geo-sub-region =	needs to be a Pvalue, but will default to P150 if not supplied (some pages use 'has parts' = P527)
geo-data3 = etc	numbered Qvalue item, for use in conjunction with other shape/label parameters
shapeD =	(same as before). It sets default shape, which might be n-circle to include numbers/auto-caption list. other 'D values can also be used to set color, outline etc
geo-number-size =	will give a fixed size for shape numbers, if they are shown. (defaults to 12 when using proportional dots)
geo-boundaries =	if set to 1 will add the sub-region Qvalues to 'map-data-light', to show the boundaries on the map.
show-geo-dots =	defaults to 1 if there is a geo-region, to use proportional dots. Will be fixed size if 0. (set mark-sizeD=0 to have no dot at all, eg to show labels or boundaries)
find-geo-dots =	1 or 0 (needs to also include geo-region) defaults to 1 but 0 allows for just showing boundaries, for example.
label-posD =	gets additional options: [off] gives no label, [on] will position lower centre, [on+] (or right+ etc) includes numeric values as well as name

RobinLeicester (talk) 14:15, 3 January 2026 (UTC)[reply]

20km
12miles

12

11

10

9

8

6

5

4

3

2

1

   

Relative land area map of South Wales Principal Areas. (Example of type 3. geo-region is the only data-source (with type=P2046 and subregion=P527). It finds all the values for itself (Except Newport, which appears to have a problem with its coords at wikidata).
Total South Wales area (sum of datapoints) = 3,440sq. km

---

[Hide/show list of Principal Areas and their sizes]

1

Bridgend County Borough (250.73sq.km area)
wikidata:Q697126

2

Caerphilly County Borough (277.39sq.km area)
wikidata:Q748065

3

City and County of Cardiff (140.9sq.km area)
wikidata:Q24342199

4

Blaenau Gwent (108.73sq.km area)
wikidata:Q596885

5

Merthyr Tydfil County Borough (111.45sq.km area)
wikidata:Q3306663

6

Neath Port Talbot (441.31sq.km area)
wikidata:Q748078

8

Vale of Glamorgan (331.08sq.km area)
wikidata:Q844784

9

Rhondda Cynon Taf (424.15sq.km area)
wikidata:Q817960

10

Torfaen (125.7sq.km area)
wikidata:Q643919

11

City and County of Swansea (379.66sq.km area)
wikidata:Q10996863

12

Monmouthshire (849.09sq.km area)
wikidata:Q207176

Thanks for the good work. Will do some test cases in my own sandboxes. ChaseKiwi (talk) 14:42, 3 January 2026 (UTC)[reply]