OpenStreetMap

Peaks and Mountains

Posted by valhikes on 7 February 2024 in English.

Ever since visiting Mount Lassic and then making edits in the region, I’ve had this nagging difficulty: What to do with a mountain whose high point is named differently? Mount Lassic has three peaks, the highest is called Signal Peak. I eventually mapped its survey point, which is also called Mount Lassic, and hoped that was done. (Apparently I shouldn’t map survey points except at the exact point indicated, so I’ve done this WRONG. I’ll just name a peak “Such-and-such Benchmark” then. Except a benchmark is specifically a vertical control and most at peaks are horizontal controls. “Such-and-such Triangulation Station” gets a bit long. Oh, the humanity!) Unfortunately, if one searches for the mountain, one only gets the Mount Lassic Wilderness and the Mount Lassic Trail, but there’s no hint that this goes to the high point of Mount Lassic. It goes, in fact, to “Signal Peak”.

Other places where there’s a named high point (peak) different from the main mountain are Marble Mountain (with Black Marble Mountain the high point). Someone seems to have simply marked a lower peak as Marble Mountain. If one does this, there’s a bit of a debate if it is the highest white peak or the most prominent white peak. Mount Konocti with high point Wright Peak. Currently both are marked close to the high point, but the main mountain has been given a lower elevation so doesn’t show often, but it is searchable.

Ideally, this all renders such that one sees the mountain name at low zoom and get individual peaks at high zoom. For purposes of clarity, I am using “mountain” to mean the landmass that may have many peaks and “peak” to refer to points where every direction is downhill. I think this is common English usage, but I’ve seen areas of maps where it looks like the usage was reversed. The only solution above that renders all eventually is the one on Marble Mountain. However, the result is not as desired and false. And which peak to you demote the actual mountain to? Mount Konocti has several named peaks to push the mount down.

Discussions in the past have gone on to relations. There’s a few in use, either of type “site” or “multipolygon” or suggested “multipoint”. Another solution is to mark the area as a natural=mountain. None of it gets rendered, but perhaps the renderers just need to catch up. All of it is currently used somewhere.

For the relations, some objections are that while points and ways are obvious from the start, even many experienced mappers don’t quite get relations. Count me among them. I’ve tried a few route relations. (And I should get back to the California Coastal Trail, I suppose.) There’s a comment about multipolygons being a bad idea after all. I’m definitely not going to delve into that. I went ahead and tried a site relation for Mount Lassic, first dropping on the other two minor peaks with the bare minimum of information. It still isn’t searchable and doesn’t render. My objections are that if someone adds a peak that should be part of the relation, it may or may not every get included.

Objections to marking an area as a natural=mountain are that the area is quite nebulous. The objectors liken the indistinct nature of where the mountain is to that of already “in use” natural=mountain_range, which seems to lack understanding that mountain ranges have many sub-ranges. Peakbagger.com will list 5 levels of ranges for any particular peak. Being part of the Rocky Mountains is far from the end of the story for mountain ranges. Mountains really don’t have so much difficulty. One person points out the object in drawing is to mark a general area that gets labeled, but that area itself is never expected to be rendered.

Although I’ve made a stab at making a relation, I think an area is best. I’m surprised that there’s 20 uses of natural=mountain worldwide and some of them don’t even make sense. How does a mountain have a leaf_type? (I must be doing this wrong?) There’s a quite old multilingual proposal. There’s a region:type that’s clearly getting discouraged now. There’s another 115 uses of natural=peak applied to ways, which seem to be generally closed. Here is one solving the problem of the different peak and mountain names.

Seriously, it’s cute that there’s a Bears Ears East and Bears Ears West, but when I zoom out, there should just be Bears Ears. It might be nice to find Maroon Bells on the map instead of Maroon Peak when zoomed out. It might be nice to have the various Mount Massive peaks represented and still known as part of the whole too.

Also, natural=mountain_range probably needs a bit of work in spite of the 5000+ uses already. The focus here is just getting the mountains right.

Location: Humboldt County, California, United States

Discussion

Comment from Kai Johnson on 7 February 2024 at 18:13

Those are some interesting thoughts on mountains whose summits are named differently from the mountain itself.

I think of all the things you mentioned, using natural=mountain as a single node to label the mountain is the most practical. This is a natural feature that has a presumably verifiable name, so it can be mapped. However, as the area of the mountain is likely indistinct and not verifiable (except in unusual circumstances), it doesn’t make sense to map it as an area using a closed way.

I understand the desire to use a relation to group related features, but this is something that OSM struggles with right now. Consider Relation: Great Lakes (1124369) which has had a history of being tagged in different ways, or the challenge of structuring a Tag:place=archipelago relation.

You could make a relation with natural=mountain and the peaks as members, but I think that would be somewhat experimental until OSM figures out how to map groups of things effectively.

Comment from SK53 on 7 February 2024 at 18:50

You are not alone!

One approach has been to name the connecting ridge as with Buachaille Etive Mòr although the name is equally linked to the main peak {Stob Dearg](https://www.openstreetmap.org/node/25453202) as the inventive use of name:ga suggests.

Elsewhere in Scotland, very uninformative place=locality has been used for An Teallach and ‘alt_name’ for Liathach although the name really refers to the whole mountain.

For Monte Rosa natural=mountain_range has been used, but this is inaccurate both in terminology and mapping (I’d say Monte Rosa ends at the Lisjoch and does not include Lyskamm or Castor & Pollux; the way also does not include the high point of the Monte Rosa massif, Dufourspitze).

Dent du Midi uses both natural=massif and place=locality.

The Ten Mile Range just gets natural=ridge plus some wikidata and wikipedia tags.

TL;DR: tagging is a mess for these.

Comment from Kai Johnson on 7 February 2024 at 19:28

This would be a good topic to post on the OpenStreetMap Community Forum to see if we can get some consensus on how to map mountains whose names differ from the names of their summits.

Comment from valhikes on 7 February 2024 at 21:31

Looks like someone has dropped in a wiki page for natural=massif stating that it is for this specific purpose. (Born November 2023.) The abandoned proposal indicates it’s more of a small range. The dictionary definition is a “compact cluster of mountains” but dictionaries can be rather imprecise with their language. My fuzzy feel for what a “massif” is suggests it might be applicable. It’s got 26 uses to natural=mountain’s 20 uses! The wiki editor has unilaterally (I’m being presumptuous) decided that it should only be applied to areas. Areas was all I was thinking until this first comment mentioning that they could be points. I have to admit, points maybe should be valid.

By the wiki, natural=peak should only be applied to points. In spite of the 115 ways this does seem the right and good way. Most of what I clicked on were indistinct bumps, often in parks. I’m willing to just shuffle these examples into the “wrong” category. Sticking a point in the middle would do as well. Better since it would be rendered.

One could decide that peak should just get extended, as this example shows with Wilderness Peak surrounded by Andrew Nyman Mountain, both natural=peak. This would preclude mapping a mountain/massif as a single point. Oh, dear, take it to the extreme and you don’t need mountain_range. Just draw ever bigger “peak” contours for each level of range. However, I would prefer not to conflate the concepts. Peak is a point where every direction is downhill. It can be as minor or major as you like.

@SK53 Those seem to generally be kludges to make things render. I’ve hit a few possible nails with the “locality” hammer, too. Hopefully they were applicable.

As I sit here shuffling thoughts around for the comment, I think I might just put some momentum behind the massif. It feels like it would have fewer problems with people trying to promote their peak just because it “feels more important”.

Comment from osmuser63783 on 18 February 2024 at 14:23

The natural=massif Wiki page is a byproduct of this community forum discussion in German about the topic.

Comment from dieterdreist on 19 February 2024 at 00:04

Interesting read. I agree from the currently common options a site relation seems best for a natural=mountain object, where it is needed (i.e. peak name and mountain name are different), because it elegantly avoids the problem of having to define a precise area and doesn’t need any additional geometry.

Regarding the mountain ranges, we could have hierarchies of nested mountain ranges (at the lowest level, nodes (peaks) or site relations (mountains) could be added, while everything above would only contain relations. Having 5 levels (or more) of nested mountain “areas” (consisting of nodes and relations) wouldn’t be a problem or expensive with the current system - if people can agree which mountains are in which range, and which ranges build up the ‘‘named mountain area’’ in the next level.

Comment from osmuser63783 on 19 February 2024 at 20:32

@dieterdreist: many peaks have a wikidata tag, the wikidata items for mountains often in turn link to the items for the mountain ranges they are in, and these are organised in a hierarchy :-) so someone who is looking for this data should be able to find it there!

Comment from dieterdreist on 19 February 2024 at 22:00

@osmuser63783 I like wikidata, but it is not a substitute for mapping stuff in OSM. We’re a mapping project with the aim to map the world, mountain ranges shouldn’t be out of scope.

Comment from valhikes on 7 March 2024 at 02:28

Mapnik has it’s support behind natural=massif as well. It renders. Not quite the way I would want, but if I zoom in far enough, it says Mount Lassic. Taginfo indicates Dianacht Topo uses it (area only), OpenTopoMap (area or way), and OsmAnd (all).

I saw in the discussion that got the wiki entry that it wasn’t linked to peak on purpose. Perhaps it would be okay after all. Hill is linked, and what good is that? Prominence is not although it is the better answer to the linked enhancement proposal. (The people saying it can just be calculated: PeakVisor says they recalculate for their ~1M peaks every time there’s a better elevation model and it takes a little over a day. All to save a tag?)

I like an area. It maintains itself as to included peaks. It is straightforward.

As to verifiability, it is verifiable that there’s a thing there that a user of map data might want to consider, it’s just the edges that are difficult. They also lack importance. A valley goes from ridge to ridge, but it is only the bottom of it that people want labeled or to consider as the valley. Sometimes “around here” is actually okay.

Log in to leave a comment