Named Collections of Peaks

I don’t think this is a big deal. Nothing uses multilinestring relations. Whatever we do about multipolygons we can do about other compound-geometry relation types too.

Even if you plaster a big red warning about how the relation type isn’t for categories, people use them for categories because their goal is to create a convenient page on or hang a wikidata tag off of it for Kartographer to pick up, and such a generic keyword naturally fits. Besides, we only say relations aren’t “categories” because Wikipedia’s MediaWiki software calls this concept a “category”. In other fields like library science, they’re called “collections”, “facets”, “sets”, or “groups”.

I agree that there are sets of things that people perceive as a single unit for some purposes, like the Great Lakes. But this topic is really about something that’s only superficially similar to those sets. If we want any relation type to be processed in a specific manner – like imputing a fuzzy boundary – then we might as well define a new relation type. Otherwise, why did we bother coining route since collection was adequate for grouping any linear feature?

As a counterpoint, this multilinestring relation represents some bushes arranged to spell “KOREAN WAR MEMORIAL”, part of a prominent decorative feature in a Korean War veterans’ memorial.

The words “KOREAN WAR MEMORIAL” have a total of 17 letters, but this relation has 29 members, because some letters like “K” and “R” require at least two strokes. This relation should be interpreted as either a single message with a MultiLineString geometry (hence type=multilinestring) or as an indistinct, unrelated series of hedges. What I think you’re suggesting is that I should instead turn this into a superrelation of nine subrelations and eight ways representing individual letters. Even if today I might be in the mood to micromap amenity=letters, I don’t see how type=group as a tag would tell a data consumer anything other than “Yes, I really mean it, this is a relation.”

(I did break up the next line word by word, because it doesn’t read as a single phrase. This also allowed me to clarify the abbreviations. In this context, “USA” stands for “United States Army”, not “United States of America”.)

This reminds me of what it would take to derive ZIP code areas from OSM data in the U.S. A user looking up the nearest pharmacy or getting the weather where they’re standing doesn’t necessarily want to enter their specific address but might enter a ZIP code instead. Many street maps label ZIP codes in a similar manner as neighborhood names. For example, the Chicago Metro Area StreetMap (1996) by Universal Map includes ZIP code labels and ZIP code “boundaries” in purple:

Many online maps and geocoders approximate ZIP code areas using the Census Bureau’s ZCTAs, but these geometries are actually based on census blocks, which poorly reflect actual ZIP codes. Since a ZIP code is a collection of unpublished delivery routes that can change at any time, we’re unable to map the delivery area as an area in OSM, but we do tag each individual feature with the ZIP code in its address. A data consumer could use a clustering algorithm or a Voronoi tessellation to derive a more precise approximation of each ZIP code.

I suspect a 2D point cloud relation would be overkill for labeling a mountain range, if that’s all we want to enable in data consumers. But perhaps a point cloud relation would also enable a geocoder to determine that a user location is “in” the Green Mountains with some confidence level. If so, a similar clustering algorithm could allow a data consumer to make sense of such a relation.

If you can be “in” the Green Mountains, then it’s an area. You can probably use the USGS 3D elevation to figure out where the slopes flatten out. Many other mountain ranges are also mapped as an area.

When someone says “a collection of peaks” I tend to think about a ridge instead.

We can also revive the is_in tag for this purpose if we cannot determine the outlines of an area.

Well, ish… The problem is that areas don’t always have well-defined boundaries. The classic investigation of that is here. Various OSM tools (including Nominatim) struggle when things don’t have defined edges - as things in the real world often don’t.

1 Like

Idea: a relation, type=fuzzy_area, members are 1+ nodes with roles definitly_inside or definitely_outside.

You can also draw a shape with an estimated outline, add a fixme tag and call it “good enough a first version.” Alternatively you simply map a node, as is done for many regions with fuzzy boundaries. Example

To be clear, these areas aren’t just fuzzy because mappers haven’t worked it out yet. They’re fuzzy because the real world doesn’t care about the same degree of exactitude when it comes to these large-scale natural features (or neighborhoods very often). Calling it a first pass implies that anyone knows the one right answer or could somehow measure it.

