Visitors to GeoMeme choose a location on the map, and two search terms to compare. GeoMeme then measures and compares the number of matching tweets within the bounds of the map, based on public data from a number of mobile twitter apps.

As an example, GeoMeme can work out that ‘love’ beats ‘hate’ in Manhattan:

GeoMeme is a desktop web application and also a location-aware mobile web app for iPhone and Android phones.

Implementing the mobile version of GeoMeme as a web app has some advantages and disadvantages, compared to building native iPhone &/or Android applications.

Native apps are great because they currently offer the deepest integration to the full capability of the phone, for example using device APIs to access Contacts, the Camera Roll, an Accelerometer, or the GPS chip. For some applications, this deep device integration is essential and so a native application is beneficial.

On the other hand, emerging HTML5-based mobile browsers are aiming to standardise integration to such device APIs, starting with Geolocation APIs; meaning that location-aware mobile web apps are now becoming viable. Aligned with this development is the new version of the Google Maps API. v3 has been greatly simplified since v2, and is now optimized for use on mobile phones. Less is more.

The deciding factor for me choosing to build a mobile web app for GeoMeme rather than a native app was development speed. A mobile web app enjoys far greater code re-use from the desktop web version, and it is possible to push regular updates and improvements to users, without having to wait for appstore approval or for users to upgrade.

I believe this need for development speed is common among a good proportion of mobile apps that are still in ‘rapid iteration’ or ‘release early, release often’ mode, so this post is intended to share some of the techniques used in GeoMeme with developers wanting to build their own location-aware mobile web apps.

Let’s build an example location-aware mobile web app called ‘Here I Am!’, for the photographically challenged. The app will present some local photographs (from Panoramio) which can be shared with friends on Twitter or Facebook.

Where on earth is that mobile phone..?

The first job of a location-aware mobile app is to work out where on earth the mobile phone currently is. Unfortunately, at the time of writing, there is still no universally reliable and accurate solution for a mobile web app to detect the location of the mobile phone it is running on. However the following partial solutions can be combined to good effect:

a) Google Loader

Load the Google Maps v3 API using Google Loader:

<script type="text/javascript" src="http://www.google.com/jsapi?key=YOUR_API_KEY&autoload=%7Bmodules%3A%5B%7Bname%3A%22maps%22%2Cversion%3A3%2Cother_params%3A%22sensor%3Dtrue%22%7D%5D%7D"></script>
<script type="text/javascript">
google.setOnLoadCallback(function() {
    // initialize the mobile map...
});
</script>

Google Loader requires developers to sign up for an API key, however the advantage of this approach is that the approximate location of the user is revealed, based on network IP address.

In the case of a mobile phone user, this network IP address often refers to the mobile operator’s internet gateway, which can be shared between a large number of subscribers spread over an entire country. This technique becomes more accurate for mobile phones which are connected to the internet via wi-fi rather than GPRS, or becomes less accurate for some phones (e.g. Blackberry) which can connect to the internet via international proxy servers.

Generally, this technique can be successful in working out which country the user is in, but cannot be assumed to be any more accurate than that.

Some example javascript to locate a map based on Google Loader:

if (typeof(google.loader.ClientLocation) != 'undefined') {
	var lat = google.loader.ClientLocation.latitude;
	var lng = google.loader.ClientLocation.longitude;
	var position = new google.maps.LatLng(lat, lng);
	map.setOptions({
		center: position,
		zoom: 10
	});
}

b) W3C Geolocation API

The World Wide Web Consortium (W3C) has been working since 2008 to standardise web geolocation APIs.

Mobile Safari on iPhone (since OS3.0) already supports the emerging W3C standard, to expose location information derived from its GPS chip. The new Chrome mobile browser on Android (from 2.0 Eclair) will also support this standard. For example:

if (typeof(navigator.geolocation) != 'undefined') {
	navigator.geolocation.getCurrentPosition(function(position) {
		var lat = position.coords.latitude;
		var lng = position.coords.longitude;
		var position = new google.maps.LatLng(lat, lng);
		map.setOptions({
			center: position,
			zoom: 15
		});
	});
}

The W3C Geolocation API looks likely to feature as part of HTML5 (the next major revision of HTML), and will also be supported by the next generation of Webkit-based mobile browsers, so expect this technique to start working on an increasing proportion of new mobile phones.

c) Google Gears for Mobile

Gears adds a number of HTML5 features, including a Geolocation API, to legacy web browsers. Although it is possible for Windows IE Mobile and Mobile Opera browsers to become location-aware in this way, the bigger opportunity here is that Android phones (from version 1.0 through 1.6) come with Gears already pre-installed. This means that we can detect the location of these Android phones with the following javascript:

