Irish Mountains


did you notice that on the OSM map the elevations of Irish mountains
do not match the usual “above mean sea level” (MSL) values?
In Wikipedia you will find the MSL values for elevation.
But on the OSM map there are “WGS84 elliptical heigths” values
on the mountain peaks, which differ a lot from MSL.

In the “development” forum I asked about how we should
interpret the definition of the “ele” Tag in the Wiki.
I think many mappers don’t know about the difference
between the WGS84 geoidal and ellipsoidal heights.

At the moment, Irish mountain peaks are mapped in a different
coordinate system as in other countries.
I hope we could harmonize “ele” for the OSM globally.

Just came across the same issue today. The heights rendered in OpenStreetmap are 50m / 160 ft different from the generally know Irish Sea Level based heights. I have been unable to find an explanation online for doing it this way and I can’t think of an advantage over with making the default ele tag based on sea level as the OSM Wiki says it should be.

Can anyone help?

It’s not quite as simple.

You also need to look at the history of the wiki page. Originally, elevation was given in the usual above sea level. Then at some time, a single person with no documentation of a discussion or decision changed it to WGS84 and the change went unnoticed for years. He was probably thinking it was for the good, but IMHO it was a very stupid thing to do. Almost nobody checks the wiki before adding something as common and intuitive as an elevation. So now you have a total mess of mixed values in the data. Your guess on how many people simply put in above sea level and how many looked it up in the Wiki and pulled out the calculator is as good as mine. :slight_smile:

But if I remember correctly, the difference between the systems should be much smaller than 50m. Also because of the mess in the wiki, this would be rather random and not a systematical error for all elevations. So I would assume the reason for your discrepancy is somewhere else. I would rather suspect a systematic programming error - were those elevation values maybe imported?

bye, Nop

Thanks Nop

However I did look at the history and unless I am reading it incorrectly this data arrived this way in the original import 9 years ago from iemv_import - ie. the big original bulk summit data import from source

Edited over 9 years ago by iemv_import
Version #1 · Changeset #797943
Location: 54.9853066, -7.0807528

ele 449.2
ele:local 396 (OSNI 1:50,000 confirms as 396)

BTW this in the summit of Loughermore Mountain.

Am I missing something?



So it was an import which explains the uniform discrepancy, and it was also pretty well done, giving the correct value in ele:local. The ele value is also repeated in ele:wgs84, so there is your explanation: An import done properly but according to an unrealistic and impractical statement in the wiki.

However renderers usually show ele values as they are given that most of the ele values are truly given in meters above sea level regardless of what the wiki says. This is visible on the main mapnik map. Also, in my map I display ele values for cities as they are and I never got any feedback or complaint about wrong elevations in the 10 years it is online.

So the only thing map renderers can improve with the current mess is use an ele:local value if it is present and assume ele is given in meters above sea level otherwise.

The reasonable thing in my eyes would be to try to reduce the mess in the data by changing the wiki back to local above sea level as default in ele and other coordinate systems in special tags. Then automatically change all documented wgs84 values like in the irish import back to local values in the data. Then all maps would show the values expected by their users and the only remaining problem would be a few undocumented wgs84 values to clean up.

bye, Nop

I don’t think this is right - the OSM wiki specifies using the EGM96 geoid model as reference - not the simple GPS WGS84 ellipsoid. The data set uploaded uses the WGS84 which being based on a one simple ellipsoid representing the surface of the whole earth will be prone to massive error (or variation) in relation to national mean sea levels and EGM96 (which is a complex bumpy approximation to real surface shape). I think EGM96 height Datum and Irish Mean Sea Level should be within a couple of metres so - are pretty interchangeable for practical hill height.

I would like to contact the original uploader - the user had the following contact details:

Queries to IrlJidel or mackerski or email talk-ie mailing list,

irc:// #osm-ie : Irish OSM channel

Any idea how I could do this?

I have fixed this for the main spot heights outside of Munster (i.e. anything in the Wikipedia top 100 mountains, which is anything above ~ 650m)

I have only fixed the “ele” tag (by copying the value from the ele:local tag). I am not sure if or when the text labels in various layers (including opentopomap) will update.

There are still around 30 in Munster left to check, in the ranges:
Brandon Group
Caha Mountains
Central Dingle
Dunkerron Mountains
Glenbeigh Horseshoe
Iveragh Peninsula
Mangerton Mountains
Purple Mountain
Slieve Mish

