Flawed data uploaded recently due to GPS errors.
In my view of "First Discovered By Me" I noticed an unusual diagonal line of hits in places I simply hadn't gone, at all.
Zooming in, I noticed most of the network names seem to be Home Depot related. Sure enough, these scans had poor GPS results due to the fact that they were done indoors and there were probably quantum effects on the radio waves due to edges in the ceiling.
Here's the beautiful part: The bad data (shown connected up in a black line) all points directly to where the problem happened: the Home Depot! Apparently the error is linear and additive. Interesting.
Picture: http://oi45.tinypic.com/f5q8l.jpg
Any way to prune the data set of the bad location data? More to the point, it might be worthwhile to scan the data-set for same-user entries with large variances in location over short periods of time, all along a single line, and prune all those entries as similarly indoor-generated GPS errors.
I see enough similar odd-placed lines to think this problem occurs with other devices on other scales...
Zooming in, I noticed most of the network names seem to be Home Depot related. Sure enough, these scans had poor GPS results due to the fact that they were done indoors and there were probably quantum effects on the radio waves due to edges in the ceiling.
Here's the beautiful part: The bad data (shown connected up in a black line) all points directly to where the problem happened: the Home Depot! Apparently the error is linear and additive. Interesting.
Picture: http://oi45.tinypic.com/f5q8l.jpg
Any way to prune the data set of the bad location data? More to the point, it might be worthwhile to scan the data-set for same-user entries with large variances in location over short periods of time, all along a single line, and prune all those entries as similarly indoor-generated GPS errors.
I see enough similar odd-placed lines to think this problem occurs with other devices on other scales...
if you can send what you think are the affected transaction id's to wigle-admin@wigle.net we will have a look.
thanks!
-uhtu
thanks!
-uhtu
OK I will get those soon.
I had the same problem with one upload. I was walking and wardriving and the map shows a straight line of about 300 m of bad positioned APs, crossing some blocks. I suppose I had GPS errors at that moment ![Sad :(](./images/smilies/icon_sad.gif)
![Sad :(](./images/smilies/icon_sad.gif)
Mmm I checking again the map (with the "first discovered by me" option) and is worse that I thought. One of the lines is several kilometers long. I'm attaching the map with the lines marked in blue but I cannot associate them to a file. In any case this happened in different uploads.
I'll try to export the whole database in my phone and check it to see if the problem is there. I'll keep you posted.
Regards.
I'll try to export the whole database in my phone and check it to see if the problem is there. I'll keep you posted.
Regards.
The problem is present in the exported CSV. Some AP are distributed along a straight line. In my own file I have a AP with tens of points going hundreds of kilometers away!
I don't know if it is a problem of the GPS or in Wigle for android![Confused :?](./images/smilies/icon_confused.gif)
I don't know if it is a problem of the GPS or in Wigle for android
![Confused :?](./images/smilies/icon_confused.gif)
I've noticed the same thing. What happens is I turn on the GPS and Wigle on my Android phone. The GPS is not accurate when it first starts, so I get a lot of weird locations for my home wifi network (and nearby networks).
To avoid these weird lines, at least for some cases, turn on the GPS and wait a little while until starting to scan with Wigle.
To avoid these weird lines, at least for some cases, turn on the GPS and wait a little while until starting to scan with Wigle.
I think its not a true GPS fail, could it be due to using the "Assisted GPS" feature of smartphones (more commonly known as using positions of known mapped wifi networks - as we are doing) to ascertain the location of a network? It would be useful to know if this is the same network being mapped in these "ribbons".
If that was the case and the AGPS is based on Google derived network data similar to the WIGLE project, could the Android OS itself be covertly reporting the location of every network that comes within range of a smartphone in realtime? This would help explain this type of amplification error i.e. Each time a location is mapped in WIGLE without true GPS Android uses the data on local networks slurped during a "Streetview" excercise. Say for example the location of an original network taken by google was wrong - for example a Streetview vehicle temporarily lost a GPS signal when the network was originally polled. Each time an Android user maps the network in WIGLE when the AGPS is on it not only reports the position inaccurately but (in theory) the OS could send the data back up to Google who "refine" the position of the AP in their central AGPS directory based on further erroneous data! Rinse and repeat!
If that was the case and the AGPS is based on Google derived network data similar to the WIGLE project, could the Android OS itself be covertly reporting the location of every network that comes within range of a smartphone in realtime? This would help explain this type of amplification error i.e. Each time a location is mapped in WIGLE without true GPS Android uses the data on local networks slurped during a "Streetview" excercise. Say for example the location of an original network taken by google was wrong - for example a Streetview vehicle temporarily lost a GPS signal when the network was originally polled. Each time an Android user maps the network in WIGLE when the AGPS is on it not only reports the position inaccurately but (in theory) the OS could send the data back up to Google who "refine" the position of the AP in their central AGPS directory based on further erroneous data! Rinse and repeat!
Yeah these errors are actually rather common and considering the distances involved, cant just be from network location, which if anything would be reducing them.
They are all centered on areas where people were likely scanning indoors, and all centered on areas where the indoor location had a roof that wasnt like that of a typical house, or a thick office building. all areas where there was likely a lot of metal in the roof over the span of the entire thing. industrial or large facilities, mostly... places where not a lot of satellites are ever directly visible and then, more reflected satellite data that does remain visible is still available.
the hallmark signature of these scan errors in the data set will be a scan that travels at walking pace, then suddenly picks up speed, usually to well beyond vehicle speed limits, back and forth in a linear pattern, before again becoming a regular pedestrian.The "time discovered" field of each individual scan can be used to give the speed at least on local clients. not sure what data the server keeps about this on its end, but actual time observed and upload batch ID would go a long way towards ordering data sets to locate the error. unfortunately releasing this also drops everyones tracks explicitly, which, while not the end of the world considering we all deliberately uploaded, may not be a feature the site operators want to have enabled...
thoughts?
They are all centered on areas where people were likely scanning indoors, and all centered on areas where the indoor location had a roof that wasnt like that of a typical house, or a thick office building. all areas where there was likely a lot of metal in the roof over the span of the entire thing. industrial or large facilities, mostly... places where not a lot of satellites are ever directly visible and then, more reflected satellite data that does remain visible is still available.
the hallmark signature of these scan errors in the data set will be a scan that travels at walking pace, then suddenly picks up speed, usually to well beyond vehicle speed limits, back and forth in a linear pattern, before again becoming a regular pedestrian.The "time discovered" field of each individual scan can be used to give the speed at least on local clients. not sure what data the server keeps about this on its end, but actual time observed and upload batch ID would go a long way towards ordering data sets to locate the error. unfortunately releasing this also drops everyones tracks explicitly, which, while not the end of the world considering we all deliberately uploaded, may not be a feature the site operators want to have enabled...
thoughts?
GPS data can be sometimes surprisingly off. I'v noticed this at first only when driving threw another state, then it "happened" again about a block from my office. When I had the coordinates double checked, it put me in the Mississippi River. I swear me or my car has never been in the Mississippi, though I cross over it almost daily. This "location mistake" didn't last, about 1hour later still dry in my office, it located me where I was. Very odd, I have no idea what would cause this. Perhaps NASA or NOAA has some insight into sun spot activity etc that may coincide. What I did notice but only after the fact was the data this happened, last year I'll look up the day, we had a rather vivid for this latitude display of "northern lights". I know that can play games with certain radio frequencies, never heard it affecting GPS sats however.
Who is online
Users browsing this forum: No registered users and 58 guests