Talk:Key:ele

Used on the nodes of a highway

On many early highways in Norway, I find that all the nodes has the ele=*-tag set. Often with six decimals. Trash or keep? Or maybe just remove the decimals? Gorm 20:30, 1 December 2009 (UTC)

Points with varying altitude

In sweden (and norway, finland, iceland...) we have a lot of lakes that are used for hydropower plants. This causes the surface altitude to vary a lot between over the year. For instance the surface of the lake I live nearby may vary between 88.54 and 89.14 m, while some other like Höljessjön can be 270-304m (yes 34m difference!). How would that fit into the ele= attribute? I would say it calls for a different attribute for lakes used this way. Perhaps ele_min= and ele_max=. Karlskoging1 23:56, 30 March 2007 (BST)

Well that's similar to having high and low tide right? Is there a discussion anywhere about tagging high and low tide for Coastlines? I imagine we probably decided to draw the way along the mid-point or average tidal position of the coastline (as seen from above) ...and so the 'ele' tag should also be the mid-point or average -- Harry Wood 12:23, 7 January 2008 (UTC)

I would think that it make most sense to mark the highest water level for reservoirs as the surrounding infrastructure (roads/paths) will be set by this. --Mungewell 01:53, 16 April 2008 (UTC)

For varying altitudes like tide on seas or the mentioned lakes with different levels, i think best would be to enter the highest level, as surrounding infrastructure mentioned by Mungewell. Maybe an additional tag like "tide=-34" for showing the tide.gunni 07 August 2008 (UTC)

Some mappable objects have a height above ground level, it should be stated that that Altitude refers to the top of the object (for example the top of a communications tower). --Mungewell 01:53, 16 April 2008 (UTC)

Geodetic datum

We have many geodetic datum for vertical measurement.

Where is zero for ele=0?

This is important... we have many different scale!

Typical:

MSL - mean sea level or HAE - height above the ellipsoid

18. august 2007 [User:Hanoj|Hanoj]

Since everybody is going to be generally using GPS and/or STRM data, both of which use the WGS84 ellipsoid as a basis for their height datum, this sounds like the natural one to use. This would seem a better alternative that a country specific scheme, like AHD, or ODN etc... --inas 00:05, 29 August 2007 (BST)

That would then mean that (mean) sea level at most places would not be zero. That is seriously unintuitive for most people.

When we wan't to generate usable data there are two ways to choose: State the elevation above WGS84 and store somewhere the difference to the locally used scale. Or vice versa use a local scale and store somewhere the difference to WGS84. Only trouble is, where is this somewhere to store that difference.

But what about a notation like this? ele:msl=55 ele:wgs84=52 and so on. That might be redundant because the difference is the same in vast areas but someone rendering would be able to choose. -- Fröstel 00:18, 15 November 2007 (UTC)

Also, the accuracy of typical consumer GPS units in the vertical direction is quite bad and unstable, and it is far more likely that the elevations will be picked from out-of-copyright maps or public domain "common knowledge". These are typically not expressed as height over the WGS84 ellipsoid, especially not for out-of-copyright maps from long before 1984... --Tml 19:00, 2 September 2007 (BST)

This is certainly the case for mountain peaks, but not for cycle paths etc. I guess it depends on the use. Also, don't forget if we use SRTM data (all public domain), this is height above the WGS84 ellipsoid. --inas 02:05, 11 September 2007 (BST)

WGS-84 is the base for alt

OSM is based on WGS-84. Also every GPS mesurement. Also the worldwide international electronic seamap (ECDIS). Also the SRTM-database.

So we should use also WSG-84 for Altitude in OSM.

But we need a transformation-program to converse local altitudes in WGS-84

And I propose to use a specific tag for to explicit the base for Altitude:
alt:wgs84=#

--Markus 08:39, 17 September 2008 (UTC)

Name of the tag

Imported nodes are tagged ele= (altitude in meters). ele would be a much better key for this, so we don't have to redo them all. user:blarson 01:00 30 March 2007

