4 posts from December 2008

When I posted about lib-flickr-minimal, I noted that the newly-launched flickr.places.placesForUser method made a more interesting demo of data you could fetch when authenticated than, say, showing a user's most recent private photos. Evidently the developers at Flickr agreed it was an interesting concept, because over the last couple of months that area of the API has been extended considerably, As a result, I've expanded the demo into an AppJet application of its own.

Where? What? When? is the result. It shows you, on a map, the locations with the most photos according to a given criterion: by default, that's a tag, but it can also show your photos, or those from your friends and family, or your contacts. You can then inspect a place and see the most recent relevant photos, or the most popular tags, for that location.

How did that evolve from the initial demo app? Instead of simply printing a table based on Flickr's response into the document, I directly plotted the results on the map. I added a small form to enable the choice of criteria, and when Flickr added the placesForTags method, I added that as a choice. Belatedly, I realised that would also work for users without authentication, so I removed the requirement to authenticate, and made tags the logged-out default. (The image above shows a slight change to the initial results: it's the same tag, London, but at the neighbourhood, not locality, level. All of the locations are within the greater city's area, which probably won't be a surprise, but that's not true for Paris. Evidently, what happens in Vegas doesn't always stay there.)

The design of the application isn't quite settled, but I knew I wanted to replace the standard Google Maps pushpins with partially-transparent circles. Initially, I went with red, but when I showed it to colleagues, they said it reminded them of maps of bomb blast radii, so I spent a while looking around for the right colour, before settling on a yellow. The circles themselves are scaled according to the natural log of the number of photos for that location; I played with square roots as well, but I feel that logarithms give the right sense of scale.

The last piece of work I did was adding tag display for locations, using the tagsForPlace method. These tags can be surfed: clicking on one will load a new search for the given tag. It's noticable that the first few tags for most places are almost always place names, while common tags seem to share a familiar pattern of scattered, similarly-sized circles across the US, Europe, south-east Asia and coastal Australia.

