On 14.02.2016, at 00:16, Felix Baumann <[email protected]> wrote: > A reason for that could be geoblocking, though I think they removed that part > of the code again > (it would be good, if Hanno could shed some light on this)
We did indeed remove that part of the code a long while back. We don't look at the IP address of the uploader anymore as it lead to too many rejections of perfectly good data. Turns out GeoIP databases aren't all that trustworthy, even if all you want to know is the country. Debugging this sort of situation is unfortunately tedious, as there's no real way for anyone but me to do it. For cell information someone else could download the entire public aggregate database and compare the data in the uploads to those aggregates. But for WiFi we can't offer any way that would allow someone to do queries for single wifi networks. Which also means there's not really any way to even offer a good service-side "debug mode" for queries. There's a whole bunch of reasons why the data might not have been accepted: - The GPS accuracy was too bad (currently more than 100 meters for WiFi or more than 200 meters for cell networks). - The cell identifier was incomplete or some of its parts where out of valid their ranges (cell modems can get into all sorts of funky states). - The WiFi networks were already known as non-stationary ones. - The cell or WiFi networks were previously known, but at a very different / far away position. On the query front some other things could go wrong: - After filtering out some of the WiFi networks, less than two WiFi networks where known at a position, so we don't return WiFi based results for it. - If we've only seen the cell or WiFi networks for the first time, they have a really low confidence score. If there's any other information in the query, for example from a secondary SIM or a GeoIP based result that points to a different location, we might prefer that other location since it has a higher score. There's a bunch of clustering happening in the query to figure out all the possible locations and whether or not they agree with each other. At the end we return the position cluster with the highest cumulative score. - I've opened https://github.com/mozilla/MozStumbler/issues/1751 to suggest we disable the GeoIP (and cell area) fallback for this visualization. I think that might help in avoiding the "too low score" problem. Hanno _______________________________________________ dev-geolocation mailing list [email protected] https://lists.mozilla.org/listinfo/dev-geolocation
