Case sensitivity for Azure Maps Search V2?

Question

We want to start using the structured search of the Search V2 preview endpoint (yes, we know it's preview). While we love its fuzzy search capabilities (which the V1 endpoint doesn't have), we wonder why it often returns different results for different casing instead of returning all possible results.

The following example shows that by writing the German word for "street" (which is "Straße" or "straße") starting with upper or lower case in the address line makes a difference.
We'd expect that both addresses would be returned as results and not just one or the other.

Two samples, one with "Straße" and one with "straße" in the address line:

A: curl --request GET --url 'https://atlas.microsoft.com/geocode?api-version=2022-02-01-preview&subscription-key=SUBSCRIPTION_KEY&addressLine=Burkhard%20stra%C3%9Fe%2011&locality=Hann&location=9.6616%2C51.4186&view=DE&postalCode=34346' --header 'Accept-Language: de-DE'

returns exactly one feature with the formattedAddress "Burg Straße 11, 34346 Hannoversch Münden"

B: curl --request GET --url 'https://atlas.microsoft.com/geocode?api-version=2022-02-01-preview&subscription-key=SUBSCRIPTION_KEY&addressLine=Burkhard%20Stra%C3%9Fe%2011&locality=Hann&location=9.6616%2C51.4186&view=DE&postalCode=34346' --header 'Accept-Language: de-DE'

returns exactly one feature with the formattedAddress "Burckhardt Straße 11, 34346 Hannoversch Münden"

Is there any way to disable case insensitivity, especially for such common words like the German word for "street" which occurs in most addresses anyway?
Or is there something else we can do to get both results for either query?

Thanks in advance and kind regards,
Sebastian

Answer 1

The search v2 services is using the Bing Maps geocoder behind the scenes. It has much better algorithms behind it than v1 but unfortunately there have been a few known caveats in that service as well and even documented on the Bing Maps side: https://learn.microsoft.com/en-us/bingmaps/getting-started/bing-maps-api-best-practices#use-the-find-by-query-api Basically, the unstructured (single line address query) is highly recommended over the structured address query. So much so it is recommended to take your structured address data and create a single line address query and pass it in that way. Trying your addresses and changing the case of the "s" seems to result in the same result for both queries. I'm not 100% sure why, but this just seems to return more accurate results on average, likely has something to do with the parsing logic and the early-stage logic filters in the algorithms. I've found the v1 services to be more consistent in their results and better at handling structured addresses, while the Bing Maps geocoder which powers the v2 service is much better at handling unstructured addresses (single line queries).

That said, there is also some issues when combining postal codes with addresses as these aren't always well-connected entities. So, including a postal code in an address query can sometimes reduce the accuracy of the results. I know, this seems crazy as you would think more data is better, but this is something I've encountered with just about every geocoder out there at one point or another. Often removing the postal code from the query helps get more accurate results (unless you are only searching for a postal code, in which case, only include that and maybe the country).

Note, I'm not on the maps team or ever worked on the geocoding services side of our map platforms. My comments above are mainly just from my past experience using these services.