Template talk:OSM Location map

Bug with layering

Currently, in any map using this template (as far as I can tell), there is an issue with layering (z-index) on the maps. The HTML generated for part of the map (the one which includes the labels, as well as a few other things), has a z-index of 1. Meanwhile, the layer which contains the links to Wikimedia, OpenStreetmap, and the actual fullscreen button (which currently only works due to a weird tooltip in the z-index 1 layer of the map). This means that the links are not possible to click (tested in multiple browsers).

To resolve this issue, the classes "mw-kartographer-fullScreen" and "mw-kartographer-attribution" should get z-index of 2, or the elements with those classes in this particular template should have inline styles giving them that z-index. The one thing to be aware of is to not give the element surrounding them z-index of 2, as this would break the labels in the z-index of 1 layer. TheTrueShaman (talk) 22:54, 31 March 2024 (UTC)

TheTrueShaman, Thanks for raising this, although I am not sure if I am understanding correctly, so apologies if the following makes no sense.

The starting point for this template is a system which no longer works, so this design is trying to replicate that by other means. The reason to use it (rather than just using {{maplink}}) is to get access to all sorts of non-maplink features to show on top of the map. It now relies on maplink for the basemap so the first challenge was to get a working overlay, and then to not have wikilinks to unhelpful items. To my mind, a fullscreen maplink which doesn't include the added items would come into that category. The wierd tooltip is the solution I came up with that wiki-links to a second version of maplink, which then also adds in the dots from the location map (potentially ignoring anything an editor decides to exclude, eg river names or neighbouring regions, or whatever). (ie it only works because it has been made to do something specific. It is not just passing through to original maplink link). The other working wikilinks are those which a particular map editor has added within a label, or via a shape. (The List of college bowl games#Map of Division I bowl games is a good example). This is, for better or worse, behaving as intended.

I am aware that my over-limited html knowledge means I don't know about the z-indexes or classes you mention, and am not sure what outcome they might acheive. If the explanation above is missing your point, my apologies, and by all means explain further. But I believe that the various link options are at least doing something useful, if in a slightly roundabout way. RobinLeicester (talk) 17:39, 2 April 2024 (UTC)

Hey RobinLeicester, thanks for the prompt response. If I'm correctly understanding you, you have also correctly understood me (mostly, I think). I now understand why you have implemented the weird tooltip and why the normal fullscreen button doesn't work. I also now understand that what I wanted to do would likely be infeasible (due to the code relying on another template), and would likely not be productive.

However, I still think it would be quite useful to have the links in the bottom right functioning. This is because these links send you to the legal rights pages surrounding these maps: Wikimedia and OpenStreetMap. I find that these links in the bottom right could be quite useful to readers due to them providing information on what they can do with the map data and how it was found. And I think I may have figured out how to do this. Inline CSS!

If you were to put the following code in front of the rest of the template code, this will actually make these links clickable. <style>.mw-kartographer-attribution { z-index:2 } </style>

Now it's up to you to decide if this is a good idea or not. TheTrueShaman (talk) 17:52, 7 April 2024 (UTC)

Thanks, I will give that a go. Looks to makes sense! On a separate issue, and just in case you can make any headway on this, you will see below that Mobile view is not happy with this as currently working. I have found it is not just the fullscreen link that is affected. All the marks and labels are being shunted upwards by 30px, so are currently in completely the wrong places. To get the standard page working I had made a very ungainly cludge with the {{Overlay}} height= parameter, which somehow gets the marks to the right place, (It needs to be frame-height-7 for whatever reason). Initial invetsigation into mobile view suggests that needs to be frame-height-37. (Again, no idea why). But to do this I need to test if mobile is in use, and I have not found a way to discover that. {{If mobile}} doesn't work within a template as the div items it uses just confuses the parser, I think. There is promising looking stuff at https://www.mediawiki.org/wiki/Extension:MobileDetect, but I know nothing about how to get it to work on en:wikipedia, or how to use it in a template if it did. I have not yet had time to pursue this so if you have any insights to offer (or know who to ask) that would be much appreciated. RobinLeicester (talk) 21:42, 7 April 2024 (UTC)

