This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(121.6, 50%, 21%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJM%3C/text%3E%3C/svg%3E)
When I perform a fuzzy search using the Azure Maps REST API, the results are not limited to the bounding box I specify. This makes searching for partial addresses much less useful, since many/most/all of the results are from other states and the relevant results from the specified state are not included in the first 10-20 results.
For example, if I search for "123 Main" and specify a bounding box that covers the state of Louisiana, I should get a half dozen or so point addresses in the results, and all the results should be constrained to the bounding box. (There may be a few results from the edges of surrounding states since the bounding box is a rectangle.) Instead, I get results from Connecticut, Ohio, Massachusetts, and so on that are clearly outside the bounding box.
The documentation clearly states, "You can use the btmRight and topleft parameters to set the bounding box. These parameters restrict the search to a specific area on the map."
https://learn.microsoft.com/en-us/azure/azure-maps/how-to-use-best-practices-for-search#limit-search-results
https://learn.microsoft.com/en-us/rest/api/maps/search/get-search-fuzzy
The test query I am using is:
Am I doing something wrong? How do I limit the search results to the bounding box?
Hi @Jeremiah Mercier , Thanks for your query. Community SME's on this topic or our team will review your scenario and circle back at the possible earliest time.
The bounding box is meant to help influence the relevance of the results and is not a filter.
I think you're confusing the bounding box with the lat and lon parameters. From the docs:
To influence the area of relevance for the results, define the lat and lon coordinate parameters. Use the radius parameter to set the radius of the search area.
You can use the btmRight and topleft parameters to set the bounding box. These parameters restrict the search to a specific area on the map.
When the area of the bounding box is small (a few city blocks), it is more likely to act as a filter. When the bounding box is large (state size) the weight of the bounding box is reduced and is not used as a filter, but instead used to help prioritize the relevance of the results. I'm fairly certain the docs are inaccurate in this regards. The main purpose of the bounding box parameters is for scenarios where you want to find results close to the viewable map area of an interactive map. Most search API's I've seen act in the way I describe when there is a bounding box parameter.
If you want to search for results within a specific area, there is the Search Inside Geometry API for this: https://learn.microsoft.com/en-us/rest/api/maps/search/post-search-inside-geometry?tabs=HTTP
That may be how other API's work, but this is not what the documentation states for this API. If you look at the results from the sample I posted, you'll notice that the results are not relevant to either the hint point or the bounding box. The results are spread across the country with no apparent regard to either. This is not for lack of relevant results.
A coworker discovered that if the lat & lon parameters are removed, then the bounding box works as expected & as documented. The query then returns 20 different "123 Main Street" or "123 North/South/East/West Main Street" point addresses all within the bounding box, all of which are more relevant to the hint point (lat/lon parameters) in the original query than the original results. This suggests that (1) the bounding box is intended to work as documented and (2) the results returned by the original query are not being influenced by either the hint point (lat/lon) or the bounding box.
[https://atlas.microsoft.com/search/fuzzy/json?subscription-key=[SUBSCRIPTION_KEY]&api-version=1.0&query=123+Main&countrySet=US&idxSet=Addr,PAD,POI,XStr&limit=20&typeahead=true&topLeft=33.019457,-94.043147&btmRight=28.928609,-88.817017
Dropping the lat/lon parameters is not a satisfactory solution, however, since we want to both restrict the search results to a large area and influence the area of relevance to a specific location within that larger area. This is consistent with the guidance provided in the best practices:
To geobias results to the relevant area for your user, always add as many location details as possible.
Incidentally, I tested removing the bounding box (topLeft/btmRight) and using only the lat/lon parameters, then removing the lat/lon parameters as well, and the results of all three queries were virtually identical. The lat/lon parameters do not appear to be working at all, and when specified, appear to break the bounding box filter.
[https://atlas.microsoft.com/search/fuzzy/json?subscription-key=[SUBSCRIPTION_KEY]&api-version=1.0&query=123+Main&countrySet=US&idxSet=Addr,PAD,POI,XStr&lat=30.3618&limit=20&lon=-91.1067&typeahead=true&topLeft=33.019457,-94.043147&btmRight=28.928609,-88.817017
[https://atlas.microsoft.com/search/fuzzy/json?subscription-key=[SUBSCRIPTION_KEY]&api-version=1.0&query=123+Main&countrySet=US&idxSet=Addr,PAD,POI,XStr&lat=30.3618&limit=20&lon=-91.1067&typeahead=true
[https://atlas.microsoft.com/search/fuzzy/json?subscription-key=[SUBSCRIPTION_KEY]&api-version=1.0&query=123+Main&countrySet=US&idxSet=Addr,PAD,POI,XStr&limit=20&typeahead=true
The Search Inside Geometry API is not a satisfactory solution since it provides no fuzzy or typeahead logic. We are attempting to implement auto-suggest results similar to the behavior of Bing Maps or Google Maps, which both return a list of suggestions for a partial address while typing the address.
That may be how other API's work, but this is not what the documentation states for this API. If you look at the results from the sample I posted, you'll notice that the results are not relevant to either the hint point or the bounding box. The results are spread across the country with no apparent regard to either. This is not for lack of relevant results.
A coworker discovered that if the lat & lon parameters are removed, then the bounding box works as expected & as documented. The query then returns 20 different "123 Main Street" or "123 North/South/East/West Main Street" point addresses all within the bounding box, all of which are more relevant to the hint point (lat/lon parameters) in the original query than the original results. This suggests that (1) the bounding box is intended to work as documented and (2) the results returned by the original query are not being influenced by either the hint point (lat/lon) or the bounding box.
Dropping the lat/lon parameters is not a satisfactory solution, however, since we want to both restrict the search results to a large area and influence the area of relevance to a specific location within that larger area. This is consistent with the guidance provided in the best practices:
To geobias results to the relevant area for your user, always add as many location details as possible.
Incidentally, I tested removing the bounding box (topLeft/btmRight) and using only the lat/lon parameters, then removing the lat/lon parameters as well, and the results of all three queries were virtually identical. The lat/lon parameters do not appear to be working at all, and when specified, appear to break the bounding box filter.
The Search Inside Geometry API is not a satisfactory solution since it provides no fuzzy or typeahead logic. We are attempting to implement auto-suggest results similar to the behavior of Bing Maps or Google Maps, which both return a list of suggestions for a partial address while typing the address.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(153.6, 75%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKF%3C/text%3E%3C/svg%3E)
@Jeremiah Mercier I'd noticed this issue too i.e. issues with GeoBiasing and issue when using lat&lon params cancels/overrides topLeft&topRight params.
I agree with you that it's a real issue and was not behaving as intended. I don't think it was a documentation mistake. I also think the suggested fix to use countrySet param was essentially a hack to give "better" results.
However, the issue appears to have been resolved now. Using your examples above:
topLeft&topRight params onlyhttps://atlas.microsoft.com/search/fuzzy/json?subscription-key=SUBSCRIPTION_KEY&api-version=1.0&query=123+Main&idxSet=Addr,PAD,POI,XStr&limit=20&typeahead=true&topLeft=33.019457,-94.043147&btmRight=28.928609,-88.817017
Gives result:
topLeft&topRight params and lat&lon params:https://atlas.microsoft.com/search/fuzzy/json?subscription-key=SUBSCRIPTION_KEY&api-version=1.0&query=123+Main&idxSet=Addr,PAD,POI,XStr&limit=20&typeahead=true&topLeft=33.019457,-94.043147&btmRight=28.928609,-88.817017&lat=30.3618&lon=-91.1067
Notes:
countrySet param has not been used in either of these examples yet the result are what you'd expect. This param is now only really required if you have a usecase where you need a further filter so that, for example, you only want to return results on one side of a national border even though the view covers more than one country.
It is working as intended. These are bias's and not hard restrictions. center takes priority over bounding box. The behavior of these parameters are pretty standard in the geospatial industry. Unfortunately the Azure Maps reference docs aren't complete. This service is actually powered by TomTom. More complete documentation can be found here: https://developer.tomtom.com/search-api/documentation/search-service/fuzzy-search
A couple of key points from TomTom's docs:
Bias means that locations closer to the area will take precedence. Results outside that area can still be returned by will be lower in the rankings/result list.
@Kevin Flood Thank you for the feedback. I gave up on using lat/lon because it clearly wasn't working at the time & was completely breaking the bounding box. I'll retest it next time we work on this area of our app.
@rbrundritt At the time of my original post, as I stated, lat/lon was not working at all. It did not influence the results of my query. I got the same results with or without it. All it did was break the bounding box.
According to Kevin's response, this has been fixed. (I haven't tested it recently.) His comment and screenshots show that the bounding box & geobiasing point work in conjunction with each other in his example, as they should, which contradicts your statement. Your quote from the TomTom documentation refers to the mutually exclusive approaches of using a bounding box (a rectangle) and point + radius (which defines a bounding circle). None of our examples define a radius; only a geobiasing point. Thus, that note is not applicable to this situation.
The behavior of these parameters are pretty standard in the geospatial industry.
Disagree. Defining a hard boundary (e.g., only return results within this area) in combination with a geobias (e.g., prefer results near my current location) is a pretty typical requirement.
Unfortunately the Azure Maps reference docs aren't complete.
If the Microsoft documentation is incorrect, please work with the team to correct it. This is a premium service and we rely on the documentation.