Why do so many APIs offer geographic searches based on a single point and a radius, but not based on a bounding box using two points? Does your computer or mobile device have a round screen? If so, a radius search is perfect for you. But if your screen is rectangular, your search should be too. API designers need to wake up and realize that nobody has a round screen, and thus radius-based geo searches are vastly inferior to rectangular searches!
Here’s an example from Times Square. For a search at 42nd and Broadway, if you set the radius to be half the width of the screen, your search area would look like this green circle. On a square screen, those four corners outside the circle add up to 21% of the display (given a square display of width w, (w² – π×w²/4)/w² = 21%). For rectangular screens, it becomes higher. For example, putting a circle in a rectangle that’s twice as long as it is high means you are missing 61% of the display. This means you might not be including results that the user would expect to see.
So to avoid that problem, you’d have make the radius as big as the diagonal line from the center to a corner. For a square screen of width w, that radius would be w/1.4 (or w×0.71). Now the problem is that instead of not getting results for areas on on screen, our results could include locations outside of the screen. For our square-screen example, 36% of the circle would fall outside of the square. So now we’re getting back results that might not be visible to the user.
A better way to query geographic locations is to specify a bounding box. That requires two points; either pair of opposite corners will do. The Google Maps API uses a LatLngBounds class that’s created using the southwest corner and the northeast corner.
As a bonus for API providers, a bounds-restricted search is mathematically simpler than a radius-based search. Checking to see if a point lies within a box requires only 4 greater-than/less-than comparisons, while checking to see if a point lies within a circle means you have to calculate a distance, which means you’re calculating squares and square-roots. Blech!
Instead of asking the user how big a search radius he wants, it’s better to just have him zoom out the current map to include whatever area he wants to search, with a good default setting. That way the pre-search state of the map is itself a control.
If you have the luxury of providing another geo-based API function, another useful function would be to return the N-closest locations, but that’s a topic for another post.