Template talk:Infobox mountain

  1. Home
  2. Wiki

Image from Wikidata not appearing

[edit]

So I added an image to the corresponding Wikidata item for Mount Cordonnier, yet the image doesn't appear. Why? Is this a server caching issue? RedWolf (talk) 19:15, 4 March 2025 (UTC)[reply]

Does it work on any articles? If so, please link to one. I tweaked that article by adding the undocumented |fetchwikidata=photo. – Jonesey95 (talk) 23:20, 4 March 2025 (UTC)[reply]
The template says it retrieves the image property (P18) from WD. I looked at the template code and I see it asking for the value of P18. I think I had found an article that uses the WD image but that was a couple weeks ago IIRC. RedWolf (talk) 02:56, 5 March 2025 (UTC)[reply]
I also see that P18 is mentioned in the template documentation, and I showed how to make it work. If you find one that is working without |fetchwikidata=, post here and I will investigate. – Jonesey95 (talk) 05:49, 5 March 2025 (UTC)[reply]

Mapframe-zoom parameter doesn't work

[edit]

Hi, for example in Mount Everest, the parameter mapframe-zoom has no effect on the zoom of OSM map. Please inspect. Thanks. Hooman Mallahzadeh (talk) 06:00, 24 March 2025 (UTC)[reply]

@Hike395 in this edit you replaced the #invoke: with a normal transclusion. Did this start shadowing all the unlisted parameters? Should this detail be reverted to get the full parameter passing to work again? --Joy (talk) 12:23, 24 March 2025 (UTC)[reply]
 Fixed by passing |mapframe-zoom=
