geolocate appears to be giving geoip results in when only cell tower data is available

[crankycoder]

I'm pretty sure that this is a bug in ichnaea. Here are screenshots showing my location lookup and the JSON bundle that I uploaded.

[sshvetsov]

I was just looking into this. I think the problem is with JSON request object generated in org.mozilla.mozstumbler.service.stumblerthread.datahandling.StumblerBundle.toMLSGeolocate() and org.mozilla.mozstumbler.service.stumblerthread.scanners.cellscanner.CellInfo.toJSONObject().

Google Geolocation API request (since Ichnaea Geolocate API points to Goolge as reference) is specified something like this:

{
  "radioType": ...,
  "cellTowers": [
    {
      "cellId": ...,
      "locationAreaCode": ...,
      "mobileCountryCode": ...,
      "mobileNetworkCode": ...
    }
  ]
}

While MozStumbler generates something like this (note the location of "radioType"):

{
  "cellTowers": [
    {
      "cellId": ...,
      "locationAreaCode": ...,
      "mobileCountryCode": ...,
      "mobileNetworkCode": ...,
      "radioType": ...
    }
  ]
}

I played around with the "geolocate" API and it seems to work the same as "search" API if "radioType" is in the root of the JSON request. Presence or absence of "radioType" in cellTower object doesn't seem to have an effect on result.

[crankycoder]

I'm moving this back to the stumbler client.

[hannosch]

The issue is partly on the service side. The geolocate API supports either putting the radioType at the top-level. Or putting a key called "radio" inside each cell record. That is an undocumented workaround that is specific to some versions of Firefox OS.

What we should be accepting, to match the geosubmit API, is a radioType key inside each cell record.