1. This explanation seems to ignore the timestamps that are stored along with the hotspots/towers data. What do the timestamps represent? The time when the cache was downloaded onto the phone?
2. Speculatively, the way this seems to work is, that the phone identifies a tower, say, with ID12345. It then looks up the crowdsourced database for the tower with this ID, and queries it for all towers/hotspots within X miles radius. The result of the query is logged into the consolidated.db file, along with the current timestamp.
3. I don't know about the 100 miles number, but for me, in an urban setting, it certainly seems to be accurate upto approximately a mile or so, that together with the timestamp, gives a reasonably accurate picture of where I've been, and when.
This explanation seems to ignore the timestamps that are stored along with the hotspots/towers data. What do the timestamps represent?
As a devils advocate, if I'm a developer writing some sort of logging routine I'm including a timestamp without even thinking about how or why it would be used. Its a logger its supposed to have timestamps ;-)
2. Speculatively, the way this seems to work is, that the phone identifies a tower, say, with ID12345. It then looks up the crowdsourced database for the tower with this ID, and queries it for all towers/hotspots within X miles radius. The result of the query is logged into the consolidated.db file, along with the current timestamp.
3. I don't know about the 100 miles number, but for me, in an urban setting, it certainly seems to be accurate upto approximately a mile or so, that together with the timestamp, gives a reasonably accurate picture of where I've been, and when.