Re: Location quality

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


Hi Martin,

I believe that the argument for keeping lastPosition was purely for a  
javascript optimization.  You could quickly get at the last position  
that the geolocation implementation had seen without having to wait  
for the callback of watchPostion or getCurrentPosition to fire.  The  
position object, of course, will have a time attribute that the  
developer can test for.

I do agree that the method has problems.  In addition to the  
information being out of date as you suggest, the call is synchronous  
putting a significant burden on the user agent UI (modal dialog are  
bad). There was a compromise given by Aaron suggesting that we can  
return failure if the user has never previously allowed a geolocation  
request from the given URI.

I continue to see this method as, at least, not required.  I would  
like to see data that using lastPosition is significantly faster than  
using getCurrentPosition (especially in relationship to everything  
else a geolocation web application will be doing).  From a UA point of  
view, i think we should speed up the browser, not add workaround APIs  
for poor performance.

Doug Turner

Received on Friday, 24 October 2008 03:28:50 UTC