OpenStreetMap

Tool for measuring elevation above sea level on the OSM map

Posted by Alex-7 on 27 November 2017 in English (English)

I created a tool to calculate an elevation at the point of a click on the OSM map: http://ausleuchtung.ch/elevation/

The elevation is calculated as an average from the values of the ele=* keys found around the click in the radius of 1 (or 2, or 3) kilometers.

I decided to write this simple application after I read an excellent article GPS Altitude vs Pressure Altitude.

For some areas of the world there is a lot of elevation data in the OSM database, and for some there is practically none. I think it is due to the misunderstanding about the difference between GPS Altitude and Pressure Altitude. The article makes it clear that both approaches are not perfect, but these are all what we've got, and we are to use one or another.

The application seems to be simple because all the heavy lifting is done by the Overpass API, OSM, and the Leaflet.

Elevation data could be useful for many purposes. For example, for planning a hiking or a cycling route, for planning a RPAS flight, for water management, etc. For example, if a hiking route starts at the altitude of 400 meters, and ends at 1600 meters, then it is immediately clear that it would be a hard day.

I also plan from now on to measure and add more ele=* data to the OSM.

Feedback and suggestions are very welcome.

Comment from Piskvor on 27 November 2017 at 19:49

Hello, that's an interesting idea - getting an estimate from a few surrounding points. It sounds somewhat simpler than using external data, but what is the expected use? Most things tagged with ele are mountaintops and suchlike - generally things where the point elevation is significantly different from the surroundings.

