Re: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV

[Greg Troxel <[e-mail]>]

Marc Linsner <[e-mail]> writes:

> For those who are struggling with this, it is not our intention to
> (re)define zero altitude.  We are simply attempting to provide a
> mechanism for people who understand altitude values to share them
> amongst each other via a standardized mechanism.  If one were to receive
> such data, it is assumed that they will understand the definition of
> zero altitude within the jurisdiction/authority from which the data
> originated.  Some map datum define zero altitude, some don't.  For those
> that don't, we define mean low tide.

But almost no one actually understands what altitude means (I didn't
until I read several geodesy textbooks). Datums and jurisdictions
don't map cleanly; many jurisdictions have maps with several datums
still in current use - near Boston a map/chart could have any of three
vertical datums.  Most older datums are only horizontal or only
vertical.  Depths on nautical charts are almost always relative to
some (regionally varying) form of low water, but heights on land are
usually not.  What we usually call altitude is more precisely referred
to as "orthometric height", which is the distance along the plumb line
(normal to the gravity field) to a reference equipotential surface
called the geoid, loosely known as Mean Sea Level.  Vertical datums
(such as National Geodetic Vertical Datum of 1929, and the North
American Vertical Datum of 1988) were orginally based on some notion
of mean sea level at tidal stations, and extended by leveling
(following the equipotential and measuring the distance travelled
vertically).  But, the distances between equipotential surfaces change
as you move horizontally due to variations in the gravity field, so
leveling doesn't quite get you orthometric height.  So height in a
vertical datum is really relative to heights of nearby benchmarks,
whose height values have been established by leveling and a
least-squares adjustment.  My point is that referring to
altitude/height other than with a specific reference to an established
vertical or 3-dimensional datum is madness.

See the following slide for a hint of the complexities:

http://www.prism.washington.edu/educatin/forum99/Findlayson/sld009.htm

For location in the US (sorry for being US-centric; I'm not
familiar enough with datums in the rest of the world to comment
precisely), we have multiple possible meanings of altitude:
  relative to MLLW (nautical charts)
  relative to NGVD29 (older topo maps, typically NAD27 horizontal datum)
  relative to NAVD88 (newer topo maps, typically NAD83 horizontal datum)
  relative to WGS84 ellipsoidal height (not used for civil heights)
  relative to WGS84 geoid (should match NAVD88 closely enough for
        "mapping purposes")

The latter is what a typical GPS receiver produces.  GPS receivers
calculate positions on the ellipsoid (obtaining an ellipsoidal height)
and apply a geoid model to obtain an estimate of orthometric height.

This is all overkill for geopriv, but I'm really uncomfortable with a
notion that altitude is in a local convention for datums that don't
define altitude.  Even this is ambiguous: the North American Datum of
1983 is a horizontal datum, but "everybody knows" that orthometric
heights given in conjunction with this datum are in NAVD88.  Except on
nautical charts.

  From: "James M. Polk" <[e-mail]>
  Date: Wed, 09 Jul 2003 00:13:21 -0500

  We state that if the datum doesn't define a "0" altitude, we define it
  as "mean low tide". Does this not cover that angle? This seems
  pointless when the altitude is measured in floors, but I could be
  wrong.

Altitude should always have a datum.  Using orthometric height
relative to the WGS84 geoid is a fine default choice.  Mean low water
only makes sense at the shore; WGS84 is defined globally.

There should be two datums: horizontal and vertical.  For datums which
are 3-dimensional, like WGS84, the same code can be used in both
slots.  Either that, or datum codepoints should be required to be
either a 3-D datum or a pair of horizontal/vertical datums
(e.g. NAD83/NAVD88).  The use of pairs is really quite natural;
vertical and horizontal datums were typically developed alongside each
other.  (This must be defined already in other standards, but the "if
no vertical datum then use mean low water" makes me think not quite
enough of another representation was adopted.)

Perhaps we should define a 'floor' datum.  Floors aren't really a
"unit of measurement", since they aren't necessarily the same size, 13
might not exist, etc.  The floor datum is simple: the value is a
number (no units), and corresponds to elevator labeling if there are
elevators, or posted labels if those exist.  If not, 1 is where people
normally enter, and whole/half flights of stairs change value by
1/0.5.  Floor levels are very useful, perhaps more so than orthometric
height in buildings, but we shouldn't try to make them into an
altitude, since they simply don't have the same properties.  And every
building is different; a floor number without an identified building
doesn't make sense.

Perhaps civil locations should have a datum codepoint that uses
address and building # as the horizontal datum and floor as the
vertical datum.

I haven't been following very closely; sorry if I'm off in space or
seeming difficult.  I think that trying to follow established geodetic
practice will make some things smoother.  For those people that don't
know their altitude, it won't matter anyway.

-- 
        Greg Troxel <[e-mail]>

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg