The WinRT Location API: Where did my location data come from?

For those developing location-aware Windows Store Apps for Windows 8, the Windows Runtime (WinRT) provides location data to the developer via the Location API. This location data presents the best possible position information available to the system from the underlying hardware and software location sources. Essentially, the Location API object serves as a sort of abstraction layer: the application can obtain position information, but it does not have direct visibility into which locator device generated it. Did your location fix come from WiFi triangulation or a GPS update? There is no way to tell, and for applications that might depend on high precision updates, the developer is faced with a fundamental problem: how do we know whether or not a particular position report is one that you want to use?

To answer this question, we first should take a high level view of the data flow for the Location API:

A Location Provider is a Windows driver that supplies location data to the Location API. The location provider takes location data from the underlying source which can be a hardware device such as a GPS, or a software layer such as an IP address. The Location API reads the input coming in from the various providers, and chooses the best position information from among them. Windows 8 ships with a "default" location provider, named the Windows Location Provider. According to Microsoft, the Windows Location Provider "supplies apps with location data based on Wi-Fi triangulation and IP address data". Hardware manufacturers would need to develop providers for the devices they produce.

This abstraction does provide some advantages. Primarily, it is not tied to a particular hardware device or position source. Most people are familiar with GPS, the Global Positioning System, because of its widespread commercial adoption for navigation systems but it is not the only player in the game. The European Space Agency, to name one example, has been slowly building a positioning system named Galileo, and adding support for it to the Location API would be as simple as adding a driver for a Galileo receiver. 3G and 4G connectivity also brings the possibility of cell tower triangulation. As new positioning options become available, only drivers are needed to glue them to the Location API, and the applications would not need to be modified to make use of them. Another advantage is that it allows applications to obtain position data without having to concern themselves with what hardware the underlying computer platform actually has, the details of interacting with it, or whether or not that hardware is even functioning.

The downside is that you lose details. You don't explicitly know which location provider is responsible for your fix. For specific hardware receivers, you also lose device-specific information. There is no way, for example, to get acquisition status from a GPS receiver such as how many satellites are visible, how many have been found, and which ones are locked. You also don't know whether or not your underlying location providers are even functioning, much less reporting a valid position fix at all.

How does the Location Sensor determine the "best" position source? It is based on the reported accuracy, with higher-accuracy sources given preference over lower-accuracy sources. What this means is that your underlying location provider may actually change as sources come on and off line, or as external factors, such as signal strength and quality, change with time and position. When a device is turned on, for example, the GPS receiver may still be acquiring a fix when the system has finished booting. The Geolocation sensor might need to rely on the Windows Location Provider (using Wi-Fi triangulation) to provide position updates until the GPS acquires a fix with a sufficient level of accuracy to override it.

There is a corollary to this process, however, and it is a very important one: if your high precision location provider loses a fix (such as a GPS that moves indoors, under heavy tree cover, or  into an urban canyon situation where tall buildings obstruct the sky view) then the Location API will revert back to a lower position source, and possibly one with a less-than-desirable level of accuracy. This may not be a problem for, say, a weather app where position to within a few kilometers is good enough, but for a car navigation app? Such a change could be problematic.

How do you ensure your app is getting the location precision that it needs?

Accuracy

The first action you should take is to examine the Accuracy property of the Geocoordinate object. Per Microsoft, Accuracy is a double value that reports the accuracy in meters. Typical accuracies for common devices are:

Reported
Accuracy

Likely Source

1 - 10

GPS with a good position fix

10 - 100

GPS with a poor position fix (usually caused by a limited sky view ), or an initial position acquisition that is still being refined as more satellites are found and locked

100 - 350

WiFi triangulation (via Windows Location Provider)

>=25,000

IP address resolution

Of course, this list is not comprehensive but it can help the developer make a reasonable guess as to where the location data came from. An accuracy of between 100 and 350 meters is almost certainly going to be from Wi-Fi triangulation, and position from a GPS should be much less than this. If an application sees the accuracy jump from a couple of meters to over 100, then one might reasonably assume that the Location API has fallen back to Wi-Fi triangulation.

Accuracy alone, however, doesn't tell the whole story.

Update frequency

In a high-precision application, such as vehicle tracking, environments where the sky view is impaired can result in poor GPS reception and very low accuracies. Tunnels, heavy tree cover, and cities with high-rise buildings can all result in poor signal quality due to interference, reflected signals, and complete loss of reception. Under such conditions, GPS devices may report accuracies of tens of meters or worse, and might even result in values that are more consistent with lower-precision sources. In this case, the update frequency from the Location sensor may offer an additional clue as to the source of the location data.

A GPS device is constantly tracking signals and updating position information, and the nature of GPS reception is such that even a "stationary" object has some jitter in its position. If you have set the DesiredAccuracy property of the Geolocation object to High, then you are asking the Location API to give you the best possible position tracking at the expense of power savings, and with a GPS device this can result in one or more PositionChanged events per second (the exact update rate will depend on the underlying hardware and driver). Wi-Fi triangulation and IP address resolution from the Windows Location Provider, in contrast, appear to update no more frequently than once a minute.

If an application sees location reports coming in frequently, but with low positional accuracy, then one could assume that the device is still receiving GPS signals but is suffering from poor satellite reception. If, on the other hand, the accuracy is between 100 and 350 meters and not updating frequently, then its reasonable to assume that Wi-Fi triangulation is the source.

Speed and Heading

Only high-precision sources such as GPS will offer a speed and heading. If your speed and heading are non-NULL, no matter what the accuracy, you can be almost certain that your location data is comeing from GPS. Note that GPS receivers calculate speed using Doppler shifts in the GPS signals, so even a poor quality satellite fix with an accuracy of tens of meters (or more) can present accurate speeds.

What about Altitude?

At first glance, another clue appears to come from the Altitude property of the Geocoordinate object. Wi-Fi triangulation and IP address resolution do not report an altitude, meaning this property will be a null value. Only high-precision sources with 3-D tracking capabilities, such as GPS, will report an altitude. However, this is not as useful as it appears: a GPS device that is tracking only three satellites cannot determine altitude: it takes four satellites for a 3-D fix. Thus, it is possible to have a "weak" 2-D fix from a GPS device and therefore no altitude component.

Putting it all together

Though the Location API does not expose the underlying source for its position data, the developer can generally infer the source by looking at a combination of positional accuracy and update frequency. Of course, the end user probably is less concerned with the details of the position data than they are with the position data itself-- in fact, the Location API pretty much assumes this to be the case-- but there is still merit in understanding the former. Depending on the application, it may even be desirable to share this information with the user.

And as a developer, knowing the source of your location data may also help you debug your location-based application and the underlying hardware. Knowing where the Location API is getting its location data from is the first step in understanding where it might be going wrong.

Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.