7D twisting and tagging

I've been thinking about the terms we should use to machine tag our 7d tiltometer metadata.

The terms:

1. Altitude
2. Latitude
3. Longitude
4. Compass bearing
5. Tilt
6. Orientation
7. Timestamp

Some semantics:

By tilt, we mean rotation around X axis - or, are we pointing the camera at our feet?


By orientation, we mean rotation around Z axis - or, are we doing a wacky half-portrait half-landscape shot?


By compass bearing, we mean rotation around Y axis. North, East, North-North-East. Oh, you know what a compass looks like..



OK, I've got two aims:

A. Use the semantically correct term.
B. Use whatever everyone else is using - accept existing data.

Since we're hoping to make use of user-contributed photo metadata other than that we've cooked up ourselves, B. is really important to us.


altitude, latitude, longitude -> geo:

Ok, these first 3 are a no-brainer on both criteria: geo: is the preferred ns prefix for the swig Basic Geo (WGS84 lat/long) Vocabulary. And, thousands of taggers already voted with their fingers:

compass bearing, tilt -> ge:

Google Earth / KML / FlickrFly offer ge:tilt (meaning the same as we do), and ge:heading (meaning compass bearing).

The use of 'ge' seems a bit unsatisfactory to me. 'G'oogle 'E'arth describes the application, not the data. But ho hum, 9268 people don't agree:



, so that's a decider for me.

We are also stuck with the problem that FlickrFly have been recommending 'head', while the kml vocab defines 'heading'. 'Head' is the statistical winner. But perhaps we should double-tag and use both?


Orientation -> exif ?

ge:rotation doesn't quite capture our meaning. Strictly, exif:orientation's value should be restricted to 4 possible positions. But, it does have that usability factor - it's meaning is understandable.. so I think we'll cheat and use it anyway for now.


timestamp -> dc: / exif: ?

This is a tricky one. What do people actually do? Well.. mainly nobody tags this at all - this data belongs in the EXIF pile that your camera puts there for free.




Given that.. I'm tempted to go with exif on the basis that it's more familiar to amateur photographers, and thus easier to type in the box. (and persuade others to type in the box..?)

Really, we're trying to squeeze an exif-shaped datum into a tag-shaped hole on this one. Perhaps we should be querying the exif data instead?..



Provisional quakr set:

1.geo:alt
2.geo:lat
3.geo:long
4.ge:heading
5.ge:tilt
6.exif:orientation
7.exif:dateTime

Geotagging

Our data gathering trip with the 7D tiltometer produced much smirking and several notebook pages of metadata. We went home, warmed up (eventually), and uploaded the photos to flickr (see the set here).

Next... load the data

The question of how to represent all the tilt/heading/shoesize data in triple tags/machine tags is a big one - I'll leave it to Katie to deal with that later ;)
For the time being I'll just take you through the basic geotagging process.

Step 1: Decimalise the data

Our GPS device gave lat/long data in degrees and minutes like this:



What you are seeing there is data in degrees and minutes. I guess it made sense to somebody once, and there are probably important nautical reasons why you wouldn't want a decimal figure. Hmmm.

Either way, it's still no good for us - we need decimal values.

So, from 51°44.915 do the following:
1. Take the 44.915 (the minutes value - which is actually decimal already in our case)
2. Divide it by 60 (44.915/60 = 0.748583)
3. Add this on to the 51 (the degrees value)
4. 51 + 0.748583 = 51.748583

And that's it!

If your device gives you degrees, minutes and seconds, follow the full conversion instructions on wikipedia.

Step 2: Enter the data into flickr

The flickr map does allow you to drop photos directly onto the map but we have our own location data (that's the whole point), so...
I just went through each of the photos on flickr clicking on 'Add a tag'. For each photo I entered something like:

geotagged
geo:lon=-1.25691667
geo:long=-1.25691667
geo:lat=51.75406667

(more on lon vs long in later posts!)

Step 3: Import into the flickr map

This isn't crucial to anything we are doing at quakr, but we were eager to see where our photos would end up. To do this go here: http://flickr.com/account/geo/import.
Follow the instructions and you should get the message

"OK! Your import request has been placed in a queue. It shouldn't take too long to complete"

Step 4: Check the map!

I tagged all of our photos with quakr, and doing a map search for 'quakr' brings up something very pleasing...



And that's it for the basic lat/long data. Happy geotagging!

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.

Quakr-7D-Tiltometer field-trip.

This weekend, the quakr team set about collecting some data.

We made a 7D tiltometer.



Mainly out of string and double sided sticky tape.



Then we field-tested it in central Oxford.



Read all about it: Quakr 7D tiltometer Project

No logo

So there we were...

...well on our way with the Quakr project to create a 3d world from user contributed photographs.

But we had no website.

And no logo.

The problem was this:
When your intention is to show the real world in all its depth and complexity, almost any logo looks ... well ... flat and mundane.

Eureka! Make a logo, and physically place it somewhere in this beautiful world and photograph it.

Hang on, maybe there already is a photo on flickr we could use?

Hmmm... Maybe if our project was called 'One way' or 'Keep off the grass' that might be possible. Finding a photo of 'Quakr' is probably a bit far fetched.

But... there are many photos of individual l e t t e r s.

Excellent - we'll do that.
Our logo will change every time!
Other people will design our logo afresh every time!
We'll be using photographers from around the world all pulled together to build something bigger.
What could be more appropriate?

But how can we engineer this? (skip this if you have no interest in the technical nitty-gritty)

Step 1: Use the flickr api from perl to grab the photos and spit out the appropriate HTML.
Step 2: Meet the creative commons obligations for the photos under their attribution licence by listing the owners.
Step 3: Realise that to do this will suck up a lot of the screen real estate.
Step 4: Use the fantastic script.aculo.us JavaScript library to scroll through these in a much smaller space.
Step 5: Realise that the script.aculo.us Effect.ScrollTo currently only allows scrolling of the entire page, and not of a div within it (this would make the photos scroll off the page!).
Step 5: Write a script.aculo.us-style Effect.ScrollDivTo effect to achieve what we want (shortly to be contributed back)
Step 6: Make the whole shebang easy to deploy... say, by insertion of a single line of HTML into a page.
Step 7: Make the service available to everybody.
Step 8: Sit back, relax, panic and bug fix, relax again and tell the world.

Phew! So there you have it. And here. And here (look up).


It is tentatively called a Flickr Phrase (better suggestions on a postcard please).

It was as good an excuse as any to play around with the current Web 2.0 toys. And dare I say it, it looks pretty fine. I could sit here for hours hitting f5.

Want one?

It's free. It's easy. Check out the Flickr Phrase two step howto and you'll be set within minutes.

So, what are you waiting for?
Roll up. Satisfaction guaranteed.

related or relevant, 01/07

- Google Super Models - building a 3d world without pictures -- almost the opposite to our premise, but of interest probably.
here

- Google Patent Searching for "photo geolocation"
here

- Web3D related discussions
"Organization, deliverables, and calls-to-action also emerge from such a direction. For example, a client-side 3D-enabled earth that Web developers can install on any web page (no plugin required, but perhaps plugin-upgradeable). Such a direction also helps to align with natural categories of users of the Geospatial Web -- from point-of-interest list builders who don't want to understand GIS, much less 3D, to put a meaningful map on their web page, to the most hard-core specific guru-required use cases." from here

- possibly of interest, the Where 2.0 conference and Fair;
"Third Annual Where Fair
For the third year in a row, Where 2.0 will bring forward the location aware tools, apps and hardware being created in garages and university labs for the Where Fair. The Where Fair is a hands-on, science fair style event where the creators of these location based projects can share their emerging location technology with others. Where Fair projects will be selected from research, academia, and yet-to-be-discovered entrepreneurs." from here.

- garmin release a GPS for yer car with connectivity to MSN Direct for Points of Interest (POI) which can be clicked to autodial them.
here

---- more ----

- will the iPhone by GPSing? No.
here

- another conference for us? - the International Symposium on Digital Earth...
here

- Portable Absolute Orientation Estimation Device With Wireless Network Under Accelerated Situation...
here

- £34 for an electronic compass...
here

- $249 plus for an electronic attitude plus compass board...
here

--- more 2 ---

- Google (and other) maps on a GPS device... The PN-20.
reviewed here

- A.N.Other conference of possible interest...
SFSW2007

--- more 3 ---

- google earth with panoramas innit...
here

--- more 4 --- (not the tv channel)

- $20 for a GPS logger?
here

- top 10 flickr hacks...
here

- view flickr photos from your favourite *place*... linked on the menu of Google Earth -- how do we get on there too?
here
i.e. how do we get ourselves onto this list...

- GPS + Camera + PSP?
here

hello world

Building the World, one photo at a time
Is it possible to build a virtual world from user-contributed photographic metadata?

Short abstract:
This paper describes the experience of developing a 3D virtual world, based on publically available images and geo-metadata. A practical examination of the hardware, the standards, and real user practice.

Full abstract:

The Giants’ Approach: control everything
Google Earth and Microsoft’s Virtual Earth have 3D elements, but they have both chosen to control the data that creates those elements. Microsoft’s photo-realistic cities are ‘built’ from especially commissioned photos.

An Alternative: we the people
But the data is already out there. Amateur photographers have readily adopted the concept of location metadata; there are currently 0.5 million geotagged photographs on Flickr. Meanwhile, digital cameras embed Exif metadata (some already include GPS data), and geo-standards including KML and GML are in widespread use.

The view from 30,000 feet
Where are the overlaps between what the standards advocate, what cameras can provide, and what people actually do in practice?

Data (1): wish list
Is the data sufficient? What data does a 3D rendering engine ideally need to position photos in 3D space? Are the geo-standards sufficient to describe that data set? If not, how might they be extended? Could users realistically contribute that data set? What tools would help them?

Data (2): making do
Finally, to what extent can an open-world-minded application make sense of the sparse, ambiguous data which is avaliable right now?

Our application
This paper describes the experience of developing a 3D virtual world, based on publically available images and existing geo-metadata, including Flickr. We make recommendations for extending geo-metadata standards to facilitate such applications, and we document our D.I.Y. efforts at constructing a geo-camera of the future, capable of capturing the metadata we advocate.

Our application sits in the heart of the ubiqitous web, at the intersection between increasingly sophisticated gadgets, metadata standards, and the surprising extent to which users are prepared to indulge in both.