Please also see ele=* for tagging elevation data. Altitude is usually referred to as the height above ground.
OSM currently records points with their latitude and longitude (x/y coordinates); elevations are recorded less frequently. Where this is done, the elevation in WGS84 is stored in the ele=* key.
A proposal for map datums other than WGS84 is to store them in keys such as ele:xyz=####.##, where xyz is the map datum and elevation is specified in meters. Note that there was also a proposal (on this page) to use Key:alt for this purpose. This was never explained properly. Please see ele=*
- 1 Note
- 2 Basics
- 3 Height measurement in OSM
- 4 Barometric altimeter
- 5 GPS altimetry
- 6 Attributes
- 7 OSM-level model
- 8 Cartography
'Please use the established ele=* (elevation) for elevation data. Altitude commonly referred to the height above ground (= altitude). '
Currently OpenStreetMap primarily stores length and width of a point (x / y-coordinates).
Height (elevation) is still rarely stored in the database. Generally, these values are stored in the WGS84 key ele=*.
One proposal is to specify the height reference system used in the key: Template:Date [M] The idea: In ele :...=* the reference system, which was used for the amount specified in the value, is specified after the colon in key.
A key 'alt' was originally intended as an improvement for ele=*, because at the time of the proposal of alt=* in Template:Date height information was given without explicit reference to a reference height. With 'alt' all heights should refer to WGS-84. In the meantime, however, also ele=* refer to WGS-84.
Also available is the elevation model from the SRTM data ( English). It can be defined as additional transparent map layer over the base map, as for example in Cyclemap (englisch) and the Reit- und Wanderkarte. However, the SRTM model covers only differences in height greater than 50 m, and it measures not the terrain itself, but the highest points (canopy, roof). It is not associated with the map data, so You cannot, for example, read gradients directly from it.
Height measurement in OSM
Elevation in OSM is always based on a reference level and the measured difference in height.
Heights are only useful if
- The 'reference level' is exact
- The 'height difference' is exact
- The 'reference system' of the reference altitude is known, and is converted into the reference system of OSM.
The cartographer must therefore know, which Nullebene, which Geoid and which Referenzellipsoid it references, when he makes his measurements. And he needs to know how to convert this reference frame to the reference system of OSM.
Reference height is a precisely measured height, for example, a Festpunkt im Triangulationsnetz, or any derivative Vermessungspunkt. You can query reference heights from the local administration (Building Authority) or check with the local surveying office. Reference heights are usually marked with a wall stud (MB) or a level mark (HM). The accuracy is 0.1 to 100 mm.
In Germany there reference heights are defined in order steps 1 to 5 and with height stabilities 'a' (good) to 'c' (poor).
Conversion to WGS-84
The height inquired from the Building Authority must be converted into WGS-84 before it can be used for OSM. This is also true for all other elevation data from any source:
All heights obtained with an altimeter, or taken from height measurement points on panels, must be converted into WGS-84 before being used in OSM.
The prerequisite is that the frame of reference for the height indicated on the table is known. For Switzerland, one can assume that "m.ü.M." is equivalent to the LN-02 used in Switzerland. In (Western) Germany, one can assume that for the amount indicated on boards that existed before 1990 uses NN (or DHHN-12) (for newer tablets this is unclear, because it is often only copied from the old). For official heights, please ask the Office to which the claim relates for a reference system.
Conversion for Germany
- Ask the surveyor's office which reference system the claim relates to
- conversion of normal height into ellipsoidal height (Germany)
explanation of the conversion Form
- in ele:...=* Enter the reference system and the original elevation from the source
- in ele:wgs84=* enter the converted result in WGS-84
Warning: Enter altitude with unknown or unclear reference system just as Template:Day (without specifying a reference system), and don't perform any conversion (the result would probability be wrong!).
Starting with the point of reference height, the height difference measured by a barometric altimeter is used and added to the reference height:
desired height = height + reference height difference
Caution: Data from GPS heights are inaccurate (+/- 40 m), they are unusable unless averaged for OSM.
When the altimeter is calibrated to a known height reference point, his height refers to the height model, that is based on the height reference point. These are usually region-specific elevation models, relying on the "sea level". In Switzerland meters above sea, Germany | mean sea level (formerly Normal Null), in Austria meters above the Adriatic Sea.
OpenStreetMap is intended, however, to always use WGS-84.
Ellipsoidal height = Normal height + quasigeoid height
All heights obtained with the altimeter, and those copied from height measurement points on panels, need to be converted into 'WGS-84 ' before being incorporated in OSM.
Year null plane Quasigeoid reference ellipsoid Europe 2008 ETRS-89 GRS-80 Germany <1990
Normalnull - NN
Normalhöhennull - NHN
Austria Metres above the Adriatic - müa Switzerland meters above the sea - MüM CH-1903
 (LVA Bavaria)
The barometric altimeter actually measures air pressure. Since the air pressure decreases with increasing altitude, it can directly indicate the height, when calibrated properly.
The accuracy of barometric altimeters in the measurement of height differences lies between 2 and 10 meters, provided the devices are temperature stabilized and the air pressure does not change due to weather change. Exact devices are available from 30 € up.
For non-temperature-stabilized units, the temperature must be kept constant around +-5 degrees. (don't take it out of the pocket in the cold mountain air, nor hold it once in the warm hand and once with gloves on)
- Meteorological pressure fluctuations must be compensated for by all means
Pressure fluctuations are difficult to detect (for non-meteorologists) because according it cannot be distinguished, whether the air pressure has changed meteorologically, or by changing the height.
- see also
- Barometric altimeter
- Barometric formula
- height correction for altimeters
- |height correction for barometric altimeter (Garmin)
- Query official measurement point and underlying reference system (reference point)
- Convert the height of the reference point into WGS-84
- Calibrate the barometric altimeter at the reference point. Use the height already converted into WGS-84 for this
- Read and note the height difference at the point to be measured
- Every 3 hours re-calibrate against the known value (at the Plunger) calculated in WGS-84 level.
- for each pointː Add height WGS-84 reference point and altitude difference:
Attentionː Don't perform barometric altitude measurements on days with front passages passing (storms, rising or falling barometer).
The GPS device is located at the yellow dot "GPS", somewhere on the earth's surface. The GPS device 'knows' where it is currently located (x / y / z-coordinate). It knows the calculated value of the WGS-84 ellipsoid. The device also knows some reference points of a quasigeoid between which it interpolates and thus calculates the difference between the reference ellipsoid and the quasigeoid (undulation). The computational cost of this is very large and therefore almost always an average value is used instead. For Germany this is 47,5 m.
The device calculates the ellipsoidal height from the coordinate and the WGS-84 ellipsoid. From that height and the approximate quasigeoid it calculates the approximate normal height and displays it:
'such altitudes are always imprecise' :
ungenaue Höhenmessung inaccurate Quasigeoid
Professional devices can, however, with appropriate corrections, measure and calculate heights exactly in the millimeter range.
In the NMEA data you see the following fields:
$ GPGGA, time, latitude, longitude, quality, satellite number, accuracy, 115.3, M, 47.5 M │ │ │ │ │ └> Quasigeoid-height │ └> Normal height └> GGA key
Each device uses different data for the Quasigeoid internally, sometimes even every firmware version of the device uses different computational rules. Some GPS devices use plain 47.5 m, but this height is not correct. Others for example print -67.8 m. If we add the 115.3 m from the NMEA Data, we obtain the 47.5 m.
The ellipsoidal height is the most accurate measurement. This is calculated directly from the satellite data. But it will not be displayed directly, but is the sum of the quasigeoid height and the normal amount contained in NMEA. The value of the ellipsoidal height should always be used for the OSM database, because all other heights can be derived from them and any elevation models be calculated.
Ellipsoidal height = Normal height + quasigeoid
Normal height 115.3 m Display Quasigeoid height internally, inaccurate ellipsoidal height 162.8 m Originally calculated
The Quasigeoid GCG-05 mentioned above used in Germany has a position deviation (undulation) of 45.87 m to WGS-84. It thus differs by 1.63 m from the average. This is far below the fault tolerance of height measurements with normal GPS devices and therefore negligible for OpenStreetMap.
According to our formula when using the GCG-05 we obtain:
- 162.8 m - 45.87 m = 116.93 m
This corresponds almost perfectly to the 117 m "Real Height".
But GCG-05 is not compatible with the OSM license. Therefore, we use EGM-96 and EGM of 2008. The following online calculators can convert between them: only EGM-96 EGM 2008 EGM EGM 96 and 84 in comparison
At the position in the example, the deviation is 46.16 m, the difference from GCG-05 is thus only 29 centimeters.
Comparative measurements between GCG-05 and EGM-96 give a standard deviation of 33 cm. With 2008 EGM it is even less. For geodesic applications this is too much, but for OpenStreetMap it is more than acceptable.
When you obtain data from the National Survey Office, you need to check in what level format they are given. However, the variation between the different quasigeoids is generally very small (between ... and ...).
It would make sense to generally perform a recalculation to the basis ellipsoid, so you can convert into other models in the future. However, since this is usually complicated and not uniform around the world, in my opinion, only this distinction would be useful:
- ele = elevation data from the GPS (probably very inaccurate)
- ele:dhhn92 = height information based on DHHN 92
- ele:wgs84=* = ellipsoidal height, based on WGS-84 (see above)
- ele:etrs89 = ellipsoidal height in ETRS 89
'Standard in OSM' is:
Outside 'off-road' you mainly find:
ele:msl=####.# (Mean Sea Level) ele:nhn=####.# (Normalhöhennull) ele:nn=####.# (Sea level) ele:etrs89=####.# (European Terrestrial Reference System 1989) ele:dhhn92=####.# (German Levelling Network 1992) ele:müm=####.# (Switzerland: meters above sea level) ele:müa=####.# (Austria: meters on the Adriatic Sea) ele:evrs=####.# (European Vertical Reference System) ele:...=####.#
Only with appropriately specific indication it can be ensured that the various systems in the database are not mixed up.
If you copy an altitude reading from a panel, you do not know to which reference height it relates. For such cases we use the "standard" ele:unknown=* and as the source standard ele:source="copied from table".
- height in geodesy
- height above sea level
- conversion: & nbsp; WGS-84 ↔ ↔ orthometric height EGM-96
- conversion: & nbsp; → Decimal Degrees Minutes Seconds
- GEOTRANS - coordinate transformation in various models (for Windows, UNIX)
Trials are ongoing to create our own elevation model using statistical methods on large amounts of elevation data from GPS Tracks, and thus to refine the SRTM model for us.
Our statisticians need 'as many tracks with elevation data' as possible to form a network across the whole world.
The experiments are currently limited to Germany, and the results are not stored into the database.
Height differences are displayed using contour lines. For better visual identification of the mountains and valleys, slopes are often shaded.
Cartographic representation of strong gradients (cliff escarpment, Cliff, ravine, deep valley) requires special map symbols. This is not feasible with contour lines even with a small contour interval of 10 m.