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.

What's the point of your photos?

Go on! Give your photos a point! It's not hard and it'll make them far more useful and interesting to view.

Currently there are a large number of mapped photos in flickr
- More than 30,320,000 are geotagged... but ...
- 8,215 have a geo:dir
- 3,419 have a ge:head/ge:heading
- 26 have a kml:heading
- 10 have a geo:heading
- 0 have a kml:dir, quakr:compass or exif:GPSImgDirection (at least that's what the searchers tells me)

That's such a huge minority, we decided to make it all easier for you...

As of α0.38, the Quakr Viewr now supports point!

simply add
point=[[north, northnortheast, northeast, eastnortheast, east, eastsoutheast, southeast, southsoutheast, south, southsouthwest, southwest, westsouthwest, west, westnorthwest, northwest, northnorthwest]] or
point=[[n, nne, ne, ene, e, ese, se, sse, s, ssw, sw, wsw, w, wnw, nw, nnw]] or
point=[[0...359]]
and the greasemonkey flickr script will understand and add the link to the Viewr to your Flickr image page and we'll include your images in the generated world.

See http://www.flickr.com/photos/hardbutnot/1534749879/in/set-72157602245100210/
as a simple example from flickr ... and in the viewr here.

Comments as ever welcome...

newphotos - the old way

Following from our field trip with the 7D-Tiltometer, I took the liberty of taking a downsized version of each image and dummying up an XML file for them. With some very minor changes to the previously released beta αlphα, I now give you...
Quakr's New Photos rendered as ever in the Quakr Viewr¹.

The updated XML file is here if you're interested. We are currently working on making the Quakr Viewr do it's thing in an interactive way, and this dummy version will provide us a reference point to see how well the active data looks compared to some hand coded stuff. Initial feedback on that release has been garnered and the majority of the items are to do with the default keyboard arrow usage. Some people want the left and right unshifted keys to turn the camera (as it does in this release). Other people want it to move the camera - like the shift left and right keys do. Nobody liked the first release which tilted the camera like the control left and right keys currently do. Is it subjective, or does anyone feel the same? Is this different feedback deserving of a *make your own keys* function? Watch this space for answers!

1 - the viewr is now in αlphα 2 release...

Thats beta, but still αlphα

Following some excellent feedback, discussion, meetings and the like, some work has been done! I am very proud to announce the official release of the Flash version of the aforementioned αlphα Quakr Viewr [http://www.mainem.co.uk/quakr/release_alpha_flash/]. It works like a dream, utilises your keyboard arrow keys for movement so you don't have to click on the navigation buttons. It allows you to click on the images you want to examine and it'll jump in and look at them. A list of enhancements will make it even better than it is, and feel free to comment with anything that you think it needs.



Some further detail...
o) Instead of reading a .WRL file, it reads an XML file.
o) It utilises the Sandy Flash 3D engine for the main window.
o) It allows image selection by two means - selecting the image in the scene or picking from the drop down.
o) It allows movement by two means - arrow keys and some control or shift or buttons in left hand side.
o) It currently render local images onto the scene, but will have to start getting external images.
o) The mechanics of getting the image list from google/flickr is being worked on.
o) erm... oh yeah, you need Flash 8 plugged in.

In search of the right technology - part 2

So. Having played enough with VRML/WRL files, the obvious place to go next was the up and coming X3D. It's basically that WRL stuff in XML format. There are some very good people working hard to make this a spec worth looking at seriously so it was definitely worth a look. The spec's boast that interacting with an X3D object should be as easy as messing with the DOM in JavaScript. That'd solve the interaction problems we were having with the WRL implementation. The plugins (like WRL) already have the navigation and 3D math all sorted out of the box so that'd save us a job too.

But. Turns out, see, that them thar plugins are almost as awkward, power hungry and relatively unstable as the plugins for WRLs. Hmmm.

So then our thinking moved into the world of Flash.(Ah-ah, saved every one of us...) Looking around, some very good people had started or version 0.9'd some very good looking 3D engines. Some other good people were doing really interesting stuff with said engines and suddenly it all became clearish.

We found the thing called Sandy, >quote< an intuitive and user-friendly 3D open-source library developed in Actionscript 2.0 for the Flash environment. >/quote<. Sounds interesting. With a pile of tutorials downloaded and played with, it seemed even easier than at first assumed. Yay says I and gets on with the development.

By choosing Flash, we jumped away from the requirement for a plugin (I know, but you know what I mean...) but lost all the goodness of the interfaces which one gets for free. So a first pass interface was envisaged and stuck in place (version 0.02). Then we started thinking about adding images to the scene and doing all the translations and transformations in order to put the image in the right place (version 0.08). The next step was to load a pile of data from some kind of external XML file - see the alpha button (version 0.09).

Some fairly major enhancements and bug fixes later, and we think we're all ready for people to come play with our αlphα flash release. Like the WRL based αlphα release, it shows 10 pictures of the Oxford Castle floating in space above a Google mapped floor. Once you've pressed the alpha button and loaded the images, it's possible to use the selector on the lower left to jump to the perfect view of each photo. I'd be loathe to say it's anything like finished, but it's a good start.

Over the next few weeks we will be looking to enhance the Flash version of this Quakr Viewr implementation along with getting some more realistic data into a readable XML file. We're working on making it talk to the map and Flickr in order to retrieve and display the relevant images. Watch this space carefully - it does tricks.

In search of the right technology - part 1

Those many moons ago when the Quakr concept came to light in the local, there was always an unuttered question "How do we do it?". This is the first of a series exploring the current state of the technology that might just be able to build the envisaged Quakr application.

I'm gonna start by assuming that you've already grasped the beauty of what it is that we are all about, and so I can skip the sales pitch. Instead I'm gonna tickle the imagination in you by describing our αlphα attempts at the Quakr application.

So you've already got a digital camera. You've already got an account at Flickr. You've already taken photo's of your local, geo-tagged them and then stuck them into Flickr, Google or Microsoft earth. That's all well and good, but how do you go about enhancing them into a Quakr'able set. Well it's all a matter of Tags. You need to add tags to each photo for the various additional metadata required in order for the Quakr Viewr to know where and how to put them.

So we'll imagine that you've done all that and it's time to look at your images. You want an intuitive interface like Google Earth with a map on the virtual floor and a set of relevant images floating in space. We want that too. Initial investigations jumped on technology from 1997 - Virtual Reality Media Language (VRML - or WRL). I've played in that space before [ps it doesn't work cause it was built when VRML was at release 0.9... sorry!), and attempted to convince myself that it was still possible. VRML was probably one of the coolest things I ever played with in 1995. Unfortunately, the spec has not moved with the times, and here we are 10 years later and it's only now being picked up again and discussed as a viable technology. There are a few plugins from that time that still work today and after some heartache, email correspondence with Tech Support and a decision or two, we had a working alpha release of our app - Quakr Viewr.

The plugin handles all the drawing and re-drawing of the objects in space, provides a reasonable interface to allow moving around and pre-defining camera positions. "All" we had to do was build an input file of *pictures in space* and do some funny things with proximity sensors in order that the right images go away when you are looking at the back of them. But can we interact with the thing real time in order to add and remove pictures as they become relevant/irrelevant? Can we communicate in any way from the plugins view of the world back to the page with the plugin on? Hmmm. Seems following a fair amount of investigation that the answer to these two proved most elusive and so we were forced to think again. That's another story. For now, please have a browse of the αlphα and feel free to comment as you like.