On 17. Jul 2017, at 17:09, Ben Withers <manicbe...@gmail.com> wrote: > Now my only issue is fallbacks, which I assume can be enabled by editing the > api_key table. Other than setting allow_fallback to 1, what else should be > set (e.g. fallback_name, fallback_url, etc.)?
There is some help text available on the database model, at https://github.com/mozilla/ichnaea/blob/master/ichnaea/models/api.py#L49 <https://github.com/mozilla/ichnaea/blob/master/ichnaea/models/api.py#L49> Basically a fallback is a way to tell one ichnaea instance to call out and get help from a different location service. This is only done for API keys that have allow_fallback = 1 set and if the ichnaea instance itself doesn't find a position with a "good enough" quality score, or in other words if it doesn't find a position at all or one of dubious trustworthiness based on its own data. The score is based on things like sample count, number of times the network has moved (blocklist), age of the data (modified) and also time difference between creation date and modification date. This accounts for networks which were seen dozens or hundreds of times, but only on a single day. The fallback columns could be set to something like: fallback_name: mozilla fallback_url: https://location.services.mozilla.com/v1/geolocate?key=some_key <https://location.services.mozilla.com/v1/geolocate?key=some_key> fallback_ratelimit: 10 fallback_ratelimit_interval: 60 fallback_cache_expire: 86400 The cache expire setting would cache the response values of the fallback service in the local Redis instance for a day (86400 seconds). This avoids repeated calls to the external service for the same queries. The rate limit settings are a combination of how many requests are allowed to be send to the external service. It's a "number" per "time interval" combination, so in the above example 10 requests per 60 seconds. The rate limit is tracked per fallback_name and the cache is global and shared across all fallbacks. So if one configures multiple API keys with all the same fallback values, they share the same information. API compatible services are other ichnaea instances (like MLS), Combain's location service and even Google's. Not all of these allow local caching of results and they have different rate limits according to the contracts one could have with them. > And just out of interest, does Ichnaea handle timing advance parameters well? > As in, does it make a significant improvement to include them in requests in > addition to signal strength? Currently ichnaea ignores timing advance data. I think it's accepted in the public APIs and sent through the analysis pipeline, but simply ignored in there. When we did most of the development of the positioning algorithms, timing advance data was not actually gathered and send to us by any of the phones out there. For GSM it wasn't available in the Android APIs (only added recently in API level 26, https://developer.android.com/reference/android/telephony/CellSignalStrengthGsm.html#getTimingAdvance()) <https://developer.android.com/reference/android/telephony/CellSignalStrengthGsm.html#getTimingAdvance())>. For LTE it was in theory available, but almost no phones actually send us that data. I think most of the time the cell modems and firmwares simply didn't report this data up to the Android OS layer. Hanno _______________________________________________ dev-geolocation mailing list dev-geolocation@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-geolocation
