Proposal talk:Key:prominence

Old Discussion of Previous Proposal (2009)

I'm curious why this is designed as a top level tag, rather than a subtag. That is, why not make this tag as peak:prominence? As a subtag, it would be cleaner if were to later extend this concept to other top level tags, such as building:prominence. --DanHomerick 00:35, 30 September 2009 (UTC)

Only because I am mapper for one month only, and was not aware of any multi-level key policy. I don't think there is any guideline for multi-level key on the wiki? I found more of the "tag as you like" stuff. Anyway, I think peak:prominence is a good idea, and if other don't protest, I will change the proposal to peak:prominence. Then peak:isolation could be used for http://en.wikipedia.org/wiki/Topographic_isolation. --Egil Hjelmeland

As far as I can tell, there isn't a key policy of any sort. But I'm also a fairly new mapper, and haven't been listening to the talk mailing list until recently, so I don't really know. My comment above just reflects my personal preference for hierarchical organization, rather than lumping everything in a top-level namespace. --DanHomerick 07:59, 30 September 2009 (UTC)

If the key prominence could be used for other things, that it is better for it to remain in main namespace than as a subtag. For example Key:ele could be used for marking different things (and not just peaks) so it remains in main namespace. IMO the same is probably true for prominence. Subkeys are kind of kludge anyway (they don't exist really - "key:subkey" is no different that "KeySubkey" or "key_subkey" or whatever). But note that I'm not sure if such a key is needed; do you really have such a rendering problem in real life ? And if you do, is it of such degree that it couldn't be solved with more "aproximate" Key:ele ? --mnalis 21:56, 11 October 2009 (UTC)

Yes. It is not to be assumed that key names with a colon (':') in them, AKA "namespaces", are a good idea. Often it's just adding unnecessarily complexity to tags where they could be kept nice and simple. At the moment there isn't a clear policy/guideline on when they should be used, and when not. For the purposes of new proposals, mostly I'd say they should not be used.

There also isn't clearly established terminology for these things. We talk about "top level" tags or "core" tags. But it's not entirely clear what that means. Then there's the kind of tags which are listed as 'Properties' : Map Features#Properties. These are tags which get used in combination with some other "top level" tag, to provide more... properties of the object. You'll notice there's no requirement for any of these to use ':' namespacing.

-- Harry Wood 09:16, 9 April 2010 (UTC)

Relation: type=peak

I'm mapping prominence like this: I join natural=peak and natural=saddle points with natural=ridge ways. Then I grab the peak point and create a relation with the folowing tags:

• type=peak
• ele=586
• prominence=240
• name=Whatever

And add the following points and ways with the following roles:

• peak --> the peak i'm checking
• key_col --> the key col or key saddle point of that peak // That is, the highest saddle point following the ridges that drop from the peak, if there is a higher peak at the other side; if else, try the next one.
• key_ridge --> the ridge/ridges that join the key_col and the peak.
• parent_peak --> the parent peak of the peak we're checking // That is, the highest point inside the "8 shape" formed by the key_col height contour.
• parent_ridge --> the ridge/ridges that join the key_col and the parent peak.

--Iagocasabiell (talk) 10:23, 22 February 2018 (UTC)

When you make these relations, are you also tagging the original natural=peak node with prominence=240, or just the relation?--Jeisenbe (talk) 04:21, 3 October 2018 (UTC)

I'm not tagging the peak node with prominence, just the relation, and I would like to add some automation if posible.

https://www.openstreetmap.org/relation/8043073#map=19/42.90654/-8.75317

I find the lack of some mechanism of mapping prominence a nightmare. This kind of peak relation solves most of the issues and can compute elevation and prominence with some programing I don't know how to do. The peak relation works by relating the peak with the key ridge and key col, as well as with the parent peak and the ridge that connects the key col to it. The idea is to give hikers a tool to build a hierarchy net on minor peaks. I would also like to make the relation's "ele" and "prominence" to be automatticaly calculated by getting data from the relation members, so no updating is needed. In a small mountain range, this peak relation builds a hierarchy very fast and with very little effort, and this is valuable info for the map, so you may remove clutter peaks (which are important for other things) from sight if needed. The prominence may not be verifiable, but the relation between key col, key ridge and peak is.--Iagocasabiell (talk) 23:59, 7 October 2018 (UTC)

As I've been tagging like this for a while, I think ridges (key_ridge & parent_ridge) are an optional releation role: too much fuss for very little gain. The other roles are fundamental, very easy and fast to map, and give relevant info to the map. Let's say a renderer wants to get rid of the less prominent peaks in a certain zoom level: it only has to render the peaks with at least a prominence of 100 m. The prominence calculation (peak ele - key_col ele) is easy to parse, and way more precise than the terrain mesh. Actually, I think the terrain mesh could be improved a lot by fine tuning it with this peak relation.--Iagocasabiell (talk) 23:01, 28 November 2018 (UTC)

Computable and practically non-verifiable

I think this property is not suited for adding to OSM because it is

• computable based on suitable external data.
• practically non-verifiable except by computing it based on suitable external data.

There are external databases where such information can be looked up if needed (like http://viewfinderpanoramas.org/prominence.html) - it is unrealistic to assume mappers would determine this any other way than either by looking it up in such lists, by guessing or by computing it from external data - all those ways are highly undesirable for OSM.--Imagico (talk) 19:11, 24 September 2018 (UTC)

Re: "Computable." It's true that prominence can be verified by computer if you have a source for the elevation of each peak and saddle, and the route of the ridges connecting each saddle and peak. But while it is possible to calculate this network of ridges, peaks and saddles on a landmass based on external data, it isn't easy, because the data is noisy and computers can't compare the DEM data to aerial imagery or paper topographical maps. It's not reasonable to expect a map renderer to recalculate the entire topographical network of every continent each time peaks are rendered, for example. And a database user that wishes to make a list of "the tallest peaks in Asia" should not have to calculate the topography of the entire continent to know that the South Summit of Everest has a prominence of merely 11 meters, and therefore is not the "second tallest mountain in the world" by any reasonable standard.

Once you have confirmed the location and height of saddles, peaks and the ridges that connect them, the actual calculation is simple arithmetic: prominence = (elevation of peak) - (elevation of key saddle). Saddles, peaks and ridges are approved features and in many cases the data in OSM is already sufficient to calculate the prominence of peaks. I do not have any software for calculating ridge lines, but I have been able to add the prominence and elevation of hundreds of peaks in Indonesia based on open topographical map data, aerial imagery and open data sources (gunungbagging.com - license verified with site owner)

Re: "Practically non-verifiable." As we agree, prominence can be calculated, therefore it is verifiable. But can a mapper verify this "pratically", i.e. via on-the-ground survey with GPS and an altimeter? The prominence of a peak depends on 1) the elevation of the peak and 2) the elevation of the key saddle only. 3) The identity of the key saddle depends on these two numbers, plus the route of the ridges that connect them. Both of these numbers are verifiable on-the-ground, and ridges are also an approved feature which can usually be verified on-the-ground, as the example on this page shows.

It's true that certain peaks are very difficult to climb, and some saddles are difficult to reach (e.g. on an arete, a knife-shaped rocky ridge). But where the prominence data is not easily verifiable on-the-ground, the elevation data for peaks and saddles is equally problematic. Would you say that OSM should not include elevation data for peaks such like K2 and Puncak Jaya, because most mappers cannot reach the peak in person?

In practice, the prominence of 95% of peaks is easily verified by finding the nearest low saddle. Most peaks in the world have a small prominence and are close to the key saddle. Only the highest points of continents and other very prominent continental peaks are difficult to verify. Fortunately, these are the peaks for which prominence has been widely calculated.-- Jeisenbe (talk) 23:18, 24 September 2018 (UTC)

You should re-read what Verifiability means in OSM. It does not mean that you can create a consistent world view so people within this view have the same opinion, it means that different mappers will independently come to the same result.

What you essentially postulate above is a primacy of usefulness to replace the verifiability principle in OSM. Many people have attempted that in the past. It can't work and is IMO extremely short sighted. So again: Prominence is both practically non-verifiable by mappers in most cases (trivial cases where this is possible notwithstanding) and computable based on suitable external data. The difficulty of computing it has no bearing on this - OSM is not Wikipedia and computed information based on external data comes with both legal and verifiability issues. Likewise for the possibility to compute it from information within the OSM database once it has been mapped completely. Computable information does not belong in OpenStreetMap. --Imagico (talk) 08:32, 25 September 2018 (UTC)

