Not a winge, honest

from here.

I've been attempting to use sort with machine tags in the same photos.search api. Seems the sort is working to date level ONLY, even though the original photos are timestamped. I suppose I could attempt to sort inside my application, but ... is this a known bug / is there a workaround?

to reproduce, go to www.flickr.com/services/api/explore/
user id = 85097477@N00
tags = walkhome
sort = date-taken-asc
machine tags = geo:lat=, geo:lon=, geo:dir=
machine tag mode = any
extras = date_taken

first three results:
<photo id="978048548" owner="85097477@N00" secret="ad5dcdb8d5" server="1259" farm="2" title="DSC00289" ispublic="1" isfriend="0" isfamily="0" datetaken="2007-08-01 17:59:32" datetakengranularity="0"/>
<photo id="977179253" owner="85097477@N00" secret="011da408b7" server="1416" farm="2" title="DSC00285" ispublic="1" isfriend="0" isfamily="0" datetaken="2007-08-01 17:57:06" datetakengranularity="0"/>
<photo id="978039486" owner="85097477@N00" secret="df95c760e9" server="1270" farm="2" title="DSC00286" ispublic="1" isfriend="0" isfamily="0" datetaken="2007-08-01 17:58:02" datetakengranularity="0"/>

remove the machine tag bits and the first three results are correctly...
<photo id="978031002" owner="85097477@N00" secret="4a3bd3f881" server="1253" farm="2" title="DSC00283" ispublic="1" isfriend="0" isfamily="0" datetaken="2007-08-01 17:55:29" datetakengranularity="0"/>
<photo id="977176661" owner="85097477@N00" secret="3c646cda47" server="1346" farm="2" title="DSC00284" ispublic="1" isfriend="0" isfamily="0" datetaken="2007-08-01 17:56:24" datetakengranularity="0"/>
<photo id="977179253" owner="85097477@N00" secret="011da408b7" server="1416" farm="2" title="DSC00285" ispublic="1" isfriend="0" isfamily="0" datetaken="2007-08-01 17:57:06" datetakengranularity="0"/>

Meanwhile, I'm sure you've noticed some changes.... http://www.quakr.co.uk got itself a new logo! The Taggr has been updated to match and now has the quakr:zoom tag added. The Viewr is muchosly updated now at alpha 0.40 which must be some kind of milestone. The most recent additions have been a 'World Move' slider which loads into the world view more tiles and images, and a 'play' button which should auto-move the camera across the loaded image set. [due to the above flickr API bug however, it's not quite as perfect as it should be!].

All comments as ever most welcome. There's still a pile of things in our heads which will be rendered into the software in the coming months.

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...)