GeoLocation API first impressions

A couple of weeks ago I built an application using the W3C Geolocation API and thought I’d share my initial thoughts on this emerging technology. The Geolocation API promises to make life much easier for developers working on location based services by making it possible to obtain location information (e.g. GPS coordinates from the device) using browser based Javascript rather than having to get to grips with device specific APIs, platforms and languages.  Normally it would be a serious security risk to allow a web site to access personal information such as your location but the API specification mandates any browser implementing this functionality has to make the user aware that a web site is attempting to access their location and prompt the user to confirm that they are willing to share this information with the web app.  A number of mobile browsers including the iPhone Safari, mobile Opera and Windows IE browser now offer support for the Geolocation API ( along with several desktop browsers) which means that a web application can be ported to several different devices with minimal changes ( more on the reality of portability below).

The application itself was a very simple text search facility for finding academic journals in libraries across the UK. The Geolocation API was used to obtain the coordinates of the user (device) so that the search results could be ordered by proximity of the holding library to the user.  A video clip of the application running on an Android simulator is shown below. In the clip the user is warned that the web application they are accessing will access their location. The user then enters a search term and  results are ordered by proximity of the user  ( in this case EDINA offices in Edinburgh) to the holding library.

The code for obtaining the geo location using the API is pretty simple. For tha Android simulator after importing the Google Gears version of the API  (gears_init.js) The following code was all that was required.

var geo = google.gears.factory.create('beta.geolocation');
window.onload = getposition();
function updatePosition(position) {
document.getElementById('latlon').innerHTML=position.latitude + " " + position.longitude ;
document.getElementById('lat').value=position.latitude;
document.getElementById('lon').value=position.longitude;}
function handleError(positionError) {
document.getElementById('latlon').innerHTML="Attempt to get location failed:" + positionError.message ;}
function getposition(){
geo.getCurrentPosition(updatePosition, handleError ); }

First the geolocation is initialized using the google.gears.factory.create('beta.geolocation');
statement. This initialisation is specific to the Gears implementation of the API which works on Android, Opera and Windows IE browsers. This initializes the geolocation object geo which can then be used to access the methods and objects that comprise the geolocation API. This code should in theory work on any browser implementing the location API, but as I’ll explain in a later post, there are some semantic differences in the way parameters are interpreted and some extensions for particular implementations. To obtain the location of the user the geo.getCurrentPosition method is called. At a minimum. this requires two parameters – both callback methods – one for a successful attempt to access the user’s location, a second for a unsuccesful attempt. In the code snippet above the updatePosition function handles a successful attempt to get the position and uses the position object passed via the geolocation API to update document elements with the longitude and latitude of the device location. Depending on the arguments passed to the geo.getCurrentPosition method different levels of accuracy and additional information on the user location can be obtained. For example, the following

geo.getCurrentPosition(updatePosition, handleError, {enableHighAccuracy: true});

uses the enableHighAccuracy to get the most accurate result even if it takes more time and uses more power. This is a standard attribute but specific implementations allow further options to be set. So in the below, the Gears specific gearsRequestAddress parameter is used to obtain a reverse geocoded address to supplement the position object with attributes such as street name and postcode.

geo.getCurrentPosition(updatePosition, handleError, {enableHighAccuracy: true, gearsRequestAddress: true});


Obviously, adding these kinds of attributes makes the code less portable.  We tested the above code on the Android emulator and a real Windows device ( XDA Orbit). We found that the Android emulator uses reverse IP ( using IP of the desktop PC running the emulator) even when the enableHighAccuracy attribute is set to true. This meant that pushing a new gps fix on the emulator had no effect. We eventually overcame this by setting the gearsLocationProviderUrls parameter to null, forcing the GPS instead. However adding this parameter caused the Windows IE browser on the XDA Orbit to fail to initialize Gears altogether. And of course the IE browser needed to install and activate Gears first before anything would work, adding an extra step to process of getting the web app to work.

Overall then, this first forray into location based web apps using the geolocation API was encouraging. The promise of portability is a little harder to achieve in reality than the API might claim. Next step is to get this working on the iPhone ( which recently added support for the location API ) and see how much we have to change. I’ll blog on developments there. In the meantime, I’ll be getting together with the developers of the Walking Through Time project who have made more extensive use of the Geolocation API for web based mapping on the iPhone using historic Town Plan data.

Advertisement