The locations of peaks and saddles are verifiable. These features have been approved. Do you disagree with the verifiability of the locations and elevations of peaks and saddles?

The page on Verifiability suggests an example where a "user sets up an experiment and determines that the building is approximately 17m tall. This is a factual observation which can be definitively shown to be true or false, and is therefore verifiable. As such, recording building heights as numerical values is clearly preferable over the more vague 'average' / 'tall' values."

Prominence is a number that is a very simple arithmetic calculation, subtracting the elevation of a key saddle from the elevation of the peak. In what way is this significantly less verifiable than the elevation values themselves, for the vast majority of peaks? Have you found that current sources of prominence data have widely varying values, i.e. more than twice as variable than the range of elevations recorded for peaks?

"Computable information does not belong in OpenStreetMap". I haven't seen this stated as a general rule by other users. Do you believe it is incorrect to tag the width of a river because this can be computed, in theory, based on the shape of the riverbank or water polygons? Is it incorrect to show a river as a way when it also has a riverbank area, because it is possible to compute a linear way from the polygons?

My experience so far with Openstreetmap Carto is that many useful values that might be computable in theory are nearly impossible to implement in practice.-- Jeisenbe (talk) 9:53, 25 September 2018 (UTC)

This is not about what i believe. This is a proposal process and i offer arguments why your suggestion is not a good idea. You are free to disagree but so far you have not presented any arguments convincing me that your proposal is a good idea.

I would invite you to demonstrate how to practically determine the prominence on any number of local high-points here in Germany using the technique you outline. Good examples are:

• https://www.openstreetmap.org/node/26862857
• https://www.openstreetmap.org/node/26862634
• https://www.openstreetmap.org/node/87123736
• https://www.openstreetmap.org/node/1582997340

These are not rare exceptions, this is the norm. If i claim the Feldberg has a prominence of 850m how do you show that this is wrong?

Not storing computable information in the OSM database stems from the very principle of OSM being a project of crowd sourced local knowledge about the world geography. Computable data does not describe the geography, it describes the data it is computed from. Storing such computed information in the OSM database would - apart from the legal and verifiability issues - be a nightmare in terms of data updates. The width of a river can be measured and therefore can be tagged. The width of a riverbank polygon can be computed (fsvo width of a polygon) and should never be tagged. --Imagico (talk) 12:34, 25 September 2018 (UTC)

I looked at the first two examples: https://www.openstreetmap.org/node/26862857 (Feldberg - highest summit of the Black Forest mountain range) and https://www.openstreetmap.org/node/26862634 (Brocken - highest summit of the Harz mountain range). Yes, it is a lot of work to verify the prominence of the high point of a large mountain range or long range of hills with survey in person, because the key saddle is many kilometers away. In this case, the prominence of the highest peak of a mountain range is describing the prominence of the whole range, not just that point. I would recommend verifying these prominences with suitable topographic maps, if available with a correct license in Germany.

Re: "These are not rare exceptions, this is the norm." Incorrect, most peaks are low-prominence and near a higher peak. Zoom out to z14 on both of the examples above. You will see 5 or 6 slightly shorter peaks near Feldberg, and more than 20 peaks near Brocken. I see footpaths connecting most of these summits to the highest peak, with about 1 to 3 kilometer walk. It would be practical to verify the elevations and prominence of each of these peaks in person. So out of 25 peaks, only 2 cannot be verified in person; over 90% are practically verifiable.

