Closed Bug 492633 Opened 11 years ago Closed 10 years ago
Sometimes accuracy of geolocation differs drastically
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090512 Shiretoko/3.5b5pre ID:20090512031310 Running the above build and opening the following URL shows a location which is about 4km far away from my current position. Using Minefield instead I get an accuracy of about ~40m difference to my position. http://people.mozilla.org/~dougt/geo.html So are there some changes which haven't been checked into 1.9.1 yet or is this a branch only bug? Users cannot trust the given location they get and will probably not find the excellent restaurant in a foreign city. Is it worth asking for blocking1.9.1?
for me Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090512 Minefield/3.6a1pre ID:20090512044242 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090512 Shiretoko/3.5b5pre ID:20090512041901 give the same output.
So as what I can see the first value we get back from the geolocation provider has this high accuracy value only. Positions returned later have the correct value. Looking at the log the initial position is based on only two wifi networks. Could this be the problem? Now I'm in another network and everything seems to be fine. Even the initial position is shown correctly.
whimboo sent me the network log. in the case where accuracy is high, there is an extra access point visible. in the case where accuracy is low, it is missing that access point. I am not sure the difference between shiretoko and mindfield. Instead, i think it has to do with this missing access point.
Doug, its the other way around. The high accuracy is returned for the 2 nodes while 3 nodes result in a lower accuracy value but better position.
yeah, the wording is messy good accuracy == high accuracy == low accuracy value (measured in meters) bad accuracy == low accuracy == high accuracy value (measured in meters)
Doug, have you been checked in any patches lately? While trying to identify the cause with the older profile I cannot see it anymore. Even the first return position is fine now. Ok, probably it's really dependent on the amount of wifi networks. Right now 3 of them are in my log while only 2 were listed when I noticed this problem.
Some minutes ago I got a totally strange result. When opening the referenced URL inside the Private Browsing mode for a fresh profile I got the position of my previous home. I moved nearly two month ago. So what happens here? The accuracy value was 150 so it's not bad.
i haven't checked in anything related to the wifi scanning stuff and there shouldn't be much difference between trunk and 1.9.1. basically the way this works is that Google (and other similar services) drive around listening for WiFi radios. From the street you can hear most WiFi radios. in the vehicle there is also a GPS. So, they can match up what WiFi radio they hear at some given GPS location. What I think you might be seeing is they drove by your old place, then you moved, and they haven't rescanned. If you want, i can forward them the information so that they can try to correct this. In the future, i would hope that there will be a "self service" site such that I am not the bottle neck (i just can't do this for everyone).
Doug, this only happens when I start the geolocation service from within the Private Browsing mode right after the profile has been created. The initial value shows this strange location. The second one has the correct location but with an accuracy of ~12000. I don't think that this is caused by some old measured values. Therefor we have too many different code paths when a wrong position is reported back.
Henrik, can you uncomment the code in LOG() and send me the traffic? I am wondering what we are sending differently between these two requests.
I sent a log to Doug.
I can't reproduce this. Every combination of private browsing, minefield, shiretoko, etc returns the same location result for me. Which, btw, has a high accuracy range because Google hates them some Canada or something. Not blocking until we get solid STR.
Flags: blocking1.9.1? → blocking1.9.1-
Summary: Accuracy of geolocation differs drastically between Shiretoko and Minefield → Accuracy of geolocation differs drastically when only having 2 access points available
This happens when you only have 2 access points around you. Even with such an amount it shouldnt return a position which is 3km far away. Wifi doesn't work over such distances.
Henrik, are you getting better locations now?
Still not better even with more then 2 access points.
Doug, any progress on this bug? Right now I have normally more then 3 access points in my list. I saw it again while running the BFT against geo location. The first two tabs had the correct position while successive ones had the wrong position. Even after reloading the tabs nothing changes.
Summary: Accuracy of geolocation differs drastically when only having 2 access points available → Sometimes accuracy of geolocation differs drastically
While running the RC candidate, I am seeing the following: 1. Run doug's test case on my Intel Mac with a wifi connection. 2. Service reports the address as 800 High School Way Mountain View, CA 94041 The zip is right but the location seems to be a bit off - is that expected? Earlier I saw an instance in the lab with ethernet where they had me in the middle of Moffett field.
This is the text from our FAQ """ Accuracy varies greatly from location to location. In some places, our service providers may be able to provide a location to within a few meters. However, in other areas it might be much more than that. All locations returned by our service providers are estimates only and we do not guarantee the accuracy of the locations provided. Please do not use this information for emergencies. Always use common sense. """ I am marking as wfm
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.