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
- [dhcwg] Fwd: Working Group Last Call: Location Co… Ralph Droms
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Robert Elz
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… John Schnizlein
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Robert Elz
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Andrew Daviel
- RE: [dhcwg] Fwd: Working Group Last Call: Locatio… Marc Linsner
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Henning Schulzrinne
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… creediii
- [dhcwg] Unit of Measurement...? James M. Polk
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… John Schnizlein
- [dhcwg] Re: Unit of Measurement...? James M. Polk
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… James M. Polk
- RE: [dhcwg] Fwd: Working Group Last Call: Locatio… Marc Linsner
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Henning Schulzrinne
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Greg Troxel
- [dhcwg] Re: Unit of Measurement...? Henning Schulzrinne
- [dhcwg] Re: Unit of Measurement...? Greg Troxel
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Greg Troxel
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Greg Troxel
- [dhcwg] Re: Unit of Measurement...? Carl Reed
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Dominic Pinto
- Re: [dhcwg] Fwd: Working Group Last Call: Locatio… Carl Reed