Decoding the CLLocationAccuracy const's

the following are listed in CLLocation.h but from my experience they are deceiving names- possibly originally thought up to serve two purposes, 1. to test the accuracy of the location returned, but also 2. to set how hard the location manager works, specifically what is enabled (gps (how many sat channels), how hard the wifi works, triangulation etc.

extern const CLLocationAccuracy kCLLocationAccuracyBestForNavigation; // (raw value: -2)
extern const CLLocationAccuracy kCLLocationAccuracyBest; // (raw value: -1)
extern const CLLocationAccuracy kCLLocationAccuracyNearestTenMeters; // (raw value: 10)
extern const CLLocationAccuracy kCLLocationAccuracyHundredMeters; // (raw value: 100)
extern const CLLocationAccuracy kCLLocationAccuracyKilometer; // (raw value: 1000)
extern const CLLocationAccuracy kCLLocationAccuracyThreeKilometers; // (raw value: 3000)

I would love to take a look at CLLocation.m, but as that is not likely to happen any time soon- does anyone have any field testing showing what they think is going on with these different modes.

ie, kCLLocationAccuracyBest = 10 satellite (channels/trunks?), 100% power to wifi etc..

I'm kind of guessing开发者_StackOverflow中文版 at straws here- I think this is the type of information apple should have provided-

what I really want to know is, what is actually happening with kCLLocationAccuracyThreeKilometers in relation to battery draw- is the gps on? 1 sat trunk? wifi enabled? wifi on a timer? who knows? I know I'd like to

I agree with Olie that hiding the details of the algorithm is intended to protect the app developer from worrying about how location is determined. That said, I believe it's still reasonable to ask the question: "what are the power implications of my accuracy selection?".

I have a little bit of information that might guide your decision on which to use, but I don't know the true details of Apple's implementation.

First, assume that as the reading becomes more accurate, the system will need to use more power-hungry radios. For example, the GPS will be required for the most detailed readings, inside 100 Meters, and it uses the most power.

Here is an educated guess at the mechanism used to determine the accuracy. List is ordered with (1) being the highest battery drain.

1. GPS - kCLLocationAccuracyBestForNavigation;
2. GPS - kCLLocationAccuracyBest;
3. GPS - kCLLocationAccuracyNearestTenMeters;
4. WiFi (or GPS in rural area) - kCLLocationAccuracyHundredMeters;
5. Cell Tower - kCLLocationAccuracyKilometer;
6. Cell Tower - kCLLocationAccuracyThreeKilometers;

When choosing, it is recommended by Apple that you select the most coarse-grained accuracy that your application can afford.

Hope that helps, a.little.

In the business district of a major city, wifi and cell tower triangulation are both very good. Residential suburbs they're not so good. In rural areas they barely work if they work at all.

GPS doesn't work very well indoors, and can take a very long time to get any fix at all without cell tower assistance (possibly 20 minutes!!). It takes that long for the satelites to broadcast enough information to determine your location, and there can be packet loss (clouds, buildings, trees, mountains, etc). It's worth noting that a proper high end GPS will have an antenna the size of a basket ball, no handheld GPS can get a perfect signal.

Even outdoors with perfect signal, GPS is inaccurate when you change direction rapidly (such as on the highway or a windy road). The BestForNavigation setting uses the accelerometer and gyroscope to offset this.

Currently, the iOS platform uses:

• GPS: very accurate, but high power draw, slow and not always available. some hardware doesn't have a GPS.
• WiFi: lots of power draw, and only works in the city. Can also be flat out wrong (eg place you in the wrong city)
• Cell Tower: almost no power draw at all, and works well in the city. Not so great in rural areas. Doesn't exist on some hardware.
• Accelerometer: slight improvements to other location fixes, but huge power draw.
• Gyroscope: slight improvements to other location fixes, but huge power draw. iPhone 4 only.

You give it an accuracy in meters that you need (the constants are just nice names for meters), and it will use a combination of the above, to get you that level of accuracy with the fastest possible fix and lowest possible power draw. The technique it uses will change, from one user to another, and will change depending on where in the world the user is standing at the time.

The whole point of using extern rather than exposing what is actually happening is so that the under-gerwerkkins can change and your code doesn't have to worry about it to pick up the improvements.

That said, CLLocationAccuracy is typedef-ed to double, so I think it's fair to guess that kCLLocationAccuracyNearestTenMeters = 10.0, kCLLocationAccuracyHundredMeters = 100.0, etc. Best is likely either 0, 1 or kCLLocationAccuracyNearestTenMeters, and BestForNavigation is probably one they tossed it to help folks like TomTom, etc.

If you REALLY want to know, you can print out the values -- they're just doubles.

I do not believe that the number of satellites or power to wifi is altered based on your desired accuracy. The way I understand the algorithms, there is an approximation calculation that, the more times through the loop, the more accurate it gets. Hence, less-accurate just bails earlier.

But, again, the more important point is: it doesn't matter. Apple specifically doesn't describe what goes on behind the scenes because that's not part of the design. The design is: if you use kCLLocationAccuracyKilometer, you'll get an answer that's within a kilometer, etc. And Apple is now free to change how they arrive at that without you caring. This sort of isolation is a basic tenet of object oriented programming.

EDIT:

CORRECTION -- I'm just now watching the WWDC session on location (Session 115) and, at about 22:00 or so, he talks about how, when using BestForNavigation, this adds in some gyroscope correction (when available.) However, he warns that, while this is power & CPU intensive, and should be only used when necessary, as with turn-by-turn navigation.

I'm not sure how much more I can talk about this publically but, if you're a registered developer, you can get the sessions from iTunes-U.

(This is WWDC-2010, btw.)