![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Falling into Flickr's mirror universe
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 nth 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.
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 nth 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.
no subject
no subject
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.