Re: Location quality

Hi Martin,

Sorry for the slow reply on this.

On Fri, Oct 17, 2008 at 7:24 AM, Thomson, Martin
<Martin.Thomson@andrew.com> wrote:
> I notice from a reading of the current draft that the topic of accuracy and quality is a contentious one.
>
> There is a tension between simplicity (and the usability and clarity provided) and use cases that require additional flexibility.
>
> My view is that PositionOptions, as an optional parameter, is a reasonable compromise.  It's important to get the contents right though.
>
> The timeout parameter is the most important aspect of this.  Without a parameter like this, there is no reliability in the interface.  Allowing unbounded time doesn't work, but setting arbitrary limits in the browser leads to the exclusion of some really useful positioning methods.  Big tick.
>
> 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).

> 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).

> 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 subtlety might be lost on your audience.
>

I think you're right, we probably need a slightly different wording
that makes this clearer (perhaps adding an example?).

> The enableHighAccuracy flag gets a big cross.  Such a thing is awfully ambiguous and subjective.  Better to be specific.
>

Yes, enableHighAccuracy is a "known issue" :)

> 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.

> 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:

http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0060.html
http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0061.html
http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0063.html
http://lists.w3.org/Archives/Public/public-geolocation/2008Jun/0064.html

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.

All the best,
Andrei

Received on Thursday, 23 October 2008 20:01:17 UTC