Alpha 0.39 and Fast vs More?

So we've been quietly updating the Viewr in the past months, and have today released the 'World Move' slider to replace the previous 'Camera Info' slider.

Check it out at http://www.quakr.co.uk/viewr. All comments as ever welcome.

Now. In building and releasing this version (and the last three or four to be frank), we've changed the way we GET from Flickr. In the distant past, we asked Flickr for the whole set of geo-located photos in a specific Bounding Box. Simple really. The only trouble was that a whole pile of them (90+%) were *no use* to us as they had no directional tag. So then we extended the Flickr API query to get ONLY the photos which were geo-located AND had some kind of directional tag (geo:dir, ge:head, ge:heading, kml:heading or geo:heading). Fabulous. And FAST. Now we were only getting usable photos and the response was speedy.

But. Then we started thinking about usability and we added support for point. But point isn't a machine tag, so attempting the fast GET wouldn't be sufficient to capture all the newly tagged photos. Hmmm...

So what'd you prefer? 'Fast' or 'More'??? We're obviously considering a solution which would do both, but for now, give us a vote! We're defaulting to the 'More' version.

a place to stand

“GIVE ME A PLACE TO STAND AND I WILL MOVE THE EARTH” said Archimedes.

In thinking about moving the Quakr Viewr camera in a nice smoothish and less jumpy way, I suddenly hit upon what has been a philosophical problem for many years. In the Quakr Viewr world, there is no difference between moving the world and moving the camera. Imagine standing up from your seat - there is no way to satisfactorily differentiate between your head moving upwards and the world moving downwards. They both result in what your eyes see and the both result in what your mind perceives. It's only when we start thinking about everyone else who is standing up at the same time that the conclusion that the world is NOT moving but we ARE becomes the sensible one.

In Quakr Viewr I initially coded the camera to move when the user hits buttons or presses keys. When a user clicks on an image in view, selects an image from the drop-down list, or hits the previous or next buttons, the camera moves to the *best view* position for that image. Initially, it jumped to that position, but in the most recent release, it first jumps to look at the image and then moves smoothly through 20 iterations from it's current position to the aforementioned *best view* position. This is done by *simply* moving the camera, but I did investigate the possibility of moving the world. The two overly detailed reasons for this investigation were a) the sandy flash engine may work quicker with object moves instead of camera moves and b) there is more iterative move options available for object moves in the engine.

After much typing, testing and re-releasing, I found that there is no significant speed difference, but the complications of remembering where the world has been transformed to, and thus where it has to go next proved to be too much headache for me. The current release uses something Sandy Flash calls a *positionInterpolation* to control the camera position, and you'll notice that there is a bit of a jump before the movement starts as I flip what the camera is *looking at* (I'll be working on that if I find some spare time!). It's all good and here.