Template talk:OSM Location map

Alternative map syntax

RobinLeicester, per Wikipedia:Coordinates in infoboxes, the use of |lat= and |lon= is deprecated in infoboxes. I realise that this isn't an infobox, but I think it would be useful to allow the use of |coord={{coord|...}} if desired. Location map has this feature. I have created a version in the sandbox which does this, and as far as I can tell, it produces the same results (see the testcases). do you see any issues with enabling this feature in the main template? thank you. Frietjes (talk) 16:07, 4 February 2017 (UTC)

Frietjes, I can see that there are benefits with consistency and adding the ability to cope with d|m|s values. With many of the uses, the first coordinate will often be a random point defining the centre of the map - which may not be of anywhere in particular. Will that confuse the ways Coord makes use of data? I am not well up on what coord does, but had an idea it does more than simply format the numbers. I also couldn't work out how the #invoke line worked, or even what the testcases page was actually showing - sorry I am not very well up on such things. I presume it could be deployed by a search and replace process on the actual template, rather than the way the sandbox does things. You will have seen from the way the template is written that I am pretty marginal in knowing how to bend the thing to my will!

if you would like to make it happen, please carry on. Certainly all the examples look like direct equivalents. I presume there is no pressure here to remove the lat and lon option, but rather to add coord as an alternative? (The {{graph:Street map with marks}} that this uses, uses lat and lon, as does <maplink>) RobinLeicester (talk) 23:24, 5 February 2017 (UTC)

