Proposal: Mapping Mountain Ranges and Their Boundaries in OpenStreetMap (Global Discussion)

General talk
1

# Proposal: Mapping Mountain Ranges and Their Boundaries in OpenStreetMap (Global Discussion)

Hello,

I would like to start a broader discussion about how mountain ranges should be mapped in OpenStreetMap on a global level.

Currently, many mountain ranges are mapped using `natural=mountain_range`, sometimes as a node, sometimes as a way or multipolygon. In many cases, there is no clearly defined boundary, and there is also no consistent approach to grouping related peaks or subranges.

This raises several questions:

## Questions for Discussion

1. Should mountain ranges generally have mapped boundaries (as areas/multipolygons), or should they remain conceptual features without strict borders?

2. If boundaries are mapped, what criteria should be used?

  • Geomorphological classification

  • Watersheds

  • Elevation thresholds

  • Existing scientific or governmental datasets

3. Is it appropriate to create relations grouping:

  • Outer boundary (if defined)

  • Member peaks (`natural=peak`)

  • Subranges

  • Related saddles or ridgelines

4. Should there be a recommended tagging scheme for hierarchical structures (e.g. mountain system → range → subrange)?

## Challenges

One challenge is that mountain range boundaries are often not physically sharp and may differ depending on scientific interpretation. Additionally, many official geomorphological datasets are not compatible with ODbL, which complicates large-scale imports.

I am not proposing a mass import. Instead, I would like to discuss:

- Whether OSM should aim for more consistent modeling of mountain ranges

- What the best data model would be

- Whether a proposal page in the wiki would be useful

- Examples of good existing implementations

For reference, there are already various implementations worldwide, but they differ significantly in structure and detail.

I would appreciate input from mappers with experience in geomorphology, large-scale natural feature mapping, or previous discussions on similar topics.

Thank you.

2

Mountain ranges (and other not-precisely-defined natural features) should not be mapped as polygons. These polygons would inevitably suggest a precision that isn’t there, and would not be verifiable, therefore leading to potential un-resolvable edit wars (where e.g. the $CITY tourist office claims the city was in $FAMOUS_MOUNTAIN_RANGE when in reality this looks like a far cry).

If they were mapped as polygons (and I am not saying they should), then they should never be multi-thousand-node relations that painstakingly follow rivers or other observable natural features; instead, they should be mapped as a super-coarse area where everybody immediately sees that this outline is not meant to be drawn on a map or used for geocoding. Think “15 nodes for the Alps”.

It is not appropriate to build relations that aim to group peaks, saddles, sub-ranges and whatnot; these are not observable on the ground and are not geographic data. Let’s just add Wikidata identifiers to the various objects and have the relationships curated in Wikidata. OpenStreetMap is a database that is supposed to tell you where a peak is, not the name of the sister of the sherpa of the British mountaineer who claimed the first ascent.

16 Likes
3

I don’t think that that makes sense, for the reasons described above. If something really doesn’t have a defined boundary in real life we shouldn’t invent one for OSM. If it absolutely must be a polygon then maybe something rough like this.

What I’ve experimented with doing with a few places in the UK is to add a sqkm value to a node, as described in this previous OSM diary entry. It’s designed as a way of representing “woolly” features by saying “how big the thing represented by this node is”. See the Cheviot Hills here, which is represented by this node here.

1 Like
4

Mountain range data was discussed few times.

I have feeling it is kind of thing that would make more sense to map in https://www.naturalearthdata.com/ or similar project, not in OpenStreetMap.

3 Likes
5

I noticed recently that Himalaya subranges are mapped as huge multipolygons. I assumed that it was standard and never looked into the docs, ignoring them anyway. Is that an exception or is it somehow widely used? Or look at Bernes Alps: Relation: â€ȘBernese Alps‬ (â€Ș11342347‬) | OpenStreetMap

6

I think mountain ranges could be mapped as kind of site relations where the peaks would be added

7

The docs are here: https://wiki.openstreetmap.org/wiki/Tag:natural%3Dmountain_range

