About Kay Kremerskothen

Kay is a Community Manager for Flickr and passionate about extraordinary photography. As an editor on Flickr Blog he loves to showcase the beauty and diversity of Flickr in his posts. When he's not blogging or making Flickr more awesome (in front of and behind the scenes), you can find him taking pictures with his beloved Nikon and iPhone, listening to Hans Zimmer's music or playing board games. | On Flickr you can find him at https://flic.kr/quicksilver

Location, keeping it real on the streets, yo!

Or something like that anyway. Over on the artsy Flickr Blog we Introduce a new way to geotag, which has a nice pop-up map, which you can drag around, or just enter in the latitude/longitude by hand, something amazingly you couldn’t just do before.

However, ‘ere on the Dev blog there’s something else that interests us about this. A thing we call “Corrections” and it’s tucked down at the bottom when you go edit a photo’s location …

Psst

So what’s it all about?

Well something we’ve been fighting, tweaking, exploring for the last forever is getting the Reverse Geocoding working in a way that makes everyone happy.

In a nutshell Reverse Geocoding is when you take a Latitude and Longitude and then say where that point is. Ideally in a way that’s sensible to humans. In the above image you ask, “Where’s 37.7947N 122.402W?” and we used to say “San Francisco”.

We used to stay at the general city level because it turns out that people get more upset at being told they live/work/take photos in the wrong neighborhood than having no neighborhood at all.

Turns out the solution we’ve gone with it just simply to ask, at least in the first instance …

alternatives

Due to wonderful design we hopefully make this all look very easy, but let me tell you, it’s not, it’s all terribly, terribly hard. But more on that in a second.

So now on photos we’re saying which Neighborhood we think the photo (or video) is taken in, and let you tell us otherwise.

The grand idea is that if enough people start to ‘correct’ a neighborhood then we can feed that knowledge back into the system and slowly over time get our database to match what our actual users say.

The problem has moved slightly from “Why does it say my photo was taken in xxxx” to “Why doesn’t it list alternative place xxx”, but that’s a slightly better problem … anyway …

I’ll cover how people can start to get this back out again, so we can all share the love in another post soon.

On a slightly more philosophical level, it’s a never ending process. We’ll never reach a point where we can say “Right that’s in, all borders between places have been decided”. But what we should end up with are boundaries as defined by Flickr users.

As an example a lot of our UK neighborhood data comes from government and local council records (probably). And while that data is very good for the purpose it was originally gathered for, it turns out people can be very specific and touchy about someone telling them they live in Upper Tinshire or Lower Tinshire, when clearly they live in the other one, because obviously this side of the street all the way up to the Post Office is Upper Tinshire and the Fox and Hound Inn Round-a-bout represents the border, of course, Duh!

And this goes on around the world all the time.

For us, it’s a first small step into an experiment, and actually a pretty big experiment as we’re potentially accepting “corrections” from our millions and millions of users. We’re not quite sure how it’ll all turn out, but we’re armed with Maths, Algorithms and kitten photos.

Rock on!

Related: A while ago the lovely people at O’Reilly asked us if we’d like to talk about something at Where 2.0. Which was nice, and as we didn’t have anything to particularly promote or sell it left us free to talk about what was interesting to us, which turned out to be this very thing.

So if you want to see two people say “Errrrr” and “Ummmmm” a lot (according to Aaron, I haven’t seen it myself as I can’t stand watching myself talk) for 15mins saying pretty much what I typed up there, but with a cool bit by Aaron where he talks about how hard Reverse Geocoding is, then here’s a video …

The Video

And here are the slides…

The Slides

Posted in geo

Wildcard Machine Tag URLs

Machine tags!

Photo by cackhanded

If you’re not already familiar with machine tags the easiest way to think of them is being like a plain old tag but with a special syntax that allows users to define additional structured data about that tag. In turn the magic space hamsters that run the site have been trained to recognize, index and allow for searches across multiple facets of a given machine tag.

Machine tags have three parts : a namespace which is like a subject or a topic; a predicate which is a like a property of that topic; a value which is … well, a value.

For a more thorough introduction to the subject I’d recommend reading the announcement
we made in the Flickr API discussion group
when machine tags were first added to the site. If you’d like to know even more, after that, there is good collection of links available on del.icio.us.

Which brings us to the part where I tell you that we’ve added the ability to search for machine tagged photos in plain old tag URLs (as well as in tag searches on the Flickr search page) using the facetted query syntax that has always been available in the API. For example :

That’s a trick, really. You’ve always been able to do this since machine tags are just
tags. The New-New means you can be even more granular in what you are looking
for. How about :

The wildcard URL syntax is also available for an individual user’s tags :

Now for the list of caveats and Known-Knowns :

  • At the moment it is still not possible to poke around the hierarchy of a given machine tag : all the predicates for a namespace; all the unique pairs of namespace and predicates; that sort of thing. It is On The List ™ and hopefully we can offer up something for you to play with, even if it’s just in the API to start with, shortly.

  • Values in wildcard URLs should are treated the same way regular tags are in URLs. That is “san francisco” becomes “sanfrancisco” or in machine tag speak : *:*=sanfrancisco.

  • In the examples above, I’ve illustrated namespaces that are used to denote one service or another. It is important to remember that there are no rules about what can or should be a namespace. Like tagging, the hope is that the various communities will arrive at and adapt a consensus according to their needs.

  • Untitled Souvenir #1173678685

    Photo by straup

    In the meantime, kick back and enjoy photos taken by people on their Dopplr trips, photos by people who really really like airplanes or photos by people who are interested in possums
    (not to mention all manner of marsupials) or whatever else comes to mind!

Visualizing 4.5 years of Flickr development

We were impressed with Michael Ogawa’s code_swarm project, so were understandably excited when he made the source available (under the GPL v3). We sprang into action, avoiding the real work we were supposed to be doing and created some visualizations of the main Flickr subversion repository.

In this visualization, blue represents PHP, green is HTML, red is Java, purple is CSS and JavaScript, Cyan is Flash and ActionScript, with yellow filling in for everything else.

Myles took it a step further, using the tool to visualize our internal bug tracking system. In this movie, each node represents an issue, flashing red as it was opened, orange as it was assigned, blue as we argued about what to do and final green when it was resolved.

This required a little modification of the software to allow for states on nodes, so that the node color can change as the state changes. Myles has also been working on some modifications to improve upon the abrupt endings. New movies might get posted here if they’re awesome enough.

We’re hard at work (well, sort-of-work) thinking up new things to visualize and new ways to present the data. If you have some bright ideas, why not post them in the code forum.

Flickr at XTech (and slides from SXSW…)

Once upon a time, webheads used to talk about “conference season”, but it seems that these days there’s always a conference running somewhere. Having dispensed with Web 2.0, we’re now turning our attention to XTech 2008, which takes place in Dublin, Ireland from Tuesday May 6th to Friday May 9th.

The Flickr team has two talks lined up for those attending XTech. Through a freak scheduling accident they’re back-to-back, giving attendees the exciting opportunity to experience one and a half straight hours of pure Flickr-related goodness:

Hopefully we’ll see some of you there!

Looking backwards for a moment, this is also a chance to re-post the slides from my previous internationalization-themed talk, “Taking Over the World, The Flickr Way” which I gave at South by Southwest in March. This hour-long session was a high-level overview of some of the challenges and solutions we stumbled upon during the internationalization and localization of Flickr.com which we undertook in the first half of 2007:

Versions of the slides in other formats (keynote, swf, pdf) are available here.

As for Web 2.0 Expo, some of the team’s presentations should be showing up here in the next week or so, starting with slides from the delectable John Allspaw.

Videos in the Flickr API

It isn’t just you, the pictures really did start moving, some of them at least. Which is an attempt at humor to cover the fact that this post is very belated.

Presumably you’ve noticed that folks are uploading videos to Flickr, and you’re wondering how to work with video in the API? I’ll try to recap, and expand upon the info in this thread in the API group.

Long Photos

First thing to understand is as far as Flickr is concerned videos are just a funny type of photo. Your API application can ignore that video exists and everything should go on working. This means:

  • you can display a preview of a video by treating it exactly like any other photo on Flickr.
  • photos AND videos are returned by any method which used to return just photos
  • you can get info about a video like you would a photo.

Videos, photos, and “media”

If you’re calling one of the dozens of API methods including flickr.photos.search() and … that return what we call a “standard photo response” then that API method takes an “extras” argument. extras is a comma separated list of additional metadata you would like included in the API response.

With the launch of video we’ve added a new extra: “media”. Included media in your list of requested extras and we’ll include a new attribute media=photo or media=video with each photo element. Like so:

<photo id="2345938910" owner="35468159852@N01" secret="846d9c1be9" server="1423" farm="2" title="Naughty Dandelion" ispublic="1" isfriend="0" isfamily="0" media="video"/>

Additionally if you’re calling flickr.photos.search() you can filter your results by media type by passing `media=photos` or `media=videos` as an additional search argument. (not to be confused with the extras of the same name)

Default is “media=both” returning both photos and videos.

Displaying videos: just funny photos

For each uploaded video we generate a JPG preview in a range of sizes. Identical to what we do for photos.

Read the documentation for flickr.photos.getSizes() to get you started on how to display Flickr photos.

Playing videos: constructing the embed code

We don’t currently provide a way to get to the FLV for a video. (the Flash encoded video file) We’re looking into making this possible. In the mean time if you want to display watch-able videos you’ll need to embed our video player.

In addition to the photo height and width of the preview images, videos also have a stream height and stream width which we set when we process videos during upload. While you can make the video player any size you want the videos are going to look much better if displayed at the proper size.

You can get the stream height and stream width and the URL for the video player using the standard flickr.photos.getSizes() method:

<sizes canblog="1" canprint="1" candownload="1">
<size label="Square" width="75" height="75" source="http://farm2.static.flickr.com/1423/2345938910_846d9c1be9_s.jpg" url="http://www.flickr.com/photos/revdancatt/2345938910/sizes/sq/" media="photo"/>
... standard getSizes stuff ...
<size label="Video Player" width="500" height="375" source="http://www.flickr.com/apps/video/stewart.swf?v=49235&photo_id=2345938910&photo_secret=846d9c1be9" url="http://www.flickr.com/photos/revdancatt/2345938910/" media="video"/>
</sizes>

Alternately the stream width and height are included in the new video element returned by flickr.photos.getInfo()
:

...
<video ready="1" failed="0" pending="0" duration="14" width="500" height="375" />
</photo>
....

Generating Embed Code

The player takes a height, a width, a photo id, a photo secret (required for playing non-public videos), and the argument flickr_show_info_box, which when set to layers over top of the video videographer, and video title info when the video isn’t playing.

I’m not going to go over in depth the markup for the player, but here is a quick and dirty PHP function for generating it:

#
# takes a "Video Player" source from flickr.photos.getSizes() and optional display arguments
#

function flickr_video_embed($video_url, $width="400", $height="300", $info_box="true") {

    $markup = <<<EOD
<object type="application/x-shockwave-flash" width="$width" height="$height" data="$video_url"  classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"> <param name="flashvars" value="flickr_show_info_box=$info_box"></param> <param name="movie" value="$video_url"></param><param name="bgcolor" value="#000000"></param><param name="allowFullScreen" value="true"></param><embed type="application/x-shockwave-flash" src="$video_url" bgcolor="#000000" allowfullscreen="true" flashvars="flickr_show_info_box=$info_box" height="$height" width="$width"></embed></object>
EOD;
    return $markup;

}

Videos in the feeds

Videos, unsurprisingly, are included in all of the various RSS and Atom feeds which contain photos. For each video entry we include a MediaRSS content element that points to the SWF player, and has a content type of “application/x-shockwave-flash”. Additional we include the stream height and width as the height and width elements in the content element.

In RSS 2.0 feed we also include an enclosure element.

Uploading Videos

Upload videos just like you would a photo. We’ll do the magic to figure out whether the uploaded file is a video or a photo. You’ll generally want to use the asynchronous upload methods as videos tend to be larger, and take more time to upload.

Videos need to be “transcoded” — turned into an FLV which is playable on the Web. As this takes time videos aren’t always immediately available for viewing. You can check the processing status of a video using flickr.photos.getInfo(), and examining the video element.

<video ready="1" failed="0" pending="0" duration="14" width="0" height="0"/>

ready is watchable, pending is still being transcoded, and failed videos need to be re-uploaded. (possibly in a different format)

More Questions?

We’ve got an open thread in the Flickr API group discussing video.

Twitter API updates, FireEagle and new Flickr API fun

Last night twitter released their next batch of API improvements, of course the one that caught my eye was …

“[NEW] /account/update_location.[xml|json] – sets the location for the
authenticated user to the string passed in a “location” parameter.
Nothing fancy, no geocoding or normalization. Just putting this out
there so developers can start playing with how geolocation might fit
into their Twitter applications.”

saving woeids in the location field

… which is nice as it’s just thrown in there as a ‘what if’ type of thing. There’s no direct reason for twitter to have location stuff, (well no more than Flickr I guess) but everyone knows that everyone wants it.

It’d be great if you didn’t have to update twitter yourself and there was something else out there that could do it for us.

Read the rest of “Twitter API updates, FireEagle and new Flickr API fun” for more on Twitter’s location API, FireEagle, and Flickr’s not-a-geocoder.

FireDopplGängEaglr

First, there was filtr but that’s another story entirely. The point being that I gave up carrying around a capital-C camera a few years ago choosing instead to make do with cameraphones and the availability of cheap, unlimited data-plans in the U.S.

I am mostly lazy and can’t really be bothered to shuttle photos around from one device to another only to move them again to the giant device in the sky called Flickr. Before filtr I relied on the upload by email feature to snag a photo and quickly share it with the future-past but the desire to touch up — or filter — the photos before upload meant that I needed to write my own service to accept, process and then upload pictures to Flickr using the API.

ph:camera=n82

Which is what I want to talk about. Sort of.

Read the rest of “FireDopplGängEaglr” for thoughts on FireEagle, Dopplr, place, and the DWIM engine.

Inside Photophlow: an interview with Neil Berkman

photophlow

I knew when we started talking about Code.Flickr I wanted to have interviews with third party developers, and I knew that I wanted my first interview to be with Neil Berkman, one of the engineers behind the amazing Photophlow

1. Can you say a bit about what Photophlow is for people who don’t know?

Photophlow is a web application for real-time group Flickr browsing. As you search and share photos the group you’re browsing with sees the same things you are instantly. You can comment on photos, fave them, tag them and more, and all of this is shared with the group in real-time. Photophlow is meant to be used for all types of interactions around photos – organized activities such as group critiques and tutorials, as well as just plain hanging out and sharing.

We also integrate with some other services like Twitter and Tumblr. For example you can send out a Twitter message with a link to your Photophlow room to invite your followers to a real-time conversation over photos. We also integrate with the major IM networks to notify you instantly when things happen in Photophlow, like someone commenting on one of your photos.

If you’d like to a quick tour of Photophlow I’d recommend this screencast.

(editor note: Also checkout the photophlow group!)

2. How are you integrating with Flickr? What services or API methods do you use?

We use quite a bit of the API. Your identity on Photophlow is your Flickr identity, so of course we take advantage of authentication. We currently have two types of rooms – “personal rooms” tied to a user and rooms based on Flickr groups. We use the contacts and groups API’s to give control over privacy.

We take advantage of almost all of the API methods for browsing or searching for photos. And of course tagging, commenting and faving all go through the API.

One of my favorite features makes use of machine tags. We let you specify custom “photo emotes” – for example if you type /smile as a chat message we’ll show a photo you’ve tagged as phlow:emote=smile. Another makes use of the Yahoo Term Extraction API. We use this to determine interesting words and phrases in chat messages and we turn these into Flickr search links. Keying off of the conversation like this works really nicely for discovering areas of Flickrspace that you might not discover otherwise, and the results you get from clicking on a random phrase are often very funny and unexpected.

3. What if you favorite part of working with the Flickr APIs?

The nicest thing about it is the completeness. So far we’ve found that almost everything we’ve wanted to do has been possible.

4. What (if any) where the challenges?

The major challenges we face are due to the unique real-time group nature of our application. We’d like to be responsible consumers of the API so we set some restrictions for ourselves, such as never making a separate API call for each person in the room. For example when we display a photo we don’t indicate whether it’s already a fave because we’d need to make this call multiple times. We turned this into a feature – if you “re-fave” a photo we delete your previous fave and add it again, moving it to the top of your list.

5. What else should I have asked you? (I’m new at this!)

How about “what would you like to see added to the API?”

One is “invite photo to group”. Some group admins are using Photophlow to review photos to invite to their pool. It would be great if we could allow them to actually issue the invitations from within Photophlow.

Another, much larger one would be the ability to invite your Flickr contacts to use a Flickr-based application. This would take a lot of work to ensure that it could be done in a non-spammy way. Even I have mixed feelings about it but as an app developer it would be nice to allow people to use their existing connections on Flickr to be able spread the word about an application more easily.

6. Are you using any open source components in Photophlow, especially any that relate to Flickr? Are you planning to release any?

Like everybody these days we make heavy use of open source. The part of Photophlow that interacts with Flickr is developed using Ruby on Rails, and we use the Ruby API for Flickr. We’ve hacked this up a bit and may either clean it up and contribute back or take another look at the current Ruby Flickr interfaces and see if we might want to switch.

7. What is next? Are you planning to build more with Flickr? Enhance your current app, or build something new? Is there an application you’re hoping someone else would build?

We plan on improving Photophlow in a number of ways. A big one is to provide more explicit support for events such as critiques and competitions. There are a number of fun features we’d love to build, for example the ability to add notes to photos and share these in real-time.

We’re also building a new web application called Videophlow, which allows for group synchronous video viewing with a “shared remote control”. Initially this will support Youtube but we’re planning to support other services and would love to include Flickr video as well.

Thanks so much Neil and good luck at Launchpad today!

Have you got a neat Flickr project folks should know about? Let us know in recommendations for the DevBlog thread!

Photo: “photophlow” by d.j. paine