<div dir="ltr"><div>In light of the ongoing "how to tag a mountain range" discussion, I created the following object which maps the Green Mountains in Vermont, USA.  As a flatlander, I had substantial help from a 

local

Vermonter, who understood the topography and which peaks should be included.  It is modeled simply as a relation of all the mountain peaks in the range:<br></div><div><br></div><a href="https://www.openstreetmap.org/relation/12102399">https://www.openstreetmap.org/relation/12102399</a><div><br></div><div>I offer this as a proof of concept of one possible way to map a mountain range, hopefully to help further the discussion.  I am not necessarily advocating for this scheme or the specific tagging that I have on that object (and I'm not planning to write a proposal around it), but I thought it would be useful to demonstrate a concrete example that we could all look at.</div><div><br></div><div>The relation contains a bit over 200 peak nodes, which is a completely manageable size.</div><div><br></div><div>Advantages of this approach:</div><div>1. Point cloud still yields the approximate location of the range as a whole</div><div>2. There is sufficient data to algorithmically determine the location and size of a label</div><div>3. Does not introduce polygons into any editor</div><div>4. Eliminates disputes over where the boundary of the "range" lies</div><div>5. Whether or not a peak is in a mountain range is reasonably verifiable (based on local knowledge, mountaineering club definitions, etc.)</div><div><br></div><div>Disadvantages:</div><div>1. Still need to make decisions about whether peaks are in the range based on geography.</div><div>2. Need to decide whether all peak objects are included or only the most prominent ones.</div><div>3. No definitive way to determine whether a point is "inside" the mountain range geography (though one might imagine an algorithm based on the point cloud)</div><div>4. More work to map than a rough, fuzzy polygon</div><div><br></div></div>