Subject: RE: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

From: "Marc Berryman" <[email-masked]>
Date: Tue, 12 Jul 2005 17:34:18 -0500

Long and lat is fairly easy and quick to acquire, the altitude (Z)  is a
problem. In almost all cases, the long and lat are within a few feet, or
at least a very few tens of feet. Altitude is always off by many tens of
feet and may be off by a few hundred feet.  

The reason for the large discrepancy in the altitude measured by a GPS
device is the is based on a datum. The WGS 1984 is the "Standard Datum",
and the elevation is based on a Geoid. The altitude obtained with GPS is
based on the height of the Geoid, not the actual ground level, and not
even the mean sea level.

Put another way, the altitude provided by GPS does not take into account
the actual ground below you, instead it is based on an averaged ground
level - the Geoid 
	
So when people say X (longitude) Y (latitude) and Z (altitude or
elevation) location coordinates, they are assuming the Z is as accurate
as the X and Y, which is not so. Altitude derived from current GPS units
will never be valid, unless your ground elevation coincides with the
geoid elevation, which would be very rare.

The point to this quick lesson in geodetics is simply floor elevations
would only be valid if the were entered, and not measured from some GPS
unit. 

I can always find a geo location, I may not be able to find a poor civic
location.

My two cents, 
Marc

Marc Berryman, ENP
Manager Geographic Information Systems
Greater Harris County 9-1-1 Emergency Network
Houston, Texas      (713) 407-2254
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian Rosen
Sent: Tuesday, July 12, 2005 4:56 PM
To: 'Marc Linsner'; 'Henning Schulzrinne'; 'Tschofenig, Hannes'
Cc: 'GEOPRIV'
Subject: RE: AW: [Geopriv]
Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

I don't understand this question.

First of all, it is far easier to use civic in a multistory building --
35th
floor, suite 3510, Room 25 (or cubicle 25-6).  Certainly, until we get
accurate floor plans, accurately aligned to GPS coordinates, we would
strongly prefer civic.

Secondly, if you do have a way to measure accurate lat/lon inside a
multistory building, you could get accurate altitude.

For the foreseeable future, if your device measures lat/lon, by all
means
send that.  If not, please send civic.  Never convert.  If you know you
are
on the 35th floor, in Suite 3510, Room 25, and you are looking at some
sort
of map that would tell you what the lat/lon is, you are converting.
Don't
do that.  If you have a WiFi mechanism that is triangulating, and the
only
reasonable output is lat/lon, please make darn sure your base station
location is accurate, and send geo.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf
Of Marc Linsner
Sent: Tuesday, July 12, 2005 4:59 PM
To: 'Henning Schulzrinne'; 'Tschofenig, Hannes'
Cc: 'GEOPRIV'
Subject: RE: AW: [Geopriv] Quick
randomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

Henning,

> 
> Given that we have very limited deployments (to put it 
> generously) of either civic or geo options, another path 
> forward to consider: Deprecate the use of floors in the geo 
> DHCP option and don't carry it in PIDF-LO unless it is part 
> of the full civic option. Logically, floors were always a bad 
> fit for the geo option, but necessary until we had others.
> 
> The geo floor option has known problems (cannot represent certain
> floors) and I can't picture a scenario where the floor (and 
> geo) is known, but the street address isn't. Having to merge 
> floor and country information from geo and civic just adds 
> complexity and error cases, for no increase in functionality.
> 

I can't agree with 'Deprecate the use of floors in the geo DHCP option
and
don't carry it in PIDF-LO unless it is part of the full civic option.'

With all the extraeous baggage associated with supporting civic
addresses,
why would you want to force the operator of a multistory building to
support
only civic???

Geo is simply easier/cheaper to support.

-Marc-

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: John Schnizlein <[email-masked]>
Date: Wed, 13 Jul 2005 07:57:06 -0400

The assumption in "So when people say X (longitude) Y (latitude) and Z 
(altitude or elevation) location coordinates, they are assuming the Z 
is as accurate as the X and Y, which is not so." is not made in RFC 
3825.  Instead, each of the dimensions includes a (bit-length) 
indicator of precision so that the different level of accuracy 
appropriate for each dimension is explicit.

Thank you, Marc, for reminding us of geography fundamentals.  It has 
been a while since this WG has considered the valid reasons for 
including the precision of each coordinate in the representation of 
location.  The need for an independent indicator of precision is true 
for longitude also.  We also noted that although degrees of precision 
map into meters of precision reasonably well where most people live, 
this is not true near the poles.  Of course, this doesn't matter unless 
your emergency call is from Antarctica.

Thank you for your good explanation of the good reason to include the 
altitude type of "floors" in the geographic location.

John

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Jul 2005 08:49:39 -0400

I'm aware of the geoid issue.

I had thought that if you had an accurate map, then you can convert a gps
coordinate to an accurate altitude (or to put it another way, if you have an
accurate map, you can convert a gps coordinate to an accurate point on that
map, and if the map gave you an accurate altitude of the ground, you can
convert the gps altitude to true altitude), because the geoid has a precise
definition, the measurement is accurate with respect to the geoid, and if
you know the relationship of the geoid to true position, you can calculate
the true altitude.

Have I missed something?  We would need accurate maps, of course.

When discussing location in buildings, geo is of little use to the final
location determination (it might be useful for relative locations like
distance).  In the end, you need civic.  We don't walk around buildings with
gps receivers, even if they worked there.  We use civic, always.

Geo is useful in the middle of a national park.  It's not useful in the
middle of the Sears Tower.  We have to deal with both, no doubt, but,
please, don't push geo unless you have something that actually measures
location and you can't get an accurate civic out of it.