Good to know. I will use the ele= tag then. Is it for elevation? Should the proposal be changed? Sounds like it. I will change the proposal to ele then and put it to vote. --spaetz 16:50, 30 March 2007 (BST)

Why do you want to name the new (?) tag 'ele' or 'elevation', why not 'altitude'. In different disciplines elevation is often used as the denominator for an angle above (or below) the horizon (perpendicular to 'azimuth'). As I am german, I'm not sure about the use and exact meaning of 'elevation' and 'altitude' in the english language, but I'm sure that there is somebody around here with a proper understanding of the two words who can explain and clarify it for me. --Raschu 22:20, 15 October 2007 (BST)

I'm also German, but I'd prefer altitude, too --Bkr 21:51, 2 June 2008 (UTC)

Altitude is the right term. Altitude means the hight of an object over the sea-level.
See also Altitude in LEO (hight, hight over sea, Höhe über Meer, Höhe über NN)
Altitude we mesure it with an altimeter.

"Elevation" means an angle, a difference, a acclivity. In astronomy and astronavigation it mens an angle (elevation of a luminary about horizon). In military terminology it mens an angle (elevation of an object as shooting target). --Markus 08:09, 17 September 2008 (UTC)

Check the figure in http://en.wikipedia.org/wiki/Altitude: "Altitude" ist used in aviation as heigth above MSL, but "elevation" for mountains (above MSL). According to the Webster dict, "elevation" is not only an angle, but also the "height of a place". --Oosm12 (talk) 23:38, 7 November 2013 (UTC)

Original Proposal

(moved here from main page) Lazzko 14:34, 26 October 2008 (UTC)

This is the original proposal made before adoption to Map Features.

Proposal

This tag would denote the altitude of a node in meters. It could be used for mountain peaks, for the evelation of airport runways, and many other objects. After discussion it became clear that the actual tag should be ele=AltitudeInMeters, so that is what this proposal is about.

Discussion

Discussion moved into the Discussion part of this page

Is there any need for the abbreviation? Why not opt for elevation= instead? It's only a few letters longer, and is more easily readable... (renderers can easily support both keys for backwards-compatibility). Frankie Roberto 21:48, 2 August 2007 (BST)

Vote

Please vote for or against a tag ele=AltitudeInMeters.

• I approve the proposal. --spaetz 16:52, 30 March 2007 (BST)
• I approve the proposal. Morwen 17:15, 30 March 2007 (BST)
• I approve the proposal. dh1uz 08:39, 05 May 2007 (UTC)
• I approve the proposal. --Damian 10:57, 15 May 2007 (BST)
• I approve the proposal. --Jannis 01:38, 18 May 2007 (BST)
• I approve the proposal. --Gummibärli 16:49, 02 August 2007 (CEST)
• I approve the proposal -- Studerap 18:29, 2 August 2007 (BST)
• I approve the proposal -- MarcusWolschon 22:08, 14 August 2007 (BST)
• I approve the proposal -- Tml 11:18, 15 August 2007 (BST)
• I approve the proposal -- Dtucny 03:24, 21 August 2007 (BST)
• I approve the proposal -- Nybbler
• I approve the proposal -- katpatuka 07:59, 7 January 2008 (UTC)
• I approve the proposal -- hermes_p
• I approve the proposal --Ckruetze 10:30, 19 February 2008 (UTC)
• I approve the proposal --dieterdreist 15:08, 22 February 2008 (UTC)
• I approve the proposal --Uboot 00:05, 20 March 2008 (UTC)
• I approve the proposal --Wonko 22:24, 15 April 2008 (UTC)
• I approve the proposal--Cbm 07:10, 14 June 2008 (UTC)
• I disaprove.
  Altitude=AltitudeInMeters should not be wrongnamed as "ele".
  Also we need a hint to the geodetig datum which should be WGS-84.
  alt:...=# or alt:WGS84=# will be the right tag for altitude in OSM.
  --Markus 08:46, 17 September 2008 (UTC)

Moved to Map Features

WGS84 or WGS84