In the case of elevation, I think that almost-contiguous coverage (most notably SRTM: http://wiki.openstreetmap.org/wiki/SRTM ) is where it becomes useful - e.g. a trip between 800 m ASL and 700 m ASL sounds unproblematic, unless there's a 1500 m ASL pass inbetween.

As for adding ele=*, check that your readings match those obtained by the traditional surveying methods - both barometric and GPS's simplified geoid elevations tend to err in tens of meters from the official survey marks around here (but SRTM generally matches to a few m, except for some of its digital artifacts). It might be useful to also add the elevation where officially surveyed, and especially to mark the source of the elevation data.

Hide this comment

Comment from Piskvor on 27 November 2017 at 19:52

(It may not be obvious from the above, but GPS and barometric altitude are not all we've got: there are the geosurveys done by traditional methods, and there's Shuttle Radar Topography Mission data, which is used by many OSM renderers for hillshading)

Hide this comment

Comment from TomH on 27 November 2017 at 20:22

As a general rule we don't encourage the addition of elevation data beyond things like specific peaks because that is much better served using a separate elevation model such as the SRTM data that Piskvor has mentioned.

Hide this comment

Comment from Alex-7 on 27 November 2017 at 20:35

I agree that there are other ways to obtain elevation data. However in some places, for example Zurich or Geneva, even public transport stops have got the ele=* tag.

It is kind of DIY approach. Besides, the number of GPS satellites is increasing, the GPS receivers also become better. I think if not now, then in the near future the GPS altimeters could become precise enough.

Hide this comment

Comment from TomH on 27 November 2017 at 20:37

Adding ele tags to existing objects (if accurate, which GPS elevations rarely are) is certainly not terrible but equally probably isn't that valuable.

Trying to create an elevation model by adding a grid of nodes just to carry ele tags would be pretty terrible.

Hide this comment

Comment from Alex-7 on 27 November 2017 at 20:55

I agree that it is not the best way to build a comprehensive elevation model.

However, with this tool I discovered already that there is the ele=* tag for the lake Lac Tanay, but not for the nearby lake Lac de Lovenex: http://ausleuchtung.ch/elevation/?lat=46.34906049944002&lon=6.8135404586792&zm=15&rd=3

There is the elevation data in its Wikipedia article: https://fr.wikipedia.org/wiki/Lac_de_Lovenex and at its Wikidata item. But not in the OSM.

Next time when I go to this lake, I will go to the open space near the lake and measure the elevation with the GPS altimeter and add the ele=* t the OSM.

It makes sense to stay away from high walls which can reflect the GPS signal and cause interference by this.

Hide this comment

Comment from Warin61 on 27 November 2017 at 20:57

@ TomH 'We" ? From your first comment. Sounds like some royal 'we', as in it carries the weight of a command. All ideas are worth consideration, not to be dismissed out of hand?


The idea of having a grid of nodes each having a known ele is valid, but would need lots more data points in order to replicate the SRTM data. That is a very large work load to obtain that data, and it will not be obtained in some areas of the world as they have few local mappers - e.g Papua New Guinea. I don't see it being usefull around the world.

.

Hide this comment

Comment from Alex-7 on 27 November 2017 at 21:40

Some places in this area in the city of Odessa is about 1 meter below sea level, and this part of the city is prone to floods. I cannot see it even on the cycle map layer: http://www.openstreetmap.org/#map=14/46.5213/30.6799&layers=C

Next time, when I visit this city I may add some ele=* tags to prominent objects and it will be well visible with a single click. I know little about Papua New Guinea, I did not visit it yet, but in Odessa the floods cause terrible problems in this district, and such data could be helpful for understanding the issue.

The question is if my GPS altimeter will measure the elevations precisely enough, but if we do not use the altimeters the producers will not have an incentive to improve them. Besides, I can measure the elevation near the sea at the beach to calibrate the altimeter, and then cycle to the area for the actual measurements.

Hide this comment

Comment from Alex-7 on 28 November 2017 at 06:37

This work was already done in New Orleans, Louisiana: http://ausleuchtung.ch/elevation/?lat=30.01366576284663&lon=-90.21921157836915&zm=14&rd=2

and in New York City: http://ausleuchtung.ch/elevation/?lat=40.58723347936198&lon=-73.66487503051759&zm=13&rd=1

It is immediately visible that these areas are in the flooding risk zones. And I cannot see it neither on the OSM map, not on Google map. At the same time floodings cause billions in danages.

Hide this comment

Comment from The Maarssen Mapper on 28 November 2017 at 07:33

How do we denote the datum used in an ele=* tag? There are thousands of different versions, depending on where you are. Some transformations are also dynamic, i.e. they may change over time. The wiki page for ele=* says to use Mean Sea Level on the the EGRM96 geoid, but I doubt many "normal" people will be aware of what that entails and how that relates to any local reference datum. If the elevations are not associated correctly with a datum, errors will occur... There is a difference of over 2 metres between the local datums of Belgium and the Netherlands for example.

For global maritime use MSL is often used, whereas on land the local datum is often more prevalent. In ports etc. LAT (Lowest Astronomical Tide) is also used.

Vertical datums are just as big an issue as the 2D coordinate systems - possibly a bigger problem because of the lack of awareness.

Hide this comment

Comment from Alex-7 on 28 November 2017 at 07:38

I do not have enough knowledge to answer your question. However I can tell that the local elevation data in some cases is of a better quality than the data from the global sources.

For example, if you check the elevations with this Google Map tool http://www.enetplanet.com/ for the same area of New Orleans as in my post above you will see that it is always 0 meters, but in fact some places are below sea level.

And the local mappers are well aware of it. They know it only too well.

Hide this comment

Comment from The Maarssen Mapper on 28 November 2017 at 08:59

@Alex-7 My point is simply that an elevation as a number, with no frame of reference, is useless. Just like an amount of money with no currency, or a lat/lon with no CRS. It is not about the accuracy of the measurement, or the quality of the value as such, but it can only be used if it is placed in the right context. Local datums do not join up seamlessly, and global datums are not widely used by "normal people" like mappers. We have a challenge to square that circle.

Hide this comment

Comment from Adriano Cunha on 4 December 2017 at 09:16

@Alex-7 Please, don't use you GPS unit - or phone - altitude data in ele=* tags. It will do a lot of harm and no good. To understand why, you should begin with [all] IOGP Practical Geodesy Guidance Notes - http://www.iogp.org/geomatics/#practical-geodesy

Hide this comment

Comment from Alex-7 on 4 December 2017 at 12:26

Adriano, and if I use both the barometric altimeter and a GPS/GLONASS altimeter? And on the day of the actual measurement I calibrate the barometric altimeter at the point with the known elevation?

A digital barometric altimeter is not expensive, about 50 USD. I plan to buy one.

I understand what you mean. A low quality GPS altimeter can have an error of about 50 meters. On my new smartphone, however, I have got a quality receiver. I went to the lake with the known elevation of 372 meters and the altimeter shows 373 - 375 meters when I stand near the lake consistently.

I do not suggest adding elevation on the OSM map haphazardly. But in places, where it makes sense. For example, an elevation of a remote mountain lake, or elevation in an area which is below sea level. As in my example above of New Orleans.

By the way, in some cities there are a lot of ele=* tags, For example, Zurich, Geneva, Stockholm, etc. And I did not add any ele=* tags in these cities, local mappers did. I just wrote a application which allows to view this data. And in some cases this data is of better quality, as in New Orleans.

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

    [Text](URL)
  • Image

    ![Alt text](URL)

Login to leave a comment