RE: Location quality

Hi Andrei,

Answers inline.  I'll probably follow up with more information.

> -----Original Message-----
> From: Andrei Popescu [mailto:andreip@google.com]
> Sent: Friday, 24 October 2008 7:01 AM
<snip>
> >
> > Does the absence of the timeout leave it up to the browser?  A
> recommended default would help so that the lazy users can be protected
> from themselves.  I'm going to suggest that 5 seconds will get you good
> location, even using GPS if you have assistance data; but you can pick
> any value.
> >
> 
> I understand. I think we could recommend a default, but we should not
> enforce it. On some mobile phones, it takes 30 seconds to warm up the
> GPS and return an answer. Wireless links suffer from very high latency
> so connecting to a server to translate some GSM cell data into a
> location may take quite a long time. These devices would need a larger
> default timeout, that may not make sense on other systems (e.g.
> laptops that use WiFi for positioning).

That's all that you can do with a recommendation - implementers will have more information to base their default on.  But part of setting a recommendation is setting of web developer expectations.  In my experience, if you can't get a response from a server in 5 seconds, you've already lost your user (There is some variability in the number, depending on which study you refer to).  Of course, the final decision on how much this matters rests with the web developer and their usability analysis.

(I can see that we have a vastly different experience of location services.  If you want reliable results, a timeout of 12 seconds works for assisted GPS; but we've have a chipset here that is able to get a fix in much less time, say 4 seconds.  If you are "warming up" GPS for autonomous, the absolute minimum time required is 30 seconds because you need to download ephemeris at 50bps.  Signal acquisition is a much smaller part, hence the advantage of assisted GPS.)

> > The concept of a timeout on watchPosition is interesting - if the
> browser has determined that the position has changed, why would it take
> the same time to acquire another position?
> 
> Well, say you are using GSM cell or WiFi data for positioning. An
> implementation can then detect very easily that the position has
> changed by simply observing that these signals have changed. But it
> then needs to ask a server to translate the new set of signals into a
> (lat, long) coordinate pair. This second step may take quite a bit of
> time or fail completely (e.g. network congestion, server is down,
> etc).

I promised more discussion on watching :)  The problem is that location is continuous.  Watching presents a range of problems.

To say that you are using detection of a change in wireless transmitter as a basis for detecting a change in location is making a very large set of assumptions.  At the level of abstraction presented to the browser, this might not be visible.  For instance, a GPS device can enter a low-powered tracking mode that continuously tracks a position.  All you get is a result.  In this case, timeout for a single request could be 30+ seconds, but when watching, the timeout is zero.

For GPS tracking, this results in frequent "changes", every second or so, depending on the GPS implementation.  And even if you aren't moving, a GPS device can give false positives as the satellite constellation moves and the radio environment changes.

The problems with continuity lead to a range of compromises: if you need to poll, how often do you poll?  If you have a continuous feed of data, how often do you provide notifications of changes?  There's a real danger of setting arbitrary constraints to solve the problem that interfere with legitimate use cases.

I suspect that you aren't concerned about throttling the rate of up-calls.  However, you do need to ensure that developers are prepared for high rates of notifications.  If their experience only extends to static devices and they build an app that sends an async request each time that location is updated, then they might be overwhelmed when they get a notification every 100ms from a particular provider.

> > In this case, the timeout takes on a slightly different meaning: i.e.
> please let me know when the position changes, _within this time of the
> change_.
> 
> In my example above, the timeout would denote the maximum amount of
> time the implementation would be allowed to spend trying to connect to
> the server and translating the new set of location signals into a
> location object.

The problem that I have with the example, and solution, is that it is based on a set of assumptions that only work in a subset of cases.

There are methods for measuring location that are able to provide better than cell-level accuracy.  The problem is that there needs to be a trigger that initiates measurement.  If the target moves within a cell, using a change in wireless transmitters to detect a change doesn't work.  My view is that you make the trigger implementation specific, but you need to provide the implementation with enough information to allow it to make the right decisions.

<snip>
> > 3GPP have a lot of experience in this area and they have many
> protocols that can be learned from.  In place of enableHighAccuracy,
> instead specify a target uncertainty (notice that I didn't use the word
> accuracy).  Different values for horizontal and vertical uncertainty
> are common.
> 
> Ok, we actually have considered a similar solution but found it very
> problematic, as well. Here is a good explanation:
> 
> http://lists.w3.org/Archives/Public/public-

> geolocation/2008Jun/0094.html
> 
> Having said that, I do agree that we need a better solution here. It's
> just that nobody suggested anything better so far. If you know a
> better solution or happen to know other groups who have struggled with
> a similar problem, I'd be very happy if you could provide some
> pointers.

I'll draw a picture that is similar to Aza's and get back to you.
 
> > Another problem relating to quality that you will have to overcome is
> caching.  This is particularly common for location.  Another parameter
> that specifies how old location information can be will force the
> location provider to bypass any caching and actually generate
> information.  3GPP call this maximumAge and you can specify this in
> relative or absolute time.
> >
> 
> Yep, this is also an item that has been debated quite a bit. Here's
> the case so far:
> 
<snip reading>
> 
> So far we felt that having an explicit lastPosition property is less
> ambiguous and can be used to solve the same problem. If there is new
> evidence against this, we should reconsider.

I tend to agree that lastPosition isn't that helpful.  In fact, it's totally pointless; location information is _always_ out of date.  By its very nature, by the time that you've measured it, it's history.  But, as a matter of degree, we can usually handle a small time shift.

The problem is that the final position that you get in your request might be the product of caching somewhere along the line.  Maybe the GPS is sleeping right now and it just gives you where you were 3 seconds ago - probably not a big deal; or maybe you got your location from a network source using radio timing 2 minutes ago; maybe your DSL provider told you where you were yesterday.  In some cases, that cached information might be fine.  You REALLY don't want to prevent caching altogether, because it's a fundamental mechanism that makes location affordable.  Attempting to mandate that location be measured for every request is an exercise in futility - I can guarantee that you will be ignored.

What we want to do is signal to the location provider when old location isn't OK.  That's the crux of the suggestion.  Maximum age signals to the provider that your three-day-old cache isn't good enough.  Of course, there is always the option to ignore this - the timestamp will make this evident to applications that really care.

Regards,
Martin
------------------------------------------------------------------------------------------------
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]

Received on Friday, 24 October 2008 00:51:10 UTC