Field research of Bluetooth Low Energy use for indoor positioning on Android

I've started investigations and practical tests of the modern Bluetooth Low Energy (BLE) technology applicability for indoor positioning tasks. This technology has been built with many useful applications in mind from very beginning, including IPS of course. The main question was if the technology is mature enough and widely adopted to provide real value.

You may perform a quick search on Internet and find numerous papers with academic research on the subject. I did it as well, and most interesting and thorough article was "An Analysis of the Accuracy of Bluetooth Low Energy for Indoor Positioning Applications" by R. Faragher and R. Harle. It mentions almost all Pros and Cons of BLE, and provides practical results of a comparison between WiFi- and BLE-based positioning approaches. Most important conclusions that I made for myself after the reading are:

• a special non-connectable BLE devices are preferred for building IPS infrastructures because of their continuous discovery (connectable devices are reported only once per each scan request); as far as specific building environment may not comply with this requirement, a mobile application should explicitly repeat BLE scans in a loop, which may lead to additional resource consumption and occasional hangs (find more details below);
• BLE signal range is shorter than WiFi's one, and RSSI level of the same beacon may change significantly as a result of ad hoc switching between 3 frequency bands used by BLE internally (it can be a problem to sort out measurements by BLE channel using provided mobile APIs); thus, a special fingerprinting algorithm should be used with an emphasis on specific beacon existence instead of its RSSI, or deep smoothing should be applied, making processed RSSI values more inertial;
• a single BLE scan should be performed at least once at a second in order to provide 1-2 meter positioning accuracy; unfortunately this parameter can be hardly manageable and limited by hardware implementation specific to every manufacturer;
• according to the article, BLE scanning is negatively affected by enabled WiFi receiver, so for better results BLE should be used while WiFi is disabled, which may not be feasible for all use cases;
• for best result at least 5-6 beacons should be detectable in every spatial point; combining the fact with the fast decay of BLE signals one can deduce that a high density of beacons is required for good positioning performance;

Just as illustration of the issues mentioned in the 1-st and 3-rd points, here is a related discussion on the StackOverflow. To recap: BLE implementations may vary significantly between Android versions. This makes it difficult to build an application with consistent BLE behaviour on all variety of Android market, supporting BLE at the moment (70% of Android devices).

I added BLE scanning and fingerprinting in a test version of WiFiLine. One additional observation is that BLE is not yet widely used in local stores here in Moscow. Actually the number of BLE devices is 10-100 times less than WiFi hotspots. My thought is that BLE is not yet ready enough for efficient public use.

If you think you know a place with good BLE coverage and you're ready to play with the experimental version of WiFiLine, please, let me know and I'll send it to you.

WiFiLine's synthetic probability algorithm revealed

As I promised, I'm posting a short explanation of the built-in "synthetic probability" location algorithm. To start with it let us consider how WiFi data looks like. When you scan a building you get a list of geographical points with WiFi measurements, each of them contains signals from several hotspots, and every hotspot signal is normally detected many times demonstrating varying levels - so called RSSI (Received Signal Strength Indication). All this data is stored in the map, and can be viewed - just switch to the "Scan and Edit" mode, open the list of points and expand any of them - you'll see the names of hotspots detected in this point. Tap a hotspot to open a dialog presenting this spot's RSSI distribution.

Usually it's bumpy, but the more scans you perform in a point the more smooth distribution you get. According to the Central Limit Theorem the distribution tends to be Normal (Gaussian), so one can estimate its mean and standard deviation. This is where the word "synthetic" in the algorithm name comes from: it implies that we can build a synthetic (near to real, yet artificial) probability distribution (mass) function from acquired WiFi data.

Of course, this is just a probability of getting specific signal level of a hotspot S in a point X. We need to combine all such probabilities somehow in order to calculate current user location. And here is the Bayes theorem comes in handy.

P(A | B) * P(B) = P(B | A) * P(A), where

• P(A) and P(B) are the probabilities (priors) of A and B independent of each other;
• P(A | B) is the conditional probability of A given that B is true;
• P(B | A) is the conditional probability of B given that A is true;

Now let us add some suffixes to bring it into our context:

P(As_i | Bx_j) * P(Bx_j) = P(Bx_j | As_i) * P(As_i), where

suffixes 's_i' and 'x_j' stand for i-th hotspot and j-th point respectively, so:

• P(As_i) is the prior probability of i-th hotspot;
• P(As_i | Bx_j) is the conditional probability of observing i-th hotspot in j-th point;
• P(Bx_j) is the prior probability of j-th point;
• P(Bx_j | As_i) is the conditional probability of being in j-th point provided that i-th hotspot signal is detected;

Apparently, it's the last probability which we are after:

P(Bx_j | As_i) = P(As_i | Bx_j) * P(Bx_j) / P(As_i)

In the right side of the equation, P(As_i) can be estimated as a percentage of points where the hotspot Si was detected. P(Bx_j) is initially 1/N for every point, where N is the total number of points, but later it can be refined by applying our knowledge about current user location and reducing N to a reasonable neighbourhood. At last P(As_i | Bx_j) is the probability obtained from the synthesized probability distribution of signals described above.

Having P(Bx_j | As_i) for different i-s in every point j, we should combine them by hotspots (by i) in order to get the total probability of point Xj. According to the formula of mutually non-exclusive events:

P(Xj) = P(Σi(Bx_j | As_i)) = 1 - Πi(1 - P(Bx_j | As_i))

The point with largest value (or an average of K points with largerst values) is most likely the current location of the user.

This is a simplified description of the "synthetic probability" algorithm. It does not cover many nuances such as signal level calibration and in-motion scanning but gives you an idea of how WiFiLine works behind the scenes.

New WiFiLine version has been released

New version of WiFiLine - 1.1.3 - has been just released. The main changes are:

• debug marks with current user position(s) detected by all built-in algorithms are now optional and disabled by default; in order to enable the marks, one should enter "debug:on" in the processing command line (described some time ago in the blog); "debug:off" disables the marks;
• the naive multiplier algorithm has been changed a bit, but it's still an experimental thing;

According to latest tests in fields, recommended methods are extended fingerprint and synthetic probability again, as they were before. Position accuracy is 10 meters. I plan to shed some light on the probabilistic method in a future. As for neural network, it requires manual finetuning of input data to get best results. For example, it could be worth removing some non-discriminative hotspots from the map.

New map visualization feature is available in version 1.1.2

New version 1.1.2 of WiFiLine has been just released. It introduces new map visualization. In the Location mode, a map can now automatically rotate according to user's "view" direction. This makes it easier for user to take his or her bearing, but may create some difficulties in reading labels on the map.

New feature can be enabled in the context menu of the main screen. By default it's disabled, and maps are shown in the standard way: floorplan is static, and user's current bearing is indicated by a green sector inside the compass. When the feature is enabled, there is no a green sector in the compass, because user's "viewing direction" is always forward (up on the screen), and the compass shows only blue and red sectors for the North and the South.

The rotation of a map is performed around the point of user's current location. If current location is unknown (which is possible if navigation was not started, or the algorithm failed due to incomplete or irrelevant WiFi data), map remains static in its default orientation.

In other modes - Scan and Edit, Hotspot signals - the new visualization made intentionally unavailable, otherwise it would be hard for user to edit and analyze the map.

Processing commands for WiFi maps

In the previous post I have started a story about built-in processing commands for WiFi maps. But the story came out too long for a single post, so I have only managed to cover the starting phase: how to open the command line and how does it look like. Today I'll describe the commands themselves. You can enter several commands in a row delimiting them by spaces. The commands will be executed in the same order as they occur in the editbox.

• clear:name - clears names of all points
• clear:neighbors - clears all neighbors (links between points); can be useful after attempt to generate neighbors with inappropriate neighborhood radius
• clear:signals - clears detailed WiFi measurements (scans) stored in points, but leaves information about detected hotspots and their average signal levels in each point - this may help to shrink map size but prevents probabilistic location algorithm from functioning
• lineup:IDs-IDe - aligns a series of successive points with identificators IDs-IDe to the starting point IDs; IDs can be larger than IDe or vice versa; alignment is performed in direction with longest distance between points IDs and IDe, for example, if delta in X coordinate is 1000 and delta in Y coordinate is 100 the points will be aligned in a horizontal line with Y equal to Y of the starting point IDs and preserved X coordinates
• stretch:IDs-IDe-PERCENTS - expands or squeezes a series of points in direction from IDs to IDe; again IDs can be larger than IDe or vice versa; the PERCENTS is the added fraction of initial distance between the starting point and every other point till the point IDe; for example, if PERCENTS is 10, all points will be moved by 1/10 part of their corresponent distances from IDs; both X and Y directions will be affected
• shift:IDs-IDe-DX-DY - shifts the points from IDs to IDe by the specified number of image logical pixels in X and Y axes correspondingly

Here is the example of processing command executed on the Kaleidoscope map:

clear:name lineup:1-116 lineup:117-221 lineup:478-462 lineup:435-461 lineup:479-499 lineup:412-434 lineup:385-411 lineup:355-384 stretch:479-499-12 shift:550-575-5-0

The same commands can be executed automatically during XML-map loading. For this purpose a new XML-tag was added to the map specification: preprocess. The tag is optional. The map header example:

<place xmlns="http://weborienteer.com/wifiline">
  <desc>
    <header>
      <id>RU.MM.SZAO.KA</id>
      <name>Kaleidoscope Shopping Center</name>
      <date>2015-01-10 10:10:10</date>
      <coordinates longitude="37.4446" latitude="55.850567" />
      <format>1.2</format>
      <images default="1" scale="85">
        <image floor="1" svgfile="k1.svg" azimuth="155.0"></image>
      </images>
      <preprocess>clear:name lineup:1-116 lineup:117-221 lineup:478-462 lineup:435-461 lineup:479-499 lineup:412-434 lineup:385-411 lineup:355-384 stretch:479-499-12 shift:550-575-5-0</preprocess>
    </header>
  </desc>
  ...

This new feature will hopefully help to refine WiFiLine maps and make them good looking.

Secret command line for WiFi maps postprocessing

In one of my previous posts I have introduced new WiFiLine map. This is a demo map created for a shopping center in Moscow, this is why it was announced in Russian only. The most important thing about the map is that it was scanned using new continuous scanning mode. And if you look at the screenshot of the map (in this post), you may wonder how it became possible to line up all measurement points in horizontal and vertical axes. If you ever tried to scan a map in WiFiLine you may know that points appear at shaky locations because they follow your touches, and these manual operations can hardly be perfectly aligned.

Of course, one could export the map into XML-file and edit coordinates of the points manually, but this would be a lot of work. Fortunately, new WiFiLine provides a convenient way for polishing maps in semi-automatic manner. Let me describe how to unlock some features hidden by default.

First, make sure that Scan and edit mode is enabled. Then open right-side panel with the list of scan points. Touch the header "Points" with one finger and hold it, then tap the header with another finger. This will open an additional panel with command line at the bottom of the screen, similar to what is shown on the following screenshot.

Please notice there is a 2-state button S/n in the right corner. If you press it, the list of points will be switched to an alternative view, where every point is expanded with its neighbors (only identificators of neighboring points are shown).

In this view, a tap on a link will bring a confirmation dialog for deletion of this link. Press OK to confirm or No to cancel this action. Don't forget that links can be (and usually are) bidirectional, that is point N2 is listed as a neighbor in the point N1 and vice versa. By removing a neighbor in one of the points (for example, N2 from N1) you do not automatically remove the symmetrical link in opposite direction (N1 from N2). If you want to remove both links you should delete corresponding neighbors in both points. It can be necessary to delete the link if both directions if there is a wall between the points. And it makes sense to delete a link only in one direction and keep it for another if the points are connected by a one-way escalator.

Why do you need to delete some links? Well, because it's very usefull to generate a mass of links between points automatically by means of the command Generate neighbors. It will take current Neighborhood radius from the Settings and bind every two points with a distance less than the given number of meters between them. Of course, this is fast and justified, but this is also a bit straightforward, in the sense that any real-world obstacles are not taken into account. This is why it's normally required to remove impossible links between automatically generated neighbors.

By pressing the button s/N once more you revert the list of points to its initial view with hotspot signals inside every point.

Well, finally we get to the command line itself, and I'd like to write you about fancy postprocessing commands, but this post does already look like a fat one. So let divide it into 2 parts. So I'm writing here:

To be continued...

New major release of WiFiLine is out

I'm glad to inform you that WiFiLine 1.1.0 has been released. The app is reworked thoroughly.

Main changes are:

* New modern user interface with drawers sliding from the left and from the right sides of the screen;
* New location mode - naive multiplier;
* Numerous new functions (delete a hotspot, last scanning undo and others);

Some of the new features have been already covered in the blog. The others will be described in future.

Please note that the app's logo is also updated. Unfortunately Android has an old bug: the icons of updated apps are not refreshed correctly. So you may not see the new icon in the launcher unless you completely remove and then reinstall the app.

