[Tagging] Topographic Prominence for Peaks

Joseph Eisenberg joseph.eisenberg at gmail.com
Sun Sep 23 21:38:59 UTC 2018

Thanks Kevin
Yes, “prominence” here is a technical term that has only a partially
connection to the subjective “importance” of a peak.

In general, all peaks with high topographic prominence are considered
important by local people (if anyone lives near them) and mountain
climbers, but some peaks with low topographic prominence are also
well-known, eg the Matterhorn.

I see that the old, abandoned proposal also suggests the possibility of
making a relation to show the parent peak and key col. These sort of
relations may not be useful to data users, but they might help other
mappers to verify the prominence data.

Personally, I won’t add new relations when the key col and parent peak are
close by, but I will if they are far away.


On Mon, Sep 24, 2018 at 4:00 AM Kevin Kenny <kevin.b.kenny at gmail.com> wrote:

> On Sun, Sep 23, 2018 at 9:34 AM Michael Reichert <osm-ml at michreichert.de>
> wrote:
> > (1) If you assume the earth to be a plane, just order the peaks by their
> > elevation. It's so simple that I don't give the necessary SQL query
> > here. If we used a prominence=* key, it would have to be the distance to
> > the next higher peak. If the value were not a number but a term like
> > "most_important", "very_important", "neighbour_of_highest" etc. it would
> > not comply with the verifiability requirement of OSM and invite people
> > to have edit wars.
> This misunderstands the concept of topographic prominence.  A peak's
> parent in the prominence hierarchy is not the nearest higher peak. It's
> the higher peak for which the least descent is required from a given peak
> a path that joins them can begin a continuous ascent to the higher peak.
> > (2) If you assume the earth to be an ellipsoid, it is more difficult but
> > still achievable with ele=* tags in OSM and elevation raster data (SRTM
> > etc.) only. There is an open source solution to do so.
> > https://gitlab.com/nuntius35/extremal_peaks/blob/master/README.md
> > (mentioned in WeeklyOSM issue 423)
> That is correct - but SRTM is of insufficent resolution for an accurate
> prominence calculation, and the calculation is extremely expensive for
> an extremely prominent peak, where the key col can be hundreds or
> or thousands of km away. It's worth precomputing and tabulating.
> > (3) If we use a tag like prominence=* for peaks two mappers will have a
> > different opinion on the value to choose. For example, the Matterhorn is
> > 4478 m high but Monte Rosa is 4634 m high and not that far away.
> > However, the Matterhorn is more famous and people expect it to appear on
> > maps at the same or lower zoom scales than Monte Rosa. Whose opinion is
> > correct? From my point of view, the mapper using the elevation only
> > because that is the only verifiable fact while the prominence in
> > advertisement is something we don't record in OSM for a very good
> > reason. (Please replace "peak" by "city" and "height" by "population"
> > and read this paragraph again)
> Topographic prominence is entirely objective; it's a well-defined
> numerical quantity. It is not to be confused with social prominence.
> Sorting peaks by topographic prominence at a low zoom level would
> be an interesting idea, It would surely not fix the 'Matterhorn'
> vs 'Monte Rosa' problem, but it might well help the situation
> where a low-zoom map shows rather insignificant subsidiary
> mountains rather than the prominent peaks of a range.
> About all that I'd have to say about the proposal is that it
> would be useful - and would probably need a new type
> of relation - to tabulate key col location and parent peak
> as well as prominence.  The relation would have three
> members:
> parent_peak - A point object representing the parent peak
> subsidiary_peak - A point object representing the subsidiary peak
> key_col - A point object representing the key col
> and be tagged 'type=topographic_prominence'.
> The prominence of a subsidiary peak can then be
> deduced by subtracting the key col elevation from that
> of the subsidiary peak. (Alternatively, 'prominence=<metres>'
> could be added as a tag on the relation, but that's rather a
> redundant representation.)
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180924/f7dd5ed7/attachment.html>

More information about the Tagging mailing list