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:
2 Likes
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:
2 Likes
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.
3 Likes
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.
2 Likes
A fuzzy area will result in inconsistent answers, depending on who you ask.
4 Likes
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
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 
.
Given that “… there is no generally accepted practice for named collections of peaks and plenty of competing ideas…”, in my humble opinion at least the two peaks should be plotted as independent “entities” an tagged natural=peak. Each independent point with its name and elevation.
Thanks for bringing this back on topic. I agree about not overthinking it when it comes to a simple group of a couple peaks. Even a system of two reservoirs will often have similar names distinguished only by a number; the first step is certainly to map them as individual reservoirs before considering any fancier grouping.
1 Like
Perhaps my original post was confusing. In reality there are two peaks, Maroon Peak, and North Maroon Peak. Collectively they are called the “Maroon Bells”. In OSM, both are mapped and named with the above names. In OSM a third “peak” is mapped with name=Maroon Bells. There is no such “peak”, and mapping it as such is extremely misleading and deleting it is a bad idea as that name (Maroon Bells) is in common usage and a map without would be incomplete.
I think the priority should be on mapping the individual features - mapping them as a group would be of secondary importance. If it were me (and it has been, on topics like reservoirs and a few other peak combos in CO, though none as well known as the Maroon Bells), I would do this:
- Map each peak separately with its own set of
natural=peaktags. - In the case of the “Maroon Bells” name being as or more prominent than the individual peaks, I’d be inclined to use
alt_name=Maroon Bellson both peaks for a little searching backward compatibility. I don’t usually do this in cases where reservoirs have names like “Valley Reservoir 1”, “Valley Reservoir 2”, etc., and the group is just “Valley Reservoirs”. - If there is a GNIS id for the grouped feature, leave that
gnis_idon both peaks. That will show up as a duplicate in @watmildon 's GNIS validators, but it is still better than losing the ID entirely. - Then, if desired, try out one of the relation or region options discussed -
relation=siteisn’t a bad option for grouping the two together. A small “range” with a rough polygon isn’t terrible either. But whatever you did here would be supplementary to just tagging each one correctly and individually.