Wikipedia:WikiProject Mountains/General Discussion Archive 2

Elevation: metres versus feet for infoboxes

The current convention when displaying the elevation of a mountain in the infobox is to include the height in both metres and feet. The question is which one to display first. The convention I have been using is to display metres first and then put the equivalent feet value in parenthesis when listing any peaks outside the United States. For US peaks, I have been following the alternate standard of putting feet first and then the values in metres after in parenthesis. See Mount Temple or Vinson Massif for examples where metres is first and Mount Hood or Mount Rainier where feet is first. RedWolf 05:50, May 12, 2004 (UTC)

Disambiguation of elevation

Well, elevation is now a disambiguation page and all the articles with infoboxes link to it. Should we consider replacing the link to elevation with Above mean sea level e.g. Elevation? RedWolf 08:07, Aug 7, 2004 (UTC)

Well, Above mean sea level isn't a very good article for mountain reference, I feel. The disambiguation page almost does a better job of it... --patton1138 15:00, 9 Aug 2004 (UTC)

I have added a paragraph to it, relating to geography and mountains. I took what was at elevation and expanded on it somewhat. Could also consider adding sections although the article isn't really long enough yet I think to do so. BTW, I can take care of disambiguating the links with a bot so fixing the problem won't be overly tedious. RedWolf 06:21, Aug 16, 2004 (UTC)

Another option is to create a new article, such as elevation (geography) which contains what I recently added to Above mean sea level. That way, it would be less confusing to those clicking the elevation link in the info box. I have noticed that the German Wikipedia is linking to altitude. RedWolf 06:19, Aug 20, 2004 (UTC)

This sounds like the best option so far. Above mean sea level was a bit too general and 'jack of all trades' even with your addition, RedWolf. But a dedicated topic doesn't sound half bad. --patton1138 00:52, 22 Aug 2004 (UTC)

Someone created Topographical summit which might be a better alternative. I have copied the text I added to Above mean sea level to fill it out a bit. RedWolf 04:27, Nov 19, 2004 (UTC)

Duplicate peaks in one political division

There are many instances where the same name has been given to multiple peaks in the same US state and less frequently in Canadian provinces (usually just Alberta and BC). This issue has cropped up for Brown Peak (California) and now Granite Peak a few days ago. GNIS returned over 40 mountains with this name with multiples in multiple states. Geez, there should have been a law a couple hundred years ago stating that "you shall not have a given peak/mountain more than once in any one state"! :=) I have been sidestepping the issue for a while because I wasn't sure how to handle this naming madness. One option would be just list all the peaks in a given state at peak name (division name). Alternatively, as I have done for Granite Peak, list them all there and if someone feels one of them deserves an article (the highest point in Montana by this name certainly does although there are multiple peaks by that name there as well), they can go ahead and create one. Perhaps we need a revised info box for these cases? At this point, I certainly don't think we need individual articles for all 40+ Granite Peaks. RedWolf 05:42, Oct 27, 2004 (UTC)

I really like what you did at Granite Peak. I think we should promote it as the WikiProject standard infobox when there is more than 1 peak in a country with the same name. (I could accept a higher threshold, too). The nice thing is it is extendable: if someone feels that one of the peaks deserves an article, replace the GNIS link with an internal Wikipedia link. I know you've made several stubby articles for name-alike mountains --- we can keep these if they already exist. Would you like to change the Template section of our WikiProject page to explain this new disambiguating infobox?

I'm going to move Brown Peak (California) to Brown Peak (Kern County, California), and put one of these dab infoboxes at Brown Peak. Thanks for designing this! I was almost ready to give up. :-) -- hike395 06:03, 27 Oct 2004 (UTC)

I have added a first cut of Naming conventions to the project page. RedWolf 19:14, Oct 30, 2004 (UTC)

Thanks, RedWolf! Shall I copy over Brown Peak onto the main project page (just in case the article at Brown Peak gets tweaked) ? (Only suggesting Brown Peak because it is shorter than Granite Peak). Do you have a opinion about the "USGS Map" column? I like it, but could drop it, too. Also: do you have any opinion about the yellow header color #ffffcc ? Should we use that instead of the standard Mountain infobox color #e7dcc3 ? I have a very mild preference towards the standard, but if you like yellow more, that's totally OK with me. -- hike395 01:22, 1 Nov 2004 (UTC)

Template to cover part of infobox

Mount Baker
Mount Baker from the Northeast
Elevation:	10,778 ft (3,285 m) {{US mountain location|48.7768|121.8144|Washington|Mount Baker}}
Range:	Cascades
Type:	Composite volcano
Age of rock:	< 30000 yr
First ascent:	1868 by Edmund T. Coleman and party
Easiest route:	rock/ice climb

Here is a new proposal for a standard mountain infobox, for mountains in the US. It includes a template that creates the latitude, ongitude, and topo map fields. The template takes 7 arguments --- lat D/M/S, long D/M/S, and topo map name.

I decided against making a great big infobox for a few reasons. First, it was big and hairy to try and make optional rows in the table. Second, it was annoying to create and not that helpful for editors. Third, "What links here" to mountain pictures would be broken, which seems really bad.

I'm sticking with D/M/S because all of the web calculators that convert to decimal degrees (thanks, mav!) only keep 4 significant figures (=0.36″), and I like the higher precision that we get from NGS. Mav told me he likes decimal degrees better. Any tiebreakers out there?

