984982 - MLS: Add info on WiFi APs, CellTower, GPS fix, when available from FFOS

Status: RESOLVED DUPLICATE of bug 1154435

(Firefox OS Graveyard :: Wifi, defect)

Description

[Ravi Dandu]

Mozilla Location Service provides location services to devices. It can be improved by crowsourcing WiFi APs, CellTower, GPS fix when User approves the collection of this data. FFOS devices can request the user for this permission.

Comment 1

[Doug Turner (:dougt)]

Hanno,

When I startup geolocation services on a device, I will make network requests to MLS.  I will also start up the GPS.  When I do get a GPS fix, I can begin sending you requests (using the same endpoing) that include GPS information such as:

{
   "wifiAccessPoints":[
      {
         "macAddress":"ff-ff-ff-ff-ff-ff",
         "signalStrength":-75
      },
      {
         "macAddress":"ff-ff-ff-ff-ff-ff",
         "signalStrength":-79
      },
      {
         "macAddress":"ff-ff-ff-ff-ff-ff",
         "signalStrength":-91
      }
   ],
   "cellTowers":[
      {
         "radio":"gsm",
         "mobileCountryCode":"310",
         "mobileNetworkCode":"410",
         "locationAreaCode":56921,
         "cellId":4522229
      }
   ],
   "time":1395466118000,
   "lat":37.xxxxxxxx,
   "lon":-121.xxxxxxxx,
   "accuracy":27,
   "altitude":19,
   "altitude_accuracy":27,
   "heading":0,
   "speed":0
}

The response to such a request is still the best location that you can muster -- which is probably exactly what I sent you.  Would this work for you?

Comment 2

[Doug Turner (:dougt)]

Attachment: 0002-Bug-984982-Enable-support-for-uploading-gps-data.-r-.patch

Comment 3

[Kan-Ru Chen [:kanru] (UTC+9)]

Comment on attachment 8395161 [details] [diff] [review]
0002-Bug-984982-Enable-support-for-uploading-gps-data.-r-.patch

Review of attachment 8395161 [details] [diff] [review]:
-----------------------------------------------------------------

Nit: extra white spaces

::: dom/system/gonk/GonkGPSGeolocationProvider.cpp
@@ +145,5 @@
>  #if DEBUG_GPS
> +  printf("*** nmea info\n");
> +  printf("timestamp:\t%lld\n", timestamp);
> +  printf("nmea:     \t%s\n", nmea);
> +  printf("length:   \t%d\n", length);

Why did change this? Is it needed?

Comment 4

[Hanno Schlichting]

I've created a new server-side issue to track this: https://github.com/mozilla/ichnaea/issues/162

Our preferred approach is to expose this under a new API endpoint `/v1/geosubmit`. The geolocate endpoint will continue to be available and strictly adhere to the Google defined API. The geosubmit one will use the same structure / JSON ids but include the additional lat/lon bits and return back the estimated position (likely echoing back the sent lat/lon). We'll define and document the exact API and report back.

Comment 5

[Hanno Schlichting]

I wrote a first draft of the service side spec at https://gist.github.com/hannosch/53664603ed52d35f680e. It looks extremely similar to your patch.

I used the same names as the coordinates interface, so latitude and longitude are spelled out in the data submission. I think that's the only difference to your patch. The response format will be the same as before (for the geolocate API).

The API endpoint will be https://location.services.mozilla.com/v1/geosubmit?key=%API_KEY%. It's not implemented yet, so don't merge this quite yet.

Comments so far?

Comment 6

[Hanno Schlichting]

Oh, and I wrote out `timestamp` as well, instead of `time` to be closer to the DOMTimeStamp API. Having a column or variable named time was also painful, as it conflicts with SQL data types and Python's time type. So timestamp is a bit longer, but makes for less ugly server code.

Comment 7

[Hanno Schlichting]

The new geosubmit API is deployed. We are still missing docs to explain all the little details.

It's a superset of the geolocate API. So you can send valid geolocate requests against this new endpoint and get normal position lookups back.

You can also use it to send a single observation, exactly like the geolocate API, but also send along latitude, longitude, accuracy and any of the other supporting information like altitude and timestamp. It supports a couple new data points like speed, heading and signal to noise ratio for WiFi networks. If you use the API in this second way, the service will echo back the lat/lon/accuracy you sent it. This assumes the lat/lon is based on a current GPS position, and as such best represents your current location. Certainly better than anything the service could come up with.

As a third option, you can also send a batch of observations along. In this mode you don't get a position estimate back, as this mode is used for sending large chunks of data gathered over a longer period in the background.

I'll update the bug once we get the docs in shape.

Comment 8

[Chris Peterson [:cpeterson]]

Doug: what is the status of B2G system-level stumbling? Ravi says you have already completed the client-side work.

Comment 9

[Hanno Schlichting]

The client side work was a minimal patch which sent along the last known GPS coordinates with a MLS query. But we have since added things like the request cache to avoid unnecessary outbound requests. So if we have a GPS fix, we wouldn't do a MLS request anymore.

What's really needed is the equivalent of libstumbler for FxOS. Something that is a bit smarter about when and how often to collect data, store things locally for a while and than send that collected data in a batch to MLS. We haven't begun any of that work, though https://github.com/clochix/FxStumbler might help some.

Comment 10

[Hanno Schlichting]

A new fresh take on this is happening in #1154435.

Comment 11

[:garvan]

Ravi: this bug is marked as a duplicate, we are only using bug 1154435 to track this feature