These untidy queries arrive as an undifferentiated jumble of text—e.g. “pizza los angeles ca”—and while it’s obvious to a human what that means, it’s not so perfectly transparent to a computer. So it’s up to our search engineers to write programs that figure out which parts are the what of the user’s query, and which parts are the where.

We have recently done a bit of work on this front, and would like to share an initial implementation; it’s not perfect, but we hope it handles many common cases. (It works by comparing the sub sequences of words in the query string against known addresses in our database; we use the matches in order to distinguish the geographic terms in the query from the rest. Call it separating the where from the chaff …)

If you’d like to try it out, you can use the field below:

As usual, please use the comments to let us know if you find cases where it ought to work, but doesn’t.

However, not all search queries arrive at our servers in such neat and tidy packages. In some cases, queries arrive as an undifferentiated jumble of terms that may contain both types of information. If we’re lucky, we can identify and use any geographical information embedded in the text. Other times, the queries simply don’t contain geographic information that we can extract—they’re all what but no where.

In those cases, all we’ve got to go on is the IP address of the user’s computer—which isn’t great, but it’s certainly better than nothing! So we have deployed a new feature that takes the users’s IP address, then looks it up in a database of known IP addresses to find the real-world location associated with that address. It’s not foolproof, and it’s not exhaustive, but in many cases it does a fairly good job of identifying a user’s location.

If you’re curious, you can try this out now—go ahead, see if we can guess where you’re sitting. (And let us know how we did in the comments!)