RE: [Geopriv] ResponseTime

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Thu Aug 30 2007 - 10:59:45 EDT

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