hannosch
commented
9 years ago We have this idea on our backlog, but so far there are very few users actually using the service. So this hasn't made it high up on our priority list. You don't only need users of the service here, but you actually need a combination of some stumbler users in an area to get the reference points and then some non-stumbler users in the same area to find new networks and attach them to the existing reference points.
The only significant number of real users we have are Firefox OS users in India, but those are almost all in areas where there are no WiFi networks at all and only a single cell connection at a time.
For getting data from indoor environments we also want to look at using a GPS fix from outside + some relative motion data from the compass and accelerometer to get us good positions. At least for a period of some minutes this might be good enough. I think the client side team will look at this sort of thing once we are confident in those sensors as part of the "did the device move at all" work they are currently doing. Unfortunately there are many different and buggy sensors out there in Android devices.
VolMi
As a stumbler I always think it's a pity that we will never be able to get all the cells and WiFis. This is mainly because we are too few people and also fundamentally, because a lot of WiFis in larger buildings are out of GPS reach. E.g. I was in a hospital a few hours ago with >100 (!) WiFi APs visible simultaneously but far away from any free sky.
I was wondering if ichnaea does already make use of Geolocate requests to actually enhance its own database? Call it a passive submit if you will.
The idea is simple: Assume that ichnaea has entries A and B in its database and a user makes a Geolocate request providing cells/WiFis A,B,C,D,E… If any cells in this request are still unknown it would be plain silly to completely ignore their existence and their vicinity to A and B: A further Geolocate request with cells/WiFis D,E,F,… would fail if they have not been actively stumbled.
So I would suggest (if it's not done already) to build something like a passive database. It is fed with info from plausible and successful Geolocate requests for cells that do not yet exist in the main database. Further requests with no hit in the main database could then fall back to the passive data. In case of WiFis, this is propably even very accurate.
If Mozilla's Geolocation endeavour is successful, there will always be a much larger crowd of Geolocate users than feeding stumblers.