sqrt((power(69.1 * (latitude1 - latitude2),2) + power(69.1 * (longitude1 - longitude2) * cos(latitude1 / 57.3), 2)))

The Yahoo! geocoding API is pretty nice for getting lats and longs for addresses in the US:

http://developer.yahoo.com/maps/rest/V1/geocode.html

Probably can't tell you how we solve it at work, but the very much publicly-available book Computational Geometry: Algorithms and Applications, Third Edition by de Berg, Cheong, et al., mentions something about the robustness of geometric algorithms using inexact (floating point) vs. exact arithmetic. :-)

Thanks for the recommendation, most of the maths work I do these days is financial, so geometry is a nice diversion. I hadn't seen this text before so I've got it bookmarked for some reading now.

As an aside, is this something I would have gotten some exposure to if I'd been a college grad? Any time I see things like this, I worry there are large swaths of text I've missed in self-study.

You might have had some exposure to the subject, but probably as part of other problems, i.e. not under the name Computational Geometry. For me, the most valuable thing was learning that this was an actual field with a name, which gave me a starting point for self-study.

Also check out Computational Geometry in C, Second Ed., by O'Rourke. It goes into more low-level implementation details (the first book I mentioned is a good high-level introduction to reasoning about geometric algorithms, so you should read that first).

There are tens of millions of mainstream handsets on the market that contain GPS, including virtually all phones sold by Sprint and Verizon in the past few years and most new AT&T phones going forward. However, location is typically locked down and requires a relationship with the carrier to access the handset location APIs. For location privacy and business reasons, making a deal with a carrier for a location-enabled application is often a multi-year process.

The other possibility is to target smart phones such as the Nokia N95, iPhone, Blackberry, Windows Mobile, or Android that provide more open access to location. This is a good audience of early adopters with high data usage, but it's a very small percentage of total phones on the market.

Handsets using carrier-assisted GPS will typically have better performance than smartphones. The 'autonomous GPS' in most smart phones takes a long time to get an initial fix and is less accurate than carrier assisted, or aGPS handsets, which utilize cell towers on the network to enhance performance. Note: The new iPhone will combine GPS, Wi-fi, and cell tower location and so should be fairly fast and accurate.

One means by which developers can gain access to location across multiple carriers is through WHERE http://developer.where.com (caveat: i work there).

I'm working on a white paper covering all of this in more detail. If you're interested in getting a preview copy, let me know.

Most Windows Mobile devices in the US don't allow access to GPS or have it deliberatly crippled (The Sprint Mogul and AT&T Tilt are the only two I know of with user accessible GPS).

iPhone is still an unknown, as I doubt Apple will open up its app store to every developer and every app. Right now it's probably best to wait and see.

Android is, well, not out yet. Wait for a device to make it to market.

WHERE is also a fast easy way to get one shot fixes and rapidly deploy an application to the millions of "feature phones" out there already, but it won't give you background updates or complete control over the user experience.

http://del.icio.us/jmatt.peterson/location

There are a lot of APIs if you are going from address, city, zip. All sorts of variations - free, commercial, metadata, super accurate, international, US only, shipping, etc.

There are fewer and they are less reliable if you have a latitude / longitude and want address, major intersection, city, etc.

Initially I'd code for phones that provide basic location information like lat/long/precision. Personally I've written code for the iphone and android. I'd avoid any of the older phones that don't provide some sort of API. Your initial users presumably will be techies with newer phones. If you have some initial success you can add support for older phones that don't have a friendly API.

However, I am looking to use the GPS or tower triangulation built into newer phones. I'm assuming this is available through the ipHone and android APAs?

Is any of your code open-source by any chance? Just looking for some tips as to how to get started - even the basics.

(See also, the location category index http://wiki.forum.nokia.com/index.php/Symbian_C%2B%2B_Locati... )

Yahoo recently released an updated version of the Where On Earth (WOE) API for Where 2.0 (more info at http://developer.yahoo.com/geo/).

It's pretty cool, I especially like the way that WOE deals with hierarchy in places. So a street address is normally part of neighbourhood or area of a city, which is part of a state, etc.

One of my other favourite projects at Y! at the moment is also about LBS. Fireagle is one of the Brickhouse projects, so those guys are actually based in San Francisco. http://fireeagle.yahoo.net is still invite only, but that's mostly to hide it from consumers until it's ready to go. Fireeagle acts as middlewear, allowing users to update their location in lots of ways through an API (Text string, GPS units, Cell phone via services like Navizon, etc) and then share is with apps of their choice. This means that the user only has to update Fireeagle to update all their apps.

It also means app developers don't need to provide lots of ways to specify location. They can just use Fireeagle and forget about the rest.

I have some invites so if you have a good idea let me know and I'll hook you up.

http://www.hackaday.com/search/?q=gps

http://del.icio.us/pskomoroch/gis