locked
Geogoding result for invalid addresses in Belgium not correct? RRS feed

  • Question

  • Hi,

    When I use the geocoding API but enter an invalid address in Belgium (but still supply a valid zip code and city/locality), the API still returns MatchCodes = Good. I had expected that when it could not find the address and instead found the geoposition using the zip code, it would have returned "Uphierarchy". Can someone please let me know why the API stil returns the MatchCodes = Good even when it has clearly ignored the address and found a position based on the zip code instead? I see that it returns the Entithat it returns EntityType = RoadBlock instead of Address, but it is difficult to understand why the MatchCodes parameter is cannot be used fully to understand the quality of the result?

    Can anyone explain this behaviour?

    VALID ADDRESS RETURNS MATCHCODES "GOOD"
    http://dev.virtualearth.net/REST/v1/Locations?countryRegion=BE&locality=Brussels&postalCode=1020&addressLine=Rue%20F%C3%A9lix%20Sterckx%2038&key=<mykey>

    {"authenticationResultCode":"ValidCredentials","brandLogoUri":"http:\/\/dev.virtualearth.net\/Branding\/logo_powered_by.png","copyright":"Copyright © 2020 Microsoft and its suppliers. All rights reserved. This API cannot be accessed and the content and any results may not be used, reproduced or transmitted in any manner without express written permission from Microsoft Corporation.","resourceSets":[{"estimatedTotal":1,"resources":[{"__type":"Location:http:\/\/schemas.microsoft.com\/search\/local\/ws\/rest\/v1","bbox":[50.88874,4.33876,50.89054,4.34162],"name":"Rue Félix Sterckx 38, 1020 Brussels","point":{"type":"Point","coordinates":[50.88964,4.34019]},"address":{"addressLine":"Rue Félix Sterckx 38","adminDistrict":"Brussels-Capital Region","adminDistrict2":"Brussels","countryRegion":"Belgium","formattedAddress":"Rue Félix Sterckx 38, 1020 Brussels","locality":"Brussels","postalCode":"1020"},"confidence":"High","entityType":"Address","geocodePoints":[{"type":"Point","coordinates":[50.88964,4.34019],"calculationMethod":"None","usageTypes":["Display"]}],"matchCodes":["Good"]}]}],"statusCode":200,"statusDescription":"OK"


    INVALID ADDRESS BUT VALID ZIP CODE/CITY RETURNS MATCHCODES "GOOD"
    http://dev.virtualearth.net/REST/v1/Locations?countryRegion=BE&locality=Brussels&postalCode=1020&addressLine=Invalid&key=<mykey>

    {"authenticationResultCode":"ValidCredentials","brandLogoUri":"http:\/\/dev.virtualearth.net\/Branding\/logo_powered_by.png","copyright":"Copyright © 2020 Microsoft and its suppliers. All rights reserved. This API cannot be accessed and the content and any results may not be used, reproduced or transmitted in any manner without express written permission from Microsoft Corporation.","resourceSets":[{"estimatedTotal":1,"resources":[{"__type":"Location:http:\/\/schemas.microsoft.com\/search\/local\/ws\/rest\/v1","bbox":[50.86857,4.33137,50.88656,4.35987],"name":"Émile Bockstaellaan, 1020 Brussels","point":{"type":"Point","coordinates":[50.87757,4.34802]},"address":{"addressLine":"Émile Bockstaellaan","adminDistrict":"Brussels-Capital Region","adminDistrict2":"Brussels","countryRegion":"Belgium","formattedAddress":"Émile Bockstaellaan, 1020 Brussels","locality":"Brussels","postalCode":"1020"},"confidence":"High","entityType":"RoadBlock","geocodePoints":[{"type":"Point","coordinates":[50.87757,4.34802],"calculationMethod":"None","usageTypes":["Display"]}],"matchCodes":["Good"]}]}],"statusCode":200,"statusDescription":"OK"


    INVALID ADDRESS AND CITY/LOCALITY BUT VALID ZIP CODE RETURNS MATCHCODES "GOOD"
    http://dev.virtualearth.net/REST/v1/Locations?countryRegion=BE&locality=Invalid&postalCode=1020&addressLine=Invalid&key=<mykey>


    {"authenticationResultCode":"ValidCredentials","brandLogoUri":"http:\/\/dev.virtualearth.net\/Branding\/logo_powered_by.png","copyright":"Copyright © 2020 Microsoft and its suppliers. All rights reserved. This API cannot be accessed and the content and any results may not be used, reproduced or transmitted in any manner without express written permission from Microsoft Corporation.","resourceSets":[{"estimatedTotal":1,"resources":[{"__type":"Location:http:\/\/schemas.microsoft.com\/search\/local\/ws\/rest\/v1","bbox":[50.86857,4.33137,50.88656,4.35987],"name":"Boulevard Émile Bockstael, 1020 Brussels","point":{"type":"Point","coordinates":[50.87757,4.34802]},"address":{"addressLine":"Boulevard Émile Bockstael","adminDistrict":"Brussels-Capital Region","adminDistrict2":"Brussels","countryRegion":"Belgium","formattedAddress":"Boulevard Émile Bockstael, 1020 Brussels","locality":"Brussels","postalCode":"1020"},"confidence":"Medium","entityType":"RoadBlock","geocodePoints":[{"type":"Point","coordinates":[50.87757,4.34802],"calculationMethod":"None","usageTypes":["Display"]}],"matchCodes":["Good"]}]}],"statusCode":200,"statusDescription":"OK"


    INVALID ADDRESS, CITY/LOCALITY AND ZIP CODE RETURNS MATCHCODES "UPHIERARCHY"
    http://dev.virtualearth.net/REST/v1/Locations?countryRegion=BE&locality=Invalid&postalCode=Invalid&addressLine=Invalid&key=<mykey>

    {"authenticationResultCode":"ValidCredentials","brandLogoUri":"http:\/\/dev.virtualearth.net\/Branding\/logo_powered_by.png","copyright":"Copyright © 2020 Microsoft and its suppliers. All rights reserved. This API cannot be accessed and the content and any results may not be used, reproduced or transmitted in any manner without express written permission from Microsoft Corporation.","resourceSets":[{"estimatedTotal":1,"resources":[{"__type":"Location:http:\/\/schemas.microsoft.com\/search\/local\/ws\/rest\/v1","bbox":[49.493789672851563,2.5441598892211914,51.505447387695313,6.403876781463623],"name":"Belgium","point":{"type":"Point","coordinates":[50.641090393066406,4.6610097885131836]},"address":{"countryRegion":"Belgium","formattedAddress":"Belgium"},"confidence":"Medium","entityType":"CountryRegion","geocodePoints":[{"type":"Point","coordinates":[50.641090393066406,4.6610097885131836],"calculationMethod":"Rooftop","usageTypes":["Display"]}],"matchCodes":["UpHierarchy"]}]}],"statusCode":200,"statusDescription":"OK"

    Regards

    Claes

    Saturday, November 14, 2020 9:07 AM

All replies

  • Hello Claes,

    There is an excellent explanation of "MatchCodes" at MapLocationMatchCode Enumeration - Bing Maps | Microsoft Docs. While this is for the native control it does have the same meaning.

    "Good" means only one potential match was found or multiple strong matches are found. In the case of the invalid address there were not multiple potential results meaning this result was not "Ambiguous". Note also the entity type "Roadblock" when the geocoder is unable to locate a match.

    Please note that I have escalated this thread to our Maps Geocoder team and they have added it to their backlog for review but they do work on an AGILE schedule so I can't offer you a timeline for their engagement.

    Sincerely,

    IoTGirl


    Tuesday, November 17, 2020 7:26 AM
  • Thank you IoTGirl!

    Does this mean that the Maps Geocoder team will put their response here on the Forum?

    Friday, November 20, 2020 9:01 AM
  • Hi Claes,

    As I logged the issue it will likely come back to me but I can't guarantee any timeline on issues like this as "Relevancy" is quite subjective.  If you say "I have an address that is missing" that is easier to validate than "What level of confidence do you have in the result you returned based on this string?"

    I hope that clarifies,

    IoTGirl

    Friday, November 20, 2020 8:05 PM
  • Thanks a lot! If I would summarise the main question, which is what making this urgent is: If I enter an address line “ABCDE”, while still supplying a valid zip code and city in Belgium, the geocoding will be done on the zip code level and an address in the middle of the zip code area is returned. However, in this case the MatchCodes is “Good”, while we had expected it to be “UpHierarchy”. Would this question be more explicit and simple for the team to answer? Thanks for your support! Claes
    Saturday, November 21, 2020 7:29 AM
  • Hi Claes,

    I think I can answer this one. If the address line, no matter how little or off, returns a single match then the response will be good. However, if there is no first level match and something with less precision is found, you will get "UpHierarchy".  I thought the explanation at the link I gave you above was clear, can you help me understand what is missing?

    Sincerely,

    IoTGirl 

    Monday, November 23, 2020 11:57 PM
  • Hi again Thanks for putting up with my questions that is much appreciated! What I really do not get is the statement “no matter how little or off returns a single value”... How could possibly an address line called “This is an invalid address XYZ” match a single value? How it is even possible that it could match that with a single result of a completely different address line? To me it does not make sense and I get the impression that it has not done a match on the address line but instead found an address in the middle of the zip code. Any thoughts? Thanks! Claes
    Tuesday, November 24, 2020 9:16 PM
  • Hi Claes,

    As noted above, I have escalated your specific example to the engineering team. The fact that an address match is found for a ridiculous string means that the "Best effort Search" actually found a match and didn't need to go Uphierarchy. Beyond that I can only tell you what the response codes mean and I bring those here from the link:

    Values

    Unknown

    Bing Maps SDK was unable to parse the value in the response.

    Good

    The location has only one match or all returned matches are considered strong matches. For example, a query for New York returns several Good matches.

    Ambiguous

    The location is one of a set of possible matches. For example, when you query for the street address 128 Main St., the response may return two locations for 128 North Main St. and 128 South Main St. because there is not enough information to determine which option to choose.

    UpHierarchy

    The location represents a move up the geographic hierarchy. This occurs when a match for the location request was not found, so a less precise result is returned.


    Wednesday, November 25, 2020 8:01 PM
  • Thank you! Any response from the engineering team yet? Regards Claes
    Monday, November 30, 2020 5:00 PM
  • Hi Claes,

    You are now working with a Support Team member and she can assist you with these details but she will give you the same answer I do. We can confirm that Bing Maps does purchase our data from Partners and that data is ingested to build the relevance used in the search. You asked if your issue type could be changed from Data to some other type and the answer is basically no.  We use the data to build relevancy so a data fix will be required.

    Yours is a complex one as well as the team will be reversing your call to see how that result was built. This is not a short fix nor can it be a single fix as the relevancy generator will be involved in the research. We can give you no timeline as there is no obvious fix.  I hope that clarifies.

    The only answer I and the Support team can give you is that the team agrees that this is a problem and has accepted the request to add it to their list of work items.

    Sincerely,

    IoTGirl

    Monday, November 30, 2020 7:51 PM