The Code Train

Where Neil Crosby talks about coding on the train…

RSS Entries

Geolocation & Beer: Part 4 – Finding the Beer

Posted on June 2nd, 2010 by Neil Crosby. Filed under Blog Posts.

Now, I know I said there were only going to be three parts to this series, but I’ve just realised that I missed out a quite important part of how I built Beer Near Me – how I found the beer!

Even though Beer Near Me was only ever really built as a weekend project intended to help me learn about using the navigator.geolocation API, it was still pretty important to get some data to display on a map showing where the local beer was. After all, without that what would the point be?

Gathering the Data

To gather the local beer data I make several searches using the Google Local Search API – one that covers pubs, one for cocktail bars, one for off-licences, and so on. The searches I make to Google’s local search look something a little like this:

Lets walk through those query string parameters…

  • sll doesn’t actually stand for anything according to the docs, but denotes the centre point of of the search you’d like to perform. It’s a comma separated latitude/longitude value, so you’d use something like 52.2282962,0.1537945 for this parameter.

  • radius is the radius around the centre point that you’d like to search within, in miles.

  • q is the most important parameter by far though; being the query term for the thing you’re wanting to search for.

    You’ll notice that I’ve added a loc: onto the query. It turns out that without this undocumented extra bit of data, Google really doesn’t return much from its local searches. Before last week’s post I wasn’t using this extra qualifier, and whilst my searches were being centered around the expected point they weren’t returning much data.

    A case in point was around The Bricklayers Arms. Without the loc: qualifier The Bricklayers Arms was nowhere to be found. With the qualifier it suddenly started being returned by the searches to Google, along with a whole bunch of other local pubs.

Interpreting the Data

So, if that’s the search we make, what does the data we get back look like?

    "responseData": {
        "results": [
                "streetAddress":"Hötorget 13",
                    {"type":"","number":"08-782 19 30"},
                    {"type":"","number":"08-789 19 30"}
                    "Hötorget 13",
                    "111 57 Stockholm, Sweden"
                // another result
    "responseDetails": null, 
    "responseStatus": 200

(The data above is, by necessity, just a snippet of what’s actually returned.)

You’ll notice first of all that each result we get has a GsearchResultClass of GlocalSearch set. This allows easy checking of the data type returned. For our searches, the result class will always be GlocalSearch, but other searches would return values for web searches, images searches and more.

Moving on to the data that actually interests us, each item has the expected lat and lng attributes, along with other useful smidgens of data such as title, streetAddress etc.

Of particular note are the title and titleNoFormatting attributes. You’ll notice that within the title field the word “pub” is encapsulated in encoded bold tags. Two things to note here; first, “pub” was the thing we searched for, so this gets emboldened in the standard display that Google would like to use for results (but we’re still provided titleNoFormatting if we’d like to have access to an unformatted string). Second, any formatting applied by google in its API results will be encoded in this way. In Beer Near Me, I take the easy way out for the data I’m needing, and use titleNoFormatting.

Moving away from the data that comes from a single API request, lets take a quick look at what happens once we move into the world of performing lots of searches at once. Since with Beer Near Me I’m making multiple calls to Google to gather beer related locations, there’s the pretty large possibility that more than one of the searches will return the same place within its results. The deduping I do on Beer Near Me is very simple in this case – I simply keep track of the latitudes and longitudes of all the places that have been returned. That way if any locations turn up in a position that’s already had data assigned it it I can ignore it. It’s not perfect, but it does the job well enough.

Caching the Data

The last thing I want to briefly mention that I’m doing with the data is caching it using PHP’s APC.

This was the first time I’d attempted using APC on one of my own projects, so I had to install it on my Ubuntu based dev box. I did that following these instructions.

The reason for using APC to cache the calls to Google’s Local Search is simple – network calls are expensive and slow. With on average five calls to Local Search occurring on each page load on Beer Near Me you’d hope that they wouldn’t be having to go across network every single time. So, I implemented a very simple cache check:

$url = "…q=somesearch"
$urlHash = md5($url);

// Try and pull the data from cache
$results = apc_fetch($urlHash);

// If we don't find the data in cache we'll have to make
// an expensive call across the network.
if (!$results) {
    // Get the data however you'd normally get it
    $results = curl_exec($ch);

    // now store the data in APC
        $urlHash, // Key to identify the cache by
        $results, // Data from our curl call to store 
        $ttl      // Seconds - how long we'll cache for

As you can see above, I’m only using two APC methods – apc_fetch and apc_store. Really, this is all you generally need for simple caching; one method for getting the data if it already exists, and one for storing it in the cache if you had to get the data from elsewhere.

With that in place, any further requests to that same location will be a lot faster, since we’ll have stored the results locally. Result. For Beer Near Me I can afford to be fairly aggressive with our caching, since for the most parts new pubs and cocktail bars won’t spring up over the course of a few minutes and become immediately available in Google’s search results.

No more locations

And that’s it. As far as I’m concerned, that’s everything I’ve done so far on Beer Near Me. It’s been a fun little weekend project, and whilst there’s more I’d like to do with it at some point, I think I’m going to leave it alone for a few weeks now. After all, Science HackDay is in just over two weeks time, and no doubt I’ll get wonderfully caught up in something new for that. Hopefully whatever I hack on will even be useful.

Tags: , , , ,

If you enjoyed this post, subscribe to The Code Train and read more when I write more.

5 Responses to “Geolocation & Beer: Part 4 – Finding the Beer”

  1. I’ve been following your tutorial for examples, however I think it’s a bit silly that you say you do “this and that” when on your example you just use YAHOO js framework and it looks completely diferent from what you have here, for instance, I’m trying to figure out which query values you used and I can’t.

  2. Hi awls,

    There’s a reason why the code you see above looks different to the code you see on the site. On the site you can see the JavaScript that runs in the browser, whereas in the post above I’ve shown the PHP that runs on the server (which otherwise you wouldn’t see at all).

  3. actualy I meant the whole javascript part, also when I said here I ment the whole tutorial, not this part in particular, sorry for the misunderstanding

  4. It’s hard to find your blog in google. I found it on 21 spot, you should build quality backlinks , it will help you to get more visitors. I know how to help you, just type in google – k2 seo tips

  5. I read a lot of interesting content here. Probably you spend a lot of time writing, i know how to save you a lot of work, there is an online tool that creates readable, SEO friendly posts in minutes, just type in google – laranitas free content source

Comments RSS

Leave a Reply

TheCodeTrain Theme by Neil Crosby, Powered by WordPress