snaptrip: some thoughts

Having finally got snaptrip out there, I'm hoping you'll allow me a little (pretentious?) waffle about why I wrote it, where it fits, how I made some of my decisions, and what's next.

I'm a big fan of Flickr's machine tags. Most of my images have at least ten - mostly generated automatically, like my EXIF machine tags - and I tend to add geographic metadata as well. As such, it's probably not a surprise that I'd write an application that made Dopplr trip IDs available. The big surprise is that I bothered to make it accessible to most people, by building it as a website not a script.

Why a website? Well, I thought I'd like a nice interface as much as anyone, and I also know that to make a machine tag truly useful you need as many people as possible using it. Asking folk to download a script, get a key, and use a command-line interface - or no interface at all - isn't going to work.

Speaking of Dopplr, I don't think I've seen a talk by anyone there since it started, but I do think I've picked up their philosphy from slides and abstracts online. The phrase that tends to crop up is a "coral reef", the idea being there's a web of data that's available on the internet and that by doing one thing, and doing it well - the old Unix philosophy, really - that you can live in a happy niche. Well, snaptrip lives on part of the coral built by the two companies whose API it consumes.

I'm not under any illusions: it's likely that most users won't care about their past trips, or matching their Flickr photos. Those who do will probably only visit the site once, tag a few trips, and then leave. That's fine.

In my previous post I alluded to some decisions I made about the geotagging features in snaptrip. To be honest, it wasn't something I'd considered at first, but seeing Richard Crowley's Dopplroadr hack - which does some of the same things as snaptrip, but when they're uploaded rather than by looking for existing Flickr photos - made me consider the possibility. However, because I am looking at things that have probably accumulated metadata already, snaptrip is careful not to overwrite any information that's already there.

snaptrip adds fewer tags than Dopploadr. It won't add human-readable tags at all, and it adds the geographical data at a relatively low level of accuracy. I didn't want snaptrip to assert with precision that all these photos were taken dead in the centre of Copenhagen, since they probably weren't. My US trips show exactly the sort of thing I'm talking about: most of my pictures are actually taken anything from ten to two hundred miles from where Dopplr thinks I was staying. Similarly, it doesn't set a woe:id machine tag, instead preferring to use the dopplr:woeid namespace/predicate pair.

It's quite possible I'm overdoing the paranoia here, and so I'll probably add the option to set more tags later, but for now, I'm happy to tread lightly. (In that vein, snaptrip doesn't set a visible "snaptrip" tag, like many apps (Shozu and AirMe spring to mind; Picnic also suggests adding its tag). However, it does set a dopplr:tagged=snaptrip machine tag, and I should probably make that optional also. For now, you can use Flickr's tag tools to delete it.)

So, what's next? Well, the basic functionality I wanted seems to be there and stable, so I'm now considering two further avenues. I'm trying to develop tools to give you some views on the aggregated data from your past trips, but perhaps I should instead be looking at tools to increase the amount of stuff in that Dopplr history. I've got a couple of ideas...