What is the best way to architect a "find nearest" location-aware application on the iPhone?

Question

I would like to build a location-aware application that automatically detects a user's location and presents them a sorted list of the nearest landmarks from a landmark database. The application will be built on the iPhone.

The fundamental questions are:

1. How to calculate the distances to nearby landmarks and sort by "closest"
2. Where to perform the calculations - on an external server via a web service - or on the iPhone itself via an SQLite database and/or Core Location

Ideally, the application would calculate the distances using "routed distance" as opposed to crow-flies distance (i.e. greater circle distance formula), being the more accurate method. Of course with this comes a cost - it will be much slower to calculate. I would like to know what method would be most appropriate.

Also, the advantage of performing the calculations on the phone itself (using Core Location?) is that there is no need for talking to a server (faster) and the app may be used without an internet connection. The disadvantage lies in the difficulty of keeping the landmark database synchronized with the newest data.

I would like to know if there is an industry standard way of implementing a location-aware application such as this. If not, please suggest the best possible solution to the problem.

Answer 1

I would recommend a two-tier solution for most of your issues. Do gross-level decision making with the fastest solution, then use fine-level decision making with your top hits. For instance, to your question of whether to store on the device or on the server, I would recommend storing "localish" things on the device based on the user's last position. That is to say that things the user was near before she will likely be near again, so those things should be synced down. As the user moves out of an area, things from that area should be moved down the least-recently-used list and eventually purged. So when you go to a new location, it'll be slow for a while, but over time will speed up.

Regarding sorting, again, two tiers is best. Sort first by crow-flies. Then you can sort your top hits by routing if routing is cheap (though it probably isn't). If the user will only see 20 hits, then it doesn't matter whether some entry would have been #80 or #100. It's too far down to care, so it's too far down to calculate.

In general regarding sorting on the iPhone, I highly recommend speed over accuracy. If something should have been #1 and is actually #3, that's doesn't matter nearly as much as it taking 20 seconds to calculate versus 5.