[Tagging] Elevation and height on vertical features

Greg Troxel gdt at ir.bbn.com
Fri Jan 8 16:18:28 UTC 2016

Colin Smale <colin.smale at xs4all.nl> writes:

> So if all the elevations in OSM should be interpreted as WGS84, but many
> (most?) of them are not, we have no way of knowing which are "right" and
> which are "wrong". Even if the numerical value of ele=* is correct, we
> have unreliable data. 

I have always had the impression that all coordinates in OSM are
supposed to be in WGS84, but that actual practice was fuzzier about

In geodesy, the subject of elevation/height is actually very
complicated.  There is a surface called the geoid, which is 
an equipotential (equal gravity) surface, and therefore varies from an
ideal shape due to geology etc.   Traditionally, heights ("above sea
level") were referenced to this.   An example in North America


which assumed there was a thing called "sea level" and the more recent
which does not make that (wrong) assumption:


Height is defined, more or less, as the vertical distance along the plumb
line to the equipotential.

With GPS, what you actually measure is height above the ellipsoid, which
is a mathematical surface with no precise physical reality that is on
average aligned with the geoid.  Then, your GPS receiver uses a "geoid
model" to compute and estimate of the difference between the ellipsoid
and the geoid.  This is sufficiently baked in that it's hard to get at
the unprocessed height, at least on navigation receivers..  So the
"elevation" that is displayed is an estimate of a gravity-based height
in the style of NAVD88, based on measurement relative to the ellipsoid.
These models are part of WGS84:


So, we just have to use WGS84 elevations.

  According to wikipedia [1] the differences between the datums can be up
  to 100m.


  [1] https://en.wikipedia.org/wiki/Sea_level#Height_above_mean_sea_level 

I think that's true only for quite old height systems.  For modern
systems (NAVD88 and European and other equivalents from the
post-satellite era), the differences will be far smaller.

So we just have to fix things that are wrong, and transform heights in
other datums into WGS84 before entering them.  This is exactly the same
situation that we encounter for horizonal datums, except that people are
even less aware of which vertical datum they are using.

I don't think it makes sense to add datum tags and have heights in other
datums.  That just pushes the work onto the data consumer and adds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20160108/376a60ed/attachment-0001.sig>

More information about the Tagging mailing list