Technology, Books and Other Neat Stuff

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.