if (typeof(google.gears) != 'undefined') {
	var geo = google.gears.factory.create('beta.geolocation');
	geo.getCurrentPosition(function(position) {
		var lat = position.latitude;
		var lng = position.longitude;
		var position = new google.maps.LatLng(lat, lng);
		map.setOptions({
			center: position,
			zoom: 15
		});
	});
}

Google Gears for Mobile works out the location of a mobile phone from the GPS chip in the phone, or by crowdsourcing the location of the cell-tower to which the mobile phone is connected.

… and fetch me some location-based content, fast!

Once your mobile web app is location-aware, the next thing to do is to retrieve some relevant content, based on current location. GeoMeme retrieves local tweets using the Twitter API, but for ‘Here I Am!’ we’ll retrieve local photos from Panoramio (see http://www.panoramio.com/api/ for details of the API).

Google Maps v3 API includes a convenient new ‘idle’ event which is fired when the map becomes idle after panning or zooming, or after automatic geo-location using the techniques above. By listening for this event, we can fetch the most popular local photos from Panoramio whenever the map is moved. For example:

google.maps.event.addListener(map, 'idle', function() {
    loadPhotos();
});

function loadPhotos() {
    var url = 'http://www.panoramio.com/map/get_panoramas.php?order=popularity&set=public&from=0&to=20&size=mini_square&callback=addPhotos';
    var bounds = map.getBounds();
    url += '&minx=' + bounds.getSouthWest().lng().toFixed(6) + '&miny=' + bounds.getSouthWest().lat().toFixed(6);
    url += '&maxx=' + bounds.getNorthEast().lng().toFixed(6) + '&maxy=' + bounds.getNorthEast().lat().toFixed(6);
    url += '&ts=' + new Date().getTime(); // prevent caching

    // use JSONP to retrieve photo data
    // and trigger a callback to addPhotos()
    var script = document.createElement("script");
    script.setAttribute("src", url);
    script.setAttribute("type", "text/javascript");
    document.body.appendChild(script);
}

The above code sends the resulting JSON data to the addPhotos() callback function, which handles the display of the photos on the map using Icons, another new feature of Google Maps v3 API.

For speed, we also implement a performance optimization here. Existing Icons are re-used, rather than simply removing and adding new Icons each time the map is relocated:

var markers = {};

function addPhotos(data) {
	var new_markers = {};

	for (var i = 0; i < data.photos.length; i++) {
		var photo = data.photos[i];

		// for speed and to reduce flicker,
		// reuse existing markers rather than removing and re-adding
		if (photo.photo_id in markers) {
			new_markers[photo.photo_id] = markers[photo.photo_id];
		} else {
			// create new marker
			marker = new google.maps.Marker({
				position: new google.maps.LatLng(photo.latitude, photo.longitude),
				icon: photo.photo_file_url,
				map: map
			});
			new_markers[photo.photo_id] = marker;
		}
	}

	// remove old markers
	for (var photo_id in markers) {
		if (!(photo_id in new_markers)) {
			markers[photo_id].setMap(null);
			delete markers[photo_id];
		}
	}

	markers = new_markers;
}

‘Here I Am!’ – a simple location-aware mobile web application

The final part of ‘Here I Am!’ is a feature to share one of the Panoramio photos to friends on Twitter or Facebook. This is done using ordinary web links to Twitter and Facebook share pages. No complex platform integration is required for web apps to do this because, as they say, “the web is the platform.” Simply click on a photo on the map and follow the prompts.

Visit http://j.mp/lbsdemo on your mobile phone to try out ‘Here I Am!’

The full source code of ‘Here I Am!’ (weighing in at just under 8Kb) can be located here.

The app has been tested to work on iPhone, iPod Touch, Android, and Symbian Series 60 (which remains – for now at least – the dominant device family for mobile data consumption).

I hope you enjoy using some of these ideas in your own location-aware mobile web apps.

This post is one of a series that aims to share some of the technology innovation that can be found in GeoMeme. Other posts cover topics such as using Google App Engine for scalable and fast hosting of your location-based content, and fast map re-location using Google Static Maps v2.

Visitors to GeoMeme choose a location on the map, and two search terms to compare. GeoMeme then measures and compares the number of matching tweets within the bounds of the map, based on public data from a number of mobile twitter apps.

As an example, GeoMeme can work out that ‘District 9′ beats ‘Inglorious Basterds’ in Manhattan.

As well as offering users the normal pan and zoom controls to move the map around, GeoMeme also introduces an innovative geo-autocomplete control which is powered by the geocoder service from Google Maps v3 API and the new Static Maps v2 API.

This blog post shares some details of how the geo-autocomplete control works, and offers some code so you can build your own geo-autocomplete controls.

1. Based on a partial location typed by the user, obtain a list of possible matching locations:

If the user has already typed ‘San’ into a form field, we can obtain a list of possible matching locations by passing this partial location to the geocoder service from Google Maps v3 API, as follows:

var partial_location = document.getElementById("location").value;
var geocoder = new google.maps.Geocoder();

geocoder.geocode({'address': partial_location}, function(results, status) {
    if (status == google.maps.GeocoderStatus.OK) {
        document.getElementById("results").innerHTML = '';
        for (var i = 0; i < results.length; i++) {
            showResult(results[i]);
        }
    } else {
        document.getElementById("results").innerHTML = 'Geocode was not successful for the following reason: ' + status;
    }
});

function showResult(result) {
    document.getElementById("results").innerHTML += 'It could be: ' + result.formatted_address + '<br/>';
}

2. Decorate these possible matching locations with a Static Maps thumbnail to help the user choose the right one:

The geocoder returns more than just a formatted address. The full response is a JSON object of the following form:

results[]: {
    types[]: google.maps.GeocoderLocationType,
    formatted_address: String,
    address_components[]: {
        short_name: String,
        long_name: String,
        types[]: String
    },
    geometry: {
        location: LatLng,
        location_type: String,
        viewport: LatLngBounds,
        bounds: LatLngBounds
    }
}

geometry.viewport represents the recommended viewport for each returned result, from which we can derive the required Static Maps URL, as follows:

function showResult(result) {
    var src = 'http://maps.google.com/maps/api/staticmap';

    // the visible parameter specifies one or more locations
    // to show on the map. so we need to specify the south-west
    // and north-east corners of geometry.viewport
    src += '?visible=' + result.geometry.viewport.getSouthWest().toUrlValue() + '|' + result.geometry.viewport.getNorthEast().toUrlValue();

    // other parameters as per http://code.google.com/apis/maps/documentation/staticmaps/#URL_Parameters
    src += '&size=100x100&maptype=terrain&key=YOUR_API_KEY&sensor=false';

    document.getElementById("results").innerHTML += '<img src="' + src + '" /> ' + result.formatted_address + '<br/>';
}

Working out the required Static Maps URL is now a much simpler task with v2 of the Static Maps API, because there is no longer any need to manually calculate a zoom level or latitude / longitude span values.

You can see this working on GeoMeme by clicking on the location control at the top of the screen and entering a partial location. When you choose from the list of possible matches, the main map is moved to that location, providing a refreshingly quick way for users to re-position the map.

You can also download a hello world example here, built as a jQuery plugin to work with a modified version of the excellent Autocomplete plugin:

Using this geo-autocomplete plugin is recommended because it includes a number of features which protect the geocoder service from being hit too often. Including; waiting for keystrokes to stop before sending a request to the geocoder, waiting for a minimum number of characters to by typed, and caching geocoder responses to avoid duplicate requests. Options are also available to set the size and maptype of the Static Map thumbnails.

Update: geo-autocomplete has been rebuilt upon the jQuery UI framework, as a UI Widget rather than a jQuery plugin, with more powerful options for customization.

This post is one of a series that aims to share some of the technology innovation that can be found in GeoMeme. Other posts cover topics such as location-aware mobile web apps using Google Maps v3, and scalable geo apps using Google App Engine.

A study carried out in the early 1990s demonstrated that pedestrians’ speed of walking provides a reliable measure of the pace of life in a city, and that people in fast-moving cities are less likely to help others and have higher rates of coronary heart disease.

Using identical methods to those employed in the previous work, the present day research teams discovered that the pace of life is now 10% faster than in the early 1990s. The biggest changes were found in the Far East, with the pace of life in Guangzhou (China) increasing by over 20%, and Singapore showing a 30% increase, resulting in it becoming the fastest moving city in the study. More here from Richard Wiseman.

I find that rate of evolutionary acceleration a bit unnerving. And here I am, sleepless in Sydney at 4am, waiting for baby to arrive and now wondering if there’s any geo dimension to all of this. So here goes:

1. A Google spreadsheet of the data
2. geo-coding from Geonames, imported into the spreadsheet using importXML
3. a flickr photo of someone walking in each city, imported into the spreadsheet using importFeed via a Yahoo Pipe. The photos don’t look too releveant, maybe I need to clean my pipe.
4. some Google Maps code generated from Pamela Fox’s Spreadsheet Map Wizard

Space/Time poverty: how fast do people walk, where?

Click on the markers or list to see how fast.