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

["James M. Polk" <[e-mail]>]

At 02:21 PM 7/9/2003 -0400, Greg Troxel wrote:
>John Schnizlein <[e-mail]> 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.

This seems reasonable


> > 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".

I like your suggestion up until the last part. The M, L, G, or B floors 
(which they are) are to be denoted as x.1, x.2, x.3 etc. This was text that 
existed once - but was somehow was left out of the current version (my 
fault as editor though I don't remember when this happened), but was 
covered in an email to both dhc and geopriv lists by Marc Linsner dated 
6/20. This text regarding sub-floors (or in between floors) will be included.


>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.

This ID  is intended to get emergency responders to wired device locations. 
That is a very limited scope. Of course this can be used for wireless 
devices, but the amount of precision becomes an issue at that point.


>Having read what I just wrote, it seems that "floor" should be a
>string, not a number,

this will make the string variable and would make version longer than the 
originally proposed length of the Option. hmmmm

>so that it can contain whatever value is written
>on the walls outside the elevators.

In between floors (like mezzanines) are to be denoted with the x.1, x.2, 
etc value. This should solve this.

>So I must recommend that the
>floor type be deleted and left to the civil location object.

Your suggestion changing the measurement unit to altitude type (AT = 1 
means meters, AT = 2 means floors) is a preferable solution here. Floors is 
pretty important to this effort, and I don't really want to delete its 
benefit if possible.


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

ok


>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.

ok


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

ok


>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.

hmmmm

>We are in need of a European
>geodesy nerd.

I agree with this


>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.

Carl Reed wanted ED50 and ED87 included, so we put them in. We have 255 
available choices to include (from EPSG's 264 listed datums).

Should we include NAD27, or delete ED50 (and or ED87)?


>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.

This was our original plan

>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.

Looking for others to state whether this is a good idea (Carl and/or 
Nadine?)....

This seems reasonable to me, but others have a more vested interest in 
which datums are included I think


>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.

Thank you for this, I'll include it


>--
>         Greg Troxel <[e-mail]>


cheers,
James

                                *******************
                    The answer is "42", what's the question?


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