Also please note that WiFiLine is a fully functional navigation app: you have no need to use WiFiLine Editor anymore. WiFiLine Editor has not been updated - you may use it if you experience some problems with the new major release.

More details about future version of WiFiLine: part IV

Today I'm finally posting short and descriptive answer to the question that has been left open in one of my previous posts regarding new version of WiFiLine .

I think it was easy to guess that while in the location mode WiFiLine shows the search dialog in the right-side drawer.

Of course, all searching functionality is left intact (including full text search, category search, and shortest path computation) but now it's easily accessible just inside the main window.

More details about future version of WiFiLine: part III

From the very beginning WiFiLine has been using fullscreen mode in the main window. This was a feature added to maximize visible area of a map - you know, mobile screens are small and it's hard to fit navigation tips and context in the limited space.

New WiFiLine makes the fullscreen mode even more "fully screened" ;-). Latest Android version starting from KitKat (4.4) allows applications to hide the navigation bar at the bottom of the screen. This is a horizontal bar with 3 buttons - back, home, and recents. It takes a lot of space and it's almost empty itself. WiFiLine utilizes this space for maps. Look at the screenshot below - there is no the navigation bar.

Of course, you can temporary restore the status bar and navigation bar by a swipe gesture from top of the screen. This is a built-in Android feature. It will show semitransparent overlays of the status bar and the navigation bar on top of the WiFiLine window. They will be hidden again by timeout.

But if you don't like the fullscreen mode, WiFiLine allows you to switch it off now. There is an option in the context menu of the main window.

More details about future version of WiFiLine: part II

Main idea behind the new version of WiFiLine is to provide better usability. It comprises many things, and user iterface counts in the first place. New look and feel of the app is supposed to be more logical than before.

As you already know, quick and easy swipe gesture from the left edge of the screen opens now the panel with settings, that includes an option to select one of three supported modes: navigation, scan and edit, and hotspot signals density.

But there is more for swiping in the app. At every moment a swipe from the right edge of the screen opens additional panel with appropriate content (don't worry - the panels do not interfere with each other - if a user swipes out a panel from the right, the left side panel is pulled in, and vise versa - if a user swipes from the left, the right side panel is pulled in).

The content of the right side panel depends from currently selected mode. For example, in the Scan and Edit mode the panel shows a list of points with measurements. And in the hotspot signals density mode, the panel shows a list of hotspots. And even more - if a map consists of several floors, by default the panels show partial lists of points or hotspots that belong to the current floor only. You may click Show all button to get entire listing. When you zoom in the map the list of points is restricted even more to contain only points from currently visible area.

You may wonder what will be shown in the right panel while in the navigation mode. I'll let you to guess, and give the answer in future posts. Stay tuned.

More details about future version of WiFiLine

Today I'm posting a screen with a map in the updated edit mode. It now provides a grid with logical image coordinates (the ones defined in your SVG image viewBox tag, as you may recall they are used during measurements), and 10 meter scale in the bottom right corner (it's shown only if your map contains a valid scale attribute in the image tag of the map).

The next screen demonstrates new progress indicator shown during continuous scanning. It let you know that WiFi-scanning is actually running (unfortunately, it may occasionally freeze somewhere inside Android system or even hardware), and overall number of aquired measurements is counting in the center.

New WiFiLine version is under development

I decided to post a small piece of news regarding WiFiLine. Mostly it's intended to let you know that I'm working on a new version of WiFiLine. The app will be reworked considerably. Among most important features are: more simple yet modern looking user interface, new location algorithm, some other improvements in functionality. Take a look at the screens.

I'm planning to share info on the progress with you.

WiFiLine 1.0.18 is released

Changes in this version:

• Location quality is improved (if you experience some problems please let me know).
• New in-motion scanning mode is added. It's enabled when number of scans is selected as 1. In this mode first touch of the screen starts "endless" scanning until the second touch. In this timeframe a user should walk with a constant speed along a straight line. The app will place all received measurements on the map as points on the straight line between starting and ending points, with respect to their time marks.
• New function for generating subscans is added into the map inspector. It's primarily intended for the maps created in in-motion mode. In this mode map contains a single measurement in a point. The new function allows you to generate additional measurements for every point - they are taken from neignboring points with a predefined radius. The purpose is to form more smooth signal distribution on the map.
• New option to select the size of neighborhood is added into the settings. While scanning this is a radius in meters for additional signals generation (described above), while in location mode this is a maximal allowed change of user location in points. If a newly detected location is outside the radius, actual new location is chosen at next point on the path to the ambiguous location, which is too far from current point to be likely.
• In the location mode the app invokes all algorithms one by one, and displays 3 yellow marks on the map with results of every of them. This allows you to estimate how different algorithms behave themselves under different conditions. Current user location is displayed as before, according to selected algorithm. In order to make neural network showing among these additional marks, it should be initialized. This is done when neural network is selected as preferred algorithm. After this one can switch back to any other algorithm.
• Compass is fixed.

Android 5 (Lollipop) broke some Hibernate functionality

As you may know I have a side project for Android called Hibernate which is mentioned here on the blog site among other useful links, and has its own dedicated page with a short description. So I think it's not too much offtopic here if I post a piece of news about Hibernate. Unfortunately this is bad news.

Android 5.0.1 Lollipop broke some of Hibernate's functionality. Google made some changes in the new OS that made it impossible to monitor foreground task via ActivityManager. Most importantly, it was done intentionally and based on some paranoid security considerations (see below), so no workaround is left for non-rooted devices. I must say this is not the first time when Google changes their OS in very questionnable manner and actually degrades user experience.

Here is what the official documentation says about getRunningTasks method of ActivityManager:

This method is no longer available to third party applications: the introduction of document-centric recents means it can leak person information to the caller. For backwards compatibility, it will still return a small subset of its data: at least the caller's own tasks, and possibly some other tasks such as home that are known to not be sensitive.

As a result, the option Rehibernation in the Hibernate app has no effect anymore. But I'm trying to elaborate a workaround anyway.

As a side-effect, the system log is flooded with messages:

getTasks: caller XXXXX does not hold GET_TASKS; limiting output

but this does not impair usability.

WiFiLine Editor is updated

New version of WiFiLine Editor has been just submitted to Google Play. It includes minor improvements and bugfixes. If you use a limited WiFiLine app (without editor capabilities) I suggest you to switch to this fully functional version. I know some people would prefer to get something brand new and special, and I would do so as well. But unfortunately it takes some time for redesign, refactoring and implementing new features. Stay tuned.

OFF: Android 5.0.1 is off

You may have noticed that WiFiLine project is in the shade of other side projects I'm trying to experiment with. I have some ideas for WiFiLine's future, but at this time I'd like to share first thoughts about new Android version - 5.0.1 - which I received with an Over-The-Air update.

I did not do much testing so far, but here are the points that just strike the eye.

• standard font size is too small; I was compelled to change system settings for using "Huge" fonts (this is maximum), only after this the texts in dialogs and notifications became as much readable as before (with standard font size);
• the settings dialog is now organized into 2 columns, which is very unconvenient and hard to read in comparison with the previously known streamlined list;
• standard keyboard is almost unusable in its "modern" flat design; luckily, there is an option to select a "Holo" theme for the keyboard, so that it brings back conventional look and feel;
• the last annoying thing is a mess with system statuses and notifications - I'll put the details below, outside the list;

As you know there is the status bar in the upper part of the screen. On the left side notification are shown, on the right side system information about connectivity, battery power etc. is shown. In previous versions of Android swipe down gestures worked separately for the left and the right sides, that is they open either notification list or a dropdown box with quick access options. Now they are combined! No matter where you perform the swipe down - on the left or on the right side - you see the same picture, and the dropdown box is shown in the center. This is very unexpected and inconsistent. Also this does not impove usability in any way, because the options are now buried under notifications: you need to perform 2 swipe down gestures in a row - first to open the dropdown, and the second - to move notification underneath - only after this the options appear.

I hope functional improvements in Android 5 are not designed in the same counterproductive manner as with appearence and usability.

The site is back

I'm happy to inform you that www.weborienteer.com is back - now at the OpenShift cloud. As usual the backend does not only provide you with WiFiLine documentation, but also host the map database. Searching through the base is again available from WiFiLine apps. The number of examples is still limited, but you can share your works and help in populating the base.

Droidcon Moscow 2014: r-evolution of wearables

Today I'm going to post some thoughts on a subject which may seem offtopic here, but only at a first glance. Indeed, it's about Android ecosystem, and thus embraces Android-based applications, including those related to indoor, outdoor, or whatever-else-door positioning.

The main news is that I attended Droidcon Moscow 2014 today. There is no surprise that current trends were covered: wearables, augmented reality, virtual presence, and context awareness.