@Joy: per your question. We can't use the module form that automatically copies parameters, because of the wikidata logic. If you call the module, you always get |mapframe-wikidata= as a default. I had to force |mapframe-wikidata=yes if none of the following is set: |mapframe-coordinates=, |mapframe-coord=, |range_coordinates=, |range_coords=, |coordinates=, or |coords=. If I remember correctly, this code is required to allow coordinates defined on enWP to override those defined in wikidata. Otherwise there was no way to override the wikidata coordinates. — hike395 (talk) 14:01, 24 March 2025 (UTC)[reply]
@Hike395 no but we could still use Module:Template wrapper, surely? --Joy (talk) 14:59, 24 March 2025 (UTC)[reply]
Unfortunately, {{infobox mapframe}} takes completely different parameters than {{#invoke:Infobox mapframe|auto}}, so all parameters would have to get manually copied in that case anyway. :( — hike395 (talk) 15:06, 24 March 2025 (UTC)[reply]
I'm rather busy IRL, so I don't think I can investigate this thoroughly enough until next weekend. The template works now, so I think it isn't urgent to make a more robust fix? — hike395 (talk) 15:09, 24 March 2025 (UTC)[reply]
In retrospect, I don't understand what you meant by this. You want mapframe-wikidata to be set to yes if none of those exist? Or you don't want that?
I don't understand how the open-coding of onByDefault in that previous edit factors into that, in turn.
I made a sandbox edit to show what I mean. --Joy (talk) 21:35, 15 July 2025 (UTC)[reply]
I've restored the previous invocation method but kept the mapframe-wikidata and mapframe-coord parameter overrides as is.
I don't think you need to override the mapframe-wikidata parameter for this purpose, because that doesn't override the source of the coordinates, but let's see how this incremental change works first. --Joy (talk) 20:39, 1 August 2025 (UTC)[reply]
I've removed the coordinate-dependent wikidata=yes in the sandbox, and Template:Infobox mountain/testcases#Alps (map image) + mapframe still looks fine, but upon closer look the map frame coordinates shown differ from our source input values.
That last number sounds like a rounding of the link from our popup map.
So while the marker seems to be in the right place, the numbers shown in the frame match the shape. And they change as you pan and zoom. Is this actually bad, though? --Joy (talk) 20:25, 2 August 2025 (UTC)[reply]
I think we want the local coordinates to override the wikidata: local edits are more reliable that Wikidata. I would leave it the way it is (i.e., only set "mapframe-wikidata=yes" by default if coordinates are missing). — hike395 (talk) 15:58, 3 August 2025 (UTC)[reply]
But that's what I'm saying, they do. The marker is on our coordinates. It's just that if there is a shape, the popup window shows the center of the shape as the initial coordinates, and moves that as you pan or zoom. The marker does stay where it was. --Joy (talk) 16:59, 3 August 2025 (UTC)[reply]
What's the alternative? If we always set "mapframe-wikidata=yes" then do we get the whole shape? I don't think that works. — hike395 (talk) 17:49, 3 August 2025 (UTC)[reply]
We get the shape if one is available from OSM. If there isn't one, we just render the point and there shouldn't be any incongruity at all (until the reader starts panning and zooming of course). --Joy (talk) 18:03, 3 August 2025 (UTC)[reply]
I don't think this will work with Module:Infobox mapframe as written. The "fetch all data" test case doesn't show the whole shape and zooms in on the wikidata coordinates. It appears that fetchwikidata = ALL somehow sets the zoom incorrectly, possibly because coordinates are set in Wikidata. Can we hold off on making your proposed change until I spend some time understanding how Module:Infobox mapframe interacts with Wikidata? It seems mysterious, and possibly broken. — hike395 (talk) 19:12, 3 August 2025 (UTC)[reply]
Oh, that Alps fetchalldata test case wasn't right, because it didn't include the dimensions. Now that I've found them in Alps and put them there, you can see the zoom works fine again. --Joy (talk) 19:29, 3 August 2025 (UTC)[reply]

The test cases you modified were supposed to be for wikidata only, so I eliminated all non-wikidata parameters. Now that the test cases are "pure", I can see that mapframe-wikidata=yes (which is the default in this case) does not fetch the shape from OSM. I still don't understand what you're trying to accomplish with mapframe-wikidata=yes for all cases. Can you explain what you're trying to accomplish, perhaps by presenting a test case where the sandbox is better (in some way) than the current template? — hike395 (talk) 19:52, 3 August 2025 (UTC)[reply]

Later: I can see from the Alps with mapframe test that setting mapframe-wikidata=yes fetches the outline. So that is better. But that seems to only work well when you set the zoom manually (via length/width/area parameters). I think that is what is going on for the "fetch all data" test case, which is all shaded. I think I'd still like to poke around and understand what is going on. — hike395 (talk) 20:00, 3 August 2025 (UTC)[reply]
The zoom issue is orthogonal to the matter of which coordinates we render on the marker. Even without the dimensions, the default coordinates shown by the popup are 45.965, 10.825, as they seem to center the map on the center of the shape.
The zoom issue with ranges are basically the same issue we had with rivers, so I'm not sure why mountains would be different...?
BTW, on that note, I sent you a question there a while back, Template talk:Infobox river#map zoom? --Joy (talk) 20:04, 3 August 2025 (UTC)[reply]
BTW, our invocation of {{WikidataIB|getValue|P2046|...}} is only on our direct output. If we wanted to pass that down to mapframe, we'd have to add it to the parameters passed down there. I'll try to cook that up in the sandbox. --Joy (talk) 20:13, 3 August 2025 (UTC)[reply]
I tried it with [1] but it didn't seem to work. The filter code isn't actually documented other than in comments, so I might have misunderstood it. --Joy (talk) 20:37, 3 August 2025 (UTC)[reply]
There is a bunch of confusing logic around fetching/showing masks in Module:Infobox mapframe. I think the zoom logic I added before may have broken something. Will continue to investigate. — hike395 (talk) 20:03, 3 August 2025 (UTC)[reply]

Reporting bugs

[edit]
I was going to report this at an earlier time, but I didn't take it seriously enough. The zoom is useful for increasing or decreasing mapframe size if a feature is too big or too small using the default. Volcanoguy 14:50, 24 March 2025 (UTC)[reply]
Leaving out |mapframe-zoom= was not intentional, sorry. Please feel free to mention missing parameters here at the Talk page. — hike395 (talk) 15:06, 24 March 2025 (UTC)[reply]

Untangling the module

[edit]
Moved to Template talk:Infobox mapframe § Kartographer zoom

Warnings when infobox contains volcanic_field and volcanic_arc/belt

[edit]

Infobox usage of both |volcanic_field= and |volcanic_arc/belt= now causes preview warnings about this and also places the article into Category:Pages using infobox mountain with conflicting parameters under V. I don't see any relevant discussion about this on the talk page and I don't see anything looking at edit summaries that shows exactly when this rule was put into place. There also seems to be a new parameter |volcanic_region=. How is one supposed to fix articles that are currently using both these fields and have different values? Why was this rule put into place? RedWolf (talk) 17:08, 20 June 2025 (UTC)[reply]

I've brought this up before and I didn't get a good answer as to why |volcanic_field= and |volcanic_arc/belt= can't or shouldn't be used simultaneously. Volcanoguy 00:37, 21 June 2025 (UTC)[reply]
With that being said, if |volcanic_arc= and |volcanic_belt= could be used simultaneously, |volcanic_arc/belt= could be deleted since it would be a redundant parameter. Volcanoguy 04:42, 22 June 2025 (UTC)[reply]
@Hike395: Comment? Volcanoguy 21:01, 24 June 2025 (UTC)[reply]

The multiple volcano parameters have been in place since 2012. They were first proposed by droll here. Droll implemented this as an if statement in this edit for label22/data22. That is, only one of |Volcanic arc=, |Volcanic belt=, |Volcanic field=, |Volcanic arc/belt= were allowed to be shown at once. |Volcanic region= was added in this edit as part of the massive editing trying to automate Wikidata entries.

I added the preview warning and tracking category because the code hasn't supported more than one volcanic field for 13 years. The template used to pick one silently, which I thought was unfriendly to editors.

We have a choice. We can either

keep only one volcanic field in the infobox, in which case the answer to RedWolf's question is that an editor should pick the one they want. Or,
we can allow multiple fields and allow |Volcanic arc=, |Volcanic belt=, |Volcanic field=, and |Volcanic region= to have separate lines in the infobox.

What do other editors think? It sounds like both RedWolf and Volcanoguy would be in favor of allowing multiple fields. I'm concerned about infobox bloat, so I can see why droll used the if statement.

Looking at usage of |Volcanic region= here, I think it tends to be used for "volcanic province", which is, as far as I can tell is the same as a volcanic belt? @Volcanoguy: you would know more about this.

— hike395 (talk) 23:09, 24 June 2025 (UTC)[reply]

Volcanoes can be in an arc, belt and/or field simultaneously so I think it would be logical to allow multiple fields. I've used |Volcanic region= in several articles mainly because it's a more vague term; I've never seen the Northern Cordilleran Volcanic Province described as a belt, arc or field in scholarly sources. There was a time when this volcanic province (or at least a part of it) was referred to as the Stikine Volcanic Belt, but this term seems to be largely obsolete since it's mostly used in older scholarly sources. A volcanic plateau could arguably be described as a volcanic region as well, so |Volcanic region= could have multiple uses. Volcanic belts, arcs and fields could also be placed in |Volcanic region=, but I have to wonder how all three could easily be placed in one parameter; it could be confusing to readers. If someone were to list several volcanic regions in |Volcanic region=, it could end up enlarging the infobox the same way as allowing |Volcanic arc=, |Volcanic belt= and |Volcanic field= to have separate lines. Volcanoguy 01:39, 25 June 2025 (UTC)[reply]
 Done Your explanation convinced me. I think we should deprecate |volcanic arc/belt=, per your comment above.
I agree with the deprecation, especially when MOS:SLASH is considered. Volcanoguy 20:28, 25 June 2025 (UTC)[reply]
I object strongly. Volcanic fields are not the same as Volcanic arcs or belts with as noted various uses depending on your school of geology with time. Action very premature and all destructive action should be reverted. eguser:Volcanoguy has removed lots of reasonable classification in templates I have contributed to having noted that there are multiple reasons why multiple parameters were established as far back as 2012. I did not read this discussion as moving towards a consensus when I came across it on 21st June and then a sudden action is noted on day 5 ChaseKiwi (talk) 18:14, 25 June 2025 (UTC)[reply]
I think the removals you're referring to are the ones using {{Infobox fault}} rather than {{Infobox mountain}}; I've reverted those removals. Volcanoguy 18:25, 25 June 2025 (UTC)[reply]
PS: Thanks for starting the reversion exercise on {{infobox fault}} which is nothing to do with this discussion ChaseKiwi (talk) 18:26, 25 June 2025 (UTC)[reply]
Just to clarify for those involved in this discussion, I accidently removed |Volcanic_arc/belt= in articles using {{Infobox fault}}, which are the ones ChaseKiwi seems to be referring to and has nothing to do with {{Infobox mountain}}. Volcanoguy 19:00, 25 June 2025 (UTC)[reply]
Yes but some of those contributing to the debate above may not have understood that propagating rifts/arcs are perhaps best described in the absence of geological consensus by term |Volcanic_arc/belt=. |Volcanic region= is an opt out term that loses known information. No objection to a new parameter |Volcanic_arc/belt/rift= to replace old |Volcanic_arc/belt= ChaseKiwi (talk) 01:46, 26 June 2025 (UTC)[reply]
Infobox parameters should be as short as possible; |Volcanic arc= and |Volcanic belt= are much shorter than |Volcanic_arc/belt/rift= which is unnecessarily wordy and lengthy. I don't understand how |Volcanic region= loses known information when the said information should already be mentioned in the main body of an article. Volcanoguy 04:32, 26 June 2025 (UTC)[reply]
Fair enough. ChaseKiwi (talk) 19:27, 26 June 2025 (UTC)[reply]

I'm a bit confused. I made two edits:

  1. Allow multiple volcanic fields in the infobox
  2. Place articles with |Volcanic arc/belt= in Category:Pages using infobox mountain with deprecated parameters.

@ChaseKiwi: were you objecting to the second edit? Or were you objecting to the continued use of |Volcanic region=? Or am I misunderstanding? — hike395 (talk) 05:06, 27 June 2025 (UTC)[reply]

I only tested the tracking category in the sandbox, I never made it go live. I am unsure how to respond to the objection.
@Volcanoguy: I believe you may be cleaning up uses of |volcanic arc/belt=. Would a tracking category be helpful to you? Is the deprecation controversial? Should we discuss further? — hike395 (talk) 11:52, 27 June 2025 (UTC)[reply]
I've replaced |Volcanic arc/belt= with |Volcanic arc=, |Volcanic belt= or |Volcanic region= in many articles by searching "arc/belt" but |Volcanic arc/belt= may be an empty parameter in some articles. If a tracking category can identify these empty parameters then it would definitely be helpful. I didn't replace |Volcanic arc/belt= in articles relating to volcanoes in New Zealand due to ChaseKiwi's objection above so I would wait what ChaseKiwi thinks about deprecating |Volcanic arc/belt= first. Volcanoguy 16:57, 27 June 2025 (UTC)[reply]
@Hike395: After no word from ChaseKiwi in the last 4 days I decided to remove |Volcanic arc/belt= from the remaining articles. With that being said, I kind of wonder if there should be a parameter for tectonic features associated with the development of volcanoes (e.g. East African Rift, Taupō Rift, Cascadia subduction zone, Mid-Atlantic Ridge, Aleutian subduction zone, Tonga–Kermadec subduction zone). Volcanoguy 23:14, 1 July 2025 (UTC)[reply]
|Volcanic zone= perhaps?[1] — hike395 (talk) 23:23, 1 July 2025 (UTC)[reply]
No objection to volcanic zone as might be better in some cases than region and is shorter. ChaseKiwi (talk) 00:12, 2 July 2025 (UTC)[reply]
I'm not sure if there is a well-defined difference between a volcanic zone and a volcanic region. I wouldn't object to renaming |Volcanic region= to |Volcanic zone= if there is no well-defined difference between them. |Tectonic zone= could be a new parameter for rift zones, subduction zones, etc. I mentioned above. It could also be used in articles about non-volcanic mountains. Volcanoguy 01:02, 2 July 2025 (UTC)[reply]
I wouldn't mind changing |Volcanic region= to |Volcanic zone=. But I do worry that |Tectonic zone= might mislead readers. For example, Mount Shuksan could have |Tectonic zone=Cascadia subduction zone, but it formed from a terrane that collided 120 million years ago, not from the present subduction. — hike395 (talk) 02:38, 2 July 2025 (UTC)[reply]
The Cascadia subduction zone should definitely not be placed in |Tectonic zone= if this parameter were to be used in the Mount Shuksan article because the Cascadia subduction zone has nothing to do with Mount Shuksan. The Cascadia subduction zone is a much younger feature that formed about 55 million years ago.[2] Volcanoguy 17:34, 2 July 2025 (UTC)[reply]
is much really a qualifier for 20 million odd years older at a first order guess ChaseKiwi (talk) 21:11, 2 July 2025 (UTC)[reply]
I realize that it's incorrect, but I worry that a typical editor may not realize it's incorrect, even if you document it carefully. How about |Tectonic origin= ? — hike395 (talk) 12:31, 3 July 2025 (UTC)[reply]
Actually I don't think we need |Tectonic zone= or |Tectonic origin=; |Formed by= covers mountain formation so the tectonic origins of mountains can be placed there along with tectonic regions (e.g. "Volcanism along the Cascadia subduction zone", "Extension along the Taupō Rift", "Uplift along the Alpide belt"). Volcanoguy 19:37, 3 July 2025 (UTC)[reply]
Thumbs up icon — hike395 (talk) 01:34, 4 July 2025 (UTC)[reply]
I've removed the deprecated |Volcanic_region= parameter from all articles. Volcanoguy 16:43, 2 August 2025 (UTC)[reply]

References

  1. ^ "Volcanic zones". atlas.co. Retrieved 2025-07-01.
  2. ^ "Eocene initiation of the Cascadia subduction zone: A second example of plume-induced subduction initiation?". Retrieved 2025-07-02.

only images are drawn from wikidata?

[edit]

This template seems to have lots of work to draw information like for elevation form wikidata, but test case for a mountain and the test case for a mountain range only seem to successfully import the image, even if I pass fetchwikidata = ALL. There is a high chance that my test cases are incorrectly formatted somehow and that is why they don't work, but if we assume I did it correctly, then for some reason, all the effort the template goes to import from wikidata is mostly wasted. Tideflat (talk) 03:28, 27 July 2025 (UTC)[reply]

I spent a few minutes trying to double-check this, but the lack of spacing in these blocks of template code that invoke WikidataIB is entirely demoralizing.
It sounds to me that |onlysourced=true could be the reason why they're not showing up, because Wikidata shows the references to be wikidata:Property:P143, which probably doesn't satisfy that condition, as that's obviously circular. --Joy (talk) 08:48, 27 July 2025 (UTC)[reply]
I assumed that no spacing was just how template code was written on wikipedia for culture reasons. I will happy to go through and indent the code similar to normal programming code, on the template sandbox. I will comment here again when I actually do that. Tideflat (talk) 19:19, 27 July 2025 (UTC)[reply]
That Matterhorn test appears to be working correctly. Nothing at Wikidata:Matterhorn is sourced to a reliable source, so nothing is retrieved, per the Wikidata RFC. The fix is to replace "French Wikipedia" and similar with a reliable source on the Wikidata page. – Jonesey95 (talk) 19:20, 27 July 2025 (UTC)[reply]
I added such a reference, and it now works. Thank you for solving my confusion. I would add a similar reference for the Alps, but it seems I can not edit the page. Perhaps, because it is semi-protected. Though it could very well be my misunderstanding too. Tideflat (talk) 07:09, 30 July 2025 (UTC)[reply]
@Tideflat: please format the WikidataIB invocations. I find the format so intimidating and the code so confusing that I mostly stopped maintaining this infobox. — hike395 (talk) 19:03, 3 August 2025 (UTC)[reply]
I have put each WikidataIB call on its own line, for ease of human code parsing. – Jonesey95 (talk) 21:17, 3 August 2025 (UTC)[reply]
Thanks, that seems like a decent start. We should break lines for each parameter, especially complex ones, because it's still fairly jumbled. --Joy (talk) 21:21, 3 August 2025 (UTC)[reply]
I made an attempt at nicely formatting out the entire page with whitespace here: User:Tideflat/Infobox mountain. However, I just treated whitespace as not significant, and unfortunately whitespace is significant in places in wikitext, particularly inside templates. I welcome anyone fix it. If you ping me in some days again, I may be in the mood to try hard to debug it. Tideflat (talk) 00:08, 4 August 2025 (UTC)[reply]
That code looks beautiful, but adding whitespace like this is a fool's errand on Wikipedia. Even if you think you have it right, someone will put a manual line break in a parameter in an article or wrap the parameter in italic formatting, and it will break something subtle that you won't know about. Template coding is not like most programming, unfortunately. – Jonesey95 (talk) 13:19, 4 August 2025 (UTC)[reply]
Thank you, shame it doesn't work with wikitext.
I thought of using a script to automatically wrap most of the whitespace in html comments. I saw that done in a few places in the code which I took out for consistency, so perhaps that could applied more generally? Tideflat (talk) 03:39, 5 August 2025 (UTC)[reply]
If you look at my diff, you'll see how I did it with comments. It makes it somewhat more readable. If we go too far with it, this template will look unlike almost all other templates on Wikipedia, which presents its own usability issues. – Jonesey95 (talk) 04:08, 5 August 2025 (UTC)[reply]

Wikidata References

[edit]

Does the code that imports values from Wikidata make any attempt to also retrieve the references for these values? I know that the WD module will ignore references marked as imported from a Wikipedia site. RedWolf (talk) 18:33, 25 October 2025 (UTC)[reply]

Oh, I see a new parameter I wasn't aware until now: {{{refs}}}. I think it would have been better to have named it wd_refs but a minor point. I shall try that out. RedWolf (talk) 18:43, 25 October 2025 (UTC)[reply]

Coordinates not retrieved from Wikidata

[edit]

If no coordinates are specified in the infobox it does not go to Wikidata to get them (and its references).
One can specify the following for using the coordinates from WD: (Q6920264 is for Mount Cory in Alberta) 

| coordinates = {{WikidataCoord|Q6920264|display=it}}
| coordinates_ref={{Wikidata|references|Q6920264|coord}}

RedWolf (talk) 19:41, 25 October 2025 (UTC)[reply]

There's a lot of references to |onlysourced=true in the code, so if we want to stay true to that, we should have an integrated solution, rather than the above, which allows unsourced coordinates too. --Joy (talk) 15:08, 26 October 2025 (UTC)[reply]
Was not my intention to advocate we go forward with what I wrote above. It's a workaround for now until we decide whether the infobox should pull them from WD if not specified. I'm not about to go start changing infoboxes to that workaround. There's actually an issue with {{Wikidata}} where it won't use the template for a source reference if one is set, it always use {{cite web}} rather than say {{cite cgndb}}, the latter of which is where a lot of coordinates of mountains in Canada are sourced from. RedWolf (talk) 17:23, 26 October 2025 (UTC)[reply]