WiGLE.net

Hello,
would it be possible to use triangulation to count position of hotspots as https://market.android.com/details?id=h ... iscannkeep this app does?

Thank you!

WigleWifi also stores multiple observations. We do our filtering and triangulation on the server side. As mobile devices get more powerful it would be nice to do some work on the client side for more likely locating and visuals.

so when I do upload the new run will it change the older wifis?

individual observations won't change, but the derived location may update.

I've just checked and it looks like that for each run just one observation is uploaded and it just isn't right. The wifi is first seen very far from real position, this very-far position is reported as HERE IS THE WIFI!!! but even walking towards the hotspot itself won't change what will be uploaded. I sat right next to the router but still just the first observation was reported so no triangulation is calculated.

Multiple observations are recorded, as long as they differ by space and/or time. Do you have an example network bssid and wigle transaction id?

I believe a directional antenna from an access point can "throw the voice" across from the true location. I've done it myself. Could that be what is observed?

How can I get the BSSID and the wigle transaction id?

But if you'd look at this map: https://wigle.net/gps/gps/Map/onlinemap ... mapzoom=18 the wifi with SSID "BlueBell" should be in the center of the map yet it it still far too right (on the green patch).

If you zoom in far enough you can see the bssid is 00:50:7f:b7:d1:98. There is one observation, not from WigleWifi, and not as your user, so that hasn't been found by your client.

https://wigle.net/gps/gps/main/confirml ... f:b7:d1:98

good to know. btw thanks for the link so I can check how it works without further questions

my observations weren't just uploaded so I uploaded them ( https://wigle.net/gps/gps/main/confirml ... f:b7:d1:98 ) and:
-I see many very inacurate observations (position probably not via gps) - why are these even counted? (it's a bar and I've been sitting inside so yea, no gps signal)
-there are kinda accurate observations (with altitude) with high level of signal
-computed position of the wifi didn't change

so I'm still confused about how does it work.

- I see many very inacurate observations (position probably not via gps) - why are these even counted? (it's a bar and I've been sitting inside so yea, no gps signal)
We get a lot of inaccurate observations, it's constant noise that has to be dealt with. The only hope of any kind of accuracy is in aggregate. By default WigleWifi will not use wifi-network-location as of 1.46. But even a somewhat inaccurate location is at least more data then no location at all.

- there are kinda accurate observations (with altitude) with high level of signal
The observations with altitude have lower signal (more negative is worse), so the -62 is not weighted as high as the -45. We've changed the sort ordering on there to make it more apparent. We've also put on the 'accuracy' column which WigleWifi reports and we do some filtering on insanely high values there, but that doesn't apply to this specific network.

- computed position of the wifi didn't change
The numbers changed, the point on the map did not. New networks show up within an hour or so on the webmaps, recomputed positions of existing networks currently update weekly. Updating that more frequently has been on the todo list for a while, we should get on that.

-But even a somewhat inaccurate location is at least more data then no location at all.
sure, but when more accurate observation is available the less accurate should be ignored, shouldn't they? IMO when doing any kind of statistics the extremes (values very different from median) tend to be ignored.

-recomputed positions of existing networks currently update weekly
okay I didn't know that

- sure, but when more accurate observation is available the less accurate should be ignored, shouldn't they? IMO when doing any kind of statistics the extremes (values very different from median) tend to be ignored.

Agreed, if there's a way to tell which is less accurate. We record what accuracy is reported, there's not a huge difference there for this network. So we are left with signal, lat, long, and we do our regular weighted standard deviation calc that's noted on the FAQ: https://wigle.net/gps/gps/main/faq/

That said, we've got some changes in the works to help make that computation a smarter, with clustering and a spamassassin-style points system, that needs a lot more testing/tweaking/balancing though. Some improvements to the webmaps as well to help visualize observations and not just "triangulated" points. Always more things we want to do

-Agreed, if there's a way to tell which is less accurate. We record what accuracy is reported
Oh I must be totally blind to oversee that column /facepalm.

I surely don't want to bash you or otherway say this system is bad, I just want to point out that there may be some problems somewhere else than your system and I felt like sharing it - maybe it was my phone's problem or android OS problem.

example:
first line in: https://wigle.net/gps/gps/main/confirml ... f:b7:d1:98
00:50:7F:B7:D1:98 -45 0 48.70827866 21.26317978 BlueBell N 18.9781 201112 155
-45 is the best signal in the table, accuracy 18 meters is kind of good too - seems like legit observation.
maps of the observation and of actual wifi: http://goo.gl/bdNwV

so maybe it was the location from gsm with accuracy reported from gps? or maybe the gps froze? or gps got very bad signal yet kept reporting high accuracy (low number)?