Bug 83433 - Fallback Offline cell data based geolocation
Summary: Fallback Offline cell data based geolocation
Status: RESOLVED MOVED
Alias: None
Product: GeoClue
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Geoclue Bugs
QA Contact: Geoclue Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-03 11:46 UTC by Elad Alfassa
Modified: 2018-05-06 14:36 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Elad Alfassa 2014-09-03 11:46:06 UTC
Mozilla released their cell database in public domain, https://location.services.mozilla.com/downloads

The files are small enough to include with all GeoClue installations, so in theory you could use them as fallback for when you do have a cellular modem but don't have network (ie. if you exceeded your data quota).

It should only be used as fallback because if you do have network it would still be better to query Mozilla's servers, as they'd be more up-to-date and thus more accurate.
Comment 1 Bastien Nocera 2014-09-03 11:49:41 UTC
The diffs are small but the original data is 32 megs compressed.
Comment 2 Elad Alfassa 2014-09-03 11:51:53 UTC
I just noticed that myself and was about to comment in the bug. Yeah, it might be too big, and the usecase is fringe enough as it is.

I guess I should probably close this bug then...
Comment 3 Bastien Nocera 2014-09-03 12:03:49 UTC
Supporting it might be useful though. The way I would implement it would be to populate a database with that data and offer a web service with an API that's compatible with the Mozilla one. Possibly even using the Mozilla server sources.

Let's wait and see.
Comment 4 Zeeshan Ali 2015-03-03 16:10:35 UTC
(In reply to Bastien Nocera from comment #3)
> Supporting it might be useful though. The way I would implement it would be
> to populate a database with that data and offer a web service with an API
> that's compatible with the Mozilla one. Possibly even using the Mozilla
> server sources.
> 
> Let's wait and see.

Mozilla recently broke records with the amount of data they now got. Its really huge now and I don't think this would be feasible anymore.

I don't know why you were proposing web service etc but I think the point of this bug is to keep a local cache. I have been thinking about adding local caching of queries but:

1. WiFi strengths vary over time even if you don't move your laptop so we'd have to cache a lot of queries and it might go out of hand easily.

2. How do you find your external IP? There are more than one ways of achieving that (NAT, UPnP) and none of them reliable enough to just implement one of them so we'll be adding quite some complication if we want to do it right.
Comment 5 Bastien Nocera 2015-03-03 17:53:47 UTC
(In reply to Zeeshan Ali from comment #4)
> (In reply to Bastien Nocera from comment #3)
> > Supporting it might be useful though. The way I would implement it would be
> > to populate a database with that data and offer a web service with an API
> > that's compatible with the Mozilla one. Possibly even using the Mozilla
> > server sources.
> > 
> > Let's wait and see.
> 
> Mozilla recently broke records with the amount of data they now got. Its
> really huge now and I don't think this would be feasible anymore.
> 
> I don't know why you were proposing web service etc but I think the point of
> this bug is to keep a local cache.

And a web service can run locally. You should know, having work on UPnP ;)

> I have been thinking about adding local
> caching of queries but:
> 
> 1. WiFi strengths vary over time even if you don't move your laptop so we'd
> have to cache a lot of queries and it might go out of hand easily.

A local cache would certainly be useful, and given the precision of Wi-Fi triangulation, maybe it would be a good idea to look at the Mozilla server code to see what level of variance in Wi-Fi signal they expect. If we get the same result when the Wi-Fi signal quality drops by 1%, that's something.

> 2. How do you find your external IP? There are more than one ways of
> achieving that (NAT, UPnP) and none of them reliable enough to just
> implement one of them so we'll be adding quite some complication if we want
> to do it right.

I don't think that the original bug is something that we want to pursue though.
Comment 6 GitLab Migration User 2018-05-06 14:36:54 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/geoclue/geoclue/issues/50.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.