1023647 - [Tarako] Geolocation from SIM data is inaccurate

Status: RESOLVED WORKSFORME

(Core :: DOM: Geolocation, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: logcat.txt

1. go to Vallejo
2. place SIM in SIM slot 2 of Tarako
3. turn on device
4. turn off wifi
5. go to m.here.com in the browser
6. hit the dot to locate where you are once connected

Expected: geolocation is somewhat accurate
Actual: it indicates I'm out in San Francisco (~ 31 mile ) difference
"location":{"lat":37.787406,"lng":-122.455637},"accuracy":46008}

Note: T-Mobile Sim with data usage turned on

Gaia      fe0c0bcb572f23ea17170d5e9cac9f1a2415d6a6
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/0e56308ce67b
BuildID   20140610112755
Version   28.1
ro.build.version.incremental=eng.cltbld.20140610.145241
ro.build.date=Tue Jun 10 14:52:49 EDT 2014
Tarako

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

noming as wifi data might not be readily available in isolated places.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

This might be a separate bug: turning on wifi after this to try to get a correct location doesn't correct the location.  [might be because there was no movement]

Comment 3

[:garvan]

In the log it has a cell tower and a wifi scan, so the device-side is ok. MLS (the server-side) lacks good data for this query, it does however report a 46km uncertainty. The problem with such a large uncertainty in a mapping app is that the accuracy radius (typically a blue circle around your dot) is so large that you would have to zoom out to see it, or it is so large that the software doesn't bother drawing it.

WIFI GEO: sending {"cellTowers":[{"radio":"gsm","mobileCountryCode":"310","mobileNetworkCode":"260","locationAreaCode":275,"cellId":23991}],"wifiAccessPoints":[{"macAddress":"58-6d-8f-a2-e7-5f","signalStrength":-53},{"macAddress":"14-5b-d1-b7-27-10","signalStrength":-84}]}
*** WIFI GEO: gls returned status: 200 --> {"location":{"lat":37.787406,"lng":-122.455637},"accuracy":46008}

Comment 4

[:garvan]

comment #2
Based on the accuracy (46km), the wifi SSID(s) you are getting are not in the MLS database, and aren't contributing to geolocation.

Comment 5

[:garvan]

This bug just reminded me, I need to investigate/file a bug for why we only get one cell tower when scanning. That is very bad for geolocation.

Comment 6

[Hanno Schlichting]

This sort of accuracy is expected for Tarako devices. The aim is to provide city / metropolitan area level (~30 miles / 50km) accuracy to most users. Even that is still a good ways off and there's multiple approaches we are following to get there. These approaches are separate from the Tarako device and software running on it.

I don't see an actionable bug here, and would close this as "worksforme".

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

close as wfm base on comment 6

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I'm not sure if I understand the measure of saying 30 miles off is ok, when there's only 1 cell tower that's being scanned when there could be multiple cell towers being scanned.  I've had a 50 miles off course being out in the country before.  I am trying to understand how to write a better bug.  What's the margin where something is wrong?  30 miles is ok?  What about 50?

Perhaps what Garvan is researching may fix the issue...

Comment 9

[:garvan]

I think this depends on 
Bug 1010356 - Network location provider should try to send neighboring cell data
Which is in the RIL that I am aware of.

Comment 10

[Hanno Schlichting]

Tarako devices only support 2.5G networks (GSM/EDGE). In these networks the phone only sees the full cell identifiers for the serving cell. This is a limitation of the GSM standard, which didn't yet have a concept of soft-handover. So no matter what we do, we cannot use more than a single cell for location look-ups in Tarako devices.

For later B2G versions we are looking at capturing neighboring cells, as per the bug Garvan mentioned. This needs an extension in the RIL layer and then code to use the new RIL feature in our location provider. Currently on B2G you can only scan for neighboring cells by breaking any active voice and data connections. Non-intrusive background scanning isn't available yet. This sort of scanning isn't available on all chipsets and it's unclear which of the chipsets used in our devices support it. As a comparison these same API's where only introduced in Android 4.3 and are only actually working on a minority of the latest high-end Android phones. So it's more of a mid/long-term play and not something that will improve the situation in the short term.

In your specific example, we had no position estimate for your serving cell. So we did fall back on a estimate of the location area position. A single GSM cell can be up to 35km in radius, or rarely up to 120km in extended range mode. A location area consists of many GSM cells and can be many hundreds of kilometers in size. In addition we use GeoIP, but for mobile connections this is often only accurate to the country level, as there's only very few gateways between the mobile operators network and the public internet.

So there's no code changes we could have done on the device to use more information. The only way to improve the estimate is by getting a better position estimate for all the cells of all the operators worldwide. This is something we are working towards with a mixture of business deals, community engagement and letting our own devices with GPS sensors contribute back data. But this is a never-ending activity and not something that will be resolved at any point in time.

That's why I closed this specific bug. There's nothing wrong here, except for a lack of data. And there's no accuracy level we can actually promise to deliver in all cases. We aim for a city level estimate, as that's possibly to achieve based on a single cell or GeoIP. Based on WiFi or smaller cells in populated areas we might do better.

Comment 11

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Thank you for the explanation, Hanno.  This helps out a lot to understand the issue.