W3C home > Mailing lists > Public > public-geolocation@w3.org > August 2014

Re: GeoLocation API: 1. Source type of information / 2. Information from specific source type

From: Ravikumar Dandu <rdandu@mozilla.com>
Date: Tue, 12 Aug 2014 15:10:00 -0700 (PDT)
To: "Michael[tm] Smith" <mike@w3.org>, Prandstetter Josef <j.prandstetter@mysynergis.com>
Cc: Giridhar Mandyam <mandyam@quicinc.com>, public-geolocation@w3.org
Message-ID: <991400513.2229411.1407881400154.JavaMail.zimbra@mozilla.com>
  There is field "accuracy" in the output (http://dev.w3.org/geo/api/spec-source.html#accuracy). This represents the accuracy of the location returned upto the 95% confidence level. You can use this field to make decisions: what area maps to download etc.
  About the requirement to specify the technology to use: from a user point of view the "Accuracy needed" (EnableHighAccuracy) seems to be more appropriate than the technology to use. Depending on use case, App should specify the accuracy needed eg: a navigation app should enableHighAccuracy, while a Weather app need not enable high accuracy.  

There are a few reasons for App not specifying the technology to use:
1) Environment plays a role in accuracy: GPS works well in open sky scenarios, but deep indoor may not give a location at all. WiFi or Cell based location works better there. 
2) New sensors are being added to improve location: Accelorometer, Gyroscope are contributing to location apart from GPS, WiFi, Cell, IP lookup. Soon Pressure sensors etc may be added too. Writing an app which specifies the underlying technology to use will make the app outdated soon. 
3) Location API is better to be technology agnostic. The underlying algorithms combining the technologies may be more efficient to do at the platform (or lower layers) rather than each app doing that. Platform can theoretically make better decisions on optimizing between time for first fix, accuracy and power.
For your specific scenario where you are getting 15m-75m accuracy using EnableHighAccuracy versus 2-3m for GPS, are you comparing with a different GPS unit, or a native app on the same device?  
    a)If the  native app (like a native maps application on device) is returning more accurate than HTML5 app, then we should look at the browser implementation of the geolocation API. Are they calling the GPS interfaces properly? Is the implementation returns location prematurely before GPS has time to get to highest accuracy? Try using WatchPosition() instead of GetPosition() to remove time out of the issue.
    b)If the comparison is with a different device, then it could be a host of things, including the HW on the device/GPS enablement/browser implementation etc. 
    Better to first make sure HTML5 app is returning the similar accuracies as native app, by keeping the device common.

Ravi Dandu
Firefox OS

----- Original Message -----
From: "Michael[tm] Smith" <mike@w3.org>
To: "Prandstetter Josef" <j.prandstetter@mysynergis.com>
Cc: "Giridhar Mandyam" <mandyam@quicinc.com>, public-geolocation@w3.org
Sent: Tuesday, August 12, 2014 5:20:31 AM
Subject: Re: GeoLocation API: 1. Source type of information / 2.  Information   from specific source type

Prandstetter Josef <j.prandstetter@mysynergis.com>, 2014-08-12 11:09 +0000:
> Currently we wonder if the GPS receiver of the underlying hardware is used at all.
> When benchmarking the Geolocation API location accuracy (using a web page
> running in IE10/11) against the native GPS receiver location accuracy
> referencing a well known lat/lon position we found out remarkable
> differences
> *         Geolocation API accuracy 15m-75m
> *         GPS Accuracy 2m-3m

You're specifying the enableHighAccuracy option, right? And if so, is it
giving you any greater accuracy than you get without it specified?

If specifying enableHighAccuracy isn't getting you accuracy greater than
15m-75m in some particular mobile UA, that sounds more like an implementation
deficiency that needs to be corrected in that UA -- not a spec deficiency.


Michael[tm] Smith http://people.w3.org/mike
Received on Tuesday, 12 August 2014 22:10:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:08 UTC