Re: [Geopriv] Location measurement error

["Brian Rosen" <br at brianrosen.net>]

Sorry for the delay, but I am still wallowing

> > 2. When pressed to deal with it, all watchers want confidence set to at
> > least 95%.  It would be okay with them, at least today, if it was fixed
> > at
> > 95%.  Watchers HATE two measurements with different confidence.
> > Allowing
> > specification of uncertainty is completely unnecessary, fix it at 95%
> > and
> > all watchers will be at least content (they won't be happy until it's
> > 99%).
> 
> I agree on the different confidence - given the non-linear relationship,
> managing two variables is a pain.
> 
> Everyone wants 100%, but fail to acknowledge the tradeoffs.  I think that
> I can see where you are going - you are making points about what people
> _want_.  I can appreciate that.
Well, it's more of a requirement.  It's also very related to "they ignore
it".  Since the data they get has variable confidence, the uncertainty
doesn't mean the same thing.

I'm specifically suggesting, somewhat naively, that there not be a variable
for confidence, but it simply be set to 95%.  

The reality might be that the text in all the documents say:
Confidence MUST be set to 95% except for certain existing devices which will
not currently provide measurements with such a value.
> 
> > 3. Watchers specify uncertainty in meters.  That means, to you,
> > whatever the
> > shape that has the same error value for x and y and a different one for
> > z.
> > They don't want any shape that doesn't look like that.  There is no
> > need,
> > from a watcher point of view, to specify uncertainty any other way.
> 
> The point that people understand the expression of uncertainty as "within
> x metres" is relevant.  But what they want is no uncertainty, failing
> that, they want simple.  I've describe how to accommodate these wishes,
> while not ignoring the real constraints:
> <http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty>
Yeah, pretty nice piece of work.  I do need to send you some comments, but I
still like it a lot.

You could reasonably ask, if the users only want simple, is it better to
push the calculations described back to the LS?

> 
> > 4. Existing systems don't allow the watcher to specify confidence or
> > uncertainty.  They simply report what the owner of the measuring system
> > decides to report.  The notion that the error spec goes in either a
> > request
> > or a filter is a novel idea, and I'm not sure it will be implemented.
> 
> Now you've lost me.  Specifying target uncertainty is not especially
> novel, we've been handling it for almost 10 years now.  Quality of
> position parameters are a fixture of most existing LCS protocols.  They
> get pushed down the whole chain.  For example: Application -> GMLC -> MSC
> -> RNC -> SAS - all the protocols have QoP parameters of various sorts.
In the protocols with which I am familiar, you cannot specify uncertainty,
you can only receive it when you get a measurement.  OTOH, I have limited
experience outside the emergency call system.  In that system, both the E2
and ALI protocols have a way to return uncertainty, but no way to request a
specific uncertainty (or confidence).

> 
> I've explained why I think that adding an "error spec" to filters is not
> useful.
Yeah, but we are disagreeing on that point still

> 
> > 5. All PSAPs and all responders in the U.S. have a very well defined
> > value
> > for confidence and uncertainty for a filter: within 100 meters (x and
> > y),
> > 95% of the time.
> 
> If you are talking FCC mandates, you are still getting them wrong.  In any
> case, these numbers cannot be applied to an individual call - they are
> statistical figures that are applied across a large set of calls.  Again,
> this falls into the "want" basket.
It's the only thing we have.  This is the source of endless frustration to
me and the PSAP folks.  We want to put in "6 cm uncertainty, 100%
confidence".  It's the only spec we actually have.   We have a regulation
that says 100 meters, 95% of the time.  What do you want a PSAP to put in
the request?

This is the nut of the problem I have.  The user goal is (nearly always)
infinite precision, 100% confidence.  If the system didn't deliver them
location that met some purchase, legal or other spec, they wouldn't be using
it in the first place.  There IS no other spec other than "best you can do".

Clearly, as we have discussed several times, you sometimes have an
expressable time constraint (best you can do in 10 seconds).  I can't think
of any application where there is a meaningful value that could be put into
a request other than "best you can do", but you insist we come up with some
numbers.

I'd really like to get off this merry go round.  Your end says "tell me your
spec".  My end says "best you can do" or the spec is zero uncertainty and
100% confidence is all we got.