As a user, I find it quite useful if they are areas. I guess that is why they are mapped as such. But I am in general ok with OSM being a bit fuzzy, as the world is fuzzy.

3 Likes
8

Well not really. The very first sentence outside the infobox says “This tag has not been clearly defined” :slight_smile:

2 Likes
9

Like others, I don’t think mountain ranges can, or should, be mapped with polygons. OSM polygons are quite binary. Something either is inside, or outside the polygon (or on the border). In reality humand

Idea: How about a new relation type fuzzy_area, the members are just nodes, with either a role definitely_inside or definitely_outside. definitely_inside means that “basically everyone” agrees that this point is inside that area, definitely_outside = everyone agrees it’s definitely outside. Under this scheme, the boundary is not in OSM. It’s up to data consumers to figure something out. For the Alps, we can add Mount Blanc as a a “definitely inside” and (gods I dunno) Paris as “definitely outside”.

Of course, if you do map mountain ranges using this or another scheme, what do you want to do with this data? Do you have a data consumer in mind to process this data? What do you want to see? What does this data consumer software need to process this data?

2 Likes
10

I’d like to second this suggestion. Wikidata has a mountain range property which can be traversed to build arbitrary groupings of peaks into a mountain range area.

For example, the mountain range property chain for Mount Blanc is:

Modeling all of this in OSM relations would add a huge amount of complexity that is already handled in Wikidata. Additionally, deciding which levels in this list are worth making relations for will be difficult to coalesce on over time.

I would suggest that renderers that wish to display mountain ranges traverse wikidata to build up the collection of peaks that make up each mountain range (and any desired subsections) and then use that Wikidata-derived dataset for building center-lines or areas for labeling.

11

While I agree in general, I would like to address the elephant in the room. Saying “we should best avoid doing X” does little for making a consensus on what should be done if we already did X? Should we let it be since we already have it? Or maybe should it best have simplified geometry? Made into a way? Deleted?

12

Elephant? There is a whole herd of them!

For any possible way that you can think of of mapping mountain ranges, someone, somewhere has done it. I came across several when figuring out how best to show the ones that have been mapped in the UK and Ireland.

2 Likes
13

If our main concern is fuzziness around the edges, then we also have the same problem with other topographical and geological features, such as deserts, basins, valleys, ridges (which normally don’t have abrupt ends), and peninsulas – each of which has been approved for many years. We have a documented consensus not to map some of these feature types as areas or even lines. But one mapper has gone around converting major peninsulas to multipolygons in order to add indefinite=yes to the fuzzy landward side, which I suppose would often apply to the entire perimeter of a mountain range area.

The good news is that these areas don’t represent boundaries for which users would expect precise binary answers. Most renderers would only want to use one of these areas to compute a label at the centroid or along a centerline, similar to the labeling of waterbodies, and typically only at lower zoom levels where people wouldn’t nitpick about the position so much.

To the extent that a renderer would need to shade in the area for pedagogical reasons, why couldn’t it feather out the edges to convey a sense of indefiniteness? Analogously, a geocoder could have a heuristic so that a query for “mountains in Coast Range” returns peaks ranked by their proximity to the center of the range (or distance from the perimeter).

To me, the more compelling concern is that some of these features can be massive and unwieldy. Many of you would have similar qualms about mapping a large sea as an area or a continent as a boundary, even in cases where the extents are more definite.

For valleys, we’ve settled on mapping the bottom of the valley, steering clear of any foothills. This turns the feature into more of a labeling guide than a feature on the ground, but it seems to be holding up practically speaking. It stands to reason that the opposite feature, a ridge or mountain range, would benefit from a similarly abstract geometry. For those who prefer more detail, a natural=valley way often closely follows a river at the bottom. Conversely, a mountain range way could follow a series of natural=ridge ways.

This approach avoids having to make an explicit claim about which mountains belong to the range. Whenever we indicate membership, mappers and users come to expect the member list to be comprehensive, but this isn’t normally straightforward for a mountain range’s “members”.

The main downside of the linear method is that it shuts out geocoding use cases. A geocoder would require a less than reliable proximity-based workaround, similar to how Nominatim guesses relevant parent place nodes in the absence of place areas. This might be difficult without information on the width of the range.

This could also be a sensible approach, as long as it’s understood that Wikidata’s criteria for linking to a mountain range can be nuanced and inconsistent depending on the source. I think there’s a lot of nuance that a renderer developer might not be prepared to handle, compared to a more general statement about the broad linear progression geometry of a mountain range.

Along these lines, another possibility would be to store the generalized geometry as GeoJSON on Wikimedia Commons and link to it via geoshape (P3896). But this solution would give the impression of just trying to avoid OSM, rather than solving any inherent issues in OSM.

4 Likes
14

Ah yes, I get to talk about one of my favorite bits of experimental mapping, Green Mountains. Thanks to the Vermont mappers that helped me figure out which peaks are considered to be part of the range.

I always felt that a mountain range is defined by its peaks, so I put them in a multipoint relation. I am glad to hear folks embracing the wikidata method though, as this would store the information just as well, although it means you wouldn’t be storing it in OSM.

15

If mapping mountain ranges as polygons is to be considered the wrong way to do it (I’m not saying that it should be), then there would be a fair bit of cleanup needed. Some mountainous regions have wall to wall carpeting of natural=mountain_range polygons (overpass turbo)

Screenshot from Overpass turbo showing natural=mountain_range mapped as ways and relations
Screenshot from Overpass turbo showing natural=mountain_range mapped as ways and relations2180×1270 443 KB

I bet all these mountain range ways are annoying when they get in the way of mapping other feature types in the area, but at least they are relatively simple, roughly drawn polygons that can be hidden by a filter. I’d much prefer working around these than dealing with beast multipolygons like Relation: â€ȘHudson Bay‬ (â€Ș9441240‬) | OpenStreetMap. Here strict adherence to the shoreline results in a massive 4300+ member relation that is far more unwieldy than if it were a standalone, roughly drawn polygon.

Screenshot from Overpass turbo showing a beast multipolygon representing Hudson Bay
Screenshot from Overpass turbo showing a beast multipolygon representing Hudson Bay1102×986 82.2 KB

3 Likes
16

Just to note that by area, Hudson Bay is around 6 times larger than the Alps[1], so the 4300 member relation compares favourably with the 840 member relation for the Alps.

  1. respective English Wikipedia articles give areas of 1,230,000 sqkm and 200,000 sqkm ↩

17

I guess they are not all roughly drawn. I looked at the 177 member relation for the Carpathian Mountains which seemed more reasonable. Really to assess the data size of these objects we’d want to be looking at the total number of nodes. Downloading these relations in JOSM I found:

Name Members Nodes
Carpathian Mountains 177 7,895
Alps 847 58,466
Hudson Bay 4,333 303,676

300K nodes really starts to bog down JOSM performance, though I’m sure this is far from the largest object in the database. The Alps and Carpathians cover a similar area size but the Alps multipolygon is more detailed, using around seven times more nodes. Some of the reason for this is that it re-uses various highways, waterways, and a piece of coastline as members. If huge natural features like this are to be in OSM, I think the polygons should be much more roughly drawn with node counts in the hundreds to low thousands. High precision is not needed to represent the general area that a toponym applies to when the edges are fuzzy. I also don’t think these type of relations should use more detailed feature types as relation members (or be glued to them). Better to keep them separate so they don’t interfere with each other and can be safely filtered out of view when editing.

2 Likes
18

Well, in iD you would lose or Landuse Features, no?So not ideal. Of course, JOSM offers great filtering capabilities.

19

Yes, this idea is circulating for some years now, and I agree it seems interesting, although maybe complex for mappers (you have to be aware of the relation when you move something that is in this relation), we could give it a try.

20

Great, let’s start with the Alps relation then.

1 Like