Brian

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Tuesday, July 12, 2005 6:34 PM
To: Brian Rosen; Marc Linsner; Henning Schulzrinne; Tschofenig, Hannes
Cc: GEOPRIV
Subject: RE: AW: [Geopriv]

	

My two cents, 
Marc

Marc Berryman, ENP

-----Original Message-----

Brian

-----Original Message-----

Henning,

-Marc-

---

From: "Carl Reed OGC" <[email-masked]>
Date: Thu, 14 Jul 2005 13:54:36 -0600

All -

This is all more background discussion for use in this dialogue. It is in reference to the "geo" components of 3825.

 I am coming from my mapping/geodesy/GIS background. Also, to bring my discussion points into context, a while back I worked some on the OMA/LIF Mobile Location Platform (MLP) API. They had many similar discussions. As they were dealing with locations computed from the cell infrastructure (tower ID, triangular, assisted GPS, etc) and since they also have to deal with emergency management considerations, being able to express vertical and horizontal accuracy of an observation (such as location of a cell phone) was extremely important. They also went a step farther and defined mechanisms for expressing uncertainty ellipses. This is instead of the envelope being defined in 3825.

Now, I am not sure if the following can be incorporated in anyway in 3825 (size issues), but it sure would be nice - as Marc L suggests to have indicators of vertical and horizontal accuracy.  Would be nice to be to have information like horizontal accuracy of the lat/long value is +/- 50 feet.

Also, I posted an somewhat lengthy email earlier today on WGS-84, geodetic definitions, etc. Am waiting for the list moderator to approve. I apologize for that email as I know many of you are familiar with WGS-84 and its characteristics but I thought it relevant to provide terms and definitions and so forth for those not so familiar.

Continuing the discussion about having well defined terms and definitions and to provide context, what we are talking about is in terms of this particular discussion is an "observation". 
An observation feature binds the result to the (spatiotemporal) location where it was made. An observation involves a procedure to determine the value, which may involve a sensor or observer, analytical procedure, simulation or other numerical process.

An observation results in an estimate of the value of a property or phenomenon related to the target of the observation. Values are of various datatypes, including the primitive types category, quantity, count and boolean, time, location and geometry. The value normally requires a reference system to provide the context for its interpretation and valid operations on it. Common reference systems are the unit of measure for a quantity, a dictionary or "code space" for a category, a spatial reference system for location and geometry, and a temporal reference system for time values. An observed value may be semantically typed according to the phenomenon being observed or observable, sometimes called measurand. Observed values may have other properties, such as quality indicators.

3825 deals with the spatial aspects of the observation fairly well (aside from the accuracy discussion). However, 3825 does not deal with the temporal aspect. Temporal would also be nice as it provides additional context WRT the observation (when the incident was measured).

Quality indicators are metadata elements such as accuracy and precision. In both cases, these metadata elements could be extremely useful for (just one example) the end application that is providing "search" information to first responders. Knowing that a measurement is good to 50 feet in (x,y) would be extremely helpful.

That said, good precision does not necessarily mean the measurement is accurate! And lots of resolution does not necessarily mean good precision or accuracy. 

Precision is associated with measured values, for example, measurements of the concentration of a chemical in seawater. Precision is a measurement of how closely the analytical results can be duplicated. Replicate samples (prepared identically from the same sample) are analyzed in order to establish the precision of a measurement.  The precision is usually reported as a standard deviation or average replicate error. 

Accuracy should never be confused with precision.  Accuracy measures how close to a true or accepted value a measurement lies.  The classic, bull's eye cartoon, showing the difference between precision and accuracy, is shown below.  

So, once one then considers accuracy and precision in relation to the coordinate reference system in use (e.g. WGS-84) and the mensuration device, we can then establish estimates of precision and accuracy.

Sorry about the length of my emails, but being a geographer . . .

Cheers

Carl

---

From: John Schnizlein <[email-masked]>
Date: Thu, 14 Jul 2005 17:01:30 -0400

On Jul 14, 2005, at 3:54 PM, Carl Reed OGC wrote:
> ...
>  
> 3825 deals with the spatial aspects of the observation fairly well 
> (aside from the accuracy discussion). However, 3825 does not deal with 
> the temporal aspect. Temporal would also be nice as it provides 
> additional context WRT the observation (when the incident was 
> measured).

Nice to have should not delay getting rough consensus and running code.

Where expected to be most practical, the DHCP location option indicates 
the geographic location of the ethernet jack.  What purpose would be 
served by conveying when the calculations that installed this value in 
the (implicit) database were made?

> Accuracy should never be confused with precision.  Accuracy measures 
> how close to a true or accepted value a measurement lies. 

This strikes me as a distinction without a difference.  The definitions 
of the English words refer to each other.  It seems to me that what is 
relevant is the simple concept of significant figures of the location 
values.  When written in decimal, the scientific fundamental is called 
significant digits: the number of digits that are meaningful.  For 
binary representation, the number of significant bits is what is 
appropriate - and what RFC 3825 reflects.

John

References:

http://en.wikipedia.org/wiki/Significant_figures

The American Heritage® Dictionary of the English Language: Fourth 
Edition.  2000.

accuracy
SYLLABICATION:	ac·cu·ra·cy
NOUN:	1. Conformity to fact. 2. Precision; exactness. 3. The ability of 
a measurement to match the actual value of the quantity being measured.

precision
SYLLABICATION:	pre·ci·sion
NOUN:	1. The state or quality of being precise; exactness. 2a. The 
ability of a measurement to be consistently reproduced. b. The number 
of significant digits to which a value has been reliably measured.
ADJECTIVE:	1. Used or intended for accurate or exact measurement: a 
precision tool. 2. Made so as to vary minimally from a set standard: 
precision components. 3. Of or characterized by accurate action: 
precision bombing.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv