Referring to the discussion in #6 on MCC/MNC mode:
Currently the location provider does not send locations for cells that are not in the database.
mvglasow:
A somewhat more advanced approach when the cell is not in the DB would be to drop the cell ID and look just for the same MCC/MNC/LAC combination. Bigger cities have multiple LACs, thus the radius of a LAC should be somewhere in the 2–3 km range. The actual accuracy is best inferred from the database (half the longest distance between any two cells having that LAC, plus the average coverage radius of a cell). If the MCC/MNC/LAC combination still does not yield a result, try by MCC/MNC and finally just by MCC. (In some places, such as in the US, carriers use different MNCs in different regions, hence MCC/MNC may allow for a narrower radius than the MCC alone.)
Of course, accuracy will decrease dramatically if we don't have a cell ID. However, even an inaccurate location will still be useful for some purposes: MCC/MNC/LAC would result in a radius of 2–3 km, which is fully sufficient to get the local weather forecast or a list of nearby events. In small countries (such as Andorra or San Marino) even the MCC would be sufficient for that purpose.
rtreffer:
However it's not as easy to give a good accurancy as you might not know all towers inside the LAC and you'd thus have to be a bit more conservative. Another idea was to check the "tower density" and reduce the radius if the density is high....
Maximum distance between any two known cells of the same MCC/MNC/LAC plus estimated cell coverage range would provide a lower boundary for the error radius. We could get an upper boundary in the following way:
For each cell with a matching MCC/MNC/LAC, get the nearest cell with same MCC/MNC but a different LAC, and add it to the set (it should now contain all cells with same MCC/MNC/LAC and their nearest non-matching neighbors).
Now, again, find the largest distance between any two cells in the set. That provides the upper boundary for the error radius.
That computation may be a bit expensive, but you might precompute that and add it to the database (as MCC-MNC-LAC-location-accuracy tuples).
This works for MCC/MNC/LAC combinations because within the same MCC/MNC, no two LAC coverage areas should overlap. It won't work for MCC/MNC because we typically have multiple overlapping MNC coverage areas of the same MCC. Here we can just establish the lower boundary. Again, we might add MCC-MNC-location-accuracy tuples to the DB.
Going by MCC alone, we can entirely sidestep this issue by taking advantage of the fact that most MCCs are country codes. There are a few exceptions, though:
Test networks (MCC 101, some use regular MCCs with a special MNC)
International services (MCC 901)
Contries using the MCC of a different country (e.g. Kosovo uses the MCC of Monaco)
In the case of a 1:1 match between MCC and country, we could just get the shapefiles for each country and translate these into location-accuracy tuples. The location would be the gravity center and the accuracy (as per the Android definition) would be the radius of a circle around the gravity center which contains 68% of the country's surface. Usefulness depends on size of the country – accuracy can be from ~3,400 km for Russia to less than 4 km in Nauru.
Referring to the discussion in #6 on MCC/MNC mode:
Currently the location provider does not send locations for cells that are not in the database.
mvglasow:
rtreffer:
Maximum distance between any two known cells of the same MCC/MNC/LAC plus estimated cell coverage range would provide a lower boundary for the error radius. We could get an upper boundary in the following way:
That computation may be a bit expensive, but you might precompute that and add it to the database (as MCC-MNC-LAC-location-accuracy tuples).
This works for MCC/MNC/LAC combinations because within the same MCC/MNC, no two LAC coverage areas should overlap. It won't work for MCC/MNC because we typically have multiple overlapping MNC coverage areas of the same MCC. Here we can just establish the lower boundary. Again, we might add MCC-MNC-location-accuracy tuples to the DB.
Going by MCC alone, we can entirely sidestep this issue by taking advantage of the fact that most MCCs are country codes. There are a few exceptions, though:
In the case of a 1:1 match between MCC and country, we could just get the shapefiles for each country and translate these into location-accuracy tuples. The location would be the gravity center and the accuracy (as per the Android definition) would be the radius of a circle around the gravity center which contains 68% of the country's surface. Usefulness depends on size of the country – accuracy can be from ~3,400 km for Russia to less than 4 km in Nauru.