This is an archive of past discussions. 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.

Just to say I think this template is a worthy successor to {{ Mtnbox}} – thank you!  I've taken the liberty of rearranging the above as the templates and code clashed on my display. As noted in the article history, I've also removed the colons as these become misaligned when the parameters that follow them wrap around. (Thanks to the color scheme, I also reckon they're unnecessary.)
Best wishes, David Kernow 17:04, 4 May 2006 (UTC)

Note: Coor at dms is deprecated as of September 2008; use {[tl|coord}}

By using these templates in the infobox, the coordinates get display with the article title as well, similar to many articles about towns and other places. Thus one might want to update (keeping the coordinates, obviously):

{{ Coor dms}} => {{ Coor at dms}}

{{ Coor dm}} => {{ Coor at dm}}

{{ Coor d}} => {{ Coor at d}}

Samples may be seen at: Krakatoa and Kangchenjunga -- User:Docu

In fact there is an easier way to do it, just adding the template twice to the infobox, as on Template:Infobox City Japan. As it's easy to undo, I'm implementing this change. -- User:Docu

Why the extra expression of the coordinates at the top of the article? —wwoods 05:18, 29 September 2006 (UTC)

It's the default location for coordinates of the article. Template:Coor title dms started in English language Wikipedia. -- User:Docu

So how do I turn it off? In my browser it shows up as the first paragraph of the article. Or, if there's no blank line after the infobox, in the first paragraph:

"Coordinates: 43°38′58″N, 71°54′51″W Mount Cardigan is a prominent bare-rock summit in the towns of Orange and Alexandria in..."

The coordinates are already in the infobox; there's no need for another coord link floating around the top of the article.

—wwoods 18:27, 4 October 2006 (UTC)

I have to agree with wwoods on this. It's just plain silly to have the same information displayed twice on the page. I do NOT recommend changing mountain articles to use the "at" template. RedWolf 22:08, 4 October 2006 (UTC)

I agree with wwoods and RedWolf --- it seems redundant and useless to me. hike395 05:46, 6 October 2006 (UTC)

There is no need to change the templates. The display at the default location doesn't require that. BTW which skin do you use? In Monobook, the display is correct. -- User:Docu

In Classic, it isn't. —wwoods 19:26, 6 October 2006 (UTC)

At MediaWiki_talk:Standard.css#Coordinates_in_article_heading, there is a fix for that skin. -- User:Docu

So what should be done with that, add it to the template?

—wwoods 07:43, 7 October 2006 (UTC)

It should be added to MediaWiki:Standard.css. That way it would fix all other coordinates that are currently misplaced in that skin. -- User:Docu

You can now get a template link to Google Maps using Google_map = 54.454000000,-3.21200000 Google_Name = Cader%20Idris

• • Remember to URL Encode the {{{Google_Name}}} Snozzer 10:26, 31 October 2006 (UTC)

• Don't you think you should have asked for discussion before adding these parameters? I'm not saying I would have objected but this template is used by thousands of pages. RedWolf 15:23, 31 October 2006 (UTC)

The existing template functionality has not been altered at all, perhaps I should have asked first yes, but no harm has been done as all the pages using the template will continue to operate without error " TheNose | Talk" 15:25, 31 October 2006 (UTC)

In my opinion, this gives undue prominence to a single map provider. It also adds no functionality, since a link to Google Maps (amongst others) is provided through the co-ordinates, or in the case of British hills, grid reference. I have reverted the template until consensus can be reached as to whether or not this feature should be added (as discussed with its implementor). This keeps the number of unnecessary edits to a minimum, as unrecognised fields in the template will simply be ignored and articles which have already been altered to take advantage will not need to be reverted individually. It will/would be easy to restore the feature if/when a consensus is reached. -- Stemonitis 16:18, 31 October 2006 (UTC)

Agreed. I don't think we need this, as it duplicates info we already can access. Nationalparks 16:51, 31 October 2006 (UTC)

The info is not available clearly, the exisiting gbm4ibx external template is an absolute mess " TheNose | Talk" 10:22, 1 November 2006 (UTC)

A couple of points:

• Magnus' page is a quick hack to replace an older external page that went suddenly defunct. Magnus didn't implement the parsing of the 9th parameter, which could contain "region:UK" or "region:US" or "region:CH", and restrict the maps only to those that are applicable. It sounds like we should restore this feature.
• There is a way to reach a compromise here, which I think would make everyone happy, and also would be compatible with we are doing for US-ian mountains. On many mountain pages, we are using {{ Geolinks-US-mountain}} in the external links section. That highlights specific external map providers that are particularly useful for mountains, calling them with the best parameters for mountains. This way, the infobox can be neutral with respect to map providers, and explicit links to external providers can stay in external links (where they belong). I would suggest that we start {{ Geolinks-UK-mountain}} (and {{ Geolinks-IE-mountain}}) to be analogous, and the Wikipedia:WikiProject British hills participants could design it to be best for their hills.

hike395 10:26, 2 November 2006 (UTC)

A most excellent compromise and plan, I fully agree " TheNose | Talk" 11:29, 2 November 2006 (UTC)

Thanks, Snozzer! I see you started the template, I just copied the Google Maps link over from {{ Geolinks-US-mountain}}. Did you want to put this on the top 25 UK peaks? hike395 11:40, 2 November 2006 (UTC)

No Problem, I can work through and do the top 25 " TheNose | Talk" 12:29, 2 November 2006 (UTC)

I certainly think the {{ Geolinks-UK-mountain}} template is an improvement over the Infobox entry, but as we've already got the {{ gbm4ibx}} template, and its use is widespread, wouldn't it be better to improve that rather than introduce a new template? The {{ gbm4ibx}} template has the advantage of being less obtrusive and can be used inline in an article, for example when discussion various features on a mountain. — ras52 12:56, 2 November 2006 (UTC)

Please remove Category:Coordinates templates; this template isn't a coordinate template. Thanks. Mike Peel 20:02, 18 February 2007 (UTC)

Done. -- Ligulem 00:11, 20 February 2007 (UTC)

Thank you. Mike Peel 10:16, 20 February 2007 (UTC)

There appears to be a duplicate/parallel template to this one: Template:Geobox Mountain. It is only used in a handful of places, but appears to have some features superior to Template:Infobox Mountain.

Which one should be used? Should we merge it's features into Template:Infobox Mountain? -- Ozhiker 15:18, 15 March 2007 (UTC)

This has been discussed at Wikipedia talk:WikiProject Mountains#Template --- this one is the established template, and the consensus seems to be to keep using this one. I would bring any discussion up at that Talk page. Thanks! hike395 02:12, 16 March 2007 (UTC)

{{editprotected}}

I noticed that there are volcano eruption, volcano type, etc, and other information for mountains, related to volcano specific. therefore I would like to suggest new field, called "Volcano number" which is international numbering of volcanos. I edited 3 of them already to fill-in this field. This number is in form 1234-56.

See Ubinas, Tungurahua, Reventador for examples.

Thank you! User:Weis 08:00, 24 April 2007 (UTC)

I would oppose this --- the volcano number is not very commonly known: it's an index number for the Smithsonian. I don't think enough people would want to see it "at a glance" to warrant putting it into the infobox. hike395 13:35, 24 April 2007 (UTC)

N Not done; if you obtain consensus for this change and/or can link to it, nthe change may be made, but for the time being I won't make a change which has been disagreed-with in good faith. -- ais523 14:09, 24 April 2007 ( U T C)

I noticed that there are no volcanic belt, volcanic arc and tectonic setting in the infobox. Therefore I would like to suggest new fields called, "Volcanic belt", "Volcanic arc" and "Tectonic setting" since volcanoes are found in different areas around the world. " Volcanic arc" which would be useful for the Cascade Volcanoes, the Volcanoes of Indonesia, anywhere there's subduction or an arc of volcanoes, " Volcanic belt" can be used for those that are in a specific area, sush as the Trans-Mexican Volcanic Belt, Andean Volcanic Belt and "Tectonic setting" because volcanoes can be made by different things, sush as hotspots, subduction, rifting, etc. All of them are pretty important in volcanology. Black Tusk 08:49, 1 March 2007 (UTC)

This seems to be 3 different parameters each to essentialy define the same thing, i.e. what larger geological structure the mountain is part of. The most generic term of the 3 above would seem, to myself a non-geologist, the "Tectonic setting". This needs some discussion and comment from other editors to reach consenus on what to add and how it is to be incorporated (? a hierachy of parameters with only the most specific being used if more than one parameter is defined, or allow for multiple parameters to be given ?). The template currently has a "Range" parameter, could not such details be added there instead (with some agreed guidelines of how to so use and phrase the parameter value) ? David Ruben ^Talk 01:44, 6 May 2007 (UTC)

I've removed the editprotected request for now, but please do retag this talk page in due course. Also please feel free to approach me if you need any help in considering programming options (done with parser functions - WM:PF). David Ruben ^Talk 01:55, 6 May 2007 (UTC)

Volcanic belts and arcs are not a range, it's a volcanic grouping, and putting those type of things inside the "Range" parameter is kind of wrong, since they are not really a range. That's why I think it's appropriate to have their own fields in the infobox. Volcanic arcs are volcanoes that are related to subduction, volcanic belts are volcanoes that are formed by almost anything, sush as the Stikine Volcanic Belt, which was formed by rifting, the Anahim Volcanic Belt was formed when the North American Plate moved over a hotspot, and calling some volcanic arcs a volcanic belt is also wrong. Black Tusk 08:48, 6 May 2007 (UTC)

—The preceding unsigned comment was added by Black Tusk ( talk • contribs) 00:47, 7 May 2007 (UTC).

Ok I'll accept there are the difference causes, but are 3 parameters required - presumeably a mountain can only be one of these 3 possibilities, so what happens if more than one parameter gets defined (show all 3 parameter values ?). It would be easier, I suspect, to have just the one parameter that is assign the single "Volcanic belt"/"Volcanic arc"/"Tectonic setting" value appropriate for the particular mountain in question ? If so, what should the single parameter be called (? "Geological aetiology") and how should it be displayed (i.e. in the left most column what is its header). David Ruben ^Talk 01:49, 7 May 2007 (UTC)

Well, if a volcano has more than one cause, I guess those volcanoes can have more than one of the 3 parameters, for example, the volcanoes of the Garibaldi Volcanic Belt could have all 3 parameters, because the volcanoes within that volcanic belt are the northern extension of the Cascade Volcanic Arc (1), there within the Garibaldi Volcanic Belt (2), and were formed by subduction, which is what the "Tectonic setting" parameter would be for (3) (similar things like this are also in Iceland). But if there is a way to have a single parameter for all 3 parameters, I guess it might also be appropriate, although I don't think there is. Black Tusk 11:06, 6 May 2007 {UTC)

Ok I follow your points (I'm learning here). So I can forsee 3 methods of implementing:

1. Geographical_Formation (or similar) as a parameter to which the relevant details are added ?
2. Alternatively 3 separate parameters but all displayed as a single entry (i.e. the displayed text concanates the 3 parameters if they are defined).
3. This could of course be 3 separate entries and each with there own displayed row (but only displayed if defined).

Also where in the pecking order of current parameters should this be included ?

Again thanks Black Tusk, and if other people who watch this template could add in their tuppence ($0.02) worth of opinion, it will reduce the chances of squabbles (and need repeatedly re-edit this protected template) when this is implemented :-). David Ruben ^Talk 16:33, 7 May 2007 (UTC)

• I am wondering if these new fields would be of any interest to most of the people looking at volcano articles. For those who have an avid interest in volcanology, I can see how they would find it of value. However, would anyone else really find the additional lines in the infobox of much interest? I realize these would be optional parameters but I have to wonder if this is bordering on infobox clutter? I see way too many infoboxes these days trying to stick almost every conceivable common value between the underlying subject (e.g. cities — city council members in the infobox?). To me, an infobox should generally be a quick synopsis, not a detailed perspective. It's one of the reasons why I no longer actively contribute to the Album WikiProject as they keep expanding/changing the infobox to suit every conceivable nuance of each music genre but I digress. I would also prefer just one line added but this does not seem to be a feasible solution given the "technical" differences between the three fields. Which begs the question, if these are technical differences, are most people going to care much about seeing them? This is why we only have the "easiest route" in the infobox and not also the "hardest" route (which tends to be more argumentative than the easiest), the shortest route, the longest route, or all the other variations of climbing routes that could be listed. I'm not trying to pick on the volcano aspect (it's just the current focus of debate), but I think a line needs to be drawn as to how much detail needs to be given in an infobox. RedWolf 17:42, 7 May 2007 (UTC)

My ha'penny: I think that the "Type" field of the infobox is quite general, and could contain the tectonic setting. So, instead of saying a peak is a stratovolcano, it could be a hotspot stratovolcano, etc. I would propose thus adding only one extra field: Volcanic Arc/Belt. The editors could choose the most specific one (much like you must choose only one range, rather than all parent ranges). This compromise would hopefully express most everything that Black Tusk wants, while preventing infobox creep that alarms RedWolf. hike395 05:36, 8 May 2007 (UTC)

Yea, but Hike395, not all volcanoes are in mountain ranges, that's why I think it would be ok to have the volcanic arc or belt in the infobox. Black Tusk 03:16, 8 May 2007 (UTC)

Yes, I was agreeing with you --- add "Volcanic Arc/Belt" to the infobox: just one more row. hike395 03:01, 9 May 2007 (UTC)

Ok sorry, I don't really understand you Black Tusk 09:27, 9 May 2007 (UTC)

• hike395's proposal is an acceptable solution to me. RedWolf 20:43, 13 May 2007 (UTC)

Ok "Volcanic Arc/Belt" it is - but where in the pecking order of parameters should it go ? After "Prominence" or after "Type" ? David Ruben ^Talk 01:04, 14 May 2007 (UTC)

Probably after "Type". "Type", "Age", and "Last Eruption" are all geological: anywhere in there is OK with me. hike395 02:04, 14 May 2007 (UTC)

I concur with hike395. After "Type" seems to be the best spot for it. RedWolf 06:42, 14 May 2007 (UTC)

Ok Volcanic_Arc/Belt added, here is a dummy test. Would an abbreviation to fit the one line of "Vol.Arc/Belt" be better ? David Ruben ^Talk 17:48, 14 May 2007 (UTC)

I made a couple of minor tweaks: fixed the capitalization to match the rest of the template, and added an nbsp to prevent the bad linebreak which occurred above a certain font size. I think that's better than abbreviating to "Vol. arc/belt". -- Seattle Skier (talk) 03:11, 15 May 2007 (UTC)

Agree that "Vol." is a poor abbreviation to use: not clear. Thanks for adding the nbsp! hike395 03:55, 15 May 2007 (UTC)

How about dropping "Volcanic" entirely in the label? Arc and belt are wiki-linked so anyone unsure would immediately see it linked to volcanic arc and volcanic belt? RedWolf 03:53, 16 May 2007 (UTC)

Are you thinking of dropping "Volcanic" to avoid line-splitting on white space, or just to make things more compact? hike395 04:09, 16 May 2007 (UTC)

• To avoid line splitting although I also like the idea of making it more compact as well. However, it doesn't seem to be much of an issue at this point, so that proposal can be shelved for now. RedWolf 15:39, 28 May 2007 (UTC)

Can someone please lower the text size as in Template:Infobox Country? Thanks. ☆ CieloEstrellado 03:34, 24 May 2007 (UTC)

I'd prefer that we keep 100% text size, - its an accessibility issue. Andy Mabbett 12:08, 28 May 2007 (UTC)

strange to hear that 100% font size would be better accessibility. With current settings, when looking from smaller screens (and we talking here not only computer screens, but all other devices supporting web browsing) the page main content is suffocated between left-hand navigation and right-hand side infobox. not to mention that infobox is loaded first (=delayed time to read article) infobox should be for article not other way around. (infobox just takes together in different format the info article provides)

also accessibility would expect that user/reader can define image size. And if we really talk about accessibility then the table widths wouldn't be in pixels

90% font and 250px with would improve the "imprtance" division -- TarmoK 22:00, 7 July 2007 (UTC)

There's nothing strange about respecting a user's preferred text size. And no, table widths should not be in pixels. Andy Mabbett 22:13, 7 July 2007 (UTC)

• Well the Country infobox has like 4000 parameters so I can see why you would need a smaller text size for that beast. I'm happy with the current text size for this template so I am against making this change. RedWolf 15:32, 28 May 2007 (UTC)

{{ editprotected}}

Please add the mark-up for an hCard microformat, per WP:UF, by adding:

• class="vcard" to the outer container

• class="fn org" to the "Name" table row.

• class="label" to the td containing {{{Location|}}}.

• class="note" to each of the rows for Elevation, Range, Prominence, Type, Volcanic Arc/Belt, Age, Last eruption and First ascent.

Please also move the documentation, interwikis and categories to a /doc page, so that I can describe the above. Thank you. Andy Mabbett 12:01, 28 May 2007 (UTC)

Done. Please double-check that it works. CMummert · talk 14:20, 28 May 2007 (UTC)

Thank you, that looks good, and seems to work, but the documentation still needs to go in a separate page, at /doc Andy Mabbett 15:54, 28 May 2007 (UTC)

Done. Cheers. -- MZMcBride 16:13, 28 May 2007 (UTC)

Thank you, too. I've now updated the documentation. Andy Mabbett 12:03, 29 May 2007 (UTC)

Detail for microformat markup

{{ editprotected}}

Could we replace

|- 
{{#if:{{{Location|}}}|
{{!}} style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3;" {{!}} Location
{{!}} class="label" style="border-top:1px solid #999966;" {{!}} {{{Location|}}}

with

|- class="adr"
{{#if:{{{Location|}}}|
{{!}} style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3;" {{!}} Location
{{!}} class="region" style="border-top:1px solid #999966;" {{!}} {{{Location|}}}

It would put the location in the right microformat field (adress->region) rather than just a label. Thanks -- Qyd 21:07, 28 August 2007 (UTC)

If location weren't used, it would apply to the next available parameter, not necessarily something related to "adr". -- MZMcBride 21:56, 28 August 2007 (UTC)

Opps, you're right. Then maybe

|- 
{{#if:{{{Location|}}}|
{{!}} style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3;" {{!}} Location
{{!}} class="adr" style="border-top:1px solid #999966;" {{!}} <span class="region">{{{Location|}}}</span>

would work? -- Qyd 00:47, 29 August 2007 (UTC)

Do you want to remove class="label"? And, does it matter if the class="adr" goes in the <tr> or <td>? -- MZMcBride 23:17, 29 August 2007 (UTC)

Yes, the "address" fields are similar, but more detailed than "label" (and "label" is generally not parsed as well as "address" is), so if we change to "adr", then "label" should go. Shouldn't matter where class="adr" goes, as long as class="region" is wrapped in an element defined as "adr", i.e.

|- 
{{#if:{{{Location|}}}|
{{!}} style="border-top:1px solid #999966; border-right:1px solid #999966; background:#e7dcc3;" {{!}} Location
{{!}} style="border-top:1px solid #999966;" {{!}} <span class="adr"><span class="region">{{{Location|}}}</span></span>

would work just as well. -- Qyd 01:08, 30 August 2007 (UTC)

 Done. Neil  ム 13:32, 31 August 2007 (UTC)

I've updated the code to use wiki formatting; it's easier to read and doesn't require HTML comments. Additionally, I removed some redundant code (e.g., width:205px). The layout and usage should be identical. Cheers. -- MZMcBride 20:35, 8 June 2007 (UTC)

{{ Editprotected}} Could the photo caption use a slightly smaller font?

by replacing:

{{!}} style="border-top:1px solid #999966; text-align:center;" colspan="2" {{!}} [[Image:{{{Photo}}}|300px]]<br />{{{Caption|}}}

with:

{{!}} style="border-top:1px solid #999966; font-size:95%; text-align:center;" colspan="2" {{!}} [[Image:{{{Photo}}}|300px]]<br />{{{Caption|}}}

or

{{!}} style="border-top:1px solid #999966; font-size:smaller; text-align:center;" colspan="2" {{!}} [[Image:{{{Photo}}}|300px]]<br />{{{Caption|}}}

or even

{{!}} style="border-top:1px solid #999966; text-align:center;" colspan="2" {{!}} [[Image:{{{Photo}}}|300px]]<br /><small>{{{Caption|}}}</small>

It would be closer to a standard image caption. Thanks. -- Qyd 17:47, 27 June 2007 (UTC)

Done. Cheers. -- MZMcBride 18:00, 27 June 2007 (UTC)

{{ editprotected}} Please change the wikilink for the "Listing" row. Currently links to Hill lists in the British Isles: please link to Lists of mountains instead (to allow us to use listings in any country). Discussed at Wikipedia talk:WikiProject Mountains#Lists in Infobox. Thanks! hike395 08:43, 28 August 2007 (UTC)

Done. Cheers. -- MZMcBride 10:04, 28 August 2007 (UTC)

Is it possible to add locator image functionality? Sometimes a picture of a mountain is not currently available but having locator image to the mountain is enough. For instance, in Mount Leuser article. There is one example in Template:Infobox Settlement which provides the functionality with pushpin_map parameter. It would be good to have such feature in this template. — Indon ( reply) — 09:04, 2 September 2007 (UTC)

While this is not implemented in Infobox Mountain, a map can be forced in (within the name parameter), see Mount Leuser. -- Qyd 14:39, 5 September 2007 (UTC)

This doesn't look good at all -- I would far rather editors just used the map as a photo then force something in like this. hike395 02:51, 6 September 2007 (UTC)

Agreed. It would be better to use the already defined coordinate parameters to make the location map, instead of forcing it and define the same coordinate parameters twice. — Indon ( reply) — 09:09, 8 September 2007 (UTC)

Hike, this kind of map (with additional markup) can not be used instead of the photo because of the automatically added image syntax ([[Image: ...etc). Of course, that can be circumvented too... Indon, the problem with pushpin_map (dot position defined by coordinates) is that it only works with maps of rectangular projection (not suitable for larger regions), so if we would implement this, we would also need some other alternative map display system. -- Qyd 14:10, 8 September 2007 (UTC)

I would suggest continue discussing this at the relevant wikiproject, so more people can participate. hike395 03:50, 9 September 2007 (UTC)

I was (over)bold and updated the visual look somewhat to reflect the design of other similar infoboxes. I hope I didn't screw anything up (well, I'm good at templates, but not exceptionally good). If I did, feel free to revert me (well, um, or call an administrator to do that through {{ editprotected}}). Duja ► 15:26, 13 September 2007 (UTC)

I appreciate your work --- however, the style of the infobox reflects a long-standing consensus at Wikipedia:WikiProject Mountains. I'll start a conversation there, to see if we can get consensus on the new style. hike395 04:59, 14 September 2007 (UTC)

Where was the discussion on adding a parent peak parameter? Mark J seems to have added it without any community discussion. RedWolf 16:56, 21 September 2007 (UTC)

No discussion --- I was going to bring it up back at the WikiProject. I'll leave a note on the Infobox urging people to discuss editing the infobox at Wikipedia talk:WikiProject Mountains. —Preceding unsigned comment added by Hike395 ( talk • contribs) 17:00, 21 September 2007 (UTC)

The "Photo size" parameter seems to cause a problem if it exists but is empty. This is because the template places a pipe symbol after the image name with nothing between that and the closing square brackets. I think an "if" block is needed. -- Ozhiker ( talk) 10:57, 29 February 2008 (UTC)

Fixed -- Ozhiker ( talk) 13:26, 29 February 2008 (UTC)

Per a request on my talk page, I've added a pushpin location map. It uses almost the same exact coding that is used at {{ Infobox Settlement}}. Any map that has been created for {{ location map}} can be used (e.g. Nepal or Colorado). New coordinate fields were also added to facilitate this and those coordinate fields must be used to make the map work correctly. All the new fields are:

|pushpin_map            =<!-- the name of a location map as per http://en.wikipedia.org/wiki/Template:Location_map -->
|pushpin_label_position = <!-- the position of the pushpin label: left, right, top, bottom, none -->
|pushpin_map_caption    =
|pushpin_mapsize        =
|coordinates_ref= 
|latd= |latm= |lats= |latNS=
|longd= |longm= |longs= |longEW=

— MJCdetroit ^(yak) 18:40, 5 April 2008 (UTC)

See Mount Everest for an example. — MJCdetroit ^(yak) 18:50, 5 April 2008 (UTC)

• This should have been discussed on the WikiProject page before implementing it. I don't have any objection to map concept itself as I myself was testing some changes to add map parameters. However, this is a major change and the convention is to allow the community to discuss before implementation. For example, I would prefer to see the map at the bottom of the infobox rather than immediately after the image. Also, I was looking at just adding one parameter called map where one would place the call to {{ Location map}}. RedWolf ( talk) 20:52, 5 April 2008 (UTC)

Could the default mark be changed from "Red pog2.svg" to something like "RedMountain.svg"? -- Waltloc ( talk) 20:22, 21 September 2008 (UTC)

The attribute Parent_peak does not seem to display. Is that meant to be the case? imars ( talk) 11:40, 7 April 2008 (UTC)

Here is an example, Nakano Summit imars ( talk) 11:42, 7 April 2008 (UTC)

The documentation was not in sync with the implementation. The actual parameter name is "Parent peak". I have fixed the documentation. RedWolf ( talk) 06:30, 27 May 2008 (UTC)

This should be called "Parent" not "Parent peak". There's subsidiary peaks that are not part of a larger mountain. For example, see Silverthrone Caldera which contains many subsidiary peaks but is not a mountain. Can someone change this? Black Tusk ( talk) 13:38, 8 August 2008 (UTC)

I'm not sure I understand your point. If Silverthrone Caldera isn't a mountain, then it should use a different infobox, such as {{Geobox|Range}} (for example, as on the Sierra Nevada page), and the parent peak of any subsidiary peaks is most likely Mount Silverthrone. — ras52 ( talk) 14:26, 8 August 2008 (UTC)

There isn't a different infobox. The Silverthrone Caldera is not a range. Mount Silverthrone, Mount Filtzgerald, Mount Kinch etc are all subsidiary peaks of the caldera. The caldera itself can be considered a mountain "feature" but not an actual "mountain". Black Tusk ( talk) 14:33, 8 August 2008 (UTC)

I think you're misunderstanding what the parent peak field is for: it is for the prominence parent. Mount Silverthrone is the highest point of the caldera (along its rim, unsurprisingly), and so its parent peak is a mountain outside of the caldera. Nothing should list Silverthrone Caldera as its parent. — ras52 ( talk) 14:42, 8 August 2008 (UTC)

I know what the parent field is for. What I'm trying to explain is there should be something simliar to the "Parent peak" field. Anything inside or on the caldera's rim is part of the caldera. The caldera is prominent because its rim can be seen. Black Tusk ( talk) 14:58, 8 August 2008 (UTC)

But you didn't ask for something similar: you asked for it to be renamed. Specifically, you said This should be called "Parent" not "Parent peak", and changed the documentation to reflect this. If you want something similar adding, then you need to let us know what it's for. And I'm certainly not happy with a new field called "parent" — it's confusingly similar to "parent peak". — ras52 ( talk) 15:09, 8 August 2008 (UTC)

I renamed it because there's no need to have two field's that are similar. What's the point of having two similar fields, especially if something is prominent? The best thing is to have to things similar merged. Black Tusk ( talk) 15:24, 8 August 2008 (UTC)

So what do you want to use the the "parent" field for, if not for the prominence parent? — ras52 ( talk) 15:50, 8 August 2008 (UTC)

What I'm trying to say is having the "parent peak" field titled "parent peak" means it's only used for original subsidiary peaks like Little Tahoma. But if you have a field titled "parent" it can mean the subsidiary peak of the parent peak (e.g. Little Tahoma is a subsidiary peak of Mount Rainier) or the subsidiary peak of a mountain feature like the Silverthrone Caldera. Such a field would make the "parent peak" field more useful and both have prominence. Black Tusk ( talk) 16:44, 8 August 2008 (UTC)

I'm sorry, but I'm still not very clear what you're wanting. What is an "original subsidiary peak", for example? And are you saying that you would like the "parent" field of Mount Silverthrone to be Silverthrone Caldera? If so, I don't agree: the only thing in the "parent" field for Mount Silverthrone should be whatever its prominence parent is. — ras52 ( talk) 17:58, 8 August 2008 (UTC)

I ment "original subsidiary peak" as a subsidiary peak associated with another mountain like it's usually used. The Silverthrone Caldera and most other calderas are a prominent feature and thus they do have heights; for example, see here. It's rim is basically like a ridge and Mount Silverthrone lies on the rim of the Silverthrone Caldera making the Silverthrone Caldera the prominence parent of Mount Silverthrone. Black Tusk ( talk) 18:57, 8 August 2008 (UTC)

Perhaps I've misunderstood the topography of Silverthrone Caldera. What is the highest point of the caldera? I had understood it to be Mount Silverthrone, along the rim. But maybe I'm mistaken. Is it actually another peak along the rim? Or the central dome? (The coordinates given in the article are either wrong or insufficiently accurate, or Google Maps is significantly buggy interpreting latitudes and longitudes.) — ras52 ( talk) 19:31, 8 August 2008 (UTC)

I've spent a good while poring over topographic maps on nrcan.gc.ca. The Silverthrone Caldera article says the highest point is 3,160 m (10,367 ft), but I can't locate any points higher than about 9,400 ft (which is the highest 100 ft contour shown on Mount Silverthrone): so where does does it reach 3,160 m? The introductory paragraph on the Silverthrone Caldera article says Mount Silverthrone is "3,160 m (10,367 ft) high" which suggests it is the high point of the caldera. But the Mount Silverthrone article says it is 2,865 m (9,400 ft) which is exactly consistent with the maps I've looked at. Anyway, everything I've seen suggests Mount Silverthrone is the highest point of the caldera, and that there is no higher (possibly unnamed) point elsewhere on it.

There are various sorts of parent peak defined (see the topographic prominence article for details) of which the most popular seems to be the prominence parent. The common element to all of the types of parent is that the parent is higher than mountain itself. In the case of the prominence parent, it also has to be more prominent. (Note: more prominent doesn't mean it looks bigger or is more important, it is a well-defined numeric property of peaks, and only of peaks.) If Mount Silverthrone is the highest point of the Silverthrone Caldera, the parent must be higher, which means it must be away from the caldera. Monarch Mountain seems a plausible candidate.

But irrespective of precisely what Mount Silverthrone's parent is, the point is that it unquestionably is the summit of a pretty big mountain — a peak, in other words. — ras52 ( talk) 21:05, 8 August 2008 (UTC)

The coordinates seem to be wrong. Mount Silverthrone is the highest mountain of the Silverthrone Caldera but its exact elevation is uncertain. Some references state an elevation as high as 3,160 m, but the current topographic map shows contours only as high as 2,865 m. In addition, it is unclear whether the highest point is of volcanic origin or not, since the summit is covered with permanent snow and ice, and the composition of the underlying rock is unknown. The base of the mountain is pretty big and it lies on the northwestern rim of the caldera. Black Tusk ( talk) 21:22, 8 August 2008 (UTC)

OK, so the prominence parent of Mount Silverthrone is not Silverthrone Caldera. Monarch Mountain is a strong contender. So with that established, do we still have any examples of things that need a "parent" rather than a "parent peak" field? — ras52 ( talk) 22:49, 8 August 2008 (UTC)

Monarch Mountain is nowhere near Mount Silverthrone or the Silverthrone Caldera. 51°27′01.95″N 126°04′45.80″W / 51.4505417°N 126.0793889°W / 51.4505417; -126.0793889 should be in the middle of the caldera. Mount Filtzgerald lies on the northern rim of the Silverthrone Caldera at 51°31′01.9″N 126°03′56.2″W / 51.517194°N 126.065611°W / 51.517194; -126.065611. Black Tusk ( talk) 23:19, 8 August 2008 (UTC)

I know where Monarch Mountain is. There's no requirement for the prominence parent to be near by. For example, the prominence parent of Denali is Aconcagua, many thousands of miles away. Mount Fitzgerald ("Filtzgerald" has to be typo) is near by, but it isn't higher than Mount Silverthrone and so it cannot possibly be the prominence parent of Mount Silverthrone. You may want to remind yourself of the definition of the prominence parent. I'm not categorically stating that the parent of Mount Silverthrone is Monarch Mountain, but it whatever it is, it has to be something higher, and not necessarily the nearest higher peak. — ras52 ( talk) 23:47, 8 August 2008 (UTC)

OK sorry. I thought you were saying Monarch Mountain is the highest point of the Silverthrone Caldera. Black Tusk ( talk) 00:08, 9 August 2008 (UTC)

Right. So is there still any need for the "parent peak" field to be renamed "parent"? I can't see any. — ras52 ( talk) 00:12, 9 August 2008 (UTC)

I don't see a need either, although I still think there should be something for subsidiary peaks. Black Tusk ( talk) 00:21, 9 August 2008 (UTC)

io:Shablono:Monto. Thank you, Joao Xavier ( talk) 20:30, 21 June 2008 (UTC)

• Done. RedWolf ( talk) 07:04, 14 August 2008 (UTC)

{{ editprotected}}

Will somebody please reverse this edit, as "label", rather than "adr-location", is the correct hCard microformat value for non-specific address data such as "Washington, USA" (seen in [1], for example). Thank you. Andy Mabbett | Talk to Andy Mabbett 18:39, 21 August 2008 (UTC)

 Done Happy‑ melon 13:57, 23 August 2008 (UTC)

Thank you, but you seem to have changed something, other than the edit requested above. Andy Mabbett | Talk to Andy Mabbett 14:09, 23 August 2008 (UTC)

I accidentally edited the old version, it seems. Thanks for pointing that out! Happy‑ melon 14:22, 23 August 2008 (UTC)

That seems fine now. Once again, thank you. Andy Mabbett | Talk to Andy Mabbett 14:50, 23 August 2008 (UTC)

Could the default mark be changed from "Red pog2.svg" to something like "RedMountain.svg"? -- Waltloc ( talk) 20:22, 21 September 2008 (UTC)

Done. I actually had contemplated making this change about a week ago but after I tested it in a sandbox, never got around to implementing it. RedWolf ( talk) 02:09, 22 September 2008 (UTC)

Can you see what's wrong with Mars Hill (Maine)? The push-pinned map works, but "Expression error: Unexpected < operatorExpression error: Unexpected < operator" shows up with the coordinates. It didn't use to be there.

—WWoods ( talk) 04:51, 22 September 2008 (UTC)

• You cannot use decimal degrees for the pushpin coordinates, you need to enter degrees, minutes and seconds. I guess the pushpin template support is unable to handle decimal coordinates. RedWolf ( talk) 06:37, 22 September 2008 (UTC)

This template should be made similar to {{ Infobox River}} which allows parameters like | elevation_ft = 9000, etc. — CharlotteWebb 18:44, 9 November 2008 (UTC)

It's half done: the elevation can be autoconverted but the prominence needs doing. JIMp  _{talk· cont} 09:22, 14 March 2009 (UTC)

{{ edit protected}}

This adds {{ convinfobox}} (as used to autoconvert the elevation) to autoconvert the prominence. JIMp  _{talk· cont} 09:33, 14 March 2009 (UTC)

 Done. Next time, please just link to a sandbox copy :) Cheers, — Martin ( MSGJ ·  talk) 15:53, 14 March 2009 (UTC)

{{ editprotected}}

The right and top edges of the template can get clipped in display; please adjust the margins in the preamble by a pixel or so. Mintrick ( talk) 18:11, 12 December 2008 (UTC)

Can you provide an example of this clipping? RedWolf ( talk) 18:18, 12 December 2008 (UTC)

File:Mountain-render-error.png -- Mintrick ( talk) 18:47, 12 December 2008 (UTC)

Hmm, interesting. It renders fine for me with Firefox 3.0.1 and 2.0.0.18 on Mac OS X. RedWolf ( talk) 19:19, 12 December 2008 (UTC)

• Oops, that should be FF 3.0.4. RedWolf ( talk) 07:27, 13 December 2008 (UTC)

Fine for me with Firefox 3.0.3 with Ubuntu 8.10 ('intrepid'). What browser version and operating system is the screen shot from? — ras52 ( talk) 20:27, 12 December 2008 (UTC)

Firefox 3.0.4 On Windows XP. Mintrick ( talk) 20:27, 12 December 2008 (UTC)

I've disabled {{ editprotected}}. Please re-add the tag if you find some code that will fix the problem. Tra (Talk) 17:13, 13 December 2008 (UTC)

IIRC, we don't tend to centre captions, as the display of the | Caption = parameter does in this infobox. -- Tagishsimon (talk) 04:00, 6 January 2009 (UTC)

.. occurring at Wikipedia talk:WikiProject Mountains. Everyone is welcome to join in the discussion. Thanks! hike395 ( talk) 03:53, 9 January 2009 (UTC)

{{ editprotected}} Can the default photo size be changed from 300px to 285px? At present the infobox is stretched if it contains an image; this change will stop that from happening. PC78 ( talk) 17:18, 10 February 2009 (UTC)

Done. Cheers.-- Fuhghettaboutit ( talk) 01:35, 11 February 2009 (UTC)

To fix a problem with the coordinates on Slieve_Gallion, I added support for more coordinates input formats (at Template:Infobox Mountain/sandbox):

• degrees/minutes (use the fields: latd=, latm=, latNS=, longd=, longm=, longEW=)
• decimal (use the fields: latd=, longd=)
• decimal with NS-EW (use the fields: latd=, latNS=, longd=, longEW=). This format doesn't work yet together with the map.

A series of tests are at Template:Infobox_Mountain/testcases. Please feel free to add more. -- User:Docu

Excellent! Thanks! hike395 ( talk) 16:52, 20 February 2009 (UTC)

Can we fix the decimal with NS-EW + pushpin case (i.e., Ben Nevis?) I'm not sure what that would take. — hike395 ( talk) 17:49, 14 March 2009 (UTC)

That additional option is still to be implemented. It's done for the coordinates, but not for the pushin map (e.g. Ben Nevis at Template:Infobox_Mountain/testcases#Ben_Nevis). -- User:Docu

{{ editprotected}}

Could someone add the red lock icon to indicate that the template itself is editable by admins only? Thanks! hike395 ( talk) 14:17, 21 February 2009 (UTC)

Done. If you prefer, I can change editing to "autoconfirmed". -- User:Docu

I was wondering about that --- it was semi-protected for a long time, not sure why it went back to full protection. I think semi-protection is safe enough: what do other people think? hike395 ( talk) 19:19, 21 February 2009 (UTC)

I second that. JIMp  _{talk· cont} 09:34, 14 March 2009 (UTC)

• The template would fall under Wikipedia:High-risk_templates due to it being used in over 6,600 articles. RedWolf ( talk) 19:07, 14 March 2009 (UTC)

I was wondering why the {{ Infobox Mountain}} has been altered without discussion on this page. That has always been are policy it seems to me. If I'm wrong then I apologize. -- droll  [chat] 09:26, 17 March 2009 (UTC)

• It is policy to discuss here before making changes. Which edit are you referring to? RedWolf ( talk) 03:41, 20 March 2009 (UTC)

{{ edit protected}} This template describes age as "Age of rock." However, actual age and age of rock are two very different things. Basically, "age of rock" is too ambigious, and should be shortened just to "age." There is a difference between the oldest dated rock of, and the actual age of, volcanoes and mountains. This is very confusing:

I recently came across this pecularity when I was updating Hawaii hotspot to include the age of Loihi, the newest volcano in the Hawaiian arc. It puzzled me dearly that according to Garcia's paper, Loihi is 400,000 years old. But according to the Wikipedia articles, Kīlauea, Hualālai, and Mauna Kea are all younger! I ended up asking Viriditas about it. He pointed out a USGS phamphlet, which seems to confirm Garcia. Then I realized why this was happening. The USGS matrix on which the bulk of the articles is based uses the time at which the volcano rose out of the sea. The phamphlet and garcia use the beggining of the volcano's development. I suspect there are similar mishaps elsewhere. Res Mar 20:21, 12 April 2009 (UTC)

The USGS matrix is presumably only the source of US mountains, not those elsewhere in the world. (I find it difficult to be sure, because the link you provide doesn't seem to cover things outside Hawaii. Most uses of this infobox are for mountains that are not volcanoes. Is there any evidence that this field is being misused in all of those cases? I would be rather reticent of changing a internationally-used mountain infobox on the basis of an incorrect usage on a few Hawaiian volcanoes without a more detailed check on how the is used elsewhere. — ras52 ( talk) 21:10, 12 April 2009 (UTC)

Not done for now:. Please reactivate the request if/when consensus is formed. — Martin ( MSGJ ·  talk) 23:05, 12 April 2009 (UTC)

The problem is the difference between "age of rock" and "age," like I said. "Age of rock" seems to refer to the oldest dated rock, while "age" refers to the actual, estimated age. There is a large difference between the two, and not just for Hawaiian volcanoes. While the problem can be solved seperating it into "Oldest dated rock:XXX<br>Estimated age:XXX," it really whould be a value of its own. Res Mar 23:44, 12 April 2009 (UTC)

I don't see the ambiguity: age of rock is, well, the age of the rock itself, rather than the mountain. Mountains themselves are rather transient (in geological time): what exactly is the age of a typical mountain if not its rock? The age of the shape of the mountain? Erosion changes the shape of mountains quite quickly. I'm not sure if there are any other age measures that are both verifiable and general.

We could have a special age for volcanoes only, that may be verifiable, too. — hike395 ( talk) 00:18, 13 April 2009 (UTC)

Rock collected from a volcano varies in age with depth. The oldest known rock is a function of how deep they drilled to get it. The actual age can be gotten from rocks, if you drill to the core of the volcano, which is rarely possible, escpially with the bigger volcanoes; Mauna Loa is 9 kilometers deep. Most of the time they get it be calculating the lava accumulation rate. I don't think you guys are understanding me fully. Unlike mountains, volcanoes start forming in a point of time; like mountains, they accumulate over time. The thing is, the rock on top is not the same age as the rock on bottom, as it would most likely be with mountains. Sp there's a difference between "age" and "age of rock," which points to the oldest dated lava flow, rarely the actual age of the volcano Perhaps we should have an independant template for volcanoes? Res Mar 13:29, 13 April 2009 (UTC)

ResMar, I think you misunderstand me. I'm not disputing that there is often a difference between the age of the mountain or volcano (assuming that is a well-defined concept) and the age of the rock. At present we have a field that prints "Age of rock: value". It is possibly unfortunate that this field is called "age" rather than, say, "rock_age", but the field name is never displayed to readers so it doesn't really matter. If we were to either change the name of this field, or change what it means then someone has to go through every one of the 7000+ articles that use this template checking for the use of this field and changing it where appropriate. The fact that someone misunderstood its meaning for a small number of Hawaiian volcanoes is not sufficient reason for this.

Perhaps there is a case for adding a separate field for the age of the mountain or volcano — though, like Hike395, I'm sceptical that this will often be verifiable or even meaningful. Outside of oceanic hotspots, what does the age of the volcano mean? What does the age of Mount St Helens mean, for example? Certainly not the date when it rose out of the sea as it is not in the sea. — ras52 ( talk) 08:36, 14 April 2009 (UTC)

It's not date it rose out of the sea vs. the rock agw that I'm caring about. It's the date of the first lava flow vs. rock age. Do we neccesarily need to label it "rock?" Res Mar 17:33, 14 April 2009 (UTC)

I'm really struggling to understand what you want. You ask do we necessarily need to label it "rock"? Do we need to label what "rock"? If you still think there's something that needs changing, can we perhaps start again with a clear proposal of precisely what you want to change and why. Otherwise I think we're just wasting each other's time with constant misunderstandings. — ras52 ( talk) 18:59, 14 April 2009 (UTC)

{{ edit protected}} I am requesting that a patched version of this template be substituted for the existing version. The patched version as one bit of code:

{{#iferror: ({{#expr:{{{Photo size}}} * 1 }})|{{{Photo size}}}[[Category:Mountain articles requiring maintenance]]|{{{Photo size}}}px}}

This necessary since currently the user must specify the width of the image in px. (ie 225px). This is inconsistent with another field pushpin_mapsize which requires a numeric value only. The patch will allow for either method to be used.

The patched version can be found at User:Droll/sandbox. Just cut and paste. -- droll  [chat] 15:36, 25 April 2009 (UTC)

• I support this change. Please ensure to update the documentation page if this change is made. RedWolf ( talk) 16:18, 25 April 2009 (UTC)

• Looks ok to me and can simplify the use of the field. -- User:Docu

• This is clever --- I can never remember to use px or not on photo size, so it always takes me two edits. I support the change. — hike395 ( talk) 17:31, 25 April 2009 (UTC)

 Implemented. — Martin ( MSGJ ·  talk) 20:39, 25 April 2009 (UTC)

I tried to find out by reading the template documentation, but that did not help me: What is the use of the coordinates field? There was a discussion at Template_talk:Coord#Strange_behaviour_in_Mont_Blanc about a possible error in Template:Coord which turned out to be really a problem with the infobox: The coordinates of a mountain peak are determined by the parameters latd, longd and so on. But there is a second set of coordinates in the coordinates field, given as a coord template. If this second set is changed, nothing (visible) happens to the article. So what is the use of this field? -- Momotaro ( talk) 14:41, 18 June 2009 (UTC)

The coordinates= line has been there since long before the latd=, etc. lines, which I think were added to feed the pushpin map. One problem with the latter method is that it adds type:mountain to the coordinates it produces, but has no provision for the other parameters, such as region: or scale:. Maybe code could be copied from some other template, such as {{ Infobox Settlement}} or {{ Infobox nrhp}}?

—WWoods ( talk) 14:35, 19 June 2009 (UTC)

The coordinates field was added well before the coordinates started being put at the top right of the page. Yes, the latd,longd, etc. fields were added for supporting the pushpin map. If provided they actually override anything specified for the coordinates field. As for modifying the template to support region or scale, I might hold off on this for a bit. There is another version of the Infobox being worked on but which has not yet been presented to the WikiProject. I'll check on its status... RedWolf ( talk) 07:40, 20 June 2009 (UTC)

I see, thanks for your answers. If a new version of the template is being worked out, I assume it will have no such redundancy. -- Momotaro ( talk) 11:32, 21 June 2009 (UTC)

Commons has a series of categories that group mountains by height. Sometimes this is useful to have, but it's really hard to maintain manually. If these categories existed here too, it would be easy to maintain.

As this infobox already has an elevation field, a possibility could be to link the categorization to that field. This way no manual work would be needed. -- 签名 _sig at 12:11, 2 December 2009 (UTC)

• I don't see the real benefit of categorizing the tens of thousands of mountains in the world by elevation — a list can present this information much better but is harder to maintain. In any case, using the elevation field will be very problematic because the {{convert}} template is commonly used here. Also, some people have used HTML to prevent word wrapping of the unit of measure (when the template hasn't been used). RedWolf ( talk) 18:42, 2 December 2009 (UTC)

• At least for images, it allows to do nice intersections by elevation and location. Here we could limit this to a hidden category that is only generated when elevation_m (or elevation_ft) is being used. -- 签名 _sig at 07:44, 4 December 2009 (UTC)

A new layout has just been implemented. This was based on the consensus reached on the WikiProject Mountains talk page. It's possible we overlooked a few things in our testing so please report any issues in this section. Also, you can now use all lowercase for the parameter names; e.g. "Elevation" or "elevation" is supported now although new articles show use the all lowercase version. RedWolf ( talk) 06:58, 20 January 2010 (UTC)

Expression error

If an article is using the {{ convert}} template and it does not put the "convert to" unit parameter in the template, you will see an expression error. The solution is to simply add the missing "convert to" unit.

e.g. Change this

{{convert| 4520 | m | abbr=on}}

to this:

{{convert| 4520 | m | ft | abbr=on}}

RedWolf ( talk) 06:58, 20 January 2010 (UTC)

I have generated a list of pages where this will be an issue. This is about 300 infoboxes (about 4% of the total). Let's all work together to fix these (hopefully before we copy the latest sandbox version to be live). The problem infoboxes are in the following pages. Please strikethru entries as you fix them, so that we can keep track. Thanks!

• /Elevation_m_problems Y – droll  [chat] 18:40, 1 February 2010 (UTC)
• /Elevation_ft_problems Y – droll  [chat] 18:40, 1 February 2010 (UTC)
• /Prominence_m_problems Y – droll  [chat] 18:49, 1 February 2010 (UTC)
• /Prominence_ft_problems Y – droll  [chat] 19:13, 1 February 2010 (UTC)

— hike395 ( talk) 20:45, 31 January 2010 (UTC)

Missing map label

The peak label is missing on the location map. A temporary workaround is to add the "label" parameter. RedWolf ( talk) 07:22, 20 January 2010 (UTC)

• This is now fixed. RedWolf ( talk) 01:26, 21 January 2010 (UTC)

Elevation param

1. I'm just wondering why Elevation is the only parameter which does no have new lower case version. – droll  [chat] 09:14, 20 January 2010 (UTC)

• This is now fixed. RedWolf ( talk) 01:05, 21 January 2010 (UTC)

1. I wonder if having both alt_name and native_name is such a good idea when having only one would do. I'm in favor of retaining alt_name as it is the best general fit for all language groups. If an author wants to use italic and bold type face it would be easily added using wiki markup. See Infobox protected area for an example where this is the accepted method.
2. If you look at the test cases you will notice that not all the infoboxes are of the same width. This is because of the effect of objects (images and maps) that are wider than default. This issue is also addressed in Infobox protected area and I can easily fix it here.

I would be glad to address these issues if there is a consensus. Sorry I'm playing "Johnny come lately". I had some personal issues that made participation difficult. – droll  [chat] 09:59, 20 January 2010 (UTC)

I am OK with all of your proposed changes: for the last, if an image is too wide, will it break the infobox? — hike395 ( talk) 04:54, 21 January 2010 (UTC)

Mountaineering?

I'm having trouble with the "Mountaineering" header. A peak where the easiest way to the summit is by way of a quarter mile paved foot path cannot IMHO be classified as Mountaineering. Problem is I have no alternative to suggest. – droll  [chat] 10:20, 20 January 2010 (UTC)

• Hmm, good point. Off the top, I cannot think of a good alternative either. Easy to change though once we can decide on a new choice. RedWolf ( talk) 01:05, 21 January 2010 (UTC)

"Climbing"? — hike395 ( talk) 04:54, 21 January 2010 (UTC)

• Yea, "Climbing" would work although I think we need to add something to that but what? Of course though, if the easiest route is a road, putting it under climbing is strange but a road is generally a rare exception. I will change it to Climbing for now. RedWolf ( talk) 01:42, 23 January 2010 (UTC)

• Maybe Route or Access or Route of ascent or just Ascent. Just brainstorming. – droll  [chat] 06:14, 23 January 2010 (UTC)

Format tweak

So I spent some time fiddling with the variable size thing and I think it looks good. The major difference is that the default with is now 300px and setting the size of the photo or map too large will not change that. First notice that Mount Everest was wider than an average box because the width of the map is set to 325px. Also notice that Sunwapta Peak was narrower than average because neither the map size of the photo size forced it to be larger. I also made some other techy tweaks. For example I padded the mountain name header a bit – I think it looks better. Opinions may vary. The I decreased the width between label/data lines. Opinions may vary on this too. If want the changes then then Template:Infobox mountain/sandbox2 should be copied into the Template:Infobox mountain/main. – droll  [chat] 10:09, 22 January 2010 (UTC)

So I see I need to check some things out. Please do not copy my stuff to main yet. – droll  [chat] 10:37, 22 January 2010 (UTC)

• So it seems ready to go. Other opinions welcome. I shoehorned traversed in a little differently but no worries if think.

• Back at it again. Not ready for prime time. – droll  [chat] 22:08, 22 January 2010 (UTC)

• I think the sandbox is stable now but give me another day. All input welcome. – droll  [chat] 06:46, 23 January 2010 (UTC):

Looks like Mount Fuji (2) is broken? Check out the testcase page. — hike395 ( talk) 01:59, 24 January 2010 (UTC)

I did that intentionally. Check the code diff. The only difference between the two examples of Mount Fuji was one uses native_name and the other uses alt_name. I just deleted the other fields because the page takes a long time to rebuild after it is purged. Notice how the box on the left is narrower than the one above. That happened because the photo is no longer there. The default photo width was/is 288px. The box to the left is 300px wide because that is now set as the default width. It cannot grow because the maximum photo width allowed is 288px. – droll  [chat]

• Take a look at the Mount Everest example on the template page ( Infobox mountain). This will go away when the sandbox version goes active. As far as I can determine it is stable and ready to go. I've checked it out on Firefox, Internet Explorer, Opera, Chrome and Safari. There are still some changes I'd like but they can wait. – droll  [chat] 01:11, 24 January 2010 (UTC)

• Looks pretty good, I say good ahead and implement your changes. RedWolf ( talk) 06:53, 24 January 2010 (UTC)

• I saw something in the template that I don't understand but I have to leave right now. Please give me till tommorow. Thanks for understanding. – droll  [chat] 00:32, 25 January 2010 (UTC)

Native name?

I was looking at another template, I forget which one, and it used the parameter name other_name. I like this option best. I'm sure I'm picking nits but alt_name might be confused with the alt image parameter. I just don't like native_name because the word native is loaded. If the mountain is in Quebec then is the french name the native name or is the English name the native name. Like I say I'm picking nits but why not other_name. It should be almost totally non controversial. As I mentioned above, if an editor wants the alternate name in italics, they can use wiki markup. Any thoughts? – droll  [chat] 06:46, 23 January 2010 (UTC)

I'm fine with other_name, for the reasons you list, above, and leaving out the italics is OK too. It's a new parameter, so we don't need to worry about legacy infoboxes. — hike395 ( talk) 06:31, 24 January 2010 (UTC)

Using other_name is okay with me although alt_name was not a problem for me. Geobox also uses other_name so we might as well be consistent to avoid confusion. I think I did use alt_name and native_name on a few pages though already but not a big deal if they are not carried forward. RedWolf ( talk) 07:02, 24 January 2010 (UTC)

Ok, I'll go ahead and fix it up in the sandboxes. We can keep the other parameter names as alternates and I will set up a way to tracking category so we can cleanup any articles where they currently appear. – droll  [chat] 09:09, 24 January 2010 (UTC)

Stray brace

Our new infobox is producing a stray brace at Woodall Mountain. I am mystified. Does anyone want to take a look? — hike395 ( talk) 08:57, 6 February 2010 (UTC)

 Fixed I think that Droll's edits fixed the problem.

Photo size param

There's a slight bug in the handling of the Photo size parameter. The wikicode should read:

|photo_size={{{Photo size|{{{photo_size|{{{image_size|}}}}}}}}}

(note the lack of an underscore in "Photo size") — hike395 ( talk) 15:32, 6 February 2010 (UTC)

•  Fixed RedWolf ( talk) 15:51, 6 February 2010 (UTC)

I haven't disapeared. I've tweaking the code and have decided to write a new mapping template with better alt text handling. I guess Im a bit of the obsessive compulsive because I just love tweaking code. So far there are almost no noticeable differences except for the ones discussed above. I'll get back here soon with a couple more minor proposals. I think they are minor or even trivial but I'll get back with them sometime today. – droll  [chat] 16:36, 6 February 2010 (UTC)

Please see WT:WikiProject Mountains#Center location in infobox for discussion. Thanks! — hike395 ( talk) 05:27, 11 February 2010 (UTC)

I removed PAGENAME as the default for the feature name in {{ Infobox mountain/main}}. There are no articles that use this option currently and form what I understand the PAGENAME default is being discouraged. This will cause {{{name}}} to appear if the name is not specified. If I remember correctly it was this way sometime ago. The problem is that the name of the article might be disambiguated at some time and mess up the infobox. – droll  [chat] 20:06, 12 February 2010 (UTC)

• I am okay with change as I always specify the name as it's also used as the default label for the pushpin map. RedWolf ( talk) 20:28, 12 February 2010 (UTC)

There is a bug in the elevation and prominence conversion using elevation_m and prominence_m. Notice that {{convert|2959|m|ft|0}} = 2,959 metres (9,708 ft) while {{convinfobox|2959|m||ft}} = 2,959 m (9,708 ft). That's two feet off. I don't think it is worth fixing {{ convinfobox}} as we really don't need to. RedWolf, the fastest fix is to paste what is currently in the Template:Infobox mountain/sandbox into Template:Infobox mountain and remove the comment around {{pp-template|small=yes}} and {{Documentation}}. Next, paste what is in Template:Infobox mountain/sandbox2/main into Template:Infobox mountain/main. Finally go back to Template:Infobox mountain and change the first line from {{Infobox mountain/sandbox2/main to {{Infobox mountain/main. I believe the order is important.

There might be some changes we still need to talk over but I don't think we should wait. Two of Hike395's changes are not currently implemented in this version. It's kind of late for me right now so I'll write more about that and other things tomorrow. – droll  [chat] 05:03, 7 March 2010 (UTC)

Whoa, hold on. There are a whole bunch of changes between your code and the current infobox. All we need to do is to fix the convinfobox, and the elevation fields in main, we don't need to rush 90% of your changes. Let me figure out the minimal change using the current infobox. — hike395 ( talk) 06:40, 7 March 2010 (UTC)

Later --- I think I have fixed the bug that Droll found. What I did was kept his proposed {{ Infobox mountain/sandbox}} (which avoids the use of convinfobox), and did the necessary minimal changes to main (now at {{ Infobox mountain/sandbox3}} to make Droll's changes work. Let me stress that this is the minimal change necessary to fix the bug, without many other changes that make break other templates like {{ Infobox mountain pass}}. You can check the testcases at {{ Infobox mountain/testcases}}

The new way to fix the infobox is to

1. Copy {{ Infobox mountain/sandbox}} to {{ Infobox mountain}} and remove the comment around {{pp-template|small=yes}} and {{Documentation}}. This requires admin privs.
2. Paste {{ Infobox mountain/sandbox3}} into {{ Infobox mountain/main}}.
3. Change the first line of {{ Infobox mountain}} to {{Infobox mountain/sandbox3 to {{Infobox mountain/main. Again, this requires an admin.

As far as I know, this should work. Please discuss here if it doesn't. — hike395 ( talk) 07:00, 7 March 2010 (UTC)

•  Fixed I have implemented these changes. RedWolf ( talk) 17:15, 7 March 2010 (UTC)
• After making the changes and doing a few article edits. I noticed two problems. First, the map label did not include "name" (only "Name"). Secondly, the other_name parameter was not being referenced in /main. I have fixed both of these issues. RedWolf ( talk) 19:20, 7 March 2010 (UTC)

As I see, there are still problems. The convert template works in the infobox lake template but not in the infobox mountain template. I changed Pinatubo, Kuwae, and Kurile Lake because of that. -- Chris.urs-o ( talk) 09:24, 9 March 2010 (UTC)

• This is caused by a bug in {{ convert}} which I have reported. Using {{convert|81|m|ft}} causes error messages. Using {{convert|81|m|ft|0}} does not. If you use the parameter |elevation_m= or |elevation_ft= this problem is avoided as Infobox mountain now uses the second syntax internally. – droll  [chat] 10:01, 9 March 2010 (UTC)

• FIXED in Template:Infobox mountain/main, by using fewer nesting levels of if-expressions for "elevation={{convert|81|m|ft}}". See full explanation in:

Template talk:Infobox mountain/main#Fixed elevation for possible template-nesting limit

Sorry for the problems, but fixes are coming soon. - Wikid77 14:15, 9 March 2010

{{ editprotected}} For use by Cerro Azul (Chile volcano) I added support for a new parameter |map_alt= that lets the invoker override the default alt text generated for the map. Can you please install the trivial sandbox patch? I've added a test case for it and have documented it. Thanks. Eubulides ( talk) 04:45, 11 March 2010 (UTC)

I cannot think of any reason why this change should not be made. This is the right thing to do IMHO. – droll  [chat] 06:33, 11 March 2010 (UTC)

 so done. — Martin ( MSGJ ·  talk) 08:49, 11 March 2010 (UTC)

I'm going to start bring up issues I have with the template one or two at a time as I have more than a few. My first issue is with the convert template. 500 feet = 152.4 meters and 501 feet = 152.7 meters. {{convert|500|ft|m|0}} = 500 feet (152 m) and {{convert|501|ft|m|0}} = 501 feet (153 m). So it rounded up. {{convert|500|ft|m}} = 500 feet (150 m) and {{convert|501|ft|m}} = 501 feet (153 m). So that rounded up too. I think this a problem for us. When measuring things it is usually the practice to round down (find the floor). Too oversimplify, if you ask for a 1 pound of pork I don't expect to get 9 ounces and have the butcher tell me he rounded up. If I have 1 quart of vodka I can't sell it as a liter since I only have 0.946 quarts.

So which way should we go on this or should we even care. I started thinking about this because of all the trouble we're having with the convert template. When elevation_m or elevation_ft are used we could just do the math without using the template. I'm a firm believer in using library functions when they work but I'm starting to feel that the template just isn't proving reliable enough for your purpose. I don't mean to criticize the developers because they have to work within the limits of what they have available but we should look out for ourselves. I'm still running across broken articles and I think it reflects badly on wikipedia. – droll  [chat] 09:07, 10 March 2010 (UTC)

I don't think that commerce is the right analogy here. In scientific measurement, the commonly-accepted algorithm is unbiased rounding, where you round to the nearest value (as is done by the convert template), and break ties by rounding to the closest even value (so 152.5 meters will round to 152 meters). There's even an ASTM standard for this that has been in place since 1940. This is certainly what I learned in school (in lab classes). So I think that the rounding of the template is fine for elevations, prominences, etc. — hike395 ( talk) 14:42, 10 March 2010 (UTC)

So I learned it too. You can be sued if you deliver 0.9 units, but the deal was to deliver 1 unit. But your error is smaller when you say 1.501 units are 2 units, instead of 1 unit. -- Chris.urs-o ( talk) 15:37, 10 March 2010 (UTC)

OK, I see the logic in that. What about the second part. Doing our own conversion and not worrying about using {{ convert}}? – droll  [chat] 16:44, 10 March 2010 (UTC)

• When using a ft-to-m conversion, I would recommend to round to tenths of a meter, with the infobox elevation_ft, by appending "|1" (not "|0"), with elevation_ft as in {{convert|501|ft|m|1}} = 501 feet (152.7 m). That way, users could specify elevation_ft and get an accurate conversion for the equivalent meters. However, when a mountain has official ft&m amounts, such as for Mt Everest, then specify both by hand. I was thinking about the near-famous mountain in Kenya, Kilimambogo, no so famous as Kilimanjaro, so use either elevation_ft or elevation_m, if there are no official numbers for both. - Wikid77 ( talk) 21:16, 10 March 2010 (UTC)

• I'm was still seeing broken pages because of the {{ convert}} problem. I wrote a little conversion template we can use until convert is fixed. I think that in this case expediency trumped consensus but other better solutions are still possible. I just didn't see much happening. I followed Wikid77's suggestion about conversion to meters. The new template is at {{ Infobox mountain/convert}}. It even has error handling. – droll  [chat] 01:00, 11 March 2010 (UTC)

Rounding to a tenth of a meter is often (usually?) wrong. A lot of summit elevations are known only within one contour interval, e.g. ±10 ft. Converting that to a figure ±5 cm gives a false precision. This goes doubly so for prominence, for which both elevations are seldom accurately surveyed. Rounding such figures to the nearest 5 meters would be best. {{ Convert}} handles it reasonably well, though sometimes needing to specify |-1 precision.

—WWoods ( talk) 05:50, 18 March 2010 (UTC)

I have made two major changes to the code transcluded by Template:Infobox mountain/testcases. The examples on the left transclude {{ Infobox mountain/main}} directly and the examples on the right transclude ((User:Droll/subpages/sandbox4}}. There should be no difference in appearance. The code in my user space is just rearranged a bit and some meaningless code has been removed. Some of this code was leftover from when I was experimenting with another version of {{ infobox}}. Some appeared over time and I don't know where it came from. If there are not objections I will move the code from my user space into the active template. I will of include Eubulides's update in my sandbox version. – droll  [chat] 06:52, 11 March 2010 (UTC)

There is a difference in appearance (at least under Firefox 3.6/Linux): the labels on the right side of the test cases have a larger font than the left side (looks like 95% vs 90%, as we discussed on Droll's talk page). I've grown to like the smaller, yet boldface, labels: I think they don't take much space, but are still readable. I'm curious what other editors think. — hike395 ( talk) 03:55, 12 March 2010 (UTC)

Now both sides are set to 90%. I like it but let's wait a while and see if any body else has an opinion. Seem like its just Hike395, RedWolf and me. I thinking about trying to recruit some project members or something. Next step on my list is to limit the maximum size of photos and maps. – droll  [chat] 06:39, 12 March 2010 (UTC)

I guess I wasn't clear: I like 90% for labels and 95% for data. My reasoning: the labels are already bold and don't have any teeny-tiny text. The data is not bold, and has symbols like degrees/minutes/seconds, references, and <small> text. Please, take pity on my old eyes and let the data be 95%.

As for only three people participating: that's similar to 2004 when we designed the original infobox, and it was just me, RedWolf, mav, and d8uv. — hike395 ( talk) 08:44, 12 March 2010 (UTC)

• What happened to the map label? RedWolf ( talk) 07:39, 12 March 2010 (UTC)

I hasn't me this time :D. I'll track it down. – droll  [chat] 07:57, 12 March 2010 (UTC)

• It's back. How's that for service. I just copied in some code I knew was good. – droll  [chat] 08:28, 12 March 2010 (UTC)

• Now the location (as the map caption) is no longer being displayed. RedWolf ( talk) 18:59, 12 March 2010 (UTC). Fixed RedWolf ( talk) 19:43, 12 March 2010 (UTC)

• Was there a reason to remove map_alt? – droll  [chat] 20:00, 12 March 2010 (UTC)

I restored map_alt. I'm sure it was unintentional. – droll  [chat] 07:59, 13 March 2010 (UTC)

I don't understand why it's specified twice that's why I removed one of them? RedWolf ( talk) 16:59, 13 March 2010 (UTC)

• You were right as usual. I shouldn't stay up so late. I start missing things. Sorry. – droll  [chat] 20:41, 13 March 2010 (UTC)

I figured out way I am uncomfortable about the two different font sizes. Using "vertical-align:text-top" causes the baselines of the two cells to be misaligned. More tomorrow. – droll  [chat] 07:57, 13 March 2010 (UTC)

• So now, in the right column one testcases page, the label font size is 90% and the data font size is 95% and both are bottom aligned. Its a very small thing but I feel good with it now. If there is no objection I would like to move my sandbox version into the active template. – droll  [chat] 21:08, 13 March 2010 (UTC)

It looks good to me! — hike395 ( talk) 22:23, 13 March 2010 (UTC)

It's fine for me as well. RedWolf ( talk) 03:06, 14 March 2010 (UTC)

Y I synced main with my sandbox. – droll  [chat] 04:02, 14 March 2010 (UTC)

• N So the vertical-align:text-bottom didn't work out and I reverted that park of the active template. Line wrap in the data cell caused trouble. I set both sides to the default font size with is set to 95%. I think its the right thing but we can talk. I did a temporary edit of the testcases as an example. – droll  [chat] 05:20, 15 March 2010 (UTC)

I know. It looks fine in Foxfire but look at it in IE if you can. – droll  [chat] 05:28, 15 March 2010 (UTC)

Oh, yes, I see: IE made a mess of vertical-align:text-bottom. What's wrong with vertical-align:text-top? — hike395 ( talk) 07:11, 15 March 2010 (UTC)

Thanks. I'll do it. – droll  [chat] 08:42, 21 March 2010 (UTC)

I'd like to modify {{ Infobox mountain/main}} to pass the coordinates_ref= parameter to {{ Infobox coord}}, in order to allow title coordinates to be footnoted. Please unrevert (or authorize me to unrevert) this edit. Cheers,-- Stepheng3 ( talk) 06:30, 17 March 2010 (UTC)

Please make your changes to the template's sandbox and/or sandbox for /main and check out the testcases to ensure everything works as before and your change has its intended effect. However, I am wondering why we need to footnote the title coordinates when they are already footnoted in the infobox? I have not noticed footnotes on other title coordinates (not using this project's infobox). RedWolf ( talk) 06:45, 17 March 2010 (UTC)

I don't think this change would be a good idea. It is my understanding that, for a long time, the maintainers of {{ coord}} were opposed to adding the parameter notes to that template and finally added it so that coordinates that only appear in the title line could display a link to a bottom note. I do not know of any other template that adds a link like this. Examples are of templates that do not are {{ Infobox settlement}}, {{ Infobox protected area}}, {{ Infobox NRHP}} and {{ Infobox lake}}. As far as I know, such a change would be precedent-setting. IMHO the title line is already cluttered enough. – droll  [chat] 07:28, 17 March 2010 (UTC)

I don't want to sound rigid on this and I know User:Stepheng3 contributes to WP:GEO and probably has a better grasp of the issues than I do. I had left a note on Stepheng3's talk page recommending that the revision be discussed here but I'm thinking it might be better to discuss it at WP:GEO or WP:MOS. – droll  [chat] 07:51, 17 March 2010 (UTC)

Wikipedia talk:WikiProject Geographical coordinates would've been okay with me. However, since your heads-up on Template talk:Coord points here, I'd prefer to continue here.

I've implemented the proposed change at Template:Infobox mountain/sandbox2/main and created a test case at Template:Infobox mountain/testcases2, so I know it works.

I'm sensitive to the clutter issue. However, if it's important to duplicate the coordinates themselves, then wouldn't it be useful to duplicate the footnote, too? Otherwise someone looking for sources might miss the fact that the coordinates in the infobox were footnoted.

Droll, can you point me to the opposition you mention? The only discussion I'm aware of took place in 2009 and is archived at Template talk:Coord/Archive 8.

Change has to begin somewhere. If the change to {{ Infobox mountain}} is approved, I hope to proceed with the other infoboxes. So yes, this is the time for discussion. -- Stepheng3 ( talk) 08:19, 17 March 2010 (UTC)

I've always wondered why we duplicate coordinates both in infoboxes and in the title. Why not simply do nothing in the title? — hike395 ( talk) 08:43, 17 March 2010 (UTC)

I looked up the discussion about adding the notes parameter to coord. Turns out I was the opposition. As to hike395's question, I think I read somewhere that data miners like the coordinates near the top of the page. I think his point should be considered.

Since Stepheng3 prefers to continue the discussion here I have posted a heads up at Wikipedia talk:WikiProject Geographical coordinates and Wikipedia talk:Manual of Style. I'm not sure if this is good idea, as I noted above, but if this is a discussion about a global policy then we should seek input from a larger segment of the community. – droll  [chat] 10:38, 17 March 2010 (UTC)

The "testcases2" for the sandbox above display the coordinates twice, partially overlayed on top of each other. But apart from that, I'm opposed to adding the clutter of a footnote to the header line. It's just too ugly. − Woodstone ( talk) 10:46, 17 March 2010 (UTC)

The overlapping coordinates is due to the coordinates templates being used more than once on the page with different values so normally this would not be a problem. I have to agree with Woodstone though that adding a footnote to the title coordinates is clutter and so I do not support adding the title footnote at this time. If there is a wider consensus among the community that this is beneficial, then we can revisit this. RedWolf ( talk) 04:13, 19 March 2010 (UTC)

{{ Editprotected}}

Please revert the last edit to this template, {{ Infobox mountain}}. The requested changes were effected in {{ Infobox mountain/main}}. Infobox mountain is currently only a wrapper for Infobox mountain/main. No functionality should be added to Infobox mountain as it is utilized only for parameter name translation. – droll  [chat] 00:00, 21 March 2010 (UTC)

 Change reverted RedWolf ( talk) 00:07, 21 March 2010 (UTC)

I figured out a way to sort the parameter order using AWB. I figured it is worth doing especially if there are other fixes that are useful on a page. I started this project to update the parameter names on all the pages that use the template. I kept seeing additional things to do while I was at it. So here is the order I came up with:

{{Infobox mountain
| name = 
| other_name = 
| photo = 
| photo_alt = 
| photo_caption = 
| elevation = 
| elevation_m = 
| elevation_ft = 
| elevation_ref = 
| prominence = 
| prominence_m = 
| prominence_ft = 
| prominence_ref = 
| map = 
| map_alt = 
| map_caption = 
| label = 
| label_position = 
| parent_peak = 
| listing = 
| translation = 
| language = 
| pronunciation = 
| location = 
| range = 
| lat_d =  | lat_m =  | lat_s =  | lat_NS = 
| long_d =  | long_m =  | long_s =  | long_EW = 
| dim = 
| region = 
| scale = 
| source = 
| coordinates = 
| coordinates_ref = 
| grid_ref_Ireland = 
| grid_ref_UK = 
| topo = 
| type = 
| age = 
| volcanic_arc/belt = 
| last_eruption = 
| first_ascent = 
| easiest_route = 
}}

This order is mostly based on the order in which things appear in the displayed template. A few places it is just alphabetic. I would appreciate any and all thoughts.

I realized that we probably need a {{{grid_ref}}} parameter to match the {{{coordinate_ref}}} parameter. – droll  [chat] 07:55, 21 March 2010 (UTC)

Looks good. I would put parent_peak just after prominence, because that's where it occurs in the infobox (and is natural) — hike395 ( talk) 08:31, 21 March 2010 (UTC)

• After dealing with infoboxes that have used this ordering, I find it unhelpful for copy/paste actions when I want to add a location map. I typically go to the mountains category and find a mountain in the same category and copy/paste the map lines. However, the map lines of interest are spread out and not consolidated which would make copy/paste much easier. So, all the "map" parameters should be grouped together for easier copy/paste. RedWolf ( talk) 05:08, 15 June 2010 (UTC)

A while back I updated and sorted the field names of all the articles that use the template. It took forever. However, I did not intend to establish any standard. I just wanted to improve on the current status. Perhaps the order on the documentation page and Wikipedia:WikiProject Mountains/infoboxes should be improved. – droll  [chat] 07:37, 24 June 2010 (UTC)

{{ editprotected}} I don't think that the current infobox makes a clear enough distinction between "oldest dated rock" and "estimated age". In many ways estimating a mountain's age by the oldest rock aquired and dated from it is the same as scooping up rock from the Earth's surface, finding it to be 1.2 million years old, and saying that the Earth is 1.2 million years old.

Case study: Hualālai USGS reference:

"Oldest Dated Rocks: About 128,000 years before present"

"Estimated Age of Hualalai: Apparently grew above sea level before 300,000 years ago"

And yet on the page it states that the volcano is but 128,000 years old! I see this across many, many pages covered by this infobox, and overall all it does is muddle people up about the dates, create inconsistances, and make pains when trying to categorize mountains by their age.

Now I know there is a bit of gray area in what classifies a "mountain" or "volcano", but age of oldest dated rock is simply NOT age, and deserves a parameter of its own. I'd mentioned this before sometime but now I realize I was not clear enough. Can we get some concensus here? Res Mar 22:31, 14 June 2010 (UTC)

Hi, ResMar. I'm a bit confused about what you are suggesting. The infobox for Hualalai states that the 128,000 years is the age of the rock, not the age of the volcano/mountain landform itself. Are you asking for another infobox entry for age of the landform? For non-volcanic mountains, that may be ambiguous: do you mean the age of the orogeny that gave rise to the mountain? Or when it eroded into a peak? (that may be very difficult to determine). Please clarify, so we can discuss further. Thanks! — hike395 ( talk) 05:09, 15 June 2010 (UTC)

Perhaps ResMar is suggesting that the field should be changed to "Oldest dated rock" rather than just "Age of rock". Anyway, I'm disabling the request for now while the discussion continues. — Martin ( MSGJ ·  talk) 08:37, 15 June 2010 (UTC)

Changing "age of rock" to "oldest dated rock" is fine with me: it's much clearer. Would that satisfy you, ResMar? — hike395 ( talk) 09:40, 15 June 2010 (UTC)

Yes that is what I am getting at, somewhat. And I thought I was being clear about it... Res Mar 23:07, 15 June 2010 (UTC)

• The field links to Geologic time scale. Is this not sufficient to provide a clear definition? The infobox also has the field "Prominence" which can have several meanings so that's why it's linked to Topographic prominence. As well, on a point of simple presentation, changing it to the much longer suggested name will either cause a double row for the labels column or force us to shorten the text column to make room for the bigger label, neither of which appeals to me. RedWolf ( talk) 01:02, 16 June 2010 (UTC)

No it is not enough. Aesthetic decisions go behind functionality any day, and the fact that a good half of the volcano articles have their age as the oldest dated rock found is a good demonstation of that point. Res Mar 02:15, 16 June 2010 (UTC)

I modified the sandbox version to show the aesthetics of "Oldest dated rock", at Template:Infobox mountain/testcases#Mount Baker. Note that the infobox prevents line breaks in the labels, so it won't force multiple lines. What do other editors think? — hike395 ( talk) 02:34, 16 June 2010 (UTC)

Actually, now that I think of it, we can do something like I did at Kohala (mountain). Add instructions to seperate different numbers with <br/> would work without requiring any changs to the template. Res Mar 12:44, 16 June 2010 (UTC)

I would prefer to change the template, perhaps by adding a row. At Kohala, the infobox says "Estimated", but it does not say what is being estimated, The label for that row of the infobox says "Age of rock", but the estimate is for the oldest age of the rock deep inside the volcano somewhere. That's not obvious to our readers. — hike395 ( talk) 13:28, 16 June 2010 (UTC)

Yeah I would too. I'm flexible as long as the point is driven across. Res Mar 20:09, 16 June 2010 (UTC)

I updated the sandbox again: see Template:Infobox mountain/testcases#Mount Baker. Now there are two rows "age of rock" and "age of volcano" --- does that address the issue? — hike395 ( talk) 06:04, 17 June 2010 (UTC)

Why volcano? It should be "estimated age." Volcanically speaking, there are two indicators of age, first eruption and time rose out of the sea (for oceanic volcanoes), but for mountains you can estimate age too, like for the Himalayian belt couldn't you cite the time of impact? No need to be so specific :) Res Mar 13:52, 17 June 2010 (UTC)

Even if we know the age of the orogeny for a whole mountain chain, the age of a single mountain landform is rarely known and may not even be well-defined (when does a mountain peak become a mountain peak? how much erosion does it need?) My experience looking at articles with {{ geobox}} tells me that having a general infobox row available just gets abused by inexperienced editors. — hike395 ( talk) 15:04, 18 June 2010 (UTC)

Perhaps it would be easiest to drop the field entirely from the infobox rather than giving too little information. Maybe the age should be discussed in the body of the article. – droll  [chat] 04:08, 18 June 2010 (UTC)

You mean the age of the landform? (i.e., the new row?). I would be content if we didn't have the row in the infobox. What do other editors think? — hike395 ( talk) 15:04, 18 June 2010 (UTC)

• If the current parameter is too general and commonly leads to misinterpretation, then perhaps we should consider removing it entirely. That being said though, there is nothing stopping anyone from writing more than the typical one to two word geological time scale that is usually provided. Perhaps by providing this parameter it "entices" editors not to provide more information in the article body? By forcing this into the body, the editor will provide more information on whether its the age of the rock or the volcano or whatever else. I do not usually pay much attention to this field myself and it intends only to be used for volcanoes -- since this mountain type tends to get the most research/attention paid to it by geologists, age of the rock and/or volcano is something that is usually present in their reports/papers (or at least that's the impression I get). While adding a second parameter is an option, I think it may just lead to confusion as to when to use which one. As hike395 pointed out, even replacing it with orogeny would be problematic. Out of all the Geoboxes I have added, I rarely have filled in the orogeny parameter and even then I don't think I was fully confident of what I entered in many cases which usually means I fill it in even less as I do more. If it's problematic for a range, an individual mountain would be much more difficult. RedWolf ( talk) 06:59, 20 June 2010 (UTC)

• Why don't we just depreciate the parameter. Going through every article that uses the parameter and moving the information into the article would be tedious. We could just remove it from the parameter table and the examples and mention somewhere that it is deprecated. There are a couple of other fields I would like to deprecate as well. More on that later. – droll  [chat] 03:00, 24 June 2010 (UTC)