Re: [Geopriv] RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy?

This conversation peaked my interest. I have just looked at RFC-3825. Not
having been privy to all the original discussions and decisions, I am a
fresh set of "eyes" looking at this document. I think what we have here is
a failure to communicate due to ambiguous semantics in 3825. I may be
wrong in this perception, but . . .

My interpretation is that what is being defined is a uncertainty shape in
which the location of the device falls. As such, it is not truly a point.
A point in Euclidean geometry has no size, orientation, or any other
feature except position. This is the basis of the ISO/OGC definition for a
point geometry.

Take the following example. We draw a point by placing a dot with a
pencil. This dot may have a diameter of 0.2mm, but a point has no size. No
matter how far you zoomed in, it would still have no width.

What this discussion is really about is the fact that a point geometry,
whose location is defined by a lat/long coordinate, also has properties.
These properties include estimates of accuracy and precision. Very simply
stated: If the actual value is 4.321 and you say that it is 4.30, then you
are precise to the first decimal place but inaccurate by .021. There are
also properties of error and uncertainty. All these four properties are
very well defined in the literature. For example see:
http://scidiv.bcc.ctc.edu/Physics/Measure&sigfigs/B-Acc-Prec-Unc.html

So, what I would suggest is that perhaps 3825 be modified to very clearly
disambiguate the semantics of the terms being used. I suspect that what
"resolution" is really referring to is a description of the uncertainty of
the measurement. The point being measured falls somewhere in the area of
certainty. The shape of this area (yes, it is an area/polygon) actually
has a pretty strange shape if one transforms from lat/long to some other
coordinate reference system, such as State Plane.

Regards

Carl

> So you are saying that the examples in the appendix of RFC-3825 are
> wrong, and that RFC-3825 cannot and never will describe an area?
>
> It didn't die in Geopriv, I was waiting for you to actual come back with
> an explanation, what you did was write back an email that was totally
> irrelevant to the discussion. So I am still waiting!
>
>
>
>
>
>> -----Original Message-----
>> From: John Schnizlein [mailto:jschnizl@cisco.com]
>> Sent: Sunday, 10 September 2006 10:49 AM
>> To: Winterbottom, James
>> Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org
>> Subject: Re: [Ecrit] Location information in emergency
> sessioninitiation,
>> need for time and accuracy?
>>
>> What part of "geographic location of the client" is unclear to you?
>>
>> It is beyond comprehension how this could be interpreted as a area
>> rather than a point, with the resolution of the measurement of that
>> point explicitly included in the location information.
>>
>> Why is this old argument being rehashed in the ecrit WG when if
> finally
>> seemed to die (mercifully) in GeoPriv?
>>
>> On Sep 9, 2006, at 6:11 PM, Winterbottom, James wrote:
>>
>> > So I am going to ask you. Point, or area?
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 11 Sep 2006 04:36:02 -0400 (EDT)