How does a Wi-Fi only tablet route on Google Maps when on the road?

[gregz]

Might be a built database of IP locations. I'm not sure if it can distinguish movement away from set location.

Greg

[gregz]

My one 3G tablet seems to have Superior WiFi sensitivity. Still trying to fix screen.

Greg

[Ragnusen Ultred]

Am Sat, 31 Mar 2018 09:21:14 +0200 (GMT+02:00), schrieb Libor Striz:

The Google Maps app was on iOS long before Apple Maps even existed.

As you noted, the iOS platform has far less map app functionality than does the Android platform (free offline routing-capable topographic maps being one which hits me hard since I hike a lot), in the case of *road* maps, while there is still always going to be far less app functionality on the iOS platform than on Android, the huge major players are the same (e.g., Google, CoPilot, Waze, Maps.me, Google Earth) but almost all the major and minor free online and offline no-registration map players simply don't exist on iOS - they exist only on Android.

I would have thought the Google Maps on iOS uses the same techniquest that it uses on Android, which is to utiltize whatever it can from GPS (which in this case, doesn't exist), and BSSIDs (if the WiFi is turned on), and any Internet-available geolocation information (which doesn't exist in this case unless the tablet is connecting fleetingly to wide-open unsecured access points), and, potentially, an offline BSSID:location lookup *inside* of the map database itself.

I suspect that the Google Maps app *is* making use of an offline BSSID:location lookup *inside* of the map database itself, but I don't know how to prove that just yet, and nobody here has provided any references that back up that assumption anyway.

[Ragnusen Ultred]

Am Sat, 31 Mar 2018 13:34:21 +0200, schrieb Libor 'Poutnik' St???:

Hi Poutnik, The map itself is different from the location, as you noted, but they are interconnected because we are talking about the "OK MAPS" download mechanism to obtain *offline* map data.

That offline map data may contain location data, such as the BSSID:location pair for every access point that many (most?) Android phones (not mine!) report to Google every minute of every day.

Hence, the location data is interrelated with the map data *if* Google stores that location data *inside* the *offline* map data.

Nobody seems to know (and yet, nospam always alludes to being an omnipotent genius but he can't tell you or he'd have to shoot you) if the BSSID:location data is stored *inside* of the offline "OK MAPS" downloaded map data.

[nospam]

false.

false

[Ragnusen Ultred]

Am Sat, 31 Mar 2018 14:05:11 +0200, schrieb Libor 'Poutnik' St???:

Hi Poutnik,

That's correct, I don't think that's necessarily the only correct answer since an app can maintain its own database of whatever it wants to maintain (e.g., some apps track in a tunnel where they use predictive algorithms).

In the case of the Google Map app, we all know that Google maintains a huge

*online* database of BSSID:location pairs for all access points that have been reported to it by most (not mine) Android phones.

Everyone on this thread already knows that it's *possible* that Google simply downloads that BSSID:SSID:location:dBM data to the portion of map that is downloaded for offline use with the "OK MAPS" mechanism.

The main question is how to prove whether that BSSID:location information is actually stored inside the *offline* Google Maps database which is downloaded by the "OK MAPS" mechanism.

I need to run tests, but the preliminary answer is "yes". It seemed to work best in populated areas moreso than in remote areas.

If that proves out, that would be a hint that Google Maps is using a previously stored local database of BSSID:location information, which, by the way, may be the main reason that Google offline maps *expire* after a month (actually 29 or 30 days, depending on the platform).

Preliminary results are that "houses" need to be nearby.

Whether or not that means access points is unknown, but what else can it be using since there is no GPS possible nor is there cellular data possible?

I think we all suspect that Google maps is downloading to the "OK MAPS" localized database the access point information that most Android phones (not mine) hand it every day, but the question is how to prove that is the case.

Ah. This is an interesting question, where the tracking was certainly done in an area that I frequent, since it was "in town", as I was leaving the library (where I had been connected prior).

The Google Map app does ask if it can get location information even when the user is not using the app, so, there "may" be something in your question for us to track down further.

Thanks for thinking of that, which nobody else had mentioned (AFAIR).

That is a good question. I will have to use the tablet in a location where it has never been before to ascertain that answer.

But, I think we all suspect it simply downloads the BSSID:location information, which is the same information I queried a long time ago to prove we could track someone's cellphone from our desktops at home.

You have to have a "key" which Google provides for free, and then you give Google *two* SSIDs (the reason for two, as I recall, is a rudimentary security mechanism), and then you give it a bogus signal strength, and if things match up for Google's liking, it hands back the location.

Of course, Google's own map app is probably not restricted to two SSIDs even as they would want as many as possible for their "triangulation" to work reasonably accurately.

That's is the conundrum.

How does the Google Map app manage to track you when the tablet has no GPS, no cellular, and the WiFi doesn't have the credentials to connect to anything but an access point which is wide open and just happens to be on the road, but you'd pass by that access point fleetingly so there isn't much time to connect to the net.

Most of us already suspect the "OK MAPS" mechanism downloads this BSSID:location information - but the question is how to prove that is the case.

That may very well be the case. And I appreciate that sentiment of yours, which is reasonable.

I think we all know of a good mechanism that might be what it uses; we just need to figure out how to prove that is the case.

This might be the case, but I doubt it (but it's always a possibility).

Yup. Apple does this all the time, e.g., with their modems where they have an iOS device with a fast modem and another with a slow modem, so they permanently slow down the fast modem just so that the user won't see the speed difference in the two devices.

But this would be permanent, and hence not useful to the app.

This might be the case. I don't see any evidence of this though, in this case.

This is an interesting example. So it might be the case here, but I doubt it since Occam's Razor tells us that the simplest solution is the most obvious one that we all know already, but which we don't yet know how to prove it's the case.

Q: How can we prove that the Google App "OK MAPS" mechanism downloads the BSSID:location information of local access points?

[Ragnusen Ultred]

Am Sat, 31 Mar 2018 09:18:53 +0100, schrieb Andy Burns:

Thanks Andy Burns for being purposefully helpful in that you bring up something that nobody mentioned which might be what the Google Map app uses to determine location on a tablet that has no GPS and no cellular capabilities.

I hadn't thought of iBeacons, so I looked them up.

The iBeacon method (mostly used for advertising purposes, it seems) uses Bluetooth (low energy), which, we noted in our initial tests, didn't seem to make a difference - but - they were only quick and preliminary tests of bluetooth being turned on or off.

Also, the iBeacon standard doesn't include specific location information, but it does allow each iBeacon to have a unique identifier.

Here is a description of the "typical" use model in that reference: "The typical scenario looks like this. A consumer carrying a smartphone walks into a store. Apps installed on a consumer's smartphone listen for iBeacons. When an app hears an iBeacon, it communicates the relevant data (UUID, Major, Minor, Tx) to its server, which then triggers an action. This could be something as simple as a push message ["Welcome to Target! Check out Doritos on Aisle 3!"], and could include other things like targeted advertisements, special offers, and helpful reminders ["You're out of Milk!"]. Other potential applications include mobile payments and shopper analytics and implementation outside of retail, at airports, concert venues, theme parks, and more. The potential is limitless."

[Ragnusen Ultred]

Am Sat, 31 Mar 2018 11:33:46 -0400, schrieb nospam:

You, nospam, always prove in every post that...

1. You lack technical competency to simply answer the question,
2. Hence, you merely guess & worse, you play endless silly semantic games,
3. All done with nary a single helpful well intentioned bone in your body.

[Andy Burns]

I know almost nothing about iBeacons, other than reading that iPads can use them for "micro-location"

[trader_4]

Are you sure that's correct for all apps, all cases? I can certainly see it being the case when GPS is there, for example. Or for cell triangulation methods. But is anyone sure that it extends to more exotic methods, eg identifying where you are by the wifi spots that are nearby?

I don't think that's necessarily the only correct answer

Then you really mean that you're questioning what he posted, not agreeing w ith it, because he said all apps get the location from the OS.

[nospam]

they're not just for ipads, but any bluetooth le capable device, including iphones and many (but not all) android devices.

ibeacons are mainly used to provide location information inside a building, often used in museums, for self-directed guides or just to find out more about whatever the visitor is looking at:

Utilizing iBeacon technology to automatically present visitors with audio, video, and text related to the artworks and building features nearest to them, Guggenheim Near Me offers a site-specific experience for visitors as they move through the museum.

they're also used at airports, sports arenas, stores and many other places.

[Ragnusen Ultred]

Am Sun, 1 Apr 2018 16:58:18 +0100, schrieb Andy Burns:

Thank you Andy Burns for being an adult, and for suggesting a possible bluetooth-related mechanism, which nobody had mentioned prior to your post so we all appreciate that you're thinking like an adult should, and that you're being purposefully helpful.

While nospam always essentially claims to be omnipotent (even as he guesses at everything and hence everything he says is virtually worthless), it's refreshing that both you and I are adult enough to admit publicly that we aren't all that aware of iBeacons.

That's refreshing that you're honest, as I am.

Having taken your suggestion seriously, I googled for what they're used for, and, for one out of three times, nospam actually guessed correctly, in that they're likely not what is being used here (but we should prove that also).

The reasons I think it's unlikely is that the iBeacons are short-distance bluetooth low power devices, which means they likely have less distance penetration than does a typical WiFi AP, and we don't know that Google "collects" iBeacons as part of their collection efforts from most (not mine) Android phones.

So your suggestion brings up a *great* question to ask Android users, which is the following: Q: Does Android have the potential to collect iBeacon bluetooth locations and send that information to the Google servers?

I don't know the answer to that question, where if the answer is that Google can and does collect that iBeacon information from Android phones, then it's a possibility that Google then puts that iBeacon location information in the offline OK MAPS database.

[Frank Slootweg]

[Lies and PKB deleted. Oops, nothing left.] [Repeat:]

First deliver on or STFU.

[Libor 'Poutnik' Stà ™Ã­à ¾]

Dne 01/04/2018 v 17:11 Ragnusen Ultred napsal(a):

Yes, it may be, I cannot refute that.

OTOH, GM are focused on online servicing, maps and AGPS. I do not think they suppose Wifi only tablet will be used for navigation.

[Libor 'Poutnik' Stà ™Ã­à ¾]

Dne 01/04/2018 v 17:37 Ragnusen Ultred napsal(a):

Try to delete ( or temporarily move ) offline maps and eventually purge known Wifi info if possible. Download an offline map with a border at some known and well defined and inhabitated area.

Or download an offline map for an area the tablet has never been before.

What happens with location tracking, if you are crossing the border outwards ? Will it stop ?

[Tekkie®]

nospam posted for all of us...

This ragamuffin guy is known to be a troll. Clare is quite familiar with him and I suppose it's your turn in the barrel with him. I forget most of his baloney but valve stem thread and harbor fright bead breaker and brake shoe friction are some.

[Ragnusen Ultred]

Am Mon, 2 Apr 2018 08:37:32 +0200, schrieb Libor 'Poutnik' St???:

Here is the result from my experiment today where the brand new iPad (with only WiFi & Bluetooth, but no cellular and no GPS) had *never* been in this area before since I live in the mountains and this is in the flatlands of Silicon Valley.

*Google Map App:* *Apple Map App:*

[Ragnusen Ultred]

Am Mon, 2 Apr 2018 08:22:03 +0200, schrieb Libor 'Poutnik' St???:

Hi Poutnik,

Thanks for being intelligent enough to try to add on-topic value to the technical topic, unlike many folks on this newsgroup who can't do that.

I haven't been responding because I didn't have any new information to add, but now I have the following new information to add to our knowledge.

This experiment today where I picked up a friend in San Jose to take her to the SJC airport shows a rudimentary tracking ability on the WiFi only iPad, using Google Maps only (not using Apple Maps, at least not yet).

Here are the empirical results on a WiFi-only tablet (no GPS or cellular):

*Google Map App:*

*Apple Map App:*

[nospam]

what it shows is your incompetence.

[Ragnusen Ultred]

Am Tue, 03 Apr 2018 23:21:32 -0400, schrieb nospam:

As you prove in *every* post, nospam...

1. You have no intention to ever be helpful, and,
2. You don't have the technical expertise to be helpful, and,
3. You just guess all the time, which makes you even less helpful (Because your guesses are as accurate as the monkey's guesses.)

While I know you can't possibly answer any technical question accurately because of that, I do have a technical question for the intelligent helpful posters on this thread, which is:

Q1: Why doesn't the Google Map re-route when it sees that I'm going in a different direction than the original route showed?

Notice that the blue-to-gray interface of the planned route *does* change, to match up (sort of) with the actual location.

For example, this is the starting point, where the white circle and red balloon are the starting and ending points at the time of the initial route plan.

As I start moving away from the start point, the white circle with the blue arrow is my location, which is tracked by WiFi access points, where you can see my location is moving to the west on highway 85 so you notice that the blue-to-gray interface of the route changes accordingly.

When I'm at the furthest point away from the route, but still it thinks I'm on highway 85 heading west, the blue planned route is still on highway 85.

But then notice what happens when it figures out I'm on highway 17, where it still thinks I'm heading west, but I'm actually heading north and where the blue-gray interface on the planned route changes drastically accordingly.

For the technically competent poster who intends to be purposefully helpful, do you have any purposefully helpful advice for us on why the offline-created route doesn't recalculate offline?