![]() | This template does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||
|
![]() |
Template:OSM Location map is permanently
protected from editing because it is a
heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by
consensus, editors may use {{
edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's
documentation to add usage notes or
categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
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=
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)
{{coord|...}}
{{#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)|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)
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)
|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)Asking out of curiosity... What's stopping this from functioning like this map? (note the ability to pan immediately after loading the page) Reh man 10:00, 18 February 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. Reh man 01:03, 1 September 2018 (UTC)
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)
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}}}, ...
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)
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)
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)
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)
Please see the discussion at the Village pump regarding a bug in the template. Nehme1499 ( talk) 18:30, 2 May 2019 (UTC)
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)
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)
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)
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)Should the shape elements display the Wikidata reference when clicked on?
Thanks -- The Equalizer ( talk) 11:42, 15 February 2021 (UTC)
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. This is a limitation for use in non english Wikis Arjunaraoc ( talk) 05:58, 21 June 2021 (UTC)
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°N 0°E. 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)
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)
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)
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)
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)
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)
Can one change the font on the map using custom CSS? -- Mahmudmasri ( talk) 21:15, 21 March 2022 (UTC)
Please see
{{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)
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)
<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)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)
@ 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)
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)
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.
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)
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)
"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)
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)
edit-forbiddenmeans) Template:OSM Location map/coretemp). A bot did. * Pppery * it has begun... 23:28, 4 February 2024 (UTC)
Is there possibility to get an old-fashioned layer ? Eg for use on this /info/en/?search=Persian_embassy_to_Europe_(1599%E2%80%931602)#Itinerary Bouzinac ( talk) 19:08, 9 August 2023 (UTC)
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)
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)
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)
|width=
parameter. I experimented with the sandbox but did not make any progress. –
Jonesey95 (
talk)
21:50, 11 March 2024 (UTC)
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)
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)
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)
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)
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)
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)
|nolabels=1
doesn't suppress street names at a zoom of 14 or higher? —
Fourthords |
=Λ= |
04:08, 16 April 2024 (UTC)
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)
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)
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)
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)
|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
|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
|shape2 = ruleA
(both set to size=85!)
RobinLeicester (
talk)
00:05, 20 June 2024 (UTC)Can I get an assist on why this isn't working like I expect? — Fourthords | =Λ= | 01:37, 30 June 2024 (UTC)
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)
![]() | This template does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||
|
![]() |
Template:OSM Location map is permanently
protected from editing because it is a
heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by
consensus, editors may use {{
edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's
documentation to add usage notes or
categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases. |
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=
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)
{{coord|...}}
{{#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)|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)
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)
|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)Asking out of curiosity... What's stopping this from functioning like this map? (note the ability to pan immediately after loading the page) Reh man 10:00, 18 February 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. Reh man 01:03, 1 September 2018 (UTC)
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)
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}}}, ...
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)
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)
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)
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)
Please see the discussion at the Village pump regarding a bug in the template. Nehme1499 ( talk) 18:30, 2 May 2019 (UTC)
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)
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)
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)
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)Should the shape elements display the Wikidata reference when clicked on?
Thanks -- The Equalizer ( talk) 11:42, 15 February 2021 (UTC)
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. This is a limitation for use in non english Wikis Arjunaraoc ( talk) 05:58, 21 June 2021 (UTC)
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°N 0°E. 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)
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)
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)
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)
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)
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)
Can one change the font on the map using custom CSS? -- Mahmudmasri ( talk) 21:15, 21 March 2022 (UTC)
Please see
{{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)
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)
<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)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)
@ 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)
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)
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.
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)
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)
"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)
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)
edit-forbiddenmeans) Template:OSM Location map/coretemp). A bot did. * Pppery * it has begun... 23:28, 4 February 2024 (UTC)
Is there possibility to get an old-fashioned layer ? Eg for use on this /info/en/?search=Persian_embassy_to_Europe_(1599%E2%80%931602)#Itinerary Bouzinac ( talk) 19:08, 9 August 2023 (UTC)
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)
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)
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)
|width=
parameter. I experimented with the sandbox but did not make any progress. –
Jonesey95 (
talk)
21:50, 11 March 2024 (UTC)
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)
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)
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)
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)
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)
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)
|nolabels=1
doesn't suppress street names at a zoom of 14 or higher? —
Fourthords |
=Λ= |
04:08, 16 April 2024 (UTC)
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)
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)
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)
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)
|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
|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
|shape2 = ruleA
(both set to size=85!)
RobinLeicester (
talk)
00:05, 20 June 2024 (UTC)Can I get an assist on why this isn't working like I expect? — Fourthords | =Λ= | 01:37, 30 June 2024 (UTC)
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)