Highest peaks in OpenStreetMap

General talk
1

In another thread @sbre had this idea:

I have made one here, for each country:

List of highest peaks in OpenStreetMap (as of 1 January 2024)

The advantage of a list is that you can look at it side by side with another list (e.g. on Wikipedia). When they differ, one of them might be wrong.

9 Likes
2

Nice! Already found a couple of suspicious ones.
Would be nice with a “world” list too.

3

Haven’t checked for wrong elevations yet, but so far found for my country unnamed peaks or ones with the elevation in the name. Thank you for the list :grin:

4

You might want to update the US ranking :joy:

5

I wonder why Schneefernerkopf doesn’t appear in the list? The tagging looks correct to me. Could it be because it is on the country border and not assigned to either country?

6

Nice. Are you going to update it regulary?

7

Could also be on the Austria list, just not in the top 100.

1 Like
8

But how do you know what the right answer is?

9

Alternatively they can be given in feet (e.g. ele=450 ft, ele=450feet)

It would also be worth capturing elevations in feet if they are listed with a typewriter apostrophe character after the feet value (e.g., ele=450’) as this is the documented way of expressing height, width etc in feet.

(See RFC: Documenting feet as an an optional elevation unit)

2 Likes
10

Just some observations.

image
image1289Ă—549 84.6 KB

  1. Elbrus, the highest mountain in Russia and Europe is missing. It is present in OSM however.
  2. 'None’s should rather be just blank.
  3. Links to wikipedia/wikidata from the corresponding osm-tags could be beneficial.

For validation, you can compare ele values from osm with wikidata. :slight_smile: Also, high peaks without wikipedia/wikidata tags are most probably mistakes.

11

I have updated the list with data from 22 January. That’s before I made this post, so any changes since then will not yet be reflected in the data.

I am working off the weekly planet files, so unfortunately there is some delay. I will try to update the list semi-regularly, as long as there is demand.

Thanks all for your comments. The new version of the list

  • accepts an apostrophe as the unit for feet
  • correctly handles mountains on the border (such as Schneefernerkopf) as part of both countries
  • includes natural=volcano in addition to natural=peak, this is why Elbrus was missing
  • prints (none) instead of None. I prefer this to a blank cell because you can use Ctrl+F to search and highlight missing values
  • includes Wikipedia and Wikidata links

I’ve noticed Mount Everest appears in the list for Nepal but not for China. This is because the peak node is actually in Nepal, 1cm or so from the border. A mistake?

Assuming that the contour lines in our topographic maps are correct, it’s possible to spot some obvious mistakes: some are off by a factor of 10, others have the elevation in feet instead of metres and no unit.

Of course, the usual caveats apply, we can only use sources with a compatible licence, etc. Also, often other lists of the highest mountains ignore subsidiary peaks which will show up on this list.

The list may also be useful to spot mountains that are missing a name tag, or have a name tag in a language unusual for the country (e.g. when name has the English name, not the local one). And now it can be used to spot important peaks that are missing wikidata and wikipedia tags too!

4 Likes
12

This sounds like job for Sophox. The following query will output a list of peaks in Germany where OSM and Wikidata have a different elevation:

Query 
SELECT DISTINCT ?peak ?peakLabel ?osmElevation ?wikidataElevation
WHERE {
  ?peak osmt:wikidata ?wikidataId.
  ?peak osmt:ele ?osmElevation.
  ?peak osmt:name ?peakLabel.
  ?peak osmt:natural "peak".
  SERVICE <https://query.wikidata.org/sparql> {
    ?wikidataId wdt:P17 wd:Q183.
    ?wikidataId wdt:P2044 ?wikidataElevation.
  }
  FILTER (
    xsd:float(?osmElevation) != xsd:float(?wikidataElevation) &&
    ABS(xsd:float(?osmElevation) - xsd:float(?wikidataElevation)) / xsd:float(?wikidataElevation) > 0.01  &&
    ABS(xsd:float(?osmElevation) - xsd:float(?wikidataElevation)) > 5
  )
}
ORDER BY DESC(ABS(xsd:float(?osmElevation) - xsd:float(?wikidataElevation)))

It only outputs peaks where the difference is over 5 metres, and over 1%.

Q183 is Germany and can be replaced by the Wikidata ID of a different country. It doesn’t do any unit conversions so won’t work if the elevation in OSM is in metres and the one in Wikidata is in feet (seems to be quite common).

I made this with ChatGPT and I was rather surprised how well it worked. It’s probably possible to get it to do the unit conversions too.

I’ve looked at a few peaks in Germany and didn’t see any where OSM obviously had the wrong elevation. Either Wikidata was obviously wrong or OSM had the wrong Wikidata tag because two mountains have the same name.

1 Like
13

That there may be an issue with the mapping of a 30001m / 98430’ tall mountain? :thinking: :grinning:

14

This example SPARQL query converts between currency values in Wikidata. Currencies are modeled as units, so the same approach can convert whatever unit of measurement is specified for an elevation.

2 Likes
15

Hello

It’s indeed a good process.
However we’d better using common QA tools to achieve such comparison and take advantage of using (and continuously improving) the same process on many topics.

Life is way too short to bring this manually instead of automatize and querying wikidata once and for all.

16

I have updated the list of highest peaks with data from 29 January.

There have been quite a few changes. The following countries have had the most:

Country No. of changes
Papua New Guinea 11
United States 10
Vietnam 10
Bhutan 4
Chile 4
Uganda 4
Argentina 3
Eritrea 2
Moldova 3
Turkey 2

Edit: corrected list after finding a bug in my code

2 Likes
17

List updated with data from 5 February. There have been a few changes, so I’ll keep updating as long as there is activity.

I also fixed a bug where if two peaks had the same elevation, only one would be shown.

Country No. of changes
Bhutan 4
Libya 1
Madagascar 1
Montenegro 1

We can integrate this into QA tools, if we spot systematic issues, in the meantime it takes me maybe one minute to update the list every week, if you don’t count the time it takes to download the data and run the calculations, so I don’t mind doing it if people find it helpful.

From manually reviewing the data we can then spot the sort of systematic issues that could be integrated into QA tools. So far we know of cases of

  • OSM having blatantly wrong elevation e.g. in some cases off by a factor of 10 or in feet instead of metres (with no unit given)
  • OSM having slightly wrong elevation e.g. off by a metre or two
  • OSM having the wrong Wikidata tag
  • Wikidata having the wrong elevation
  • peaks missing names in the local language
  • peaks missing Wikidata

Some of these are more suited for automated QA than others. For peaks (or other items) missing Wikidata, https://map.osm.wikidata.link already exists and it works really well.

2 Likes
18

List updated with data from 12 February. I raise my hat to the mappers from / in Uruguay, where 50 new peaks have been added to OpenStreetMap!

Country No. of changes
Uruguay 50
Kazakhstan 20
Vietnam 19
Canada 17
Cyprus 11
Yemen 8
Bhutan 4
Ukraine 2
United Arab Emirates 2
5 Likes
19

List updated with data from 19 February, this weeks Yemen takes the crown :smiley:

Country No. of changes
Yemen 66
Egypt 16
United Arab Emirates 9
Vietnam 8
Uruguay 3
Albania 2
Cyprus 2
Czechia 2
Tunisia 2
4 Likes
20

List updated with data from 26 February. Again many changes in Yemen.

Country No. of changes
Yemen 22
Dominican Republic 7
Vietnam 5
Bhutan 4
France 3
Malaysia 3
United Arab Emirates 3
2 Likes