Template talk:OSM Location map/Archive 2
Latest comment: 1 year ago by RobinLeicester in topic Bug in label lines for mark 46
 | This is an archive of past discussions about Template:OSM Location map. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 | Archive 2 |
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.
- 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)
- 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)
, 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)
- 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)
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)
- 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)
- PS element has px coordinates 4,4 at a guess ChaseKiwi (talk) 07:31, 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)
- 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
- 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)
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)
- 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)