But, I'm open for comments and suggestions before I go forth and change all of the US mountains. Notice that, in order to make one template call, I re-ordered the rows in the infobox. This would make it inconsistent with non-US mountains (which may have to eventually change, if we decide to link to topo maps outside the US).

Comments? Suggestions? --- hike395 00:06, 16 Dec 2004 (UTC)

Actually http://www.deh.gov.au/erin/tools/dms2dd.html gives decimal degree to 12 decimal places. I prefer decimal degree to DMS due to the fact only two numbers are needed to denote any local. Thus the editor would only have to pass two values to the template instead of 6. --mav 00:29, 16 Dec 2004 (UTC)

My mistake --- I was typing in the Mount Baker lat/long to test the sites, but it looks like my test numbers were rounded to 0.0001;deg.

Previously we had settled on D/M/S, but this is new, so we might change (at least for the US, at the cost of inconsistency with non-US mountains). What do non-hike, non-mav people think? --- hike395 05:51, 16 Dec 2004 (UTC)

Personally, I prefer degrees, minutes and seconds. I doubt you will see many non-US mountains with even one decimal point. I can barely manage to get the seconds to the nearest 05 for most Canadian mountains. I have gotten so used to seeing lat. and long. after the elevation that I find the re-arranged order looks strange. I'm also wondering why it needs to be re-arranged exactly? None of the other rows not being used by the template occur within the first rows of the project's main infobox. As you have pointed out, the re-ordering makes it inconsistent with all the other non-US mountains. Also, why not also add elevation while you are at it? BTW, speaking of elevation, I changed the main infobox to link to topographical summit. RedWolf 04:44, Dec 17, 2004 (UTC)

I'm happy to stick with D/M/S. You're probably right that I shouldn't add inconsistency with the other mountains. I made it better in the template, above. My philosophy was to make the simplest possible template --- the lat, long, and topo map rows all depend on the same 7 arguments. If we add elevation, it doesn't save any typing. This template saves people from typing latitude & longitude twice (which is error prone). -- hike395 01:22, 20 Dec 2004 (UTC)

Looking good. I notice you are using positional parameters and not named parameters for the template. Being a developer, it doesn't really matter too much to me although I've always used named parameters for any templates I've created just because they tend to be self-documenting so at least other people who come across it might make some sense of what the templat expects. You don't think it might cause confusion to other people used to named parameters? RedWolf 04:08, Dec 22, 2004 (UTC)

It's a trade-off: it's self-documenting, but requires more typing. I don't know which is better. I tried to make the whole infobox self-documenting, by adding an HTML comment right above the template call. But, that could get dropped by random people. I could go either way. -- hike395 05:35, 22 Dec 2004 (UTC)

After looking at the Geolinks template, I became very excited about all of the external links that we could autogenerate in the Mountain infobox. I've updated the test template, above right, to use those links: topo map, aerial photos, surrounding area maps, location in the US. The downside is that almost all of these external sites need decimal degrees, not D/M/S. So, we have three choices:

1. Keep the extra external links, drop D/M/S --- very easy to type, good information, inconsistent with non-US mountains.
2. Only use topo map link, keep D/M/S, use named arguments --- a little more typing, sad to lose the information, good consistency.
3. Keep the extra external links, keep D/M/S, require editors to provide both decimal degrees and D/M/S as named arguments --- the best of both worlds, but lots of annoying typing.

What do people think? I don't think (2) is a good idea, but I'm willing to do (1) or (3). -- hike395 16:22, 27 Dec 2004 (UTC)

Eh, I don't see much in the external links. The topo map definitely must stay, but I don't see a problem in losing the other externals. They're sorta just eye candy for the most part. The only one I find mildly interesting is the location in US. The surrounding area map is ugly and is accomplished via topo. Aerial map is kinda interesting. Whatever is fine by me. I don't mind extra typing for both DMS and DD.

I actually kind of like option 2 but adding the "Location in US" link. The surrounding area map doesn't seem very useful considering there are no labels to identify features. The aerial photo is somewhat interesting but would others actually find it useful? If there are only a few parameters for a template, positional parameters are okay but while named parameters mean more typing (although copy/paste alleviates that), it at least will not be totally confusing to other people who might edit the article and wonder what all the parameters are for. Decimal degrees are fine for generated digital maps but not as much for paper topos that humans typically use. Entering both D/M/S and decimal degrees might be overwhelming to others and will make it inconsistent with non-US mountains. RedWolf 19:44, Dec 30, 2004 (UTC)

Another possibility is just

4. Don't change infobox, just add geolinks template to external links.

Given RedWolf's concerns about this, perhaps we should just stick with the infobox as it is, and add the map links to the external links section. It's a little cleaner, anyway --- external links stay together and the infobox is consistent between US and non-US mountains. -- hike395 15:40, 26 Jan 2005 (UTC)

• Didn't want to rain on your proposal hike395, but consistency was one of my chief concerns in the infobox (I write some technical documents in my day job so it kind of rubs off here). I don't have a problem with option 4. RedWolf 03:50, Jan 28, 2005 (UTC)

I've started to add geolinks to mountain articles, with a specialized template. I'll explain on the project page. hike395 04:49, 28 Jan 2005 (UTC)