I note that both of these peaks are tagged with importance=national. Prominence is a more verifiable way of distinguishing small summits from major peaks. Even if the 100 most prominent peaks in Germany cannot be tagged with prominence due to difficulty verifying this for the highest peaks of mountain ranges, as long as the easily-verifiable smaller peaks are tagged with lower prominence values, the tag will already be useful for map rendering and interpretation of OSM data.

Would you be satisfied if the proposal page (and feature wiki page) has a section about how to check that prominence is verifiable before adding this data for a particular peak?-- Jeisenbe (talk) 1:56, 26 September 2018 (UTC)

No, short of substantial arguments disproving my points no re-wording will make a non-verifiable tag verifiable. I did not criticize your proposal specifically, i criticized the underlying idea of tagging prominence in OSM. What you have brought up so far is the usual defense for tagging non-verifiable information:

• postulating the primacy of usefulness and its priority over verifiability.
• disguising the lack of verifiability by putting trivial cases in the foreground where the correct value at least seems obvious.
• downplaying the use of external, non-verifiable and legally questionable sources.
• pointing to other non-verifiable tags as even less verifiable.

By the way your argument for the vast majority of cases being trivial (which i disagree with - i could easily extend the above list with dozens of peaks in Germany where you'd have serious troubles determining the prominence - including ones in the Harz and Black Forest - where it is completely unrealistic that mappers will practically determine this without external data sources) does not work together with the usefulness argument because usefulness depends on in particular the higher prominence peaks being tagged so if you started tagging and using this the vast majority of values would be copied from external databases and your arguments would just serve to superficially hide this.

My suggestion if you need this data for some application: Add it to Wikipedia/Wikidata in case it is not already there and use this as data source for your application. --Imagico (talk) 09:15, 26 September 2018 (UTC)

Right, the major peaks already have prominence data in Wikidata, so no problem there (I mean, once I figure out how to use that data?). But Wikidata doesn't accept insignificant entries, like unnamed peaks with prominence 100m here in New Guinea. Those are the ones that I'm adding to the database. I'd like to hide small peaks with low prominence.

Re: "use of external, non-verifiable and legally questionable sources." What sources do you mean? I already wrote that mappers should "not copy from Peaklist.org or Peakbagger.com". But I believe it is legally allowable to use SRTM data or open-source topo maps, eg Opencyclemap, Opentopomap, to find the locations of peaks and saddles. Right? That's what I've been doing. This is the same as tracing a ridge or river off of landsat images, no?-- Jeisenbe (talk) 10:43, 26 September 2018 (UTC)

I don't like repeating myself - i have already covered all of this above. You have to distinguish between external sources for prominence data (the vast majority of which themselves have been calculated from elevation data) - these are problematic because of legal issues and because of the lack of verifiability - and calculating prominence from suitable data - which is problematic even when using open data with compatible licenses because such values are computable properties of the data sets in question with all the discussed problems coming with this. For the computability argument it does not matter if you do this computation automatically or if you manually do this (usually based on assuming a certain key col location - which tends to be very unreliable in particular in regions with poorly defined drainage).

Again: Feel free to disagree but i see relatively little chance in you convincing me in this matter because my reasoning is directly based on the very nature of the topographic prominence. --Imagico (talk) 11:57, 26 September 2018 (UTC)

Imagico, you wrote: "My suggestion if you need this data for some application: Add it to Wikipedia/Wikidata in case it is not already there and use this as data source for your application", but if someone intends to use prominence data in conjunction with OSM data, adding the data to wikipedia does not help, as it is incompatible with OSM data, licensewise, so you won't be able to use them together to make a produced work. --Dieterdreist (talk) 11:31, 1 October 2018 (UTC)

How did you get this idea? Commercial map providers like Mapbox have combined data from OSM and Wikidata for a long time and i know no one who sees any specific legal problem in the combination in produced works. Nominatim also uses information from Wikidata (https://github.com/openstreetmap/Nominatim/tree/master/wikidata). Anyway this question has relatively little bearing on the subject at hand - i only suggested using information from Wikidata as a possible solution for the practical needs expressed by Jeisenbe but the more important argument for me is that usefulness or convenience of having certain information in the OSM database does not stand above the need for practical verifiability by the mapper. --Imagico (talk) 11:52, 1 October 2018 (UTC)

I admit I have not been sufficiently precise in my statement. What I meant was that you cannot make a derivative database from OSM which contains data from sources with incompatible licenses, and publish works based on that db. From my understanding (which might be wrong), you could create a collective database of such "incompatible" material, but it wouldn't allow you to use the query results in a combined form (you cannot use the prominence from an external source to decide which peaks to render from OSM data). If this is a misguided reading of the license situation, I would be interested in learning more about it. --Dieterdreist (talk) 13:13, 1 October 2018 (UTC)

I disagree - both Nominatim and Mapbox maps do what you claim is not allowed. But again - this is not really the place to have this discussion. --Imagico (talk) 13:22, 1 October 2018 (UTC)

I have digged deeper and it seems it is indeed legally OK, at least if you leave the wording of ODbL and acknowledge the OSMF community guidelines to have equal value than the ODbL legal text. According to the ODbL v1.0, 4.4, "any Derivative Database that You Publicly Use must be only under the terms of: i. This License; ii. A later version of this License similar in spirit to this License; or iii. A compatible license.", what IMHO excludes the possibility to have wikipedia or wikidata in a derivative database. So the only remaining solution to make it happen would be a collective database. Indeed it seems the OSMF Collective Database Guideline Guideline (strange, but it seems to be the official name of this guideline guideline) has explicitly confirmed (or introduced, according to your interpretation of the ODbL) this by stating: "an OSM dataset used in combination with a non-OSM dataset will be considered a Collective Database, and will not trigger share-alike when:...a non-OSM database replaces or adds a property of a primary feature, and uses either all OSM data or no OSM data for that property of that primary feature within the same regional cut...".
In other words, and this is where the guideline significantly diverges from the original ODbL text, share alike can not only be circumvented by cherry picking "regions" but also by replacing single "properties" of OSM data. I find this troubling also because it is not even clear what a "feature" is in OSM, and what a "property" is (the guideline seems to think about properties as certain tags, but in an open system like OSM, a property could also be a combination of tags, and several tags could be about the same property and "features" could have implicit "properties", it is all a question of interpretation) --Dieterdreist (talk) 13:41, 1 October 2018 (UTC)

I added a new section under Rational which addresses this issue.

No, the concerns i raised have nothing to do with measuring the elevation of individual features, that would be something to discuss for ele=*. My concerns are about the practical verifiability of a peak's prominence, which generally speaking is not a locally measurable property but a function of the peak's location and elevation *and* the whole continental topography. This is not a question of measuring the elevation of individual known points, it is a question of verifiably determining the identity of the key col. This as explained can only be reliably determined by computation from suitable topography data - the existence of relatively simple cases where you can do this computation by hand in the field notwithstanding. Musings about the accuracy of elevation data sources (which by the way are largely incorrect) are a strawman argument in this context.

The whole line of argumentation is also futile because my argument is that prominence is (a) computable using suitable data and (b) only verifiable through computation - so even if you could present evidence that it is not computable that would just remove the only existing method of verification. --Imagico (talk) 17:06, 5 October 2018 (UTC)

Re: "the whole continental topography". This is only true of the highest points of continents. I responded two specific examples in Germany which you suggested, and I've said that in one case 5 out of 6 peaks can be verified by knowing the local topography in a 5x5km area, and in the other case about 24 out of 25 peaks could be verified with knowledge only of the local peaks, saddles and ridges. These are not isolated examples. In the Siskiyou Mountains of California I measured the prominence of about 2 dozen peaks in a 10x10km area yesterday. Since there is higher terrain to the northwest, northeast and south, it isn't necessary to look any further for key saddles. This is the usual situation for peaks in hilly areas all over the world: there's higher land on the other side of the key saddle, and that's all you need to know. It isn't necessary to even keep looking for the nearest higher peak.--Jeisenbe (talk) 00:08, 6 October 2018 (UTC)

Your desire to have such data in the OSM database seems to make you assume a highly biased view on this and only see the seemingly simple cases - seemingly because you only guess the identity of the key col in most cases and you will often not be able to resolve a dispute on this on the ground - hence no verifiability.

Frankly i find your approach to this critique - downplaying this aspect of your proposal, presenting only trivial cases as examples and claiming in the discussion that you have addressed the concerns somewhat insulting. You need to accept the fact that you are proposing to add information to the database that is not independently verifiable other than through computation from suitable data sources. The purpose of the proposal process is to get other perspectives, in particular critical voices, on your tagging ideas. It does not matter if you have successfully dismissed the concerns from some subjective viewpoint. Since my critique is pretty straightforward and there is not really much you can argue about it you are IMO putting too much energy into attempting to reject it while you should put more energy into considering it as what it is - an outside perspective on the matter that looks at this from a viewpoint you have not considered.--Imagico (talk) 09:36, 6 October 2018 (UTC)

I had originally accepted the assertion that prominence can currently be computed from DEMs, but I'm not so sure now.

While the elevation in DEMs is better than nothing, especially here in Indonesia where there are no good paper maps and few peaks have been surveyed with GPS, the situation in North America and Europe is different. I just added prominence values for about 2 dozen peaks near my former home in the Klamath Mountains of northern California. The first surprise was that the elevations and peak locations in OSM (all imported from the GNIS) were inaccurate. Compared to aerial imagery and paper USGS Topo maps, the peaks were off by 10's of meters in location, which could lead to inaccurate calculations. And the elevations were off by about 10 meters (all too low). It turns out that the GNIS database, which was imported for the United States peaks, is based on a DEM (the latest SRTM?). In comparison, the topo maps have accurate spot elevations for almost all the named peaks in the area, and even many small unnammed peaks which I have not bothered to map. Only 4 of the saddles had spot elevations, unfortunately. But I was able to add promince values for all but one of the peaks, with a confidence interval of +/- 5 meters. (One peak's key saddle appears to be in an area that I didn't download.)

I also noticed that the USGS elevations and contours in Hawaii are much more precise than DEM-based contours on Opentopomap. It appears that the DEM for Hawaii is worse than that available on the Continent, but the paper USGS topo maps are still high quality. For example, based on the SRTM data in Opentopomap, it would appear that Pu'u Poliahu has an elevation of 4145m prominence of 70m, but on the USGS map the elevation is 4155m and prominence is 85 meters (+/- 5 meters); the saddle is 5m lower and the peak is 10m higher on the more accurate map. Confirming the saddle elevation with a good GPS/altimeter could improve the precision further.

The new section concludes: "By encouraging mountaineering, hiking and hillwalking enthusiasts to confirm saddle and peak elevations, while adding ridgelines, this new tag will lead to improved database quality, especially in regions such as the United States where current peak data is based on inaccurate imports and saddles are often missing or lack accurate elevations."--Jeisenbe (talk) 14:57, 5 October 2018 (UTC)

Rendering Hint

Recently I mapped a new peak, some locals put a cross there and a register, baptised it and so on. In my view, it's now a peak worth of inclusion in openstreetmap. In order too state, that it should be rendered with low priority, I added its low prominence - some 30 meters, very easy to test with a GPS or a single line in a DGM. Today, I added a register and a cross on two other peaks - one has a wikipedia article, and for sure, it is the main summit, the other is just an outpost, where the cross can be better seen from the valley. So, as far as prominence is no more than a rendering hint, there may be alternatives?