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

Greg Troxel <gdt@ir.bbn.com> Thu, 10 July 2003 17:36 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 NAA13604; Thu, 10 Jul 2003 13:36:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19afKr-00056V-UW; Thu, 10 Jul 2003 13:36:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJZN-0000yT-QO for dhcwg@optimus.ietf.org; Wed, 09 Jul 2003 14:21:33 -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 OAA12889 for <dhcwg@ietf.org>; Wed, 9 Jul 2003 14:21:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJZK-0001Ws-00 for dhcwg@ietf.org; Wed, 09 Jul 2003 14:21:30 -0400
Received: from fnord.ir.bbn.com ([192.1.100.210]) by ietf-mx with esmtp (Exim 4.12) id 19aJZJ-0001Wp-00 for dhcwg@ietf.org; Wed, 09 Jul 2003 14:21:29 -0400
Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 6165A20E0; Wed, 9 Jul 2003 14:21:28 -0400 (EDT)
To: John Schnizlein <jschnizl@cisco.com>
Cc: dhcwg@ietf.org, geopriv@mail.apps.ietf.org
Subject: Re: [dhcwg] Fwd: Working Group Last Call: Location Configuration Information for GEOPRIV
References: <000501c340ab$46784be0$220d0d0a@mlinsnerzk7abh> <000501c340ab$46784be0$220d0d0a@mlinsnerzk7abh> <4.3.2.7.2.20030709121509.02189db8@wells.cisco.com>
From: Greg Troxel <gdt@ir.bbn.com>
Date: Wed, 09 Jul 2003 14:21:28 -0400
In-Reply-To: <4.3.2.7.2.20030709121509.02189db8@wells.cisco.com>
Message-ID: <rmin0fnzhlj.fsf@fnord.ir.bbn.com>
Lines: 120
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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>

John Schnizlein <jschnizl@cisco.com> writes:

> It seems we don't either. Thank you for the tutorial background.
> Is your recommendation that we specify no default?

not quite.  My recommendation is that the protocol not be capable of
encoding altitude without an associated vertical datum, since that
combination doesn't make sense.

> Are you recommending that the default for altitude be WGS84 if not
> otherwise specified by the datum value in the option?

That is one reasonable choice.  The other is to change the datum to be
a pair in such cases.  Using WGS84 height with older datums strikes me
as odd; such old horizontal datums generally have associated old
vertical datums.

> We are happy to accept specific text that makes this document better
> "follow established geodetic practice". Is it just the default for
> altitude for which you want to recommend text?

In draft-ietf-geopriv-dhcp-lci-option-01.txt,

I suggest changing "MU" and "Measurement Unit" to "AT" and
"Altitude Type".  Define code 1 to be "Altitude (orthometric height,
not ellipsoidal height) in the specified datum, expressed in meters.".

This doesn't change the semantics much, but it provides a datum
reference, and makes clearer that the different between MU=1 and MU=2
is more than using meters or feet; the type of measurement (m in WGS84
and floor) are far more different than that.

The 'floors' text is not precise enough to be interoperable.  How
about replacing it with:

  The "floors" Altitude Type is provided because altitude in WGS84 may
  not be known within a building, and a floor indication may be more
  useful.  The value 0.0 for floor is meaningful even outside a
  building, and represents ground level at the given latitude and
  longitude.  Inside a building, 0 represents the floor level
  associated with ground level at the main entrance.  This document
  defines a number; one must arrive at the number by counting floors
  from the floor defined to be 0.

  Note that this definition will differ from conventional usage for
  floor labeling in the US; some sort of locale support may be needed
  for presentation of this information to users.  A further
  complication is that floors in buildings can be labeled "M", "L",
  "G", or "B".

It seems that there is no way to provide both altitude and floor.  I'm
not sure this is good.  In general the altitude type scheme heads down
the path of blurring geodetic coordinates and civil location
information.

Having read what I just wrote, it seems that "floor" should be a
string, not a number, so that it can contain whatever value is written
on the walls outside the elevators.  So I must recommend that the
floor type be deleted and left to the civil location object.

In section 5, text for MU=1: remove "from mean low tide" (it is
inaccurate), and replace with "in the specified vertical datum".

In section 2.1, amend the datum description by adding after the
"Datum:" line:

  The datum must be both a horizontal and a vertical datum.  Some
  datums, such as WGS84, are both.  For others, such as NAD83, a datum
  codepoint denotes both a horizontal datum and an associated vertical
  datum.

In codepoint 4, add:
  The associated vertical datum is the North American Vertical Datum
  of 1988 (NAVD88).

I don't know what the corresponding vertical datums are for ED50 and
ED87.  They may well be different in different countries; I suspect
this is particularly true for ED50.  There seems to be something
called European Vertical System 2000 (EVS2000); this is perhaps
appropriate with ED87.  We are in need of a European
geodesy nerd.

The following paper may be interesting, but only if you thing the
notion of height is fun: http://www.wettzell.ifag.de/publ/publ/wtz142.pdf

The inclusion of ED50 (which is not a "modern" datum, meaning that it
isn't tied into a global system) raises the issue of inclusion of
NAD27, a similar datum for the US.  That begs the question of datums
for India and the Far East.

Stepping back, coordinates in all of these datums can be converted
into WGS84 (or ITRF).  So arguably there should be just one
on-the-wire format for geodetic location, and WGS84 seems like a good
choice.  Otherwise hosts have to deal with conversion, or
location-carrying protocols have to represent multiple datums.  My
view is that people/hosts/organizations which are capable of
generating location information sufficiently accurate for the datum to
matter (hundreds of feet) are either using GPS (hence WGS84 already)
or knowledgeable enough to perform datum transformations.

If people object to a coordinate system defined by the US
DOD, we could specify ITRF instead (but the values will remain the
same unless one is at the centimeter level, more or less).  See
http://www.iers.org/iers/products/itrf/ I recommend sticking with
WGS84.  I would be shocked if altitudes obtained with Galileo differ
from WGS84 or ITRF by any noticeable fraction of accuracy achieveable
with normal GPS receivers - all the modern horizontal and vertical
datums seem to be aligning with ITRF.  WGS84 itself has been revised
twice.

If you don't want to make datums a pair (I see the downside in
complexity), modify the altitude to specify that it is always in
WGS84, regardless of the horizontal datum.

Add a normative reference to WGS84.  See
http://164.214.2.59/publications/specs/printed/WGS84/wgs84.html
This is MIL-STD-2401, published by NIMA.

-- 
        Greg Troxel <gdt@ir.bbn.com>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg