[Tagging] tagging of "ele" / elevation data e.g. in the context of towers

Greg Troxel gdt at ir.bbn.com
Mon Feb 20 13:12:07 GMT 2012


Alan Mintz <Alan_Mintz+OSM at Earthlink.Net> writes:

> This is the standard for FCC (communications) and FAA (airspace) in
> the US. Well, close at least - elevations are generally "above mean
> sea level" - I don't know how that relates to the WGS84/GPS and/or
> survey elevation but I'd expect them to be close.

"above mean sea level" (not claiming the FCC doesn't use it; I've seen
it too) is basically sloppy from a surveying/geodesy viewpoint; the
notion of mean sea level only applies at a specific tide gauge.

The modern concept is orthometric height relative to a given vertical
datum (in the US, NAVD88).   This is more or less the same conceptually
as MSL except that it doesn't presume that mean sea level at all tide
gauges is the same (as NGVD29 did).  Orthometric height is based on
gravity, rather than geometry, and is more or less distance normal to
the geoid, a surface of constant potential that sort of matches sea level.

WGS84 proper measures locations relative to the ellipsoid.  One would
refer to the measured height (transformed to lat/lon/height from XYZ in
earth-centered earth-fixed) as an ellipsoidal height.  But because what
everyone wants is orthometric height (partly because of tradition and
existing data, and partly because water flows downhill relative to
orthometric height), one uses a geoid model that estimates the distance
From the ellipsoid to the geoid.  From that one gets an estimate of
orthometric height.

On every GPS receiver I've seen, the "altitude" is intended to match
orthometric height, and is ellipsoidal height adjusted by the geoid
model.

So it's ok to talk about WGS84 elevations, but we should be clear that
we mean elevations intended to be usable as orthometric heights using
the geoid model.

ellipsoid/geoid separates are large; around me it's ~30m.  But errors in
geoid models and differences in semi-modern (20th century and newer)
vertical datums are a meter or so, at least in North America.  So
despite my ranting, this is mostly ignorable for OSM.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120220/2ed72b00/attachment-0001.pgp>


More information about the Tagging mailing list