Yes - accuracy for systems is generally a statistical metric. Most
obviously for wireless systems but even for wireline systems - there's
an error that results from bad data in things like wiremaps. There's no
established paradigm for communicating "accuracy" in the latter
environment however.
All applications, that are optimally implemented (I want to say "all
decent applications"), need to consider the possibility that the
determined location is not correct. What this involves depends on the
nature of the application. It might decide it's OK to completely ignore
this characteristic of the location service, it might use a GUI and
display a disclaimer/warning, or it might have a sophisticated dialog
for doing sanity checks and resolving ambiguities with the user... or it
might address the issue through completely manual procedures that are
part of the overall application space but not solved by the software.
Making a blind assumption about the accuracy or wilfully ignoring
additional information like uncertainty boundaries without considering
the implications is a sign of a "non-optimal" application.
Cheers,
Martin
-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Friday, 31 August 2007 12:11 AM
To: Stuard, Doug
Cc: GEOPRIV WG
Subject: Re: [Geopriv] ResponseTime
The point has been made before, but it probably bears repeating.
There are at least two kinds of uncertainty/accuracy specifications,
namely for a particular technology and for a particular point.
Take a technology that produces a 100 m accuracy with 90% confidence.
Taken naively, this implies that every point is somewhere in a circle
with diameter 100 m.
Unfortunately, this error is not the same everywhere. Some locations
will presumably see a much larger error, possibly with non-zero mean
error. For example, if a timing error is absolute (+/- 1 ns), it
affects short distances much more than longer ones. Or multipath
makes a particular location always seem further away than it really is.
Thus, you could easily get a situation where the location for a
particular place is *always* outside that circle, even though the
technology, on average, performs as advertised. I don't know if
anybody has studied this problem in detail to see how much this
matters in practice.
http://www.comsoc.org/pci/private/2000/oct/bulusu.html shows an
example of this. ("The localization error is lowest at the position
corresponding to the centroid of the region and increases toward the
edges of the region.")
http://www.gmat.unsw.edu.au/snap/publications/lib_etal2005d.pdf
http://www.ieee-infocom.org/2004/Papers/55_5.PDF
also show behavior like that.
Btw, http://www.locatemodelcities.org/documents/
LOCATE_Final_Report.pdf is of some relevance here. In particular, it
contains definitions for terms.
Henning
On Aug 29, 2007, at 9:57 AM, Stuard, Doug wrote:
> In practice, "uncertainty" is usually taken to mean "accuracy",
> although, as pointed out, accuracy is really a combination of
> uncertainty and confidence. Given that most folks (and I'm talking
> about call takers, not system administrators) think "accuracy" and
> not the uncertainty/confidence continuum, confidence is worse than
> of no use, it is confusing, so it is either not provided or is
> suppressed. Nevertheless, the reported "accuracy" (uncertainty)
> should be based on an underlying common confidence value (even if
> it is not displayed or otherwise used).
>
>
>
> While it may be true that accuracy/uncertainty is not used TODAY by
> individual service providers, do we want to ensure that it can
> NEVER be used??? As familiarity with geolocation concepts grows,
> and as more automated systems are deployed (i.e., those that
> understand the confidence/uncertainty tradeoff and plot big (or
> little) circles on maps), greater use of the information can be
> expected.
>
>
>
> Or maybe not.
>
>
>
> The point I'm trying to make (and to get back to the original
> subject) is that by providing optional time and "accuracy" values
> (actually, uncertainty at some a commonly agreed to confidence
> level), with defined meanings similar to those I suggested earlier,
> the flexibility to adapt to a wide range of applications (emergency
> and otherwise) and technological advances can be accommodated going
> forward.
>
>
>
> All we need is an agreement as to what the confidence level should
> be (oh, and world peace, too).
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
------------------------------------------------------------------------------------------------
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
Received on Thu, 30 Aug 2007 09:59:45 -0500
This archive was generated by hypermail 2.1.8 : Thu Aug 30 2007 - 11:02:36 EDT