There's still a few things I could add; tag persistence in URLs (to make it easier to share pages), better loading indicators (especially initially), options on which photos are shown, and links to view the search on Flickr itself, for example. There's also a missing question: while the API methods support maximum and minimum times, I haven't yet added options to allow you to show When? However, for now I think I've done enough (and I'll note that the site has a link to view the source of the application, if you fancy hacking on it yourself.) Enjoy.

A few weeks ago, when I was finally prompted to write up my EXIF to machine tags script, I parenthetically remarked that

ways of getting all predicates for a namespace, and values for a namespace (at least within a given user's photos), would have made my list for 'things you'd like to see in Flickr'  if I'd felt able to get away with being so demanding

Funnily enough, a mere week after posting that, Aaron Straup Cope posted to the yws-flickr group, announcing exactly what I'd obliquely asked for: methods to work with the parts of all machine tags on Flickr. I set to work, and by that weekend had produced a machine tag browser.

Thanks to some coding help from Tom Insam and suggestions by Ryan Gallagher, the currently live version is a fair bit nicer than the initial version. The code is still a bit of a mess internally (there's far too much repetition), there are some bugs (values with full stops (or decimal points) in particular), and I still have three items on the TODO list.

Despite this, it's still sufficient for users to see that the astrometry.net system has been able to solve about 85% of the images it's processed; that three images have had an ImageMagick Lomo effect applied before upload; the names of Len Peralta's monsters by mail; and where people take screenshots in Second Life. In fact, I've been pleasantly surprised to note that the code.flickr blog mentioned it when Aaron launched machine tag heirarchies to the wider world.

As it says on the browser itself, the source code (all the clever stuff is in JavaScript) is available on github, and I'd love to recieve fixes, changes, or requests. In the meantime, have fun looking around.

Aral Balkan is trying to run the website for his conference on Google App Engine, the same platform that snaptrip uses. In October, he posted twice on Twitter:

Great, you have no control over how Google App Engine caches data requests. Pulling in RSS feeds? Forget about it! (It uses Google Proxy and you can't tell it not to cache a feed or set the cache duration.)

I'd also noticed this, because the snaptrip login page (which does double-duty as an FAQ and news page - maybe I should rename it?) pulls in entries tagged 'snaptrip' from the Atom feed of this very weblog, and after my third post it failed to update for a good half a day. I wasn't that bothered, and didn't bother to double-check the documentation, which does clearly state that

App Engine uses a HTTP/1.1 compliant proxy to fetch the result.

Evidently this is the same problem as Aral has, and as usual, Tom Insam had an answer. It's from a slightly different direction (working with Google's Open Social containers), and as he said, it's what "everyone has done for years to bust caches you don't control": append an incrementing (or random) parameter to each request, which should mean that you're not hitting the cache. Having finally written a new blog post about snaptrip, I can confirm that this approach works. I'm not sure I'll leave it in - it seems a bit rude - but if timeliness is important, you might want to do the same.

It also occurs to me that, if every call to urlfetch is cached for some time, then you may find that repeated calls via API libraries might give somewhat unexpected results (although they're more likely to have changing arguments, anyway). Be careful out there.

A decade ago, when the Jubilee Line was extended from Green Park to Stratford, there were plenty of glossy books published, examining the design and architecture of the twelve stations that made up the extension. Deservedly so, too; one, Foster's Canary Wharf, has become iconic in that time. There's still plenty you can find about the philosophy of the designers, and the way they wanted a commonality but individuality for each of the stations.

By contrast, it's almost impossible to find out about the thinking behind the Victoria Line. This was only all-new Underground line in the last century¹, and it's forty years old this year. Most people, if they think of its design at all, consider it dull at best.

However, I've been using it for my commute for a year now, and as a primary line for half a decade, and I think that does it a disservice. First, consider the station layouts. This is, I'll admit, more commonly thought of as engineering, but even so, someone had to think about it. There are sixteen stations on the line; five have cross-platform interchanges with either Tube or British Rail lines, far more than any other line², while all but one station offer interchanges with either Underground or British Rail lines.

Admittedly, partly this is due to politics: during the "tube boom" from 1898 to 1908, the organisations building lines were in competition with one another, whereas the Victoria was the first line designed by London Underground, a single company responsible for all lines. Even so, it's a boon to people who use the line - ask anyone who changes to the Piccadilly at Finsbury Park, or the Bakerloo at Oxford Street.

Beyond the engineering, though, I think the stations are also designed well. Unlike the aforementioned Jubilee Line, most stations follow the same basic look, with three escalators³ down to a main hallway between the two platforms. Unlike some earlier lines (the Central Line springs to mind), these are almost always straight, and I can't think of a station with steps from the central section to either platform. As I've said before, there are also cross-platform interchanges, which complicate things, but even there, consistency leaps out in other ways.

All of the Victoria Line platforms are tiled in a light, almost blue-tinted, grey, with simple wooden benches. Each also has a mural; there's a lovely set on Flickr by Chutney Bannister collecting them all. Recently, the southbound Oxford Street tiling was refurbished as part of the station's PPP makeover, and I was impressed by the lovely, modern design that replaced the snakes-and-ladders mural you can still see on the northbound platform. It turns out that this was the original design, removed in the 1980s after the Oxford Circus fire, but now re-instated, and it doesn't look at all dated - in fact, it's positively modern.

For now, the original 1967 tube stock is still used on the line. However, next year should see the introduction of the new 2009 stock, which, to be honest, I'm somewhat dreading. As with the stations, these are nicely consistent and minimal, with a quirky use of circular glass panels dividing vestibules from seating areas, and standard seating. The new stock will introduce more fold-up seats, and more room to stand, at the cost of fixed seats. I suppose I should wait and see how it turns out, but my gut feeling is that I'll dislike them.

That's not to say the line is without problems. As part of the engineering work to get the line ready for the new trains, its previously solid reliability seems to have taken a knock. More seriously, the above-ground buildings are generally appalling, with far too many of the stations lumbered with unpleasant subway complexes or buildings that look like glorified portakabins. This is particularly shameful at Highbury and Islington, where a damaged but glorious old station was demolished in favour of the current single-storey shed.

Despite this, I think the effort going into the line has been unfairly neglected. The design work for the Victoria line seems to be largely lost, on the Internet at least. Mischa Black was in charge of the overall design effort, leading the Design Research Unit, but I can easily imagine how the utilitarian style leant itself to concealing the identities of the others who contributed. I think it's a shame; the line, while perhaps understated, deserves more attention than it gets. I can't imagine my London without it.

¹ Parts of the Jubilee line were inherited from the Metropolitan line in 1977, and of course the extension in 1999, while needing new tracks, was not a new line end-to-end. Amazingly, the Central London tube network we know today - with the exception of the Victoria and Jubilee lines - was completed by 1907.

² I believe the Central, District and Piccadilly each have two, excluding Victoria Line interchanges, but none are within zone 1 (I'm thinking of Stratford, Mile End, and Hammersmith).

³ Annoyingly, cost-cutting sometimes (as at my home station, Blackhorse Road) led to the central escalator being replaced by a fixed staircase, which means that any failure results in people having to walk or, in extreme cases, station closures.