Flickr API - features and foibles

This week, I've been working on the flickr communications side of the Quakr Viewr app.

Semantically sensible
I've found the Flickr REST API fast, simple, and very well documented - incomparable to the befuddling eBay services docs I worked with last year.

The search API does wot it says on the tin. A GET Request for:

http://api.flickr.com/services/rest/
  ?method=flickr.photos.search
  &api_key=[your key]
  &tags=tin

, gives back a semantically sensible piece of XML metadata, with a list of elements named <photo>. By concatenating the bits in the right order, you can make the URLS of the photos themselves.

Cool things
Cool thing 1: &bbox=
The most exciting aspect of the Flickr API from our Quakr perspective is support for bounding box searches, meaning that we can give four geo:lat/long coordinates, and get back sets of photo metadata.

As a pedant, I must point out that, before the fanfare, Flickr already "supported" geotagging in that it supported whatevertagging - people were merrily adding geo:long=1234, and Flickr were letting people query it. What is new is that Flickr have started splitting the machine tag at the equals sign, treating 1234 as a number, stuffing it into some special database AS a number. Suddenly, they can do MATHS, and support COMPARISON operators, and presto, offer bounding box searching.

Cool thing 2: &extras=
The &extras optional parameter on a search causes extra metadata to be returned in the results. For Quakr, we're going to be using tags like ge:tilt for 5 of the 7 in our 7D metadata, so we need to get at these tags, and, for good user experience, to get at them quickly (ie, without making lots of extra requests.) extras=machine_tags is just the job.

Foibles
One or two features which confused me at first:

Foible 1: backdata
Geotags that were entered before the geotagging 'release' aren't imported into the special database. From the groups:

"# What about all the machine tags that are already in the Flickr database?
At the moment, they are still treated as plain old tags. We have plans to go back and re-import them as machine tags but for now, only new tags will be processed as machine tags."

The solution is given in the same post:
"In the meantime, if you re-save a machine from the 'edit this tag' page it will be re-imported as a machine tag."

Foible 2: 'limiting agent'
From the search docs:
"Geo queries require some sort of limiting agent in order to prevent the database from crying.
...If no limiting factor is passed we return only photos added in the last 12 hours (though we may extend the limit in the future)."

I solved this, following guyfisher's advice, with a

&min_taken_date=1970-01-01%252000%3A00%3A00

. (I'm OK with the start of time in viewr being the unix epoc...)