none
Ambiguous address match candidates RRS feed

  • Question

  • Hi All, 

    I'm geocoding the following address in the US: 992 E 300 N, Delco ID using the url:

    http://dev.virtualearth.net/REST/v1/Locations?CountryRegion=US&adminDistrict=ID&locality=declo&addressLine=992%20e%20300%20n&key=MY_KEY&userIp=127.0.0.1

    I'm getting back two results both with confidence=HIGH and matchCodes=GOOD so there's now difference between the results to key off.  One of the results is the EXACT address typed in:

    Result 1: 

    formattedAddress:992 E 300 N, Declo, ID 83323

    Result 2:

    formattedAddress":992 N 300 E, Rupert, ID 83350

    The second address is not even in the same "locality" so the first result should somehow indicate its better.

    I'm starting to see this type of result quite a lot in my application these days. This there something I'm missing in the request to get a better result?

    Thanks

    Fred


    Fred Spataro http://wwww.GCS-Research.com

    Tuesday, April 19, 2016 3:57 PM

Answers

  • Generally, the first result will almost always be the result you want. In this case Declo and Rupert are right beside each other and the two results aren't that far away from each other. The geocoder likely returns both results with high confidence as there is a higher than normal probability that the user might of been looking for the other address given their similarity and close proximity.

    [Blog] [twitter] [LinkedIn]

    Tuesday, April 19, 2016 10:12 PM
  • This is a issue is a bit different from the originally one as the cities are the same for both results. In this case both results are have a high likely hood of being what the user meant as it is fairly common for people to reverse the S,W,N,E by accident. That said, in this case the second result should instead be retuned as the first result and given a high confidence. We are working on updating our geocoder and already use it on the bing maps consumer site: http://bing.com/maps. Trying this address there, the result is as expected.


    [Blog] [twitter] [LinkedIn]

    Wednesday, April 20, 2016 8:19 PM

All replies

  • Generally, the first result will almost always be the result you want. In this case Declo and Rupert are right beside each other and the two results aren't that far away from each other. The geocoder likely returns both results with high confidence as there is a higher than normal probability that the user might of been looking for the other address given their similarity and close proximity.

    [Blog] [twitter] [LinkedIn]

    Tuesday, April 19, 2016 10:12 PM
  • Thanks for the reply, but I don't think that's correct or a good solution to code.  Here's an example where same switching occurs but the within the same city AND the first result is the incorrect one: 

    Input: 28 W 6th S, St Anthony, ID  83445.  

    Returns:

    [0] 28 S 6th W, St Anthony, ID  83445.  confidence Medium

    [1] 28 W 6th S, St Anthony, ID  83445.  confidence Medium

    It makes no sense to give the same "confidence" for an non-matching value.  If you use both the correct city and zipcode in the original  address request, you still get the same ambiguous results.  

    I think Idaho has been moving away from the street type (ie ST, AVE, BLVD) in their gridded addresses and that's causing a matching issue in the geocoder since there's no match for that street type value --- just a guess b/c we're only seeing the issue in addresses with the format NUMBER PREFIX NAME SUFFIX...


    Fred Spataro http://wwww.GCS-Research.com

    Wednesday, April 20, 2016 6:18 PM
  • This is a issue is a bit different from the originally one as the cities are the same for both results. In this case both results are have a high likely hood of being what the user meant as it is fairly common for people to reverse the S,W,N,E by accident. That said, in this case the second result should instead be retuned as the first result and given a high confidence. We are working on updating our geocoder and already use it on the bing maps consumer site: http://bing.com/maps. Trying this address there, the result is as expected.


    [Blog] [twitter] [LinkedIn]

    Wednesday, April 20, 2016 8:19 PM