Among all evolving products, which comprises these technologies, one is most noticable: glasses.

Google glasses are definitely the most widely known and promoted example. They are surrounded with enthusiastic boom and provide a truly new user experience. Yet I have some critical considerations.

First of all, I don't completely agree with Google's design. Their decision was to make the active part of glasses as a single eyeglass. The working area covers only a little part of visual field, and a user must squint in order to read info. I know this was the deliberate decision to not distract user from reality. The problem with this approach is that "real reality", augmented reality, and virtual reality are combining too fast and displaying virtual information over real world becomes a real, most important, value. As for distracting user from reality - this is just a matter of switching one display mode or another (such as completely transparent). Anyway, I'd prefer to have a glasses with both oculars and see them in front of eyes.

The second thought about Google glasses concerns another point: the glasses are actually a thin client (UI) for server-based apps. The apps which the glasses are capable of running are very lightweight. It's not possible to code somewhat computationally complicated, because the glasses discharge quickly and become hot (at your face's skin).

The third point is that Google glasses require special coding. The apps for the glasses are not plain old Android apps. On the other hand, if I have, for example, an Android application for augmented reality which runs on phones and tablets, I'd like to port it to glasses with minimal or even no efforts.

All that said, it's time to introduce another glasses - Epson Moverio BT-200. This gadget presents full-fledged, so to speak, glasses with two active oculars. Moreover, they are powered with real Android OS and can run native Android apps. This is good news. The bad news is that they made of 2 parts: the glasses themselves and a "system block" with touchpad, connected by a pretty thick wire. My user experience was not so good. It feels really unnatural to move fingers over the touchpad (somewhere in "background") for cursor control. I'd prefer that an eyemovement detection would have been built into the gadget. It does exists in other products and fits into such glasses metaphor very well - cursor just follows sightline.

Ok, let us admit that the outboard "system block" is the only solution possible nowadays to support full power of an Android device, but the touchpad, as a primary control, is inappropriate. As long as this block should exit due to current technical limitations, I'd made it as a normal Android device with touch screen. So, it can be used as is without glasses. And if glasses are connected, they use all the power of the device and adds new eye-tracking control experience, including movements, winks, etc. And as you may notice, this sounds like the (Epson) glasses could be implemented as stand-alone detachable gadget, which could be plugged into any Android device! That would be nice. But this is not all the story.

Even if the eye-tracking would be incorporated into the glasses, there is something more that could add next level of control and interaction. When I'm looking at the glasses, the brain-computer interface comes to my mind. For example, Emotiv devices just asks to be embedded into the glasses. Structurally all we need is to add some contacts on the inner side of the rim. Software part is not a problem at all.

Bottom line. I think the advent of virtual glasses is exciting as phenomenon, but existing models lack many features which could dramatically improve usability, and more importantly, all this is doable right now. So, I'm waiting for the evolution or revolution, as you like. Hope it'll happen soon.

WiFi + Direct + Dating

I know some of you are waiting for news about WiFiLine and this post may look like this but it is actually not. I have just released a brand new Android application - DirectDating. As you might guess from the name the app has nothing in common with navigation. Yet it's somewhat related to WiFiLine, and not only because of the author, but because it also uses WiFi technology. Specifically, it is based on the new WiFi Direct (Peer-to-Peer), and its WiFi Direct Service Discovery feature.

It was a challenge and very interesting task. And I'm glad I made it. I invite you to probe the app and share it with your friends. You may find the app in the Google Play.

WiFiLine's advantageous features

Indoor navigation is not a matured market yet, but several products similar to WiFiLine are already available: some of them can be evaluated, and some can be used commercially in a restricted environment (equipped with a special hardware). This is why I'd like to mention the most important advantages of WiFiLine:

1. It's free.
2. It's based on open standards, for example, the map format is based on XML/SVG and well documented, there is no proprietary stuff.
3. It may work with local maps (saved on a device) without any dependency from a server. No Internet connection required.
4. It does not require special and usually expensive hardware to be installed on a venue.
5. The map uses vector format (SVG) which provides high quality of images, arbitrary level of details, and rich zoom-in/zoom-out possibilities.
6. You can work with your own maps using WiFiLine Editor.

BTW, now I know (or at least I think I know) how to use environmental magnetic field for navigation, which was covered by one of previous posts - On Earth's magnetic field in navigation indoors. It still requires some research, but idea is clear and ready for prototyping. I'll let you know how it goes.