Hello Robin, turns out I gave false hope. I tried adding the styles for elements, but it didn't work because MediaWiki wikis do not allow the <style> tag to turn into HTML, rather forcing it to display as plaintext. Someone else had a similar problem, but they never found a solution either, on stack overflow. I see you also tried too, but failed similarly, so unfortunately I fear that this issue will likely remain until the graph extension comes back.

As for your mobile/desktop detection issue, I'm afraid that the {{If mobile}} template won't work. This is because the entire template relies on css, meaning that no text changes, it just hides text from displaying depending on if you're on desktop or mobile. This means that the template can't be processed in some way to get the page's state and do calculations with that. I'm sorry for being unable to help. TheTrueShaman (talk) 00:05, 8 April 2024 (UTC)

Y, sort of, re links bottom-right of the maps. I have added links to the maps terms of use and OSM page, over the little arrow symbols. It is not a livelink to the words that the maplink page has, but anyone looking for the link would hopefully find where to click. A tooltip pops up on hover as well. RobinLeicester (talk) 13:17, 26 April 2024 (UTC)

Awesome, thanks for finding a workaround! TheTrueShaman (talk) 05:08, 30 April 2024 (UTC)

nolabels?

With the repair of the underlying code and whatnot, is there a glitch with the implementation of |nolabels=? — Fourthords | =Λ= | 16:24, 14 April 2024 (UTC)

Yes, it has not been implemented on the wikimedia mapframe extension, so is currently unavailable. I will try to raise it there - but am a bit unsure who might pick it up. RobinLeicester (talk) 09:52, 15 April 2024 (UTC)

Okay, excellent! I really just wanted to confirm it was a work in progress, and not user error (or user misremembering). Thanks! — Fourthords | =Λ= | 16:40, 15 April 2024 (UTC)

Y, or at least quite a way towards a tick! It currently doesn't work in preview mode! (It didn't occur to me to save non-working attempts to install it). So you need to do all the edits with the labels still there, and only when you submit/save will they vanish. People at phab/T362531 are looking into it, so it may get fully resolved at some point. RobinLeicester (talk) 23:53, 15 April 2024 (UTC)

Oh excellent! It does work when saved, yes, thanks! Follow-up if I may? Since the template's code is being rebuilt and/or mucked-about with, is it possible to fix the previous (and extant) bug where |nolabels=1 doesn't suppress street names at a zoom of 14 or higher? — Fourthords | =Λ= | 04:08, 16 April 2024 (UTC)

