Location based services (LBS) has been a buzz word and a hype since birth of mobile services. I’m not saying that it is a failure! Many great services have been using LBS with relatively great success. When I say "relatively", it is because we until recently have been quite dependent on what the mobile operators are offering in terms of access to their systems. Not all operators offer such services, the service quality has been to poor, data accuracy not good enough etc. And maybe most important; getting the location is cool, but not always really adding value for the user. I remember an early WAP site in Norway offering the service of finding the nearest ATM from your current position. Technically and theoretically it worked well, but in real life, useless. The wbmp (black and whit bit map image) map pin pointing the ATM made my LCD screen look broken, the system was unable to tell me exactly where I was on the map (at best within a 300 meter radius), so no route description. Easier to ask for directions…
Today, fortunately things are changing. We have GPS on phones and we have lots of geo-tagged content. Google and Yahoo provide extensive APIs, Flickr, Panoramio, LastFM, YouTube to mention a few, are all providing location as metadata to content items. Its even quite common for newspapers to tag news articles with a longitude and latitude.
So, as a believer in the web as a platform for application development, I have done some simple tests and demos on location I hope some of you find interesting.
We have at least 5 ways of getting the location of the end user surfing a mobile site:
- Make the browser talk to the GPS
- Use some kind of 3rd party tools
- Do a location lookup on IP
- Geo coding of user input
- Ask the mobile operator for user location
I have picked a few alternatives to illustrate the above. There are many more APIs and providers out there (feel free to share your favourites!).
Compared to applications you install on your phone, fte biggest obstacle of creating location aware services running in the browser is that you can’t get access to the GPS. This is changing. W3C are specifying a method where the application running in the browser can ask the browser for the users current location. This is done via a javascript API which gets the current location from the GPS or other sources. I guess there will be a fall back chain with IP lookup or even user input, so you’re not dependent on the device having GPS. Rumors say that this geolocation API will be included in the iPhone 3.0 OS. It is really simple; here is the javascript code:
|
1 2 3 4 5 6 7 |
navigator.geolocation.getCurrentPosition( function(position) { alert('Current lat/lon is: ' + position.coords.latitude + ',' + position.coords.longitude); },function(error){ alert('Sorry, could not find you... error code: '+error.code); } ); |
I have also made an example for mobile here. You will need a phone with javascript support to get the most out of the demo, but a desktop web browser will do as well. If you like to test w3c geolocation in real life, Download the beta Firefox or Opera.
Google Gears has a similar solution. Currently, gears will work only in Windows/IE and Androids, but still very cool. The javascript code looks a tad different. After initializing gears with this script you can access location like this:
|
1 2 3 4 5 6 7 8 9 |
var geo = google.gears.factory.create('beta.geolocation'); geo.getCurrentPosition( function(position) { alert(position.gearsAddress.city + ', '+position.gearsAddress.country+'. Current lat/lon is: ' + position.latitude + ',' + position.longitude); }, function (positionError) { alert('Attempt to get location failed: ' + positionError.message); }, { enableHighAccuracy: true, gearsRequestAddress: true } ); |
Google also have a javascript library called "ClientLocation". This library tries to locate your IP address. In a mobile setting this is not ideal, because you are probably connected via your mobile operators gateway, and the gateway will be localized, not you. On wireless spots, your home LAN however, it will probably work good enough.
Include this line of code in your <head> element:
[code][/code]
And access the location data like this:
|
1 2 3 4 |
<script> alert('Current lat/lon is: ' + google.loader.ClientLocation.latitude + ',' + google.loader.ClientLocation.longitude); </script> [ |
Other 3rd party tools to try are for example Loki and Webwm. I am not too familiar with these these, but they seem to work best for desktop web sites. Other 3rd party tools worth mentioning is of course the BONDI project.
Looking up the location of the end users IP is fall back for both Google Gears and the W3C API. You can however, make your own lookup and thereby not be dependent on javascript. Maxmind.com has a few options, both free and commercial. I have tested the free GeoLite City. Its very easy; download the IP database and some API and off you go. The PHP code looks like this:
|
1 2 3 4 5 |
require_once("geoipcity.inc"); require_once("geoipregionvars.php";); $gi = geoip_open(dirname(__FILE__) ."/GeoLiteCity.dat",GEOIP_STANDARD); $record = geoip_record_by_addr($gi,$_SERVER[";REMOTE_ADDR";]); var_dump($record); |
LBS based on IP is, as mentioned, not very accurate. It is useless for providing detailed maps, route descriptions and find-your-nearest-atm-type applications. You need GPS for that. However, its great for whats-happening-close-to-me type applications where you need a city level accuracy of the users location. You can test GeoLite City here.
You can also ask the end user to provide a location. Google, among others, provide a geo coding tool. An API translating a human readable name to coordinates. The API can pin point you at any level of a curacy, country, city or street address. PHP code for this API:
|
1 2 3 4 5 6 |
$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, "http://maps.google.com/maps/geo?q=".urlencode($address)."&output=json&oe=utf8&sensor=false&key=yourkey"); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $reps = curl_exec($ch); curl_close($ch); var_dump(json_decode($output,true)); |
And now to the last example; asking the mobile operator for the users location. This method is of course very dependent on what the various mobile operators out there provide and allow. The biggest disadvantages with this method is that you in most cases need the end user’s mobile phone number and that the user needs to be connected to internet through his mobile operators network. There are privacy issues attached to that, of course… So, if you want to implement the mobile operators way of doing location lookups, you need to decide which to target, and then do the required integrations to their various APIs which can be a challenging job. Or you can use an aggregator. Then you get away with only one API. In the example i have used Mobiletech which is an aggregator covering the Scandinavian operators.
In the "i-mode world" ther is a slightly different way of solving the issue. You just create a link like this [code]locate me[/code] and your server is provided with location. Read more on the wirelessfaq. GSMA are also working on a project trying to standardize the mobile operators APIs, including location lookups.
So, lots of ways to get the longitude and latitude. Useful for pin pointing a location on a map, but what if you need the users address? For example you could help the user fill in a order form (as we know, very cumbersome on mobile). Google provide a reverse geo coding service. Put the lat/long in, and get the street address out. Very neat.
These are a few of the options and APIs you have when creating a location aware mobile web application running in the browser. There are many more out there, so please feel free to share your favorite APIs, tools, tricks and services.
Location is truly putting meaning into the word "mobile"!
10 Comments
An alternative approach is to use the X header format and simply add the “device data you need” to the outgoing HTTP request headers (via the mobile browser)
Cheers,
Peter J. Cranstone
CEO 5o9 Inc