Perhaps somebody else might check those.


Recently I have been reviewing the spot heights of Irish peaks as registered in OSM. As per the previous replies, over time there seems to have been a mixture of EGM96 and WGS84 values entered. This has been causing considerable confusion of late.

As a member of the review team, I would very much like to correct this anomaly in as accurate and simple a manner as possible! Over the recent past MountainViews has surveyed many of the peak heights to a 0.1m accuracy and has documented all the correct values. Many mountain names have also been corrected in both English and Irish.

At we can produce an updated dataset of these correct values in a variety of formats. Is there anyone “here” that has the authority and/or ability to utilise such a dataset to update the OSM data on Irish mountains?

Your thoughts as to the most correct and efficient method of correcting the OSM data would be appreciated.

Hi @craghead !

Donal from the OpenStreetMap Ireland community here.

First up, we would love to incorporate the data from MountainViews in OpenStreetMap. I’ve been a member of both communities for years and the possibility of collaboration has occurred to me a few times.

The best approach for this is:

  1. Confirm that the license on the MountainViews dataset is compatible with OpenStreetMap. The OSM community (and the OSM Foundation that oversee the governance of the dataset) want to ensure the data can be used freely and openly and that requires due diligence with any contributed data. The Licence Working Group have documented their work here and there is a community-maintained matrix here.

  2. If the data license is compatible, the update needs to align with the [Automated Edits code of conduct](Automated Edits code of conduct). OpenStreetMap has a fairly good process for managing imports to ensure potential missteps are avoided.

  3. Create project to manage the import process. Identify how data will be imported and how updates to existing data will be handled.

  4. Engage the community to get buy-in and agreement to proceed with the import.

  5. Execute the import with a graduated plan (canary, gradual expansion, completion to 100%).

I’m happy to support this effort and help grease the wheels with a view of seeing this happen. I can be reached at donal.hunt --AT-- openstreetmap --DOT-- ie (username dónal in OSM circles).

Talk soon!

Hi @Donal,

Many thanks for your welcome response. Make my day and tell me that you are also a Cork man!

Delighted that the OSM Ireland community is up to the challenge. I will get on to the rest of the team at and discuss your highlighted points right away. We will get back to you as soon as possible once all of your points have been properly addressed.

Looking forward to getting this long running anomaly sorted at last.


I’ve just been looking peaks in the British Isles and identified this problem as well. I’ve created a plot using Python, that compares SRTM data and the Database of British and Irish Hills with the OSM elevation data. It appears ~12 years ago the xybot used the wgs84 rather than local elevation for the “ele” tag, whereas local/EGM96 elevations are now prefered according to the latest tagging recommendations.

The Database of British and Irish Hills is released under a Creative Commons Attribution 4.0 International Licence, so I’d expect as long as a reference is made to the data then it would be good to use.


Hi Donal and Craghead

I’m the guy who did a manual update of the big hills in Ireland elevation data last year, I think I got most of them, at least the ones I’ve been up!

Interestingly somebody else was looking at a similar issue across the UK and Ireland. Details here :

The relevant points, which you may find helpful:

There are 4 datasets which substantially overlap,

  • OSM terrain model (SRTM)
  • OSM peaks data
  • Mountainviews
  • “Database of British and Irish Hills”

The linked post has a Python script to find and visually display discrepancies between the three non-mountainviews datasets.

I suspect that the terrain model is the most reliable of these and anything more than 25m vertical distance between terrain model and peak data indicates a potential issue.

I appreciate the work you’re putting into doing this “properly” as opposed to my blitz to pass the time during lockdown!

Yes, thanks for noticing, and indeed they are not correctly indicated, they also wrote about this here. I think the developers will change the values of the altitude above the sea to the correct ones.

Sorry for the radio silence on this thread. Wasn’t notified about the latest messages. ?

I would like to nominate this for discussion at the OSM Ireland CLG AGM next week. See

Would someone be willing to speak very quickly on the matter and the proposed course of action? It may attract interest from the community or at the very least consensus that the plan is sensible and should be executed. ?

My main concern is to ensure the authoritative data sources used have a compatible license so we don’t have to revert data in the future. Very much supportive of having OpenStreetMap building collaboration with communities like MountainViews as a demonstration of how open data can be used effectively across projects.