Hmm, I very much doubt it. On this bug-fix, the wikimedia guy is simply making available a feature that was put in place years ago. After the non-progress over getting any resources allocated to fix graph, there seems little chance of something involving more delving. However, I have no idea what is involved, so will pass on the request. (discussion is at https://www.mediawiki.org/wiki/Help_talk:Extension:Kartographer in case anyone wishes to join in!) RobinLeicester (talk) 12:51, 16 April 2024 (UTC)

Thanks again so very much! — Fourthords | =Λ= | 13:07, 16 April 2024 (UTC)

Y now working as it should - in both preview and normal. Good work by people at WMF. RobinLeicester (talk) 13:11, 26 April 2024 (UTC)

Qvalue ExternalLines now working on the Frame version

An unexpected outcome of the switch to mapframe for the frame version of the map is that it has become possible to display the administrative boundary lines, etc that are accessed via Wikidata Qvalues. These have long been available on the fullscreen version, although I have no idea just how many people have made use of them. With the ability to show them on the frame version, it seemed wise to proceed with caution in making them suddenly visible. To this end, all such lines are for now a 10% opacity grey line, 6, 9 and 3 pixels wide for map-data, map-data-heavy and map-data-light, respectively. The fullscreen version will continue to draw orange lines of thickness 9 and 3 pixels for light and heavy options, and take user settings for the main map-data. If you are here because of the arrival of wierd lines on you map, this may be the explanation. Are they helpful? Would they be better supressed/need opting in? be given more user control? Getting some idea of how these are (or might be) used would be really interesting. RobinLeicester (talk) 00:11, 18 April 2024 (UTC)

File: error from recent changes

Recent changes to this template or one of its subtemplates have caused this example code:

{{OSM Location map
| coord = {{coord|51.7802|-3.6525}}
| zoom = 14
| width = 280 
| height = 280
| caption =  Map 
|minimap = file bottom right
|mini-file = Wales relief location map.jpg
}}

to result in output that includes this bogus wikitext:

[[file:Invisible Square.svg|10px|alt=[[File:Wales relief location map.jpg]]|link=File:Wales relief location map.jpg|[[File:Wales relief location map.jpg]]]]

– Jonesey95 (talk) 18:15, 25 April 2024 (UTC)

RobinLeicester: There are almost 350 articles affected by this, so please see what you can do right away. —Anomalocaris (talk) 20:39, 25 April 2024 (UTC)

Sorry - seemed like a useful benefit from a better tooltip solution - but clearly with very unhappy consequences on certain pages. I have reverted the edit, so hopefully back to normal now. I will leave well alone at this point. Sorry for delay in getting to it. RobinLeicester (talk) 20:53, 25 April 2024 (UTC)

Adjustment to css that draws centered text to solve a missing-link problem

A 'hidden' problem was causing wikilinks to have no link, on maps with lots of dots. It turned out to be caused by a previous solution used to center text, which allocated arbitrary width values wide enough to ensure the text could then be centered. This was creating invisible strips across the map, blanking out any link areas below. A more diligent search of inline css options finally unearthed a solution. For the record, it now uses width: fit-content; text-align: center; transform: translateX(-50%) to set the width to match the actual text and move it to the left by half of that width. This is now the method that positions numbers on dots, and any top, bottom and center labels. In an ideal world, the same method could be rolled out for other text-position needs, but these don't need to define 'width', so for now the rest can be left well alone. RobinLeicester (talk) 00:03, 30 April 2024 (UTC)

Arrows?

Is there a canonical way to represent an arrow pointing from one location to another? I could hack it with an arc and a marker, but that doesn't seem right to do. Remsense诉 16:27, 7 June 2024 (UTC)

Good question. If you use the 'mark-line' option (draw a line from a mark to the mark-number preceeding it), you can put an elongated triangle at one end. example:

|mark-coord2 = {{coord|51.5828|-3.7454}}
|mark-size2=8
|shape2=circle
|shape-color2=hard blue
|mark-title2 = none

|mark-coord3 = {{coord|51.5628|-3.7254}}
|mark-size3=12,35
|shape3=i-triangle
|shape-angle3=145
|shape-color3=hard blue
|shape-outline3=hard blue,0
|label-pos3=left,mark-line,2
|mark-title3 = none

This puts a small circle at the 'mark2' point (set mark-size2=0 to remove), and a blue arrow at 'mark3', with a 2px line between them. It needs trial and error with shape-angle3 to get the arrowhead to align, and all the options can be adjusted to suit the need. (nb copy from source. formatting now gets mangled in 'talk' pages, apparently). I would be interested to hear how you get on. RobinLeicester (talk) 14:40, 8 June 2024 (UTC)

Thank you! I have a few instances where I really want to use this template, I'll let you know the results I get. Remsense诉 02:55, 9 June 2024 (UTC)

1km
0.6miles

   

The idea was too good to resist, so I have added a 'curved-arc-with-arrow' shape as a single shape option.

|shape1 = curveC <!-- curveC is clockwise, or curveA is anticlockwise-->
|mark-size1 = 85 <!-- distance from tail to tip (very roughly!), in pixels -->
|shape-angle1=194 <!-- rotates the arc+arrow around a notional mid-point -->
|shape-outline1=dark grey,4,50,solid <!-- set the outline attributes for color,line-width,opacity%,css-style

Use coords to position a mid-point, then it requires quite a bit of trail and error with mark-size and shape-angle RobinLeicester (talk) 16:10, 12 June 2024 (UTC)

That's brilliant (as usual with your great work). Off to give it a try on the article Mýrdalsjökull which in my recent view needed a tidy up before the next major jökulhlaup. If it works some other jökulhlaup, land slip and lahar articles may be improved. ChaseKiwi (talk) 18:42, 12 June 2024 (UTC)

My work using this has detected a general bug in the overlay which appears to have an invisible and non indexed line element in the top left hand corner that is made visible by non default implementation of the parameter shape-outline= color,line-thickness,opacity,css-style parameter. This can be seen in any of the test cases now I know how to look for it but is often close to invisible by the default pastel shading and the default 1 pixel size. Any increase in line thickness to say value of 10 and change to a hard colour with 0% opacity shows the bug. Hopefully its in the overlay code of this template rather than other's overlay code so will be easy to fix. I had delayed posting in case I could identify the buggy code as it looks like the type of test case a developer might have left in code and forgotten to remove ChaseKiwi (talk) 07:26, 14 June 2024 (UTC)

PS element has px coordinates 4,4 at a guess ChaseKiwi (talk) 07:31, 14 June 2024 (UTC)

Another great piece of debug analysis. Thanks. The extra div elements for curve means it uses a different routine from the main shape switch-block, and the outline-width was ending up being used in the main block as well. I have set it back to invisible, and will try and spot where it might be coming from. RobinLeicester (talk) 15:17, 14 June 2024 (UTC)

Wow, that's really neat! I've since adapted your example to produce what's now at the top of History of the Chinese language, which I feel is much better than the cluttered SVG it replaced. Remsense诉 08:00, 14 June 2024 (UTC)

ruleA is also now available, using the same principle as curveA, ie control is the mid-point, with mark-size, shape-angle and shape-outline attributes available: The example above now includes |shape2 = ruleA (both set to size=85!) RobinLeicester (talk) 00:05, 20 June 2024 (UTC)

first point not showing?

5000km
3,100miles

Manila

Vancouver

  

Can I get an assist on why this isn't working like I expect? — Fourthords | =Λ= | 01:37, 30 June 2024 (UTC)

This is due to well known mapping feature (bugs) that has annoyed us Pacific centric contributors for decades and nothing to do with the template. Unhappily there is inconsistency in how the transition at 180 degrees is handled between image and real map and so no one has addressed it for consistent transition as it would be a very large bit of work. The mark is shown but is off map to the west. You also have an invisible label at 0,0 (different size as you have not defined default size parameter mark-sizeD=10 with your code and started label=, label1=).

Code that works in edit mode for the map center coordinates you choose that reads as a nonsense is pedantically: {{OSM location map |coord={{coord|31.9229|178.9386}} |zoom=1 |float=right |width=228 |height=350 |mark-sizeD=10 |label=Vancouver |mark-coord={{coord|49.25|236.9}} |label1=Manila |mark-coord1={{coord|14.5958|120.9772}}}} (if you go one degree other way for map center coords eg -179 long, then its Manila that needs nonsense long coord) You need another bit of code for image display being right. Only answer is something like this code for one map ChaseKiwi (talk) 11:06, 30 June 2024 (UTC)

see for example https://phabricator.wikimedia.org/T195654 ChaseKiwi (talk) 11:17, 30 June 2024 (UTC)

Well, that's frustrating and unfortunate. I was hoping to replace a rather-wonky implementation of {{location map+}}, but I guess it's still better for the time being. Thanks! (It's also a relief to learn it wasn't user error!) — Fourthords | =Λ= | 16:56, 30 June 2024 (UTC)

At least within this template, I would be up for seeing if this can be improved. (The fullscreen version is a different issue, and outside my scope) I am trying to work out what the solution should look like, and if it should be automated or manual. And if the map is wide enough, (zoom 0 and 1) should the dots repeat? I am away for a couple of weeks, but if there is a solution that doesn't bring unwanted side-effects, I could see if I can try to implement it when I am back. RobinLeicester (talk) 23:30, 5 July 2024 (UTC)

It can be programmed around at least for raw json OSM data. I did it for a polygon or two as in top map display on page Havre Trough just to prove it possible, so I suppose location markers could be duplicated too in code. The click through display would always have artefact location markers at beyond full zoom out necessary to show the whole world when you start tiling world maps. ChaseKiwi (talk) 11:56, 7 July 2024 (UTC)

10 000km
6,000miles

Vancouver

Manila

Manila

  

ChaseKiwi, I would welcome thoughts on a test fix for the anti-merridian problem (although I have used the easier but less correct 'dateline' terminology.) My idea is to use an additional parameter, 'dateline', that can be -1, 0 or 1 (default =0), which will either add or subtract 360 to the longitude of a marker if 1 or -1 is set. The upper map in this section is now showing the sandbox version, with dateline+/- implemented up to mark-coord2. Switching the map centre to -179 would need removal of dateline1=1 and adding dateline2=-1 for Manilla, but the coordinates themselves can all be left as correct values. I have also messed around with a zoom zero map that keeps going, but needs each iteration of the dot to be added separately. You will see it also moves the fullscreen dot to the correct place, but at present that has the adjusted coord in the tooltip - may be solvable with a bit of effort.

Question is: Is it too confusing to get your head round? That may not matter so much if it meets the need, and is better than hard-coding the oversized longitudes. (I seem to remember that out of range coord values get flagged up somewhere, so it would avoid that). But does it feel useable.

It is only on the sandbox version at present, so now is a good time to spot or iron out concerns before it is live. RobinLeicester (talk) 00:30, 23 July 2024 (UTC)

Ok - see Template:OSM Location map/sandbox/testcases which I created to mitigate server load issues in testing multiple boundary cases at once. Its not working for marker objects but fine for marker labels unless I have made a coding mistake. I assume the invisible marker objects are just overlying dublicates as dateline variable not working for them. As to the average map user understanding the complexity here I am not hopeful but it will in due course give the functionality.ChaseKiwi (talk) 19:43, 23 July 2024 (UTC)

Good work on the testcases. I have now rolled out marks 3 to 10, (which is why not all your dateline tests were showing up). I believe it is all working as expected, but let me know if you think not. The coords get converted to x,y values before any of the graphical elements are done, so provided the right combination of coord and dateline is in place, all the graphics 'should' work as normal, and not worry about where the dateline is. (This is not true of the multi-element graphics in maplink etc, as you have well demonstrated elsewhere).

The only item that will not work with dateline is 'mark-line', drawing a line to the previous dot. I am yet to be convinced anyone will use this method for drawing lines, so am inclined to ignore it for now, unless there is a clamour for it to be available! RobinLeicester (talk) 12:55, 25 July 2024 (UTC)

Ok its working with marks with the Template:coords but not where marks have their lat and log separately specified. Once you have it working for all the test cases on the right I might think more about the potential mark-line impact - perhaps someone will want to map twin cities, cable or major trade routes across the Pacific Rim. I am probably more used to Pacific centric maps than you. ChaseKiwi (talk) 21:57, 25 July 2024 (UTC)

Ok, the markline is looking good now in your code boundary tests. I did try to represent ocean currents with a CurveA and was able to rescue to be as intended the display with a dateline =1. Can not explain southern hemisphere mark cut off issue but it is a long standing bug that you are now no doubt working on. ChaseKiwi (talk) 17:22, 27 July 2024 (UTC)

Back from a wikibreak, and looking again at this. What is the southern hemisphere mark cut off issue? (I am happy to work on it, but haven't spotted the problem!) RobinLeicester (talk) 23:04, 20 August 2024 (UTC)

Not your fault - n-square marksize needs to be 12 or more to render without number cut off at bottom issues- you just put the smaller marksize 10 markers to the southChaseKiwi (talk) 17:49, 22 August 2024 (UTC)

Bug in label lines for mark 46

I found an error in a map I created (here) that prevents the appearance of a with-line or n-line for the label for mark-coord46 (and only 46; it works fine for all other numbers I've tried). The label shows up as though the coordinates for the label's with-line or n-line are set to 0. I worked around it by changing the number of the map mark in question to 49, leaving a gap in my number key. Amasea (talk) 21:41, 9 August 2024 (UTC)

Y fixed. Thanks Amasea for spotting and reporting that. It was a tiny 'copy-and-paste' coding error. RobinLeicester (talk) 22:51, 20 August 2024 (UTC)

Template-protected edit request on 10 August 2024

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)

 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)

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)

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)

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)

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

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

Border of maps

Hi, How we can show borders of an area from OpenStreetMap Wikidata. Something like this border:

Here, border of Shiraz city has been shown. Thanks, Hooman Mallahzadeh (talk) 07:20, 24 August 2024 (UTC)

@RobinLeicester@El C Hi, if this capability has not implemented till now, I really propose to implement that. It is really beneficial and is necessary. Thanks, Hooman Mallahzadeh (talk) 16:44, 26 August 2024 (UTC)

The maplink template that is being overlaid is at the moment presumably being passed the overlay markers for click through which as I understand maplink precludes the passing of other parameters. A completely new template that uses maplink to pass the same modified OCM map to both the overlay and background click through map and never passes the overlay markers well might be possible now Robin gave us all a CSS interactive live solution and raises interesting possibilities with raw json data which I am more interested in than the maplink type=shape|id= syntax you are interested in. Whatever quite beyond me, so you are welcome. ChaseKiwi (talk) 20:28, 26 August 2024 (UTC)

I probably wrote too soon above - you should be able to to something useful with the map-data option using standard wikidata (ie map-data=Q6397066) but it will only show as a line border (orange by default but this can be changed) You will not get shape-inverse etc functionality as far as I understand it. ChaseKiwi (talk) 20:58, 26 August 2024 (UTC)

@ChaseKiwi I did all you said but nothing happened for the border of this map:

240m
262yds

11

10

9

8

7

6

5

4

3

2

1

   

فهرست سازه‌های تخت جمشید

1

پلکان ورودی

2

دروازه ملل

3

کاخ آپادانا

4

کاخ صد ستون

5

کاخ تچر

6

کاخ سه دروازه

7

کاخ هدیش

8

کاخ ملکه و موزه پارسه

9

نقش بارعام خشیایارشاه

10

آرامگاه اردشیر سوم

11

آرامگاه اردشیر دوم

How your solution works for border? Would you please apply that? Thanks, Hooman Mallahzadeh (talk) 11:32, 27 August 2024 (UTC) Yes while not my solution, it works with the default gray outline (10% opacity grey line, 3 pixels wide) as used to minimise potential artifact. On click through it displays the outline as expected, modified by adjustable parameters in this case in red. I have used the Shiraz data item at Q6397066 as I have not got a clue what the data item Q129072 is (can't even find it on a world map so guess it may be malformed). Anyway now aware of geography between Marvdasht and Seyedan.

16km
9.9miles

1

   

Hooman Mallahzadeh thanks for asking about the maplink shape-inverse, which is something I had previously looked at but not implemented. You will see in the example above, that it is now available in these templates (Y). They use 'map-data-inverse=Q6397066' to show the area occupied by Shiraz. To my surprise it also works for Persepolis (Q129072), as shown in the zoomed in version. (I was not confident it would have an OSM tag implemented, so maybe we have you to thank for that.) As noted above, not all Q values will have a valid OSM boundary to display, and/or may not have been linked (within OpenStreetMap) to its Q value, in which case it will not show on the map.

I have intentionally given no extra options on these map-data items, as I am trying to keep feature-creep to a minimum, to avoid overloading the template size. You will see that I have gone for much thinner lines and paler overlay than the maplink default. I find that to be too dark and heavy, but it can be adjusted if this looks too subtle.

In terms of the geojson coding, this uses 'geomask', rather than the 'geoline' of the other mapdata items, and has a 10% opacity fill, and 50% opacity 1px line, all of which use color #555555 and are hard-coded values. RobinLeicester (talk) 22:57, 2 September 2024 (UTC)

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)

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

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)

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)

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)

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)

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

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)

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)

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)

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

NBC

34

38

soft blue

39

hard blue

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)