I have been thinking about mobile location based services (LBSes) for a long time. My typical user story is, "Alice and Bob are eating dinner in a restaurant. They decide they want to see a movie. Using her phone, Alice looks up nearby movies, theaters, and show times and buys two tickets to the next showing of a fun movie. They pay their bill and go to the theater." Other user stories have them looking for a cafe or a night club. Whatever it is, they are away from their home PCs, they have a mobile connected device, and they want information that is relevant to their current location.
Moviefone's mobile web site solves the user story. You tell it your zip code, and it tells you about the movies, theaters, and show times near you. One problem with this is that you might not know your current location's zip code. Another problem is that zip codes are geographically large. The nearest movie theater in my zip code is two miles away, but the nearest movie theater is only one mile away, in another zip code. The ideal LBS automatically knows where you are and has good precision.
The iPhone Google Maps application is compelling because it locates you automatically, using cell tower triangulation, WiFi access points, or GPS on iPhone 3G. In one very poorly controlled test I conducted, it takes about 5 seconds for Maps to locate you by cell tower, another 5 seconds for the more accurate and precise WiFi location, and another 20 seconds or so for the very accurate and precise GPS location. (These are very rough timings, to be taken with a grain of salt.) iPhone exposes this to developers through the Core Location API. On Windows Mobile, Google Gears exposes a similar API to developers. What APIs are available to other developers, or to developers who want a generalized way to locate the mobile user?
OpenCellID is an open database of cell tower IDs and their geographic coordinates. The first problem is that it is incomplete. For example, there are no database entries for cell towers in Western Massachusetts or on Cape Cod. You might be able to pay another provider for more complete data, but you would encounter the next problem: it is difficult to obtain the local cell IDs through the phone. Most handsets do not expose location data, through
JSR-179 or any other accessible API, and carriers do not expose cell tower IDs through WAP HTTP headers. Finally, cell tower based location is not precise enough to solve some problems, such as what street am I on. On the positive side, finding location by cell tower is fast, and might be precise enough for some applications (what city am I in?).
WIGLE is an open database of WiFi access point SSIDs and their geographic coordinates. WIGLE's static and interactive maps show the amazing density of WiFi access points in urban areas. In the city, a WiFi based location can be very accurate, and precise enough and fast enough for most applications. The advantage over GPS is that it works inside buildings, where GPS might not work. The primary disadvantage is that the device might not have a WiFi radio or it might be too far away from a WiFi network. (Thanks to the
Adeona FAQ for pointing me to WIGLE.)
If you are building a location based service, cell tower ID and WiFi access point SSID are two pieces of information that you might be able to use, either in the absence of GPS or as an alternative to GPS. WiFi SSIDs are probably the best approach for users stories like "Alice and Bob are eating dinner in a restaurant..."
Posts