The current description of the tag is highly confusing in its wording and seems to contradict discussion elsewhere on this page.

The text claims that the value is relative to a "WGS84" which is not the "WGS84" reported by "raw" GPS data, but actually an adjusted geoid which may or may not be the "corrected" above-mean-sea-level value used by any given model of GPS receiver (I imagine there is a manufacturer choice as to which correction data set to use for display purposes).

So the big question is: Is the ele tag already in the OSM database supposed to be relative to:

1. The WGS84 ellipsoid used in the GPS signal definition.
2. The EGM96 geoid suggested by the current wiki page wording.
3. Any random mean sea level reference used by the mappers GPS equipment in its NMEA-0183 data output (GGA statement).

Jbohmdk 07:21, 15 November 2014 (UTC)

Feet and inches

This article currently specifies that the elevation must be expressed as a plain number in meters and suggests using a subkey for elevations in feet and inches, which are conventional in the United States. Should we consider relaxing that requirement and allow conventional units to be tagged in the main key?

ele=* is currently inconsistent with other measured keys, such as height=*, maxspeed=*, maxweight=*, maxheight=*, which all condone the use of local units as signposted. diameter=* even requires an alternative unit to be specified for some use cases. Unlike pipe diameters, the elevations of peaks, mountain passes, and railroad stations are typically signposted in many regions. Back when ele=* was first proposed, probably as OSM's first measured key, there was definitely an idea that tag values should be as structured as possible, which meant a normalized floating point number without any other complications. I distinctly remember converting maxspeed=* and maxweight=* to SI units for a few years after that, often inaccurately, but at some point the consensus shifted in favor of using the local units.

In terms of backwards compatibility, ele=* is a longstanding key, and openstreetmap-carto filters out any non-metric ele=* value when labeling peaks. [1] But height=* accepts feet, even though osm-carto labels waterfall heights in the same manner as peak heights. [2] Temporarily leaving unlabeled any elevations in feet doesn't seem as severe as the poor routing that occurred during the transition period for maxspeed=* mph.

 – Minh Nguyễn ^💬 05:25, 24 September 2021 (UTC)

I would discuss it on tagging mailing list as it is quite significant change. On one hand I am all "death to imperial units". But it is not a really good reason, especially as it likely makes editing in USA quite annoying and OSM tagging schemes should not be used as culture war tools. Even 100% correct ones. So I would not oppose such change, if it would be clearly supported by mappers in general. And yes, I know that strictly speaking it is more correct to speak about United States customary units. Mateusz Konieczny (talk) 07:10, 24 September 2021 (UTC)

I agree with extending the discussion to the tagging ml audience. In principle I am favorable to tagging values in other units by adding the unit to the value in the same key as the metric values, like we do in other fields like maxspeed (kph without unit, otherwise with mph or whatever and explicitly stated).—Dieterdreist (talk) 07:30, 24 September 2021 (UTC)

@Mateusz Konieczny and Dieterdreist: Thanks, I drafted a proposal and will take it to the tagging mailing list next. (I had started to write up a simple post to the list, but it started to look like a formal proposal anyways.) – Minh Nguyễn ^💬 02:16, 29 November 2021 (UTC)

Decimal separator

Shouldn't the wiki describe which is the default decimal separator? This varies from country to country (mainly between point "." and comma ",") and it would be useful to have that information in this wiki. --AntMadeira (talk) 10:35, 16 October 2023 (UTC)

Switzerland

Having skimmed over the Swisstopo website, it does not mention "LN02" anymore, but states that "The local reference system, CH1903+, is static and provides the coordinates reference system for all surveying activities. By connecting observations to the old national survey, the data from the still official reference system, CH1903, could be adopted and transformed into the new system, CH1903+.". Source: https://www.swisstopo.admin.ch/en/national-survey-lv95

Therefore, the Switzerland entry in the table should be updated, but preferably by someone who knows what they're doing rather than me. In the meantime, I placed {{Dubious}} in the table to indicate discrepancy. Duja (talk) 09:31, 20 March 2024 (UTC)