We decided we’d need to find a way to put pictures on the map quite early on, knowing Gemma couldn’t be the one to stop and take them. Rather than try to pin a camera to her vest or strap one to a hat, the simplest solution was to find photos taken by spectators.
The Instagram API is fairly new and the app itself is getting extremely popular. Being mobile-based, we hoped it would be popular among spectators on the day, taking quick snaps and hopefully uploading a good amount of photos to dig around in.
The pictures are geo-tagged as well as captioned, so we could perform location queries and text-based searches (ultimately, a combination).
Firstly we agreed on places around which we’d search for pictures — busy spectator spots and London’s landmarks.
The idea was to look for pictures at these places as Gemma passed them. So we translated them into distances, i.e. determine the elapsed distance that would have been run when reaching each of these places.
Tower Bridge, for example, is at 12.5 miles. Big Ben is at 25 miles and so on — for about 10-15 hotspots.
The application monitored the total distance covered and at each of these key numbers hit the Instagram API for the most recent pictures around the location.
Setting up an Instagram application is instantaneous, though I waited a long time for my API key initially — I did apply when the announcement was first made however, so the turnaround may be a lot faster now.
There’s no moderation or application approval process, when you’re up and running you can start performing queries immediately.
The API is RESTful over HTTPS with a number of endpoints to query images, comments, users, locations, tags and so on. The developer docs are fairly comprehensive.
We’re interested in the media endpoint. Note that the following URLs require an access token or client id, which you will be given, omitted here for brevity.
Get the current most popular photos:
Or to get information about a single image with a media id:
The search method was our main tool. It takes up to five parameters, lat, lng, max_timestamp, min_timestamp and distance.
Note only latitude and longitude parameters are required and distance is in meters, default at 1km with a maximum of 5km.
So at each of our key distances, the app took the latest latitude and longitude positions and grabbed the latest photos.
In an attempt to only select images of the marathon, this was backed up by inspecting within the result set for images with a caption containing any one of a set of predefined keywords such as ‘marathon’ or ‘runners’. That way we could almost ensure that we wouldn’t pick up any images not concerned with the race — though would find false positives.
Once we had the JSON data it was simply visualised on the map, Instagram host the images for us.
One thing lacking in the data perhaps, is that the location information only offers the latitude and longitude coordinates, no place or address names unless otherwise nominated by the user. For each image then I ran the data through Google’s Geocoding service to get a street or area name, just for display purposes.
On the whole, it worked well. The API is as straightforward as any and realistically, the biggest worry for us is that most people seem to use Instagram to take pictures of food and little else, we thought we’d have pictures of everyone’s breakfast around various parts of London all day.
Doubtingly, I wrote a simple ‘refresh’ button to rerun any query in case anything untoward or particularly boring popped up when I logged in to check, but between the huge crowds and the caption matching, I only had used it twice and both very early on in the day.
Here’s a handful of the pictures: