The Bing Maps SOAP Search Service

Given the choice, I normally go for REST over SOAP. Not in the context of choosing a lie-in over a shower, but rather in the context of webservice architecture. Retrieving a JSON or XML response from a RESTful web service just seems so much more lightweight, simple, and totally platform-agnostic than setting up a SOAP request.

As a result, following the launch of the Bing Maps REST Services last year, I generally don’t use the SOAP Services much. In most cases, the two services provide the same functionality – for example:

• You can retrieve static map images using the SOAP Imagery Service or REST Imagery API
• You can geocode (or reverse-geocode) address coordinates using the SOAP Geocode Service or REST Locations API
• You can calculate routes between locations using the SOAP Route Service or the REST Routes API

However, for some reason, there is no REST equivalent to the SOAP Search Service. So, if you want to perform a geographic search of Bing’s information (e.g. to find pubs, restaurants, railway stations, hotels etc. in a particular city, or near a latitude/longitude coordinate) you have to use the SOAP service.

There are two basic ways of performing a search – you can either supply an (unstructured) Query, or an StructuredQuery.

Query

An unstructured query is where you supply a single text string that describes both what you’re looking for, and where it should be located. For example:

• “London pubs”
• “Hospitals near Norwich”

You set the query string in the Query property of your SearchRequest class, as follows:

SearchRequest searchRequest = new SearchRequest();
searchRequest.Query =  "Cafe in New York";

From an end-user point of view, there are advantages to using a service that requires only a single search request parameter. The design of Google, Ask Jeeves, and many other web-based portals clearly demonstrate the effective simplicity of asking the user for only a single input, and then using a variety of natural language parsing algorithms to determine exactly what results are required to be returned.

From a developer point-of-view, however, the unstructured query is a pain, because that interpretation stage – the decision of how to translate from a natural language expression (“Cafes near New York”) to a set of filters on a dataset (WHERE type = “cafe” AND location = “New York”) – is taken out of your hands. I couldn’t find any documentation on how Bing parses the search query, and you certainly can’t modify it.

For example, is “Cafes near New York” the same query as “Cafes in New York”? If not, what is the arbitrary limit chosen to determine proximity to a location? How about “Cafes north of New York”, or “Cafes within 25 miles of New York”?

And what about the categories of what you’re searching for – what’s a valid thing to search for? Searching for “Restaurants in Norwich” gives a different result from “Takeaways in Norwich”. And searching for “Chinese takeaways near Norwich” gives me a further subset of that result. Yet, searching for “Chinese takeaways that serve deep-fried seaweed near Norwich” gives no results, and yet I know of an establishment across the road from me that does just that…

StructuredQuery

The structured query mitigates the problems with the unstructured query to some extent, by splitting out the “what are you searching for?” and the “where is it?” into two separate parameters – namely the Keyword and Location properties of a StructuredSearchQuery object. The equivalent search for the query “Cafes in New York”, using the StructuredSearchQuery, is as follows:

StructuredSearchQuery SSQ = new StructuredSearchQuery();
SSQ.Location =  "New York";
SSQ.Keyword = "Cafe";

SearchRequest searchRequest = new  SearchRequest();
searchRequest.StructuredQuery = SSQ;

In addition to making it easier for developers to apply separate geographic and categorical filters from their application, the StructuredQuery appears to be the only way of searching for locations based on coordinates, rather than a placename. Although not obvious from the MSDN documentation, the string set in the Location property doesn’t have to be a placename – it can alternatively be a latitude/longitude coordinate tuple (WGS84), specified in “latitude, longitude” format. To find my local pub, I can therefore use the following code:

StructuredSearchQuery SSQ = new StructuredSearchQuery();
SSQ.Location =  "52.62, 1.295";
SSQ.Keyword = "Pub";

SearchRequest searchRequest = new  SearchRequest();
searchRequest.StructuredQuery = SSQ;

Of course, this still doesn’t answer questions about how far the search radius extends around the supplied point, or whether searching for “Bar” would bring up different results than “Pub”….