> 
> > 6. With a minRate, you cover the case of "best you can do in x
> > seconds".
> > Without a way to specify error in some way, you can only say that.  If
> > you
> > want "best you can do", there is no way to say that.  If you want to
> > say
> > "within 10 meters is good enough" there is no way to say that.
> 
> Actually, with a minRate, you specify that the LS update you every x
> seconds.  Unless there is a way for the LS to push the LG, you only get a
> better estimate if the LG happens to get one.  That is my point - and one
> that you seem to be reinforcing.  I'm officially confused now.
I refuse to get drawn into the difference between an LS to watcher and LG to
watcher and/or LS to LG to watcher.  We may need another protocol for LS to
LG.  So far, we don't have one.  When we are in that circumstance, we ignore
the difference between LG and LS; assume a proprietary protocol, or a single
box.  The watcher tells the LS, the LS tells the LG.  

We talked about a similar problem in a NENA call today: if you use the
enter/exit boundary filter, at what rate should the LG take measurements to
give you the desired result (how long after you entered/left the boundary
are you willing to wait to be told you entered or left)?  I suggest that you
can use minRate as a hint, and perhaps we should say that.  We could also
have a specific parameter for the purpose.



> 
> > 7. Event notification is a much more acceptable way to get a
> > measurement
> > that takes seconds to compute.  The error spec in the filter is much
> > more
> > useful that the error spec in the request.  If you want an error return
> > that
> > is effectively "you'll never get one with this filter" I would be okay
> > with
> > that, but see below.
> 
> OK, say that I subscribe for location information.  You are saying that
> specifying a filter is better than cramming some extra parameters in the
> subscription request.  I can't contest that.  It misses the point, but in
> and of itself, the argument is sound.
> 
> The problem with a filter (or indeed anything related to the subscription
> and only the subscription) is that whatever you do there, you have no
> influence over the information.  You get whatever the LG generates.
> Without some influence over the location generation, anything you do is
> essentially pointless.  Unless the LG is given instructions on what to do,
> you get whatever you get.  Assuming that the LG is independently motivated
> to generate an extremely accurate result isn't going to work.  The model
> can't assume that the LS has some secret means to influence the LG.
> Unless you specify a means for the LS to do so, which I'd be very
> interested in.
See above

> 
> > 8. The biggest problem with all of the mechanisms that have so far been
> > proposed is that they don't include any way for a watcher to determine
> > what
> > an achievable error could be from a particular LG (or LS, since that is
> > what
> > it deals with).  Until you come up with a way for the watcher to find
> > what
> > the measurement mechanism's achievable error spec is, you don't have a
> > useful set of mechanisms.
> 
> That's because noone knows what the achievable error is.  It's not related
> to the "mechanism", but to the specific situation: time of day, wind speed
> and direction, battery levels, indoors/outdoors, access technology, what
> the owner had for lunch, solar winds, etc.

Okay, so what you are saying is this:
We haven't a clue what we can do.  
The app has no clue what you can do.
The app wants zero error and 100% confidence
The app wants the best you can do (with perhaps a time constraint)

What the heck do you want it to say?

Oh, let's see, let's try 6cm and 99% confidence.  Gee, no answer.  Darn.

Okay, let's try 6cm and 95% confidence.  Gee, no answer.  Darn again.

Okay, let's try 1m and 95% confidence

You wouldn't go the other way:

Okay, let's give it 2km uncertainty and 10% confidence.  Oh, great, an
answer.  

I wonder if it will do better.  Let's try 1km and 30%...

That's the real, honest situation.

It's the reality for pizza hut
It's the reality for 1-1-2
It's the reality for turn by turn directions
It's the reality for "where is the nearest Starbucks"
It's the reality for "tell me when my kid goes outside the mall"

What the heck do you want the app to do?

> 
> > It occurs to me to ask if "within a 100 meters, 95% of the time" is
> > actually
> > the same as a circular error shape with a 100 meter radius and a 95%
> > confidence.  It sounds like the same thing.  Is it exactly the same
> > thing?
> 
> Yes.  I'm surprised that this realization took so long, given that the
> exact statement has been made many times in the past.

Actually, you just said it wasn't the same thing above.  You said that 100 m
95% of the time (the FCC mandate) was not the same as 95 meter circular
radius uncertainty with 95% confidence.  You said it was a statistical
calculation over a large number of measurements (implying it's not the spec
you use for a single measurement).

Okay, so if you are a U.S. PSAP, what DO you ask for?

Brian

_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv