By Osma Ahvenlampi, SVP Engineering

Three weeks ago, when we announced the IndoorAtlas SDK 2.0 for Android and iOS, one of the major features we highlighted was its new ability to begin positioning automatically, without a pre-set venue or floor map initialization. In this post, we’ll go deeper to what that means, how it works, and how it can be best used in an application. We’ll also discuss some of the situations where this functionality can have surprising, or even undesirable behavior, and how can a developer work to avoid those if necessary.

If you’ve developed apps which use the Android or iOS platform location services, you’re probably quite used to simply being able to subscribe to location services from the operating systems’ location frameworks and and start receiving more or less accurate location information almost immediately. Well, apart from it not being all that accurate indoors, and sometimes taking quite a while to work because locking to a GPS signal can be a challenge. That’s why you’re looking at our technology, of course!

In the indoor space, being able to automatically locate a device is a bit more challenging. There is no global satellite signal, beacons are restricted by their identifiers to basically their owners only, cell tower signals aren’t all that precise for positioning, and wifi networks tend to move around. Our previous generation required the app to know ahead of time which venue and floor the positioning is performed in. This stood in way of offering the kind of experience we want to enable, so we had to find a way to overcome this.

This capability is built upon an array of technologies and large amounts of data. In every indoor map collected with our MapCreator tools, we have detailed collection of not just the foundational, magnetic field data which enables software-only, super-scalable and high accuracy device tracking, but also radio network, altitude and other data which can help provide a rough estimate of location. It is that rough estimate that is the first step towards an automated location service.

For you as a developer, this means a couple of things:

Quality & amount of mapped data

The quality of work done to survey the venue and create the positioning map is of paramount importance for good end user experience. It’s also important that you can rely on one good map – having lots of unfinished tests around will pollute your positioning experience. Today, your first tool in this should be our map accuracy analytics. We will be offering more tools in the near future to help you manage that selection of high-quality venue data.

Difference between Android and iOS

In the application, especially when working on the Android platform, you should be able to rely on the automation, but as with any technology sensitive to the environment it is running in, field testing with the final app in the end user locations is a priority. If you do encounter experience which can not be explained by map analytics, it’s time to dig deeper in the technology itself. This is also when it’s important to understand the difference between Android and iOS.

Those familiar with Apple policies will know that iOS places lots of limitations to apps’ abilities to sense what Apple considers to be privacy sensitive data regarding their environment. Unfortunately, this also limits us from using every possible source of data for the highest possible performance indoor positioning experience, and to reach the same level as we do on Android, sometimes app-level work-arounds come into play as well.

For example; if you’re working on an app intended for a limited number of venues known to you in advance, such as in-store navigation, you may have already experimented with deploying iBeacons or similar technology in the locations. It is possible to take advantage of this effort by signaling the beacons’ known coordinates to the IndoorAtlas SDK. On the roughest level, this can be to signal the floorplan, as is shown in our iOS Getting Started document. You can also go into more detailed position and even post a down-to-the-meter accurate on-time initialization coordinate to the SDK. This might be relevant, for example when a user passes a doorway which you can identify from a beacon signal.

Or perhaps your application has some destination information. When entering a building from an outdoor location, the phone’s own platform location estimate will be accurate enough that you don’t need to do anything, but let’s say you have mapped one store inside a larger venue, but the surrounding area is does not have an IndoorAtlas map yet. If your app has knowledge that the user is reaching that venue, again you can send a hint to the SDK about this.