Also, many devices didn't have built-in GPS (the original iPhone, for one), so how do you run location services?
There were, at the time, several crowd-sourced sites of Wifi AP locations, which devices could use to estimate location from Wifi RSSI. So making a private, comprehensive database of the same is a pretty obvious task for a company that is either trying to catalog the world's information, or that wants to do something with location-based services on mobile devices in the future.
Beyond that, getting an approximate location first is useful, even if you do plan to use GPS. It takes up to 30 seconds to download the ephemeris for a GPS satellite over the air (assuming no uncorrectable errors), after first locking on to the frequency and PRN of each satellite. Cold-start times of 5 minutes under realistic urban conditions were not unusual. Do you want to wait 5 minutes for the map to load on your phone?
However, knowing your approximate location (from nearby APs) narrows the PRN and frequency search space (and you also know which satellites are above the horizon). With ephemeris data downloaded over the internet, every cold start can be as fast as a warm start: Just a couple seconds.
There are plenty of reasons to think that Google intended to war drive from the beginning.
Just by downloading recent data without any prior knowledge of your location (aside of maybe determining which continent you're on, which most of the time is already known because of which cellular network you're connected to), you can usually easily reduce that to around a minute with no WiFi, BT or cellular triangulation necessary - and that's on a cold start; hot start will be instantaneous anyway.
Have you ever used Garmin back in the day, or a USB GPS receiver? It can take a minute or so to get enough initial information to deduce a location at a low datarate. AGPS gets some or all of that information (I'm not sure) from another source, usually a cell phone network so that first location is deduced much faster. Modern phones have GPS receivers, but use AGPS. If a modern phone has no network signal, it will still get a GPS signal, it will just take longer to get the first location.
Not to be confused with other technologies such as skyhook [2], which was used in iPhone 1 and other older devices to fuse radio signal strength, known wifi hotspot locations, etc as a kind of pseudo-GPS. It was only relevant for a few years.
That looks like it'll either be much lower resolution than Google's timeline (manual or 15 minute checks) or will consume a lot more battery life than I'd be happy with (due to relying on GPS, turning it on for a location fix every minute).
Given wireless is turned on 24/7 for most people, it seems to me that a better method would be to cache APs that the user sees, so that if the same set of APs (or a significant subset there-of) are visible there is no need to ask for the GPS parts to be turned on. Obviously that is more work and there are some complexities to account for¹²³ but this is how Google's timeline uses little power. They have an centralised international database of AP locations (slurped while collecting images for Maps/Streetview and no doubt other sources) but that isn't really needed – you can just keep a list of APs seen recently and where on each users own device4.
---
[1] APs move or get renamed
[2] Assuming APs are identified by SSID there will be some names that are the same in multiple locations
[3] Some APs constantly move by design, i.e. those on public transport.
[4] Not having a central DB just means each device doesn't immediately benefit from the location cache avoiding GPS use when visiting a new area, but each device will quickly build a view of local APs for any area it enters.
A warm start is actually typically faster than 30 seconds, averaging closer to 20 seconds. Additionally, almost all fixes using smart phones are hot starts. This is because smartphones use assisted GPS, they download almanac and ephemeris data not from the GPS network itself (where they are broadcast every 12.5 minutes and 30 seconds, respectively) but over a data network, in seconds. Similarly, smartphones have a pretty good idea of where they are already, because they keep track of their positions historically and they use cell tower triangulation as a secondary location system. From a hot start a GPS receiver could get a fix in only a handful of seconds, potentially.
This is extremely interesting. One thing I didn't understand was how this location database is being built. Is Google collecting GPS signals and WIFI hotspots so that the two can be associated to pinpoint your location? If so, does that mean Android phones are periodically sending your location back to Google? Do Apple, Nokia, RIM, and Microsoft do the same thing?
I don't think they require it - the data in question allows it to optimise startup otherwise it can take many minutes to successfully acquire enough data to compute your location
Actually it depends on the signal, whether WiFi is turned on, etc. I used to build mobile apps for luxury clubs who wanted to know which members were arriving at the club (e.g. to go ahead and start getting their golf clubs ready. First world problems, I know). The GPS data we get access to for both Google and Apple includes lat/lng plus a radius in meters that represents the accuracy of the measurement. Depending on the different factors it can be over 100m or as little as about 5m.
So, presumably if I bought one of their phones and turned it on, I would wait ten minutes to get a GPS fix instead of it using a almanac and working out the lat and long of three cell towers at certain signal strength?
Does anyone know if it's possible to get at this info from user side ? Some API access? sounds fun
Pinpointing a phone requires three satellites. With A-GPS, it can be accomplished with two satellites and cell tower data and/or WiFi info.
Official Apple statement:
Calculating a phone’s location using just GPS satellite data can take up to several minutes. iPhone can reduce this time to just a few seconds by using Wi-Fi hotspot and cell tower data to quickly find GPS satellites, and even triangulate its location using just Wi-Fi hotspot and cell tower data when GPS is not available (such as indoors or in basements). These calculations are performed live on the iPhone using a crowd-sourced database of Wi-Fi hotspot and cell tower data that is generated by tens of millions of iPhones sending the geo-tagged locations of nearby Wi-Fi hotspots and cell towers in an anonymous and encrypted form to Apple.
https://www.businesswire.com/news/home/20110427005749/en/App...
Because on devices with only WIFI the only way to give you 'GPS' like data is to scan for nearby wifi access points. There are several big databases in the sky that know about a great many Access Points and when your laptop says 'i see these 10 APs with this amount of signal' it can figure out where you are.
Wasn’t there this thing that Google collected a list of SSIDs using their Google Maps cars, and that gave them “good enough” geolocation using passive WiFi scanning, which was much less battery intensive and faster than GPS?
Google offers (or at least used to) an API which takes 4 or more WiFi Mac addresses (part of what is broadcast) and will return an approximate location. I think the data is collected by the street view cars. If you move house and take your WiFi modem with you it causes confusion, hence the need for at least 4 different devices.
The sampling rate seems slower than it used to be.
The authors wrote a client to ask Apple’s WiFi Positioning API for the locations of random AP addresses. Enough of the random addresses were known to Apple’s location database that it returned real location data. Apple’s API also returns the addresses and locations of 400+ other nearby APs. That enables iOS devices to do faster and offline content geolocation in the same region.
> Apple’s API will return the geolocations of up to 400 hundred more BSSIDs that are nearby the one requested. It then uses approximately eight of those BSSIDs to work out the user’s location based on known landmarks.
> In essence, Google’s WPS computes the user’s location and shares it with the device. Apple’s WPS gives its devices a large enough amount of data about the location of known access points in the area that the devices can do that estimation on their own.
I thought AGPS was just the download of almanac/ephemeris data from a server on the internet. I didn't think it had anything to do with figuring out location using visible wifi APs or anything like that. Sure, you need an internet connection to download the AGPS data, but that could also be your cellular data connection and not wifi.
For one, it can speed up finding your location if GPS is cold. Maps will start zeroing in by using wifi while GPS is heating up and then it gets the precise location from gps when it is available.
Googlers correct me on this, but from observation, that's how it seems to work.
As I understand it, roughly knowing your position lets it get a lock on enough satellites faster, because, given position and time, it knows where they're supposed to be.
Also, I believe that part of the reason why Google wants that SSID info is because they can later use it for location purposes as well, making that initial position determination more accurate than with just the cell towers alone. In general, the more environmental data they can correlate with accurate GPS coordinates, the better they can predict location when GPS is unavailable.
There were, at the time, several crowd-sourced sites of Wifi AP locations, which devices could use to estimate location from Wifi RSSI. So making a private, comprehensive database of the same is a pretty obvious task for a company that is either trying to catalog the world's information, or that wants to do something with location-based services on mobile devices in the future.
Beyond that, getting an approximate location first is useful, even if you do plan to use GPS. It takes up to 30 seconds to download the ephemeris for a GPS satellite over the air (assuming no uncorrectable errors), after first locking on to the frequency and PRN of each satellite. Cold-start times of 5 minutes under realistic urban conditions were not unusual. Do you want to wait 5 minutes for the map to load on your phone?
However, knowing your approximate location (from nearby APs) narrows the PRN and frequency search space (and you also know which satellites are above the horizon). With ephemeris data downloaded over the internet, every cold start can be as fast as a warm start: Just a couple seconds.
There are plenty of reasons to think that Google intended to war drive from the beginning.
reply