A node doesn’t suffice for something that’s fuzzy but roughly linear. This is similar in a way to the discussion about seas:


You can measure it by asking people “are you inside or outside this area?” In OSM that means you can reshape an area. I don’t think we should limit area mapping to exact boundaries. The map doesn’t have to be perfect. (Excluding administrative boundaries, but that’s not the topic we’re discussing here)

And otherwise I think a node is in many cases good enough.

1 Like

A node is insufficient if you wish to label a large geographical feature with labels that are appropriate to their size and extent. You need some information about its shape. Rought approximations are okay, but a single point node is insufficient:

1 Like

In that case I would use an area as a rough approximation.

Take a look at the scale on the map that @ZeLonewolf posted. This is a relatively small mountain range. It’s part of the Appalachian Mountains, a much longer mountain range that also benefits from linear labeling. We have a hard enough time keeping each of the Great Lakes’ multipolygons from getting broken, let alone something that wouldn’t render as a crisp area in any renderer:


That may be true, but relations that cover large areas are also generally prone to breaking. Relation: ‪Stelling van Amsterdam‬ (‪2980655‬) | OpenStreetMap for example has been broken many times when people remapped forts or decided that objects inside the forts should also be part of the relation.

A mountain area is probably not going to change that fast, but for a more general use case I would hesitate to map this sort of site / multipoint relation.

You could experiment with site relation rendering in Americana.

With my Americana maintainer1 hat on, I would tread carefully with something like that. The moment we’re able to render large geographic features attractively with frequent updates, there will be a rush to add them to the map in whatever scheme we support. As a general philosophy I’d be open to supporting a nascent tagging scheme, but only one where people generally agree it’s a good idea, and it works cartographically on the map.

1Speaking only for myself and not the team.

I was referring to crisply rendering the area as a fill. That would make no sense in a style like Americana and probably would only make sense in a physical map specifically about mountain ranges. Without such rendering, no one will ever know if they’ve broken a multipolygon relation that spans a continent.

If the suggestion is to map a line roughly following the Appalachian Trail in order to place that label, then that would at least be more manageable. But we’ll have to live with the fact that there’s no way to tell whether something is in the Appalachian Mountains using OSM data alone.


A fuzzy area will result in inconsistent answers, depending on who you ask.


I would like to give an idea.
What is the minimum common height of the mountains being talked about in this thread?
An Elevation layer can be used to demarcate the area of a mountain, it’s what I’ve used to get an idea when mapping mountains around me.
natural=ridge can also be used to include natural=peak.
In the following example I built a layer that goes from 2900 mts to 3450 mts, from red (lowest elevation) to blue (highest elevation).

In the following screenshot, the elevation range is 3000mts-4350mts, which allows you to see the valleys better but at the same time shows some small mountains from the upper half. My suggestion is to determine individually what the elevation range of each mountain is and draw an area along the minimum common contour line.

1 Like

FYI, this is a “paradox” in philosophy, the Sorites paradox


A fuzzy area will result in inconsistent answers, depending on who you ask

exactly, that’s part of it. Provided you ask a lot of people you will likely see which area is surely inside and where is the “border” zone and how thick it is.

Reminds me of various surveys asking people to define the “Midwest” region of the United States. For example, this person aggregated many maps and found a general fuzzy boundary, though no one place was in every source found. radicalcartography

1 Like

I think there is another reason to avoid them: they are arcane objects from a detailed field of endeavour. I hope we are not expecting new users to familiarize themselves with the Simple Features spec.

I recently noticed that one of the peaks of Liathach has had this name attached as an alt_name when usually it refers to the entire range (as is true of Beinn Eighe to the immediate north). I think this was one of the ones helpfully tagged with the Cebuano wikipedia article.

Another example for the OP: Zwillinge (Castor & Pollux) on the CH/IT border S of Zermatt.

1 Like

I am unsure exactly which field you refer to here, but I’d say OpenStreetMap could be quite accurately described as a detailed field of endeavour made up of arcane objects :smile:.