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

"Carl Reed" <creediii@mindspring.com> Thu, 24 July 2003 18:18 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19662; Thu, 24 Jul 2003 14:18:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkeF-0004Fw-83; Thu, 24 Jul 2003 14:17:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19eMgJ-0004AG-UW for dhcwg@optimus.ietf.org; Sun, 20 Jul 2003 18:29:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29805 for <dhcwg@ietf.org>; Sun, 20 Jul 2003 18:29:19 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19eMgE-0005aM-00 for dhcwg@ietf.org; Sun, 20 Jul 2003 18:29:22 -0400
Received: from blount.mail.mindspring.net ([207.69.200.226]) by ietf-mx with esmtp (Exim 4.12) id 19eMfR-0005a0-00 for dhcwg@ietf.org; Sun, 20 Jul 2003 18:28:33 -0400
Received: from dialup-209.245.9.215.dial1.denver1.level3.net ([209.245.9.215] helo=compaq) by blount.mail.mindspring.net with smtp (Exim 3.33 #1) id 19eMWt-0006IB-00; Sun, 20 Jul 2003 18:19:43 -0400
Message-ID: <005b01c34f0c$94d51420$d709f5d1@compaq>
From: Carl Reed <creediii@mindspring.com>
To: Greg Troxel <gdt@ir.bbn.com>, Marc Linsner <mlinsner@cisco.com>
Cc: 'Andrew Daviel' <andrew@daviel.org>, dhcwg@ietf.org, geopriv@mail.apps.ietf.org
References: <000501c340ab$46784be0$220d0d0a@mlinsnerzk7abh> <rmin0fn4v77.fsf@fnord.ir.bbn.com>
Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location ConfigurationInformation for GEOPRIV
Date: Sun, 20 Jul 2003 16:11:06 -0600
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_002F_01C34ED9.864A6C80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

Yes, Greg - Thank you for taking the time to do this research.

I should note that most commercial GIS in use today simply assume mean sea
level as the point of origin for base "0" for altitude. This works OK for
numerous GIS (non-survey!) applications, especially when working large
scale. This is partly due to the fact that many GIS type applications work
fine as long as all the elevations are in relation to one another.

In any case, I have attached a really good set of slides on Geodesy that one
of our members (a professional geodesist) put together to help educate the
OGC membership. I should have sent this earlier, but had forgotten we had
this presentation.

Hope the meetings in Vienna went well!

Regards

Carl


----- Original Message -----
From: Greg Troxel <gdt@ir.bbn.com>
To: Marc Linsner <mlinsner@cisco.com>
Cc: 'Andrew Daviel' <andrew@daviel.org>; <dhcwg@ietf.org>;
<geopriv@mail.apps.ietf.org>
Sent: Wednesday, July 09, 2003 8:43 AM
Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location
ConfigurationInformation for GEOPRIV


> Marc Linsner <mlinsner@cisco.com> 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" <jmpolk@cisco.com>
>   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 <gdt@ir.bbn.com>