I can think of various cases where what local people call a mountain does not match the concept of a `natural=peak` node because the mountain is actually a massive one that contains multiple individually named peaks.
Examples (from French Alps):
Meije: 3 to 8 peaks depending on sources (4 on OSM)
Grandes Jorasses: 6 peaks, none of which is called “Grandes Jorasses”
L’Ailefroide: 4 peaks on OSM
Levanna: 3 or 4 peaks
and it goes like this for many places!
As far as I could find, these groups are not represented on OSM, I would like to add some of them, but I am rather new to contributing to OSM and am not sure what is the best way to represent this. Some ideas I can think of:
Tag `natural=mountain_range`: That seems to correspond to much larger scale structures such as “The Alps” or “The Hymalaya”, and it is not used as a relation so it does not inform of which peaks belong to it (unless it is an area, but it is hard to define area boundaries in my case).
Relation `type=site`: It could do, but feels a bit abstract, has this been used for this use case already? Is there any tag to add to precise the nature of the site?
Any other ideas? Any related example that comes to mind? Thanks!
There’s type=cluster / type=group when it’s simply a collective name= type=site is a feature of its own, requiring natural= / site=
Inventing a *:name= / *_name= (caveat: the few group:name= / group_name= aren’t used for this, and are poorly named) on the =peak might be simple, but need to consider how unique and thus useful the names are. It isn’t mutually exclusive with the type= feature.
I also considered it since in the 4 examples I gave the peaks are indeed distributed along a single ridge, but it feels a bit off because (a) I’m not sure such compounds are always a ridge and (b) people don’t usually call it “the ridge of Grandes Jorasses”, just “the Grandes Jorasses”, which they consider to be a mountain.
The type=group or cluster seems promissing; @Kovoschiz I’m not sure how to interpret what you say about type=site: do you think it is relevant in the end? It could be type=site,natural=peak?
I suggest not using type=site (and it’s not 1 =peak , but multiple)
I advocate for type=cluster , as it’s less confusing and misusable than any random “grouping” for type=group
OSM data model is simply not suitable for large and vaguely defined features such as mountains, valleys, plains and bays. Various approaches have been discussed and proposed, but none gained widespread acceptance. Now we’re in an “any way you like” situation.
In Serbia, most mountains are geologically old and more like highlands, typically having multiple non-prominent peaks, and are bounded by river valleys. Therefore, most don’t even have a discernible ridge, and no sharp boundaries. Back in the day I added simple points tagged natural=mountain_range; name=* next to every highest peak (which often has a different name than the mountain). Someone else later added ways with those same tags, roughly along the mountain’s longer axis. Yet others have added even more vaguely defined areas for some, such as Serbian Carpathians. It’s a mess overall, and those names do not render almost everywhere, but at least you can find them using Nominatim.
For your case, I would hesitate using relations, particularly new-fangled ones such as group, since they would be undiscoverable. For Grandes Jorasses, I would say that a natural=ridge way describes the situation just fine. OSM tag values do not necessarily correspond with real-life terms, and we don’t even have a tag with value mountain unless you invent one. But, as I said, this is an uncharted territory in OSM data model.
I’m responding to type=site + natural=peak
A type=site + natural=mountain would need to include everything =ridge , =arete , =saddle , etc. It doesn’t refer to only the top either.
A =mountain can further have multiple sets of =peak / tops. So the scope is beyond the post question.