![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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.
aggravated
(no subject)
Stupid, but that's almost certainly why.
(no subject)
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.
(no subject)
(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.
That cat
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
Good luck with the new jobs!