/
26 April - GPS comparison testing with Google Maps

26 April - GPS comparison testing with Google Maps

Owned by Diarmid Mackenzie
Apr 26, 2020
2 min read

Following on from my discoveries yeasterday, I wanted to see how Google Maps compared with Safe Paths in GPS accuracy.

25 April 2020 - Real-world GPS test #1
25 April 2020 - Real world GPS #2

My testing was pretty simple: in teh same positions that I had tested previously, open up Google Maps, and check my reported location for accuracy.

What I saw was the following:

  • When you open up Google Maps for the first time, it’s initial indication of your position is not very accurate: can be 50m or more out.

  • Within <10 seconds, the blue dot moves to a much more accurate location - it then seems to be accurate to within about 10m.

  • Enabling disabling WiFi does seem to impact the assessed position, but the impact is not huge, usually < 10m. So far, enabling WiFi appears to make things more acurate, rather than less accurate.

  • So far my testing was mostly done on phone A from the previous reports.

 

What I infer from this is that:

  • GPS data available to mobile apps can be accurate enough for Safe Paths' needs (~10m accuracy).

  • However, it appears that the first data reported back to an App on the GPS API tends to be much less accurate, 50m or more off.

  • To get sufficient accuracy, an App must wait for the GPS to train which may take 5-10 seconds.

  • Once tis period has passed, the GPS data seems to respond accurately & immediately to my movements.

This aligns well with the info here:

GPS Accuracy issues / Limitations

“It can also take a GPS receiver up to several minutesto perceive its location when first turned on or brought outdoors.”

I’m not seeing a delay of several minutes (probably I am not in the worst possible conditions), but I am seeing a delay of a few seconds before I get accurate info.

I don’t know enough about teh app implementation, but I wonder whether we are currently just takign the first reported GPS info back that we get on the API, and assuming that’s correct. That would certainly be consistent with the jump GPS data I see in my tests.

I will raise a GitHub issue for discussion with Dev.