Poor Accuracy of Locate Widget

[MichaelOakeson]

We are using the Locate Widget in our app and we have noticed that the locate widget isn't very accurate at times. 

We tested using the sample Locate Widget from the ArcGIS app and we received similar results that we wish to document and would like to petition the developers to make this more accurate.  

Sorry there is no sound in the video as I'm just doing a screen recording with my iPhone, but I'm walking up at a college campus and using the Locate Widget, near the end of my attached video I tap the widget, it takes me close to where I'm at, and then tap it again before it actually gets to where I'm at.

We are using this Locate Widget in our new app. In our old app, we were using just HTML Geolocation API and built it out ourselves and it seems to be more accurate than the current widget.  We would love to use ArcGIS API for our app, but again, its accuracy is a little lacking.

Would appreciate any help on this.

[AndyGup]

Hi @MichaelOakeson the widget actually uses the browser's geolocation API to get the current position. If there's an accuracy issue it is most likely related to the device and the browser implementation of the geolocation API, accuracy can also be affected by your cellular carrier, your WiFi settings and bluetooth settings. If you are testing and seeing a difference in location between the geolocation API and the widget's reported location then please open a support ticket so we can get a thorough evaluation of the issue. 

[BobCowling2]

@AndyGup I believe this post by @MichaelOakeson has been overlooked. There are indeed issues with the accuracy of your web GPS widgets. I have tested them vs Mapbox GL JS (which also uses the browser's geolocation API) on the same phone, same location, same browser, and have gotten far superior results. The Mapbox one is how I would expect a GPS tracker to behave. The ESRI track widget bounces all over the place and cannot seem to maintain a consistent location. It is interesting because the WebAppBuilder on JS API V3 does not seem to have these major issues like the v4 one does. @KellyHutchins 

[AndyGup]

Hi @BobCowling2 thanks for reaching out, can you please open a support ticket? That way they can gather all the necessary information from your set up. The bouncing around might be related to spurious location values not being filtered out. 

[BobCowling2]

@AndyGupI do not seem I have permissions to open a ticket but I did put in a bug report on this matter. Otherwise, we have a few threads in this community describing this issue over the past few years. 

[AndyGup]

Hi Bob, do you know if your organization has a tech support contract, and if there is someone else that can open a ticket for you? I'm not sure what a bug report is. This is one of those instances where we need to get tech support involved to capture detailed information about your configuration, your phone, etc.

[BobCowling2]

Hello @AndyGup I believe someone did put in a support ticket on this for me at our organization.

Do you believe this is not an issue with the widget itself but my phone? So far I experienced this on three different phones I have tested since last week. 

I did some testing this weekend on both a Pixel 4a and Samsung Galaxy S10, both in Google Chrome browser. Same issues on both phones with the GPS being inaccurate and not tracking my precise location correctly. On the pixel 4a I did notice when I started my RunKeeper app with the GPS active, the GPS location on the track widget was very accurate and followed my location perfectly. 

When trying Mapbox on both phones, the locations were correct once again. So the question is, if both use the geolocation API why is Mapbox GL JS showing accurate results and not the ESRI track widget?

We really need a solution for our application that will follow the user around. I have read some of your blog posts, and from what I understand the Geoloaction API can be very accurate. 

edit: Also tried this with OpenLayers geolocation (https://openlayers.org/en/latest/examples/geolocation.html). Was getting accuracy of 4 meters at times. Location was where I would expect it to be and tracked perfectly. Direct comparison to ArcGIS JS Geolocation was off by what I would say was at least 50 feet. So I am not sure what the problem is here exactly. I would be interested to know if you have a sample geolocation track widget with accuracy readout somewhere I can try without having to put it together myself. 

[AndyGup]

Hi @BobCowling2 Can you get us the support ticket number? Thanks for the additional info. We aren't sure yet where the issue is occuring. We compared code between our Widget and Mapbox GL JS. The only difference is we set high-accuracy by default: https://developers.arcgis.com/javascript/latest/api-reference/esri-widgets-Track.html#geolocationOpt.... 

[ZacharyHart]

@AndyGup  Any updates on this? 

[AndyGup]

> I believe someone did put in a support ticket on this for me at our organization.

Hi@ZacharyHart  I haven't seen a support ticket, you might want to double check on your end. We took a close look at the Locate Widget and confirmed it is using the browser's built-in W3C Geolocation API via the getCurrentPosition() method. Because the widget only acts as a pass-thru for the geolocation results, the points you are seeing are exactly what is provided by the browser's own API. The best way to get better geolocation capabilities are to either use the native device operating system APIs or build additional software functionality to help normalize the raw location results.

TL;DR;

Differences in geolocation could potentially be explained by variations in how the Geolocation API options (maximumAge, timeout, enableHighAccuracy) are configured on the widget via the geolocationOptions property. Generally speaking, the Geolocation API does a decent job for consumer-grade geolocation use cases. However, here are some examples of things that affect accuracy:

* GPS variations - not all chips are the same, plus GPS satellite signal strength fluctuates and is affected by your surroundings (hills, mountains, buildings, power lines, trees, storm clouds, car roof, etc)

* OS and browser variations in geolocation implementation

* browser or device caching of geolocation data

* nearby WiFi routers, cellular service trilateration since these signals also fluctuate continuously

* Use of a VPN

* Combinations of all of the above