Mhhhhf Fly Henry H Rhmmm On Mon, Sep 24, 2018 at 6:38 AM Joseph Eisenberg <joseph.eisenb...@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.ke...@gmail.com> > wrote: > >> On Sun, Sep 23, 2018 at 9:34 AM Michael Reichert <osm...@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@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
