Indoor localization

[dotevo]

Is possible to add floor number for data? It can be useful into public buildings as indoor navigation with for example openstreetmap data

http://osmtools.org/indoor/#lat=51.0890&lon=17.0211&z=15

[hannosch]

We haven't thought about indoor location yet. Currently we rely on the GPS sensor to tell us about the surrounding environment, and with GPS not working indoors we cannot get measurements from such places.

So this needs a bunch of work and hasn't been a priority for us yet.

[Djfe]

if you need something like that you should use IPS technology and not GPS (too unaccurate, mostly for cars) and how many wifi aps do you have nearby to determine a real position?

[pyrog]

if you need something like that you should use IPS technology

IPS = Indoor positioning system See #64

[Mathnerd314]

There are a few papers that do fingerprinting approaches with WiFi, and they get robust indoor localization down to 1-2 meters. If you have enough datapoints, you can even do topology-mapping stuff and turn an unpositioned collection of RSSi's into a 3d model (something like this, also the SLAM papers).

The documentation says these complex approaches were avoided because there was not enough data; is that still true? The map looks pretty dense, at least for most of the US cities. And of course, interested users can just collect more data. :-)

As a first step, maybe 'device type' and 'device orientation' fields could be added and used for calibrating RSSI signals (so that ichnaea knows that an RSSI of 70 on device A is roughly equivalent to an RSSI of 60 on device B). The device type could be hashed for privacy, although since the data isn't public it's not too important.

Also there is this MIT-licensed project: https://github.com/dmsl/anyplace. & this (GPL) And this one: https://github.com/schollz/find (AGPL, cc @schollz on whether it could be used with Mozilla)

[schollz]

Hi @Mathnerd314, excellent research! I haven't seen those papers.

I don't think AGPL will be a problem with Mozilla - but please let me know if it is and I can make a version that you could use. I'm also happy to help if you have general questions.

I might add that for many IPS systems that are not time-of-flight calculations are purely classification based (via Naive Bayes / SVM / Random forests / KNN / etc.) so they would require the user to submit indoor-specific information. This information could be the name of the room they are in (like the case in my program), or it could be a user-selected Lon/Lat/Floor on a map that corresponds to their position.

[hannosch]

Thanks for those pointers. Unfortunately the general problem still remains: We only collect data when we get a GPS position to anchor it. That approach means we get almost no data from indoors, just those few places with thin enough glass ceilings. We also only collect data if the GPS positions are at least some 30 meters and a minimum time interval apart, so our grid would be quite coarse grained.

With those things in mind, there are almost no places where we'd have enough data for the fingerprinting approach to work and significantly improve upon what we get now.

[Mathnerd314]

Ok. So first MozStumbler should be updated to collect indoor data. The closest issue over there is https://github.com/mozilla/MozStumbler/issues/1578; should I open a new one?

[hannosch]

@Mathnerd314 please open a different issue. The one you linked to is about device-local geolocation without any service interaction - also known as offline geolocation. That's something quite different from what you have in mind.