[Tagging] Topographic Prominence for Peaks

Joseph Eisenberg joseph.eisenberg at gmail.com
Sun Sep 23 23:17:14 UTC 2018


Mhhhhf
Fly
Henry
H
Rhmmm
On Mon, Sep 24, 2018 at 6:38 AM Joseph Eisenberg <joseph.eisenberg at gmail.com>
wrote:

> 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.
>
> Joseph
>
> 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/035a84f9/attachment.html>


More information about the Tagging mailing list