The “Diary” project showed a map for each day of a user’s activities (see Creating a Geographic Diary via Flickr). How about if we try to discover who else was taking photos at the same place and time?

I wrote a small app called ShowPix to show the most interesting geotagged photos on Flickr for a given time and place, using Flickr’s “interestingness” metric. It works like this: 00:00:00&maxdate=2011-12-17 23:59:59&minlat=38.791867&minlon=-77.119775&maxlat=38.995482&maxlon=-76.909318

It’s a long URL, but fairly straightforward. The mindate and maxdate parameters assign the date and time range, while minlat, maxlat, minlon and maxlon assign the latitude and longitude. In this example I picked a 24-hour period on December 17, 2011 (the date of Santarchy), and the bounding box for the District of Columbia. Because D.C. isn’t rectangular, it also includes parts of Virginia and Maryland.

The program uses Flickr’s API to get back a list of photos, and the Google Static Maps API to display the map with the markers.

The method is used to get the images. In PHP (using the phpFlickr library), the code looks like this:

$bbox = $_GET[“minlon”] . “,” . $_GET[“minlat”] . “,” . $_GET[“maxlon”] . “,” . $_GET[“maxlat”];
$start = $_GET[“mindate”];
$end = $_GET[“maxdate”];
$photos = $f->photos_search(array(“extras”=>$extras, “per_page”=>$images, “min_taken_date”=>$start, “max_taken_date”=>$end, “sort”=>”interestingness-desc”, “bbox”=>$bbox, “accuracy”=>1));

During the course of testing this, I discovered two hugely annoying bugs in the Flickr API. First, the API call will return photos from outside the time boundaries, and I presume it was missing just as many that were in the boundary. The results were off by as much as seven hours. It turns out that the API doesn’t match against the time recorded in the photo in the meta data; it adjusts it to create a global time. Their thinking was clearly designed to help people doing a global search. For example, consider a search for all photos taken between 1pm and 2pm on a given day. There are two meanings:

  • If you use the local time, the photos will actually span an entire day, as each of the 24 time zones passes through 1pm – 2pm one after the other.
  • If you adjust each photo to account for its time zone, you will get a single hour for the entire globe, but only one of those time zones will actually be from 1pm – 2pm.

Flickr chose the 2nd option, while I would have greatly preferred the 1st. You could argue this is a feature, not a bug, but it is hugely frustrating to search for a known photo using its given date and time, and have Flickr report back that it wasn’t found. Each search must now account for the time zone of the photos being searched. Madness!

What’s worse is Flickr didn’t document this at all, leaving it to forums to grumble and figure it out on our own. Nor have they provided a fix. What they ought to do is provide an alternative to, or add a new argument to act as a switch for which method is preferred.

Then there’s the second bug. After you adjust for the time zone, some known photos might still not turn up. I found I couldn’t guarantee inclusion unless I added a fudge factor of 15 minutes. My guess is that the API goes against a totally different database than the real Flickr database. I suspect that Flickr didn’t want their API to affect the performance of their own site, so they created a mirror image. And I further suspect that the data is not 100% the same. Perhaps for performance reasons they round off the time of a photo to the nearest quarter hour? I would love to hear from Flickr what really is going on.

I augmented the app to allow the user to select a time zone adjustment and a fudge factor: 00:00:00&maxdate=2011-12-17 23:59:59&minlat=38.791867&minlon=-77.119775&maxlat=38.995482&maxlon=-76.909318&adjust=-7&fudge=15

This URl adds two new parameters: “adjust=-7” means adjust by seven hours (which works only on the east coast), and “fudge=15” expands the start and end times by 15 minutes. The fudge factor will now also include photos outside the requested time span, but oh well.

As with the Diary project, this app also displays a map showing markers for each photo. I use the Google Static Map API, so the markers aren’t interactive; it’s just a simple map, one that is easily created.

The map’s main limitation is the length of the URL to create it. The Google URL includes the latitude & longitude for each photo. But that URL can’t be longer than 2048 characters. Since a typical lat/lon pair requires 23 characters, I made the app default to show the 80 most interesting photos for the given time and place. You can adjust that by adding “&images=100” or whatever to the URL, but if the Google map’s URL is too long it creates “Error 414,” the code for “Request-URI Too Large”. The page will display, but the map will not be included. (Flickr will normally return up to 500 photos, but for geo queries like this, 250 is the maximum number.)

I’ve got a bit more work to do to polish this app and make it easier to use, but this basic version can already be used to discover interesting photos.

Searching Time & Place by Interestingness on Flickr

Leave a Reply