Falling into Flickr's mirror universe

[sbisson]

I have been bashing my head against the keyboard most the day, trying to write a location-based query against the Flickr API. Every time I ran my search I kept getting the same picture - that of a cat somewhere in the Seychelles. This wasn't right - as I was trying to search for images in London, Bath and Edinburgh.

My JavaScript JSON code was right, my loop was working. I was giving Flickr a latitude/longitude-based bounding box for the search, and a reasonable base date for the search results. So what was going wrong? I was getting the same results using Flickr's API explorer, so I knew it wasn't my code that was wrong - and a search with Flickr's own mapping tools gave me plenty of results. So there was some mismatch between the queries I was building and the data Flickr was querying on.

I finally found the answer, on my n^th read through of the documentation. The reason why my queries weren't working was actually very simple - and also completely illogical.

Instead of using conventional lat/long pairs for the bounding box, Flickr is using long/lat. I have no idea why someone made that illogical decision - it's something that's very easy to miss, as we're conditioned to think in lat/long, so I just misparsed the documentation that Flickr provides every time I read it.

Still, my code's working now (I'll be putting my location/weather/interestingness mashup online soon at my new development web site - www.sbisson.com). I just need to make a few final refinements to the search loop, and then write the tutorial article that I've been developing the code for...

Lesson re-learnt: be more careful when reading the documentation.

And if I ever meet the person at Flickr who made the decision to have an API that reversed common conventions, I'm going to have a conversation about how design by contract needs to respect conventional data formats.

Comments

[mdlbear]

x, y

Stupid, but that's almost certainly why.

[andrewducker]

Of course, if it was a sensible API the parameter would be encapsulated in something that specified what is was. Or is XML now on the way out?

[sbisson.livejournal.com]

The trouble is, if you're doing cross-site work without access to a server-side proxy XML doesn't really cut it. JSON works as it inserts the JavaScript object into the calling page, getting around the JavaScript security model in useful ways... Normally I'd prefer a proper XML API, but needs must!

However, in this case even XML wouldn't have helped as the API parameter I was using was a set of comma-separated values labled bbox - it's purely the documentation that detiled how the values were to be formatted. A well written API would have had four terms - minlat, minlong, maxlat, maxlong - not one.

[sbisson.livejournal.com]

That's what I suspected too - blasted graphics conventions get everywhere, even when there are standard conventions in the mapping world.

It's a problem we need to get over. A better written API with a well defined set of variables would have been the best approach... It's a lot easier to attach a value to a name, than deliver a list to a name.

[mdlbear]

Of course, map coordinates are completely unambiguous if you attach the appropriate compass direction (N/S or E/W) to them. One of the few places where strong typing is a win.

That cat

[(Anonymous)]

I'm not sure why you got so upset - why would you not want to a picture of my cat? He's possibly the greatest cat alive today!

Unfortunately my wife and I will be leaving Seychelles in a week and are heading off to Kuwait for new jobs. Nobby's not coming - he's a Seychelles cat through and through.

Steve Copley

Re: That cat

[sbisson.livejournal.com]

It wasn't the cat that was the issue (he's a lovely looking beast, and we've got four of our own here!) - it was that I was expecting to get images from the UK and not the other side of the world!

Good luck with the new jobs!