Correcting Location Data … the Flickr way …

It’s a little odd posting over there but now that Flickr does have a Dev Blog, it kinda makes sense to mostly post Flickr related geo-stuff there. And more comment here, even if I’m still stuck with an utterly dorky theme.

Anyway, recently I made a few posts about our new “corrections” stuff, you can read about it in more general terms on the main Flickr Blog: Introducing a new way to geotag and nerdy terms in the dev blog: Location, keeping it real on the streets, yo! with the first follow up here; Defining the boundaries we are all within.

In the Location, keeping it real on the streets, yo! post there’s a couple of paragraphs where I manage to nearly sum up why I think it’s important …

“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.”

… and …

“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.”

But what does it all really mean (to me)? Well, at a very basic level it means we’ve taken the descriptive geo-data on Flickr down to the next granular level. Instead of only going down to Town and City levels, we now go down to neighborhoods, and this is now reflected in the API.

Rereading Yahoo Woe (Where On Earth, that is) IDs but imagine it talks about going down to the next level will do the trick.

Before if you used flickr.photos.getInfo on a photo that had location information you’d get something like this …

<location latitude="37.772156" longitude="-122.430726" accuracy="14" place_id="kH8dLOubBZRvX_YZ" woeid="2487956">
	<locality place_id="kH8dLOubBZRvX_YZ" woeid="2487956">San Francisco</locality>
	<county place_id="hCca8XSYA5nn0X1Sfw" woeid="12587707">San Francisco</county>
	<region place_id="SVrAMtCbAphCLAtP" woeid="2347563">California</region>
	<country place_id="4KO02SibApitvSBieQ" woeid="23424977">United States</country>
</location>

… but now you get (scroll right if you’re viewing this on the web) …

<location latitude="37.772156" longitude="-122.430726" accuracy="14" place_id="69uQyQCbCZ5svKzBvA" woeid="28288710">
	<neighbourhood place_id="69uQyQCbCZ5svKzBvA" woeid="28288710">Lower Haight</neighbourhood>
	<locality place_id="kH8dLOubBZRvX_YZ" woeid="2487956">San Francisco</locality>
	<county place_id="hCca8XSYA5nn0X1Sfw" woeid="12587707">San Francisco</county>
	<region place_id="SVrAMtCbAphCLAtP" woeid="2347563">California</region>
	<country place_id="4KO02SibApitvSBieQ" woeid="23424977">United States</country>
</location>

The neighborhood node thingy being the new bit.

How’s this useful? Well in a hacky kind of way you can now pair up a couple of flickr api calls to do reverse geocoding …

Use the first one with a sacrificial photo you have write permission on (i.e. your own). Set it’s location with a Lat/Long and then go get the information for that photo to find out where Flickr thinks that photo was taken. There’s a couple of other ways of doing it, but that’s probably the easiest to understand.

The advantage to Flickr and the whole ecosystem that builds up around it of doing this is, as we feed back user submitted corrections into the backend, the neighborhoods Flickr assigns to a Lat/Long will slowly evolve over time to our user’s view of the world … and we have quite a lot of them, so in major cities this should be quite good.

This is hopefully converting a “database” view of an area (for want of a better term) into how real people on the ground view of an area.

On that subject, it’s also possible that users of FireEagle (now public), websites that integrate with FireEagle and users of websites that intergrate with FireEagle will also gain the benefit of potentially millions of people make updates to location, depending on how far back into WOE we can roll the data.

That to me is the magic part, people taking photos over here and saying “Oh no, that photo wasn’t taken in such-and-such, but actually here” can have a positive effect on someone’s experience with a totally unrelated website who happens to be using FireEagle to update their location. Suddenly that website gains the local knowledge from thousands of photographers :)

Well, that’s kinda the theory anyway, but it’s always interesting being able to take that kind of theory and attempt to put it into practice.

3 Responses to “Correcting Location Data … the Flickr way …”

  1. “The neighborhood node thingy being the new bit.” (en-US ?)
    but it’s spelt neighbourhood in the XML (en-GB ?)

    I expected this would be added sometime so I put it in my flickcurl code as the en-US one. And I made a release yesterday where I could have added this. 2x FAIL :(

  2. Crazy Brits with their extra letters in “neighborhood.” :)

  3. Is there a way to add neighborhood names that are not already on the list? It got the names right automatically for most of my photos, but others of them are in places that don’t fall neatly into any of the neighborhods that are there to choose from.

Leave a Reply