Sometimes a group of peaks is given a name. For example, in Colorado, the “Maroon Bells”, which consists of two peaks “North Maroon Peak” and “Maroon Peak”.[0] Currently “Maroon Bells” is mapped in OSM as node tagged with natural=peak[1], but in reality there is no such peak, and in fact the node has been placed in the saddle between the two peaks mentioned above. It is very misleading to say that there is a peak at that location. I see someone has made a mountain_range relation[2], but the note=* tag on the feature says it is experimental, and in any event, I don’t think the Maroon Bells are a “Mountain Range”, at least not in the common understanding of the word.
How should such named collections of peaks be mapped?
For the original mountain range discussion that prompted me to create the mountain range relation (which I did with a bunch of local help from @Adam_Franco), see the discussions we had on the tagging mailing list in December 2020.
I think the short answer is that there is no generally accepted practice for named collections of peaks and plenty of competing ideas.
Thanks @ZeLonewolf I see that now that I have looked at the history.
Interesting discussion, but I still think the “Maroon Bells” are not a “mountain range”, it is explicitly a collection of two peaks.
Geojson, and other formats, have a datatype called “multipoint.” OSM has a relation type called multipolygon. If the question involved two lakes that shared a name, e.g. “ABC Lakes”, I would draw two closed ways, add them to a multipolygon relation, and tag that relation name=ABC Lakes. If OSM had a multipoint relation type it could be used in a similar manner to handle this “peaks” situation.
So you are suggesting that the two peaks be put into a relation and the relation tagged type=site (I assume that you are not suggesting that an area be drawn around the two peaks)? That could work. Any other tags on the relation besides type=site and name=Maroon Bells?
multipoint would be a fine complement to multipolygon and multilinestring. site is sometimes suitable for collections of points, but in Simple Features terminology, it represents a geometry collection rather than a multipoint. It’s also kind of amusing to think of something as large as a mountain range as a “site” in any English sense of the word.
The two peaks that make up the Maroon Bells are only about 0.3 miles apart, there are probably some industrial sites that are probably larger than that, although I don’t know if in OSM they are tagged as “sites”
Yes, I was thinking that being able to add other types of geometry would be helpful, although I can’t think of an example where that would be appropriate here.
There is no obvious way to determine where the Green Mountains begin or end. However, it is possible to determine which peaks are considered in the range.
If it were only for the Green Mountains! It though happens that a mountain has several summits: The undocumented region:type=mountain_area here (around the Alps) is used by some, there is even a renderer that shows it and goes to great lengths to do so decently.
On Topic: There exists indeed literature that gives the borders of single mountains or ranges in terms of streams/rivers/flatlands/&c. Such mappings can end up in monstrous multipolygons. the Alps themselves a prime example, although being a mountain_range instead. IMO, it is all unwarranted exactitude.
Smaller than a mountain_range would be natural=massif or natural=mountain.
Both do not solve the problem of fuzzy borders. Personally I don’t have a problem with mapping something fuzzy if it is as best as you can. I guess no renderer will ever plot the outline of a mountain (range). This info will be used for labeling and geocoding which both can be done perfectly with fuzzy lines.
The Green Mountains are a real mountain range, not just a region in terms of human geography. That said, it is influenced by cultural factors: geophysically, the range continues into Massachusetts and Connecticut, but under different local names.
If we think of the range as a collection, then this kind of nuance is easy to model in Wikidata with its mountain range (P4552) property that can be applied recursively or multiple times. If you look at how the property is used, it’s also being applied to mountain passes, valleys, ski resorts, and towns; Wikidata’s validator only requires that the item be a place of some sort. This broader notion of what’s in a range can help to define the fuzzy boundaries even better than an OSM modeling that, for practical reasons, would be limited to just peaks.
This is how natural=valley has developed: for a linear-ish valley, you draw a way along a stream that runs along the valley floor. But you don’t have to make it follow every meander to a tee, because ultimately the way (simplified) is only used as a label spline. For a bowl-shaped valley, you draw the edges of the valley. But it doesn’t even really matter how tightly you hew to the foothills, or even whether you exclude an intruding peak, because ultimately the area (simplified) is only used to place a label at the centroid.
I don’t know how well this approach translates to mountain ranges if apparently the renderer mentioned earlier is trying to do more than place a label.
PS: Zoom out, starting at level 5 the Alps are labelled. I think 55.565 nodes are too much to place a label. I also do not see use of telling by the Meter, if something is inside or outside of the Alps region. Not even the best Geographers can, but with OSM it seems possible.
There’s also a collection relation type that sounds similarly generic, but I have little insight into how it’s actually being used. My only encounters with it so far have been relations that a Wikipedian created so that Kartographer could conveniently mark a category of something on a map on a Wikipedia article. Like your group proposal, collection relations are supposed to share a common name, but in practice this name just describes the category’s inclusion criteria.
I think there needs to be a clear distinction between grouping elements that share a common identity and grouping features that share a common identity. For a group of elements, multipolygon, multilinestring, and multipoint suffice because a user doesn’t need to drill down into the members; a renderer can collect the members into a single geometry with the relation’s tags and ignore anything else about the members. But for a group of features, each member still needs to be discoverable by its own identity. This is the case with the peaks in a mountain range, or the lakes in the Great Lakes or Finger Lakes, or perhaps the buildings that make up a multi-building complex that doesn’t lend its name to the surrounding land. Without this distinction, any relation type is bound to be misused for categories.
It’s worth reiterating that, in some sense, a mountain range is more than just a collection of peaks, just as an office park is more than just a collection of office buildings. The things that connect them are just as integral to the overall feature. Unlike the Great Lakes site relation, the proposed simplification of a mountain range as a collection of peaks is only intended as a solution to the problem of fuzzy boundaries, not as a statement about the sparseness or porousness of a mountain range. It would be as if we mapped the Mojave Desert as a collection of cacti or the Sargasso Sea as a collection of underwater shrubbery. Perhaps multipoint, group, collection, and site are all inadequate for this purpose because they don’t communicate the intention well. What we really need is a relation type that explicitly represents a 2D point cloud.
Implementing a geometry primitive like MultiPolygon in a metadata object like a relation was a mistake when we first did it and one we’re still working out how to undo. Let’s not double down on it.
Without this distinction, any relation type is bound to be misused for categories.
well, relations are not categories, we have a rule for this. You most likely will add a name to the group, that’s usually the reason you want to have it, the group is made because there “is” a group perceived by the locals (they have a name for the group).
It could be lakes, islands, trees, peaks, that’s the kind of things the group relation aims at.
A different kind of example is the hollywood sign, it is made of different letters, in OpenStreetMap distinct geometries (each of the letters can also be described individually, e.g. which letter it is, or how high), together they form a word, and it becomes a whole new quality (and probably gets different main level tags in osm). Not sure this should be a group, although it follows the same kind of thing requirement. Currently it’s a site
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 osm.org 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.