RobinLeicester, no, there is no pressure to remove the old syntax. each section of the testcases are showing a comparison of the main and sandbox template using the lat/lon (first comparison) and coord (second comparison) syntax. since the main template does not yet support the coord syntax, that example is showing nonsense right now. the {{coord}} template generates a link and metadata that includes the lat/lon information. the {{#invoke:coordinates|coord2text}} extracts the lat and lon information as text. so, someone can specify the coordinates in any format supported by {{coord}} and we can extract the equivalent lat/lon in degrees from it. to make all this happen, we just need to update the template here, and not all the transcluding articles. I will go forward with the update within the next few days if there aren't any problems with the new code. Frietjes (talk) 16:46, 6 February 2017 (UTC)

Frietjes, I have added another testcase example which shows a problem with removing the local defaults. The idea is that the mark1 parameters act as a localised default to save having to set all the elements individually for other marks. They will be specific to that map, but all similar items can inherit those marks, and can then all be altered by one quick edit. (the un-numbered one might be used as an overlay image, under all the other marks, so needs to not be the 'master' setting - e.g see Leicester Castle.) I would say the feature should be retained - it would break quite a few maps that are already in place. But thanks for your involvement. The coord feature looks fine. If you are working on it, I will hold fire with any other edits for now, to avoid edit conflicts. RobinLeicester (talk) 00:45, 7 February 2017 (UTC)

RobinLeicester, I updated the defaults in the sandbox [1]. is that better? Frietjes (talk) 01:11, 7 February 2017 (UTC)

Frietjes, It works ... but are you proposing to retain a 'pass-on' layer as the sandbox currently does, with the core subpage being retained? I can see how an extra layer simplifies this edit process, but is there a risk that having both layers will start to complicate things when something else needs sorting out? I had assumed the intention was to embed the coord instructions into the main template page. RobinLeicester (talk) 01:28, 7 February 2017 (UTC)

RobinLeicester, I was planning to keep the two layer structure since (1) it helps ensure that the defaults are uniform (for example, search the current code for mini-width, mini-height, and width and you will find differing values), and (2) reduces the code complexity for the new |coord= feature. the second reason is really the main reason for having two layers. imagine if everywhere you had a {{{lat|0}}} you had to replace that with {{#if:{{{coord|}}}{{{coordinates|}}}|{{#invoke:coordinates|coord2text|{{{coord|}}}{{{coordinates|}}}|lat}}|{{{lat|0}}}}}. not only would that make the code less readable, it would increase the number of times that module:coordinates would be called to fetch the latitude. Frietjes (talk) 13:47, 7 February 2017 (UTC)

Frietjes, That all makes sense. I think I have not quite got my head around what actually goes on with the coord stuff, and how it does what it does, but I am pleased with the outcome. The default mini-widths don't really matter as any mini-map will need to spell out its width and height. When the dust has settled on the switchover, I will go back over the other parameters to check which could be given defaults. RobinLeicester (talk) 18:22, 7 February 2017 (UTC)

Frietjes, Thanks for the transfer. Unfortunately I had naively assumed this solved the problem of empty parameters, and had cheerfully slimmed down various bits. Only then did I discover that mark-size= , for example, would not pick up the default values, and so caused syntax errors in the calculations. I have added some #if statements in the core page, which gets round it for the ones I have done (only up to mark-size2 so far), but just wanted to check there wasn't some better way of solving the problem. (If you look at test4 on the testcases, you will could try deleting the value in mark-size3 and will see the result.) Any suggestions would be welcome, or I can go through and put the ifs on the rest of the items. RobinLeicester (talk) 02:19, 9 February 2017 (UTC)

RobinLeicester, you can use {{if empty}} to have it take the first non-blank value in a list. I put this in the top level template, so the core template can assume that those particular parameters will always have non-blank values. Frietjes (talk) 13:36, 9 February 2017 (UTC)

RobinLeicester, should |zoom=<blank> be the same as |zoom=0? if so, we can simplify that part of the code. Frietjes (talk) 13:39, 9 February 2017 (UTC)

Frietjes, {{if empty}} is ideal, thanks. I have gone through and applied it to a few other params. Zoom can just default to 0, so I have removed the NULL stuff from that. I will update the documentation with the coord stuff, and have a browse around some of the live maps to make sure they have not become unhappy. RobinLeicester (talk) 16:26, 9 February 2017 (UTC)

Map interactivity on article

Asking out of curiosity... What's stopping this from functioning like this map? (note the ability to pan immediately after loading the page) Rehman 10:00, 18 February 2018 (UTC)

Reh, it's a decision made by the maps team due to the demands of maps on Wikipedia being much larger than smaller wiki's like Meta and Wikivoyage. CKoerner (WMF) (talk) 10:28, 20 May 2018 (UTC)

Thanks for the reply, Chris. It would be so great if this will be enabled on enwiki someday. Cheers, Rehman 15:04, 20 May 2018 (UTC)

For others interested in what I mentioned above, {{Infobox mapframe}} does the magic. I'll leave the discussion on whether they should be merged, to the good folks behind those templates. Rehman 01:03, 1 September 2018 (UTC)

Base map for overlay?

I am considering making an overlay, but need some advice on how to obtain the proper base map. ♦ J. Johnson (JJ) (talk) 20:23, 15 July 2018 (UTC)

Bugs

I just fixed (here) in {{OSM_Location_map/core}} a bug that preventing setting |shape23=.

And I invite eyes on something else I saw at {{OSM_Location_map/Labelitem}} that looks odd. At the bottom (following the last #switch) there is a single '}' and a single '{' which look like they should be doubled:

{{#ifeq:{{{mark-size|0}}}|0|
 |{{#if:{{{numbered|}}}
  |{{#switch:{{{numbered|}}}|0=| },
{
 "lat": {{{mark-lat|0}}},
 ...

♦ J. Johnson (JJ) (talk) 20:52, 26 August 2018 (UTC)

BTW, I have a case where if the "mark1" is left out there is an error: <maplink> Couldn't parse JSON: Syntax error. If anyone is interested I can provide details. ♦ J. Johnson (JJ) (talk) 21:12, 26 August 2018 (UTC)

Notice

Just a heads up for anyone watching: I'm going add a line to the template to categorize articles using. Also am looking at a tweak or two in the documentation. And I am working up some instructions on how to create overlay files (at User:J. Johnson/OSM overlay how-to); this would be a good point to critique it. ♦ J. Johnson (JJ) (talk) 17:55, 29 August 2018 (UTC)

• The template now includes articles using it in Category:Articles containing OSM location maps. Currently that includes 602 articles. ♦ J. Johnson (JJ) (talk) 22:58, 31 August 2018 (UTC)

Proposed change to handling of defaults

I am considering changing how this template handles default values for numbered marks. Currently the parameters for the numbered marks have built-in defaults, but any values set for mark1 become the defaults for the rest of the numbered marks. In trying out this template I have found this behavior to be less convenient than might have been expected, especially, if one wants mark1 to be different in some way. So, for each of these parameters I would like to add a parameter for explicitly setting a default – such as 'mark-shape-def' – that has no effect if not set, but otherwise overrides any value set in mark1. Comments? ♦ J. Johnson (JJ) (talk) 20:08, 6 September 2018 (UTC)

Copy edit

I have extensively edited this page, with end users on mobile phones in mind. If we start adding the template intoschools info boxes there will be a lot of effort spent tweaking- and possibly on phones. If I run a training session- I don't want to produce more slides than are absolutely necessary and will refer the difficult questions to this page- so I am attempting to head off the problems by having a user friendly page. Please try to keep examples and their code in sync. Cheers,--ClemRutter (talk) 22:43, 1 December 2018 (UTC)

Odd blank map bug

Please see the discussion at the Village pump regarding a bug in the template. Nehme₁₄₉₉ (talk) 18:30, 2 May 2019 (UTC)

Full screen link so tiny?

Why is the full screen link so tiny? The whole map should be clickable... can we do this technically?--Kozuch (talk) 19:33, 2 August 2019 (UTC)

"Full screen" should be "Interactive map"

That would be far more meaningful for readers. I have recently spent a few days arguing that an article should have coordinates because that's the only way to provide access to interactive mapping tools. Yes, I should have investigated the features of the OSM map thoroughly first, but I somewhat reasonably assumed that "Full screen" would only give me a full screen version of the same thing. Many readers will make the same mistake.

Readers will infer "full screen" from "interactive map" far more readily than the reverse. But, if you prefer "Full screen interactive map", I could live with that, too. ―Mandruss ☎ 05:05, 27 April 2020 (UTC)

Minimap- left or right.

The documentation is clear-the minimap is put in the bottom left hand corner, and we cannot change it. Every page I have seen recently displays it to the right. I have hit a rare occasion where I want to move it to the left. Can it be done- if so how? I was playing with it in My sandbox if anyone wants to look.--ClemRutter (talk) 12:53, 4 August 2020 (UTC)

Apologies ClemRutter - documentation was clear but wrong (and inexcusably so). I have corrected the documentation - It can only be on the right. I would love to make it moveable, but it is such a cludge implementation already that I think it would be painful (and potentially unsuccesful) to code for either side. However, I will take a look, and see if it is possible, and if the whole minimap thing might be improved, eg optionally using x and y as percentage rather than pixels. RobinLeicester (talk) 17:02, 2 November 2020 (UTC)

ClemRutter - in case you are still interested, the minimap can now live on any of the four corners, by using minimap=file bottom left, or whichever is preferred. Positioning the locator dot has also been improved with use of minipog-gx and -gy to allow grid values 0-100 whatever the size of the minimap. RobinLeicester (talk) 01:35, 18 November 2020 (UTC)

Shapes

Should the shape elements display the Wikidata reference when clicked on?

Thanks --The Equalizer (talk) 11:42, 15 February 2021 (UTC)

Label wikilinks

For labels, the doc says "No inline formatting, line wrapping, or other tags, links etc. are possible.". Why aren't wikilinks possible? If they were, it would allow for the substituting in of this template for Template:Location map, which often has wikilinks for labels, in cases where the option of an interactive map would be an improvement but not at the cost of the links. —Somnifuguist (talk) 13:57, 17 June 2021 (UTC)

Static map does not use local wiki language version used by maplink template

Static map does not use  local wiki language version used by maplink template. This is a limitation for use in non english Wikis Arjunaraoc (talk) 05:58, 21 June 2021 (UTC)

0,0 coords

In checking coordinates of river articles for errors, I have found a few articles using this template that are putting coordinates in the article at 0°N 0°E / 0; 0. Could there be something in the template code that is adding an extra coordinate?

See Dhanshiri River, as an example. It shows up on the map of Category:Rivers of Bangladesh, ie map.

-- Talk to G Moore 21:31, 2 July 2021 (UTC)

@G. Moore: I encountered this as well. It's now hopefully fixed with this edit to the template. It might take some time for the cache to clear and the 0,0 coord to be removed from the map you linked. —Somnifuguist (talk) 02:45, 21 August 2021 (UTC)

Previewing the map does not work if editing with 'New wikitext mode' (beta)

I just noticed that the OSM Location map does not show up on preview (it loads forever) if editing with the 'New wikitext mode' that's available under Special:Preferences/Beta features. Is this something that the template hackers here can fix, or should I report it to the Visual Editor people? Thanks, AxelBoldt (talk) 00:45, 29 August 2021 (UTC)

AxelBoldt, I have not delved into the New wikitext mode, and alas, I have no understanding of where a solution might be looked for. A couple of years ago there were problems with the mobile version not displaying the maps because it was not picking up the frame size from the underlying 'Graph' modules. A Css fix (kludge?) resolved that one, but it may be this is having a similar problem in some way. If you want to see more on that fix, or feed it back to the Visual Editor people, it is documented at https://www.mediawiki.org/wiki/Template_talk:Graph:Street_map_with_marks. RobinLeicester (talk) 19:48, 14 October 2021 (UTC)

WTF happened to the Great Lakes?

While browsing articles on Michigan highways, I noticed that the map appears to struggle to display Lake Huron, Lake Superior, and Lake Michigan at certain zoom levels, including displaying part of Lake Huron as a state park. I don't know when this started, or what is causing it, but it's a very weird error. casualdejekyll (talk) 03:33, 19 September 2021 (UTC)

Casualdejekyll This has been quite a longstanding issue, affecting various lakes at different times. Very frustrating that it remains unresolved. It is not anything this template can affect, as the maps just 'arrive' from the underlying Kartographer mapping system. There is an example of where the issue has been raised at https://phabricator.wikimedia.org/T267506. RobinLeicester (talk) 19:34, 14 October 2021 (UTC)

Small text size

Is there a way to increase the default size of the text below the map to at least 85%. The names of the mark-titles seem to display far smaller than the minimum needed for accessibility (MOS:SMALL). An example of this is in the 'Numbered dots' section in the documentation (the map of Listed buildings in Stoneygate). EdwardUK (talk) 00:10, 12 October 2021 (UTC)

EdwardUK, Yes, they do seem to be smaller than they used to be. Has there been a style change to make captions smaller? At a one off level, an editor can add, for example, a <span style="font-size:120%"> into the 'caption=' line, and this will carry through to enlarge the numbered lists as well. That would only affect that individual item. I am more inclined to edit the template to make the list the same size as the rest of the caption, so that all lists get enlarged - but I am not sure if that will mess up some pages. I will have a look at a few 'in use' pages and see if that could be a problem. Thanks for highlighting the issue. RobinLeicester (talk) 10:11, 13 October 2021 (UTC)

Now fixed. An otherwise very helpful editor had inadvertantly shrunk the caption instead of the 'interactive full screen' text. Hopefully this is now as it should be.

Label Text Color

While I agree with the need to create a consistent style, what is reasoning behind the suggestion that the colors should blend in to the background map? If anything, the labels should stand out, as the goal is to make the information being displayed obvious. Using the same color scheme as the base map means that it is unclear what information presented on the map is relevant to the article. (While I could understand if color-blindness legibility was the goal, this is not mentioned as a justification.)

I would suggest using black as the default color instead. If nothing else, I would strongly recommend that it be changed to something else from red, as this is confusing because it makes the label look like a red link to an unwritten article. –Noha307 (talk) 01:06, 1 November 2021 (UTC)

Good observations Noha307, and the redlink problem in particular is a good enough justification to change that to black. (It was mainly a result of leaving a default alone in the underlying stuff, and it has just drifted on - that and the fact it is often used with a red pog, which gives a bit of a tie-in). I will have a go at setting default to either black or a deep grey, and see what reaction it gets.

The theory on the 'blending in' colours is that all labels that are not 'the subject' of the map should feel like they are just part of the map itself, rather than shouting for your attention. Doesn't always hold true, and there are so many use cases that it may often be better for an individual map to go its own way. The potential advantage of having the colors set using labels is that if the base map were to be radically re-colored the labels could be adapted globally to match, if the colour labels are used. (nb. I think in the main people either use the primary colour labels, set their own #values, or leave it on default). RobinLeicester (talk) 18:13, 1 November 2021 (UTC)

Label colours now default to #222211, slightly softer than the very harsh look from actual black. Any opinions from anyone who noticed the change?RobinLeicester (talk) 18:28, 1 November 2021 (UTC)

Place names now in the same language as the wiki

The maps now have access to multiple language/script versions of place names, where these are supplied by Open Street Map. Until now only the 'local' version of these names has been available. On an English language wiki, for example, this was a particular problem in parts of India, China, and various south-east Asian countries, unless the reader happens to know the script being used. In 2018 the mapping improvements to {{Maplink}} created a range of localising options, the default being that the map will select what is most likely to be useful to the user's language preference and the language of the wiki in question. This was not possible on the parallel mapping system used by OSM Location Map, because a system called 'graphoid' that rendered the maps had become un-updatable for some reason.

Over recent years the decision was made to abandon graphoid, and now all maps are generated on the fly (with possibly a bit of caching on busy pages...?) You may find that pages with maps now take longer to load, but with much-improved resolution especially noticeable with small text. It also means that with graphoid out of the way, the 'locally internationalised' place names could be made available. A technical edit to the underlying {{Graph:Street map with marks}} by a knowledable editor/coder User:TheDJ has now put this in place for these maps. I believe this will be a big improvement for all south-east Asian maps especially. Big thanks to TheDJ. Please comment below if you notice either the improvement, or any drawbacks or situations where it is not doing what it should (eg for the many fabulous maps by Chandan Guha). (nb if there are no English versions of a particular place added to Open Street Map, it will still show the local script). RobinLeicester (talk) 12:55, 21 January 2022 (UTC)

Font on the map

Can one change the font on the map using custom CSS? --Mahmudmasri (talk) 21:15, 21 March 2022 (UTC)

Bug in zoom levels 0 and 1: bogus red mark

Please see

10 000km
6,000miles

  

{{OSM Location map  
| coord = {{coord|53.4146|-4.3341}}
|  zoom = 0
|mark-coord = {{coord|-89|0}}
}}

There shouldn't be a red mark here. I have only seen this bug in zoom levels 0 and 1. AxelBoldt (talk) 23:34, 1 July 2022 (UTC)

Any use of either un-numbered mark or mark1 will re-assign it to the desired location. If you really need a blank mercator projection of the whole world, you can hide the mark at the south pole, as I have done to the example. (Maplink is very fussy about syntax, and I can't find a way of reliably having no marks at all) RobinLeicester (talk) 00:59, 11 February 2024 (UTC)

Numbered dots, autocaptioning

With the numbered dots feature of this excellent template it seems that each new label in the autocaption appears on a new line. This rapidly makes the captions very long (e.g. Herea_Te_Heuheu_Tūkino_I#The_name_Te_Heuheu or Fritzens-Sanzeno_culture#Extent), which wastes a lot of space on the page. It would be great if it were possible to have multiple items appear on a single line. Furius (talk) 02:10, 20 November 2022 (UTC)

Furius, Sorry it has taken so long to address this. It is possible to add a multi-column instruction to the caption, which will carry through to the numbered entries. eg caption=Places in the life of Herea {{div col| colwidth=10em}}

The 10em sets a width value for the column, and it then fits as many columns as your width can accomodate. By putting it after the main caption text, the columns will only apply to the numbered entries below that. RobinLeicester (talk) 00:45, 11 February 2024 (UTC)

My mind is blown! That is very nearly perfect! ... I feel bad to say this, but there is one tiny problem - adding this to the caption seem to defloat the map, as you can see here: Herea_Te_Heuheu_Tūkino_I#Life. This is far from a fatal problem, but I raise it in case there's an easy solution. Furius (talk) 01:04, 11 February 2024 (UTC)

Not bad, but helpful. User input is the best input. The answer (at least as a 'fudge') is to put a {{div col end}} at the end of the final mark-title. You will see I did this on your page. I had hoped the end of the box meant it wouldn't need it, but it clearly left something in a slightly broken state. I am also perplexed about the un-needed gap after the top caption. I will investigate this at some point. RobinLeicester (talk) 01:45, 11 February 2024 (UTC)

This is absolutely brilliant. Thanks so much! Furius (talk) 01:48, 11 February 2024 (UTC)

Clever workaround. This hack was causing <small>...</small> tags to be misnested, but luckily, they were making the text too small to comply with MOS:SMALLTEXT, so I have removed them to comply with this accessibility guideline. I also adjusted other text that was rendering at smaller than 85% of the default font size. – Jonesey95 (talk) 19:02, 11 February 2024 (UTC)

Broken on Wikipedia app by Wikimedia Foundation

OSM Location maps don’t show up when the article (for example Barrack Street Bridge and Museum August Kestner) is viewed in the Wikipedia app made by the Wikimedia Foundation. I am running Wikipedia 6.9.4 (2000) on iOS. Betterkeks (talk) 14:39, 26 November 2022 (UTC)

Extend to more than 60 markers?

@RobinLeicester: Hello, would it be feasible to extend the function of this template to more than 60 markers? My little project at User:Marsupium/Iberian synagogues would need more than 400 … Thanks a lot in advance, --Marsupium (talk) 11:05, 14 April 2023 (UTC)

@Marsupium: Unfortunately it would be really hard to add anything like that many under it's current form. Each parameter for each mark has to be added in as a separate item, so it would both take for ever to code, and make the template vast and potentially even more unwieldy than it already is. Unlike the {{Location map}} series, there is no way I could find to set up the map, and then keep adding dots as un-numbered entries. Having said that, the underlying {{Graph:Map with marks}} [see below for correct vesrion] system has various options for adding as many as you like - but it requires you to engage with the GeoJSON formatting, and also has the potential to set up a data file to bring in the data from an external source. I have never done any of the latter, and the GeoJSON is very fussy to get right, which is why I produced a more standard parameter-based overlay. Sorry that is not very helpful, but might give a direction to go. RobinLeicester (talk) 22:10, 25 April 2023 (UTC)

Hello, thanks a lot for the reply! Even though it might not work with this template I'm very grateful for your hints and they will help me to find a path to follow I think. Thanks again! --Marsupium (talk) 18:22, 26 April 2023 (UTC)

nb - the template I gave has been renamed, which confused me, and that 'Graph' template appears to be an old fork, which may not get the revisions needed under the current 'crisis'. The place to look (once it is working) for the underlying template is {{Map with marks}}, although the renaming is a mystery to me. It is 'supposed' to be called {{Graph:Street map with marks}}, which is what it is called at mediawiki.RobinLeicester (talk) 12:52, 27 April 2023 (UTC)

Broken underlying Graph module

Having written all the above, I have just discovered the whole 'Graph' based system is currently out of action, from 18th April. They had been running an ancient, unmaintained version of the VEGA software, apparently, which now has security vulnerabilities. As of 23rd April they were suggesting may be they would get 'some functionality' within a week. More details at Wikipedia:Village_pump_(technical)#Graph_extension_disabled_per_immediate_effect. We will have to wait and see. In the meantime all maps using this template are effectively vanished. Very sorry about that. RobinLeicester (talk) 22:20, 25 April 2023 (UTC)

@RobinLeicester: Probably a daft question, but couldn't this be migrated to use mw:Extension:Kartographer instead? Since that's dedicated to maps, it might make more sense than using a graph? Thanks. Mike Peel (talk) 18:54, 27 April 2023 (UTC)

@Mike Peel:Fair question, which is also being asked in the Mediawiki Phab pages. The answer I gave there is "There is a good implemetation of Kartographer at {{Maplink}}, but it can't show any of the text labels or other items that allow a properly customised map rather than just a view into the base-map. I will have a think about whether a temporary base-map would seem better than an apology for the time being. It would be a disaster, long-term, for the maps with a lot of customisations."

If there are elements of Maplink or Kartographer I am missing, then that would be great, but I notice that Maplinks approach to extending its features is to use an overlay which then relies on the Graph module, and is thus also currently out of action. Vega 5 installation is progressing, but there may be quite a bit of code re-writing to get everything working. RobinLeicester (talk) 15:44, 29 April 2023 (UTC)

Map of Old John Tower in Bradgate Park, Leicestershire. This is an externally-produced simulation (aproximately) of how this map used to look

1km
0.6miles

Old John Tower

C

r

o

p

s

t

o

n

R

e

s

e

r

v

o

i

r

Hallgates

Old John Car Park
(Hunt's Hill)

Bradgate
House

B R A D G A T E  P A R K

War memorial

  

Map of Old John Tower in Bradgate Park, Leicestershire - As currently being displayed

In case anyone is wondering what sorts of things used to be possible, now that all the examples have lost their features, here is an sample of some of the things that the Graph features used to provide.

Please help

I copied a map from lt-wiki page lt:Valstybinis Kernavės kultūrinis rezervatas, but it looks very different in Kernavė Mounds. Please advise.

This will be because a temporary template fix to the en Wikipedia template on 15/16th May to handle the withdrawal of the graph module more cleanly has not been done on what I guess is the Lithuania language Wikipedia. For all I know on that wikipedia you can use the temporary solution at Template:OSM Location map/coretemp if you know what you are doing and have the right rights which might not be maintained if you don't remove the fix when the graph module is working again ChaseKiwi (talk) 20:29, 14 July 2023 (UTC)

Multiple maps on a page causing numbering errors

Hi all, I'm having an issue where this page, which uses three OSM Location map templates. This issue appeared recently (it wasn't there when I made the page) - the points on each individual map are labelled correctly, but the key below each map doesn't keep the same numbering (so if it's item 3, this will display correctly as item 3 on the map, but the key will show this as item 1). Is there a way to fix this, other than combining everything into a single map? --Prosperosity (talk) 21:09, 9 July 2023 (UTC)

Suggest you report on phabricator as the issue has almost certainly been introduced in behind the scenes mapping coding with failure to reset a variable (array). It looks to me your use of template may have bypassed the problems in display of the graph model overlay facilities of this template so annoying for most since April but it may be that the error is related to someone's attempt to deal with it for all I know

PS There is backdoor fiddling going on. For example the first interim solution to the graph issue at least on the map display showed from 16th May till 6th June a message that very informatively said there was a problem with map display as intended. This was removed by User:Pppery and you are welcome to take it up with them. I for one like to know when there are bugs in display of previously working wikipedia pages like yours and thousands of others and someone has taken notice. Else you just get thousands of duplicate bug reports. Whatever my personal compliments to template main owner User:RobinLeicester whose excellent work has been mucked up by a security issue and is as frustrated as a lot of the rest of us who use this excellent template and in their case might be landed with recoding once VEGA5 graphical programming language is reenabled for use by a select few.

When the graph module is reenabled and this apparently other bug is sorted, you could add extra interaction to your useful graphs using the mark-descriptionN descriptors .ChaseKiwi (talk) 20:15, 14 July 2023 (UTC)

Could you explain what edit of mine you are referring to? I made no edits at all on June 6, and was on a wikibreak for most of June, so couldn't possibly have broken something then. * Pppery * _{it has begun...} 20:27, 14 July 2023 (UTC)

its in your name at Template:OSM Location map/coretemp view history. I for one think the message removed by who ever used your tag was informative. ChaseKiwi (talk) 20:32, 14 July 2023 (UTC)

(edit conflict) Oh, I see, you meant July 6 and this edit, not June 6. Well in that case I stand by the claim that the message "This is a stopgap mapping solution, while attempts are made to resolve technical difficulties with {{OSM Location map}}" should not be displayed to the reader, as it's far more likely to be unintelligible gobbledygook than to convey anything and the sort of people who care probably know about the problem anyway. See also WP:ASR * Pppery * _{it has begun...} 20:33, 14 July 2023 (UTC)

Sorry got date wrong , yes its 6th July. Hope you had a good break. I repeat that the message removed was informative for editors even though as you say many know of issue. Not a recent Lithuanian editor I see however. ChaseKiwi (talk) 20:32, 14 July 2023 (UTC)

For the record, this is still an issue, as can be seen on List of Massachusetts Bay Transportation Authority yards. Pi.1415926535 (talk) 20:47, 3 January 2024 (UTC)

When there are multiple OSM maps on a single page, I'm currently getting an error - the numbering of the paddles continues from the previous maps, rather than restarting at (1). For example, for me, the paddles on the map here run from 89-94, rather than 1-6. I guess this is linked to the issues with the graph plug-in? Furius (talk) 20:59, 27 January 2024 (UTC)

Yes, it remains deeply frustrating that graph is switched off, while WMF discussions alternate between hopeful and inconclusive on what to do about the 'graphs' / Vega / SVG options. If there had been any inkling it would stretch out this long, maybe the stopgap could have been improved a bit. I don't know if maplink has a way to zero the numbering, and the fact the stopgap has been edit-forbidden by Pppery makes it hard and de-motivating to improve it. All I can do is continue to apologise and encourage people to add their pressure for getting it returned. See the discussion at www.mediawiki.org/wiki/Extension_talk:Graph/Plans RobinLeicester (talk) 22:54, 4 February 2024 (UTC)

What are you talking about? I did not protect (assuming that is what edit-forbidden means) Template:OSM Location map/coretemp). A bot did. * Pppery * _{it has begun...} 23:28, 4 February 2024 (UTC)

Pppery, Apologies. I have finally worked that out. Your edit was after the protection was applied, and looked (to me) like the two were connected. Sorry, I am not well up on protection etc, and have found it quite a nuisance. I was fooled by the bot's paragraph about not automatically protecting things, and hadn't read on to the paragraph that says it does, to templates. I am now trying to address some of the difficulties people have found with what I hoped was a stop-gap of a few weeks, and months later continues to drag on in an unresolved manner. RobinLeicester (talk) 22:44, 5 February 2024 (UTC)

Older framemap

Is there possibility to get an old-fashioned layer ? Eg for use on this https://wiki.riteme.site/wiki/Persian_embassy_to_Europe_(1599%E2%80%931602)#Itinerary Bouzinac (talk) 19:08, 9 August 2023 (UTC)

Is there a limit on the number of locations that can be displayed on the map?

I'm trying to display 18 locations on this map, but only 16 are showing up. Is the map limited to displaying 16 locations? Rreagan007 (talk) 00:11, 5 September 2023 (UTC)

I am also experiencing this exact same bug on Big 12 Conference as well as this one too. I was under the impression it was supposed to display up to 60 different markers per map. MAGA2016 (talk) 21:47, 21 September 2023 (UTC)

Rreagan007, MAGA2016, Very sorry, almost all of the functionality of this mapping template is currently out of action. There is still hope that at some point soon the WMF people will find a solution that will get it back up and running, but it has been a very frustrating 6 months! I have used {{maplink}} to show the first 16 items to show as numbered markers, just to provide a sort-of-legible placeholder for the maps people have devised. But all the smaller dots, shapes, images, text, etc that this template could do are not possible at present. If you are making a new map, it is better to use maplink for now, as this will not show them properly yet ... if ever! For existing {{OSM Location map}} items, I would say leave as-is for the present, and hopefully we can get them back to what they should be. If you want to add your voice to the need to solve the mapping uses (alongside solving the other broken 'graph' templates) I would be delighted if you could do so. There is ongoing discussion at www.mediawiki.org/wiki/Extension_talk:Graph/Plans. RobinLeicester (talk) 17:36, 25 September 2023 (UTC)

This is killing the maps for Ontario Hockey League, Quebec Major Junior Hockey League, and Western Hockey League. Making a change to a template that breaks pages that are using it is unacceptable! If some action has been taken to make the first 16 items appear, why can that not be extended to 60? DOSGuy (talk) 22:43, 1 December 2023 (UTC)

MAGA2016 I notice that you had found an effective workaround to the dot numbering issue on your Big 12 Conference page, which my new fix has now mangled. Are you OK to go back and remove all your manual 'numbered' items, so the captions match the map again. Sorry to throw that back to you. RobinLeicester (talk) 02:18, 11 February 2024 (UTC)

Thank you for the updates! The Big 12 page is looking and functioning correctly. The numbered items have been removed. MAGA2016 (talk) 21:11, 11 February 2024 (UTC)

Modest improvements (with some drawbacks) to temporary fix

The better fix to the numbered dots situation is that each map should now start with number 1, regardless of how many maps there are on a page, and the fullscreen version should also start at 1 to match the framed version. (It now assigns a group number based on the map coords plus first marker coords, so is hopefully unique to that map).

The more qualified news is that I have also expanded the number of dots to 25. Maplink seems to have serious limitations on how many dots it can show per page (not just per map). They look fine in preview mode, but it either chops off the higher numbers, or in the case of pages with several maps, might stop showing all the dots on some maps - even ones with few dots on them. At present the template documentation page, mostly has no dots on the maps, so I am trying to think what to do about that. My inclination, since the whole documentation is about all the more fundamentally broken features, is to add yet more of an apology to that documentation, and see how many dots I can maximise for the articles themselves. If you are here because the dots have vanished from a map, please reply to this item, and indicate which articles are affected, and I will see what might be done.

As I keep repeating - if you would like to see the 'real' OSM Location map return, with decent graphical options, please add your voice at www.mediawiki.org/wiki/Extension_talk:Graph/Plans, otherwise they will think there is 'no demand for it'. RobinLeicester (talk) 00:31, 11 February 2024 (UTC)

In the meantime, there have been a couple of adjustments to the caption area. Furius had pointed out that columns for auto-captions would be useful, and Jonesey95 identified that some of the text was smaller than appropriate. The larger text about 'Interactive fullscreen etc' then felt too intrusive, so my solution is to just put '[fullscreen map]' and incorporate a tooltip with extra information, which has the added benefit of separating that line from any caption below.

The auto-caption= option can now be given a width value. Instead of just putting 1, any number larger than 4 will be interpreted as an 'em' width, and split the caption into columns of that width - typically you might want a value between 12 and 30 (select on the text-length of items and width of map). I would still not recommend embarking on new maps with this template, as it is hard to know what the 'real' map would come out like. But we might as well improve as best we can, those bits that are currently salvageable. RobinLeicester (talk) 19:26, 12 February 2024 (UTC)

Splendid! I really do hope that the graphs interface is soon re-enabled, but in the meanwhile I continue to find this template extremely useful for NZ history articles. The new auto-caption system replaces the use of {{div col| colwidth=10em}} tags, correct? Furius (talk) 08:42, 13 February 2024 (UTC)

Yes, it puts the div col stuff where it belongs inside the template, so you just supply the width number if columns are wanted. Great work on the NZ History. Looks fascinating. RobinLeicester (talk) 11:37, 13 February 2024 (UTC)

News of Impending Return

Over the last few weeks I have worked on the possibilities for creating the OSM Location maps without using the disabled graph module. There is still no sign of a resolution to that problem, and my efforts here are tinged with the knowledge that various other graph applications will still be left high and dry. However, for this template, I have found that by working within a {{maplink}} overlay, and jumping through a range of wierd and wonderful hoops, it is possible to use CSS graphics to re-create what used to be done through 'graph' - at least to a decent extent. The biggest hitch is with text, and in particular with left-pos text, which may look like it is not quite in the right place. It will be possible to adjust to fit, but may not come back as 'automatically right'.

There will doubtless also be other hitches and bugs from such a major re-write. With that in mind, the new version is now at {{OSM Location map/sandbox}}, and some results can be seen on both the documentation page, and also at OSM Location map/examples. (You can use the sandbox version to preview other maps, but please hold fire on any editing/saving in case last minute adjustments are needed. (Please indicate here if you spot major issues). You also will notice New Features on some of the example maps, and I will produce some documentation on how these can be used, soon(tm). In the meantime, unless some substantial issue arises during further testing, my expectation is to 'go live' in the next few days, and see what happens on the real-world articles. RobinLeicester (talk) 15:24, 7 March 2024 (UTC)

I have reached a point where it seemed good to install the new version for real. It is now live, with actual dots and text for the first time in 11 months. All 60 marks are now back and working. The 'unresolved problem' in terms of like-for-like return is that CSS text is not as easy to place as the old system. Labels on the left side of a mark, in particular, might be too close or too far away. There is an extra 'jdx=' parameter that can shove it left or right by a given number of pixels, but this is a case-by-case solution. The order of drawing the dots has also unavoidably changed. I will produce some better documentation on what has been done, what has to accommodated and what new features are now available. In the meantime, please let me know if there are major or minor problems resulting from this. (it has been a massive re-write, so bugs, I am afraid, can be expected. Most can be solved - I hope - if I know about them).Thanks for your patiance. RobinLeicester (talk) 21:11, 11 March 2024 (UTC)

RobinLeicester, can you please look at Bunker (Berlin) and the other pages on this list? They are displaying extremely poorly and show error messages including <maplink>: Attribute "zoom" has an invalid value. Is this a problem with the template code or with the articles' template parameters? – Jonesey95 (talk) 21:38, 11 March 2024 (UTC)

An initial look indicates that {{OSM Location map/core}} does not account for the possibility of a present but empty |width= parameter. I experimented with the sandbox but did not make any progress. – Jonesey95 (talk) 21:50, 11 March 2024 (UTC)

There is a different flavor of error appearing at Southwest Airlines Flight 1380 and a few other pages on this list. Happy debugging! Thanks for taking on this big project. – Jonesey95 (talk) 22:01, 11 March 2024 (UTC)

Thanks Jonesey95. empty width/height now trapped. I will see what is going on with the others on the list

Better so far, and your fix was much more elegant than what I was trying. Horseshoe Bridge and 2022–23 PGA Tour are still broken. I will post more varieties as they turn up. If you find that some of them are errors in template usage, you may want to track them with categories. – Jonesey95 (talk) 00:42, 12 March 2024 (UTC)

Doing great! 2021–22 PGA Tour is still broken. – Jonesey95 (talk) 14:12, 12 March 2024 (UTC)

Y label positioning is now sorted, so jdx has been discontinued. Any usage of jdx in templates can be safely removed. Post here if there are still positioning issues that need to be tackled. RobinLeicester (talk) 00:10, 10 April 2024 (UTC)

This is very exciting! I'm looked through the articles where I've deployed this template and haven't seen any errors so far. I'm very much looking forward to deploying some of the new functionality. Furius (talk) 22:43, 11 March 2024 (UTC)

Thanks to Jonesey95 for invaluable troubleshooting - This PGA map was put between col-begin col-end templates, which it did not like, for whatever reason. On this occasion I just removed the col features as they seemed to be of no particular purpose. Whether the maps should be possible within them, or indicates an error somewhere is maybe something I need to check out sometime.RobinLeicester (talk) 17:04, 12 March 2024 (UTC)

Furius, great to hear your maps are working. I have now written a page with details on how to use the new features - at Template:OSM Location map/Return to service. RobinLeicester (talk) 17:04, 12 March 2024 (UTC)

Thank you very much for your efforts to restore this template! I have six templates which depend upon it, and they all seem to work now just as before. Other than text placement, which you've already mentioned, the only issue I've found is that the background map is not visible in Dark mode. However, I don't recall whether this ever worked with the Graph module. Waz⁸:T-C-E 04:14, 14 March 2024 (UTC)

Omit modern town names

5km
3miles

Rome

Bovillae

  

Location of Bovillae relative to Rome on modern map

I'm running the following (also rendered at right):

{{OSM Location map
| coord        = {{coord|41.82533058887774|12.577536287455763}}
| zoom         = 10
| height       = 300
| width        = 300
| caption      = Location of Bovillae relative to Rome on modern map
| label1       = Bovillae
| mark-coord1  = {{coord|41|45|36|N|12|37|12|E}}
| label2       = Rome
| mark-coord2  = {{coord|41.89242233853287|12.485142607100402}}
| nolabels     = 1  <!-- does this work? -->
}}

It doesn't seem as if |nolabels=1 suppresses the labels in the basemap. Is that what it is supposed to do? Or am I misreading the documentation? If I am, is there some way to suppress the labels (the ones I provide excepted) regardless? Thanks. Ifly6 (talk) 19:50, 12 March 2024 (UTC)

Hi Ifly6, it used to be possible with the old setup, and your method would have been correct. I have not yet found a way to do it using {{maplink}}, but I will have another search and see what I can find. RobinLeicester (talk) 22:24, 12 March 2024 (UTC)

And look at that. The labels have gone! Word of warning though, it currently doesn't work in preview mode! So you need to do all the edits with the labels still there, and only when you submit/save will they vanish. People are looking into it, so it may get resolved. RobinLeicester (talk) 23:48, 15 April 2024 (UTC)

Fantastic! Ifly6 (talk) 02:31, 16 April 2024 (UTC)

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)

Option for more marks

Habst, I noticed that you have expanded the sandbox version of this template, to try out 250 marks rather than the current 60 maximum. This is interesting (and I hope for your sake you had a faster method than I have yet managed). It is a feature that has been requested on a number of occassions. However I am concerned that as currently configured this template is probably already too big with 60 marks, and I notice on the testcases page, for example, that the sandbox version, with a max of 40 or so of the available 250 dots, fails to create the last map, saying 'The time allocated for running scripts has expired.'

What I am wondering is whether a cut-down, streamlined template, specifically for lots of dots, would be a useful template in its own right. The two biggest limiting factors to my mind are {{maplink}}, which I think would not cope with more dots, and the excessive size and processing time inflicted by all the options on offer here. The question is, would a 'many dot' template with no fullscreen version still be desirable? And which features (numbering on dots; text labels; different shapes/colors/sizes/outlines; wikilinks; auto-caption text) would be considered essential, and which might be edited out? To my mind, the single biggest overhead is from the labels. Just having dots (especially not numbered ones - which will end up covered up by other dots), and no fullscreen version, would cut out a great chunk of the size and complexity. But would it still make a useful mapping use-case? Any thoughts you, or anyone else, has on this would be useful input.

For the record, what I would really imagine to be useful would be to click a listed item in the caption and have it 'light up' on the map. Alas, I think we are a long way away from that kind of real-time interactivity - but who knows. It would certainly solve some of the other 'usefulness' problems of a map with a lot of dots. RobinLeicester (talk) 19:04, 2 April 2024 (UTC)

@RobinLeicester, thanks for the ping. Yes, I wrote this script to generate the rest of the marks code so I didn't have to type them all in: User:Habst/generateMarks.js

Currently, if you want to add a new mark, you need to edit 5 separate places in two files of the template code. (Ideally, it would be just one place, or even more ideally the number of supported marks would simply be a Lua variable that could be incremented or decremented.)

Just as big a problem as the script time expiring, is the post-expand include size. We only have about 2 MiB per article to work with, and {{OSM Location map/sandbox}} is already almost 600 KB and {{OSM Location map/core}} is ~225 KB according to xtools. When I tried to use it in an article, I did hit that post-expand include size limit pretty quickly.

I don't even think that the template would need to be cut down per se, relevant parts just need to be written in Lua rather than Wikimedia template syntax (so it would require a significant rewrite). And personally, I think the fullscreen mode is most important when there are many dots, so I think keeping that feature is worthwhile. Thanks, --Habst (talk) 19:40, 2 April 2024 (UTC)

Thanks, I can see the sense in all you are saying about both the Lua and the importance of Fullscreen. The need to come up with a 'near-as-possible' replacement that worked with the already written user-base, I was keen to get this template working just using what I already knew about. Having spent quite a few months to acheive that, I am not currently inclined to start learning my way around Lua. However, if you were inclined to work on a second such mapping template, starting from the ground up, it may be that a much tighter code could produce all the things you are looking for. Mind you, I would still worry about how the fullscreen maplink option would handle lots of dots. Maybe if Kartographer was called directly that would also cut down the overheads. Well outside my knowledge-base!)

RobinLeicester (talk) 21:07, 2 April 2024 (UTC)

Does not work in mobile view yet

The article "Template:OSM Location map" works in mobile mode but the OSM maps within do not support the fullscreen link. Is the support already planned?Ruedi33a (talk) 20:04, 3 April 2024 (UTC)

Thanks for that pointer. Support is certainly desired. The challenge might be in finding out why it doesn't currently work. Still various loose edges to tidy up, so it may not be an instant fix. RobinLeicester (talk) 20:03, 4 April 2024 (UTC)

YI have reworked parts of the template which I believe cuts out the troublesome feature that was shifting not just the fullscreen but all the dots and labels to the wrong place in mobile view. I am hoping this is now on track. Any further checking you can do is appreciated. RobinLeicester (talk) 21:02, 12 April 2024 (UTC)

Thanks a million! The click to fullscreen mode works perfectly fine now. Ruedi33a (talk) 03:12, 13 April 2024 (UTC)

All the dots and labels are in the right place in mobile view now, too. Great work and enjoy Napoleon. Ruedi33a (talk) 03:25, 13 April 2024 (UTC)

Have another look at Napoleon in mobile view ... It appears that St Helena is not to be left out! It is half way down the next paragraph. With no reliable way to identify mobile view, that is just a thing to live with for now. I would class it as a div handling bug by mobile-view rather than this template. I may try and find out where to report it. RobinLeicester (talk) 09:49, 15 April 2024 (UTC)

Y Dots outside the frame are now filtered out, whilst still showing on full-screen. (Although fullscreen is not functional on the mobile App at this point) Mobile view maps are at least more-or-less matching what is on a standard broswer, on both computers and phones.

Template is now free from underlying templates

I have now re-worked the opening section of OSM Location map/core, so it now does the whole setting up of the frame itself and calls #tag:mapframe as a direct call, rather than the convoluted use of both {{mapframe}} and {{overlay}}. This took quite of lot of messing about with divs and stuff that I don't really understand, but I am hopeful the end result is a much cleaner implementation. It gave a very useful decrease in 'Post-expand include size'. It also solved (I hope) the mobile bug that was throwing everything off target on phones. Any issues or bugs it may have thrown up - please post here. Thanks again to such stalwart bug-spotters as Jonesey95, ChaseKiwi and Furius. Much appreciated. RobinLeicester (talk) 21:18, 12 April 2024 (UTC)

Thanks for this! The amount of work that you've put in here has been extraordinary. Furius (talk) 21:46, 12 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)

2km
1.2miles

  

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)

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:

300m
330yds

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.

15km
10miles

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)