Unexpected Results From Azure Maps Query for Searcy, AR

This is possibly an issue with the V1 search services which are powered directly by TomTom. I recommend using the latest version of the Search service (version "2026-01-01") which is powered by Microsoft directly and leverages Bing data which includes TomTom and many other data sets for higher accuracy. https://learn.microsoft.com/en-us/rest/api/maps/search?view=rest-maps-2026-01-01

Hello Nate Fleming,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you are having unexpected Results From Azure Maps Query for Searcy, AR.

In addition to @rbrundritt the identified direction to move off Search v1 is correct, but to fully solve the issue you must also correct the request pattern itself. The current repro is using legacy search/fuzzy in predictive mode (typeahead=true), which Microsoft has superseded in Search 2026-01-01. For this scenario, the correct design is to use geocode:autocomplete only for suggestions and then use geocode for the final committed lookup. Do not treat a predictive suggestion as authoritative geocoding. - https://learn.microsoft.com/en-us/azure/azure-maps/migrate-search-v1-api, https://learn.microsoft.com/en-us/rest/api/maps/search/get-search-fuzzy?view=rest-maps-1.0, https://learn.microsoft.com/en-us/rest/api/maps/search/get-geocode-autocomplete?view=rest-maps-2026-01-01, https://learn.microsoft.com/en-us/rest/api/maps/search/get-geocoding?view=rest-maps-2026-01-01

For the autocomplete stage, replace the v1 call with the dedicated GA endpoint and restrict the result type so that the UI only returns city-like places. Microsoft’s autocomplete API supports resultTypeGroups and resultTypes, and it requires either coordinates or bbox. For this case, use Place + PopulatedPlace so that you do not surface irrelevant administrative or mixed types as municipality suggestions. - https://learn.microsoft.com/en-us/rest/api/maps/search/get-geocode-autocomplete?view=rest-maps-2026-01-01, https://learn.microsoft.com/en-us/azure/azure-maps/migrate-search-v1-api

GET https://atlas.microsoft.com/geocode:autocomplete
    ?api-version=2026-01-01
    &query=Searcy
    &coordinates=<userLon>,<userLat>
    &countryRegion=US
    &resultTypeGroups=Place
    &resultTypes=PopulatedPlace
    &top=5

After the user selects a suggestion or submits the final string, run a final geocoding request. If the intended search is “Searcy, AR”, use either the free-form query form or, preferably, the structured form when you want deterministic state/county validation. Microsoft’s Get Geocoding API supports locality, adminDistrict, and adminDistrict2 exactly for this purpose. - https://learn.microsoft.com/en-us/rest/api/maps/search/get-geocoding?view=rest-maps-2026-01-01, https://learn.microsoft.com/en-us/azure/azure-maps/migrate-search-v1-api

GET https://atlas.microsoft.com/geocode
    ?api-version=2026-01-01
    &locality=Searcy
    &adminDistrict=AR
    &adminDistrict2=White
    &countryRegion=US

If you prefer free-form committed resolution instead of structured input, use this exact final lookup and do not add countryRegion to the same request when query is already present, because Microsoft documents that structured geography parameters should not be mixed with query in that manner. [learn.microsoft.com]

GET https://atlas.microsoft.com/geocode
    ?api-version=2026-01-01
    &query=Searcy, AR

The application must then validate the returned result before showing it to the user. Accept the result only if the returned hierarchy matches the intended place for example, locality = Searcy, state/admin district = Arkansas (AR), and if your business rule depends on county-level correctness, county/admin district 2 = White. Microsoft’s migration guidance explicitly says applications must evaluate result type, confidence, and match codes, and must not assume that every successful response is usable. - https://learn.microsoft.com/en-us/azure/azure-maps/migrate-search-v1-api, https://learn.microsoft.com/en-us/rest/api/maps/search/get-geocoding?view=rest-maps-2026-01-01

If, after implementing the corrected 2026-01-01 autocomplete + final geocode flow and enforcing the hierarchy validation above, Azure Maps still returns a validated city-level Searcy result in Cross County, then the issue should be treated as a map-data defect, not as expected application behavior. In that case, submit it through the Azure Maps feedback tool, which is Microsoft’s official correction path for Azure Maps/Bing Maps data issues. - https://learn.microsoft.com/en-us/azure/azure-maps/how-to-use-feedback-tool

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Hello @Nate Fleming ,

Welcome to Microsoft Q&A .Thank you for reaching out to us.

Thank you for the detailed scenario and API reference.

The Azure Maps fuzzy/typeahead search for “Searcy, AR” returns multiple candidate results, including:

• Searcy, AR (White County)
• Searcy, AR (Cross County)

While Searcy is officially recognized as a city in White County, the additional Cross County entry may appear unexpected when viewed against strict administrative boundaries.

Azure Maps Search is designed to support fuzzy matching and autocomplete scenarios, where the goal is to maximize relevant suggestions rather than strictly enforce administrative hierarchies.

This behavior is influenced by:

• Fuzzy matching logic, which expands results beyond exact matches
• Typeahead mode, which prioritizes broader suggestion coverage
• A consolidated geographic index, combining multiple datasets into a unified search experience
• Multiple geographic representations associated with similar place names

Because of this design, a query such as “Searcy” may return several geographically plausible candidates with varying levels of relevance.

To improve precision and reduce ambiguity, the following approaches are recommended:

1. Validating using the latest Search API Testing the same query with the newer API version is recommended: Search - REST API (Azure Maps) | Microsoft Learn The latest version provides:
   • Improved data integration
   • More consistent geocoding behavior
   • Better alignment with administrative expectations
2. Improving query specificity Refining the query reduces ambiguity:
   • “Searcy, White County, Arkansas”
   • “Searcy, Arkansas, USA”
   More structured inputs typically result in higher-confidence matches.
3. Disabling typeahead for deterministic results For scenarios requiring direct geocoding rather than suggestions use typeahead=false.This reduces broad matching behavior and improves result stability
4. Adjusting or remove geo-bias
   1. Ensure latitude/longitude aligns with the intended region
   2. Remove geo-bias if not required, as it can influence result ranking
5. Applying response validation To ensure accurate selection:
   • Validate countrySubdivision = Arkansas
   • Validate countrySecondarySubdivision = White County (if strict mapping is required)
   • Prefer higher-confidence results returned by the API

The following references might be helpful , please check them out

• Best practices for Azure Maps Search service - Microsoft Azure Maps | Microsoft Learn
• Search for a location using Azure Maps Search services | Microsoft Learn
• Geocoding coverage in Microsoft Azure Maps Search service - Microsoft Azure Maps | Microsoft Learn

Please let us know if the response was helpful

Thank you

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the response was helpful. This will be benefitting other community members who face the same issue.