none
Bing Rest API ignoring Zip code when returning Lat/Long on best match RRS feed

  • Question

  • I am using Bing geocoding api to geo code addresses however when it does not find the valid address and while returning best possible geo codes for it, it does not look onto the zip codes or other available info and thus returns a lat-long that is not expected. Example: 507900  Sun Valley    Grand Blanc,48439  returns geo coding that belongs to Las Vegas Nevada to this address: 5061 Sun Valley Dr, Las Vegas, NV 89122, US

    I understand that the 5056 Address does not exist so instead of considering the zip code 48439 that belongs to MI why is it displaying a latitude and longitude in Las Vegas?

    If an unfound address is geo coded, can we force it to look onto other available fields on the input such as state, zip code, street name etc? Many thanks for your time.

    I have tried to separate the input address fields have a comma between the address and city and zip code however it did not work as expected.

    Thanks!


    • Edited by jobbazar Wednesday, September 18, 2019 3:03 PM
    Wednesday, September 11, 2019 5:21 PM

Answers

  • I now have a workable solution. I reformatted the entire input and have State, Zipcode and City first and then with a comma the remaining address that is house number and street etc and it worked.

    The only issue that I have is when it does not find the correct zip it goes to other lat/long but that is fine as my input is bad and I am okay with that.

    thanks again!@

    • Marked as answer by jobbazar Wednesday, September 18, 2019 3:03 PM
    Wednesday, September 18, 2019 3:03 PM

All replies

  • Hello Jobbazar,

    If you do not separate the components of the address, the geocoder uses order priority.  You are likely telling the API that the Zip Code is low priority as if you put the zip last, it will have least priority but you did not provide a sample call so I am making that assumption.  Please take a look at the docs here: https://docs.microsoft.com/en-us/bingmaps/rest-services/locations/find-a-location-by-address

    You should delineate each part of the address to ensure better interpretation. Notice that the sample:

    http://dev.virtualearth.net/REST/v1/Locations/US/WA/98052/Redmond/1%20Microsoft%20Way?o=xml&key={BingMapsKey} 

    Has the order clearly set, Country, State, ZIP, City, address.  This tells the Geocoder how to narrow it's search for the specific coordinate.  Specifically it says, restrict results to the US, then within the US, restrict to Washington State, then within Washington, look in 98052, then within Redmond City at this address, 1 Microsoft Way.

    Sincerely,

    IoTGirl




    Wednesday, September 11, 2019 6:10 PM
    Owner
  • @IoTGirl,

    Thank you. That explains.  I am not geocoding one address at a time and actually doing it bulk. So I create my input file and run it through the API.

    http://spatial.virtualearth.net:xx/REST/v1/dataflows/geocode?input=pipe&output=json<>

    My input file format is: Key|en-US|Address (number street line, Zipcode1, Zipcode2)

    So for me to add the Zipcode1 to priority are you suggesting to have it without the comma?

    Like (separated by space):

    Key|en-US|Address (number street line  Zipcode1  Zipcode2)

    or are you saying I should have it like this:

    Key|en-US|Zipcode1 Zipcode2 number street line)

    Wednesday, September 11, 2019 7:02 PM
  • Take a look at our recent blog for guidance on Bulk Geocode alignments https://blogs.bing.com/maps/2010/08/31/batch-geocoding-and-batch-reverse-geocoding-with-bing-maps/

        <GeocodeRequest Culture="en-US" IncludeNeighborhood="1">  
         
    <Address AddressLine="One Microsoft Way" AdminDistrict="WA" Locality="Redmond" PostalCode="98052" /> 
       
    </GeocodeRequest>

    Wednesday, September 11, 2019 10:22 PM
    Owner
  • Thank you @IoTGirl,

    I got that (batch mode cleansing) figured out and it's all running okay. I am not clear on the format of the address.

    I want to make sure the zip code is in consideration on determining Lat/Long when hierarchy is considered.

    Do I need to put the zipcode in same line of the address like this:

    Key|1212 Main Street Lansing 48912

    Thank you so much again!

     

    Thursday, September 12, 2019 1:20 AM
  • If you want the Zipcode respected in either single or batch geocoder you need to call it out as a "Postal Code" entity I have shown you in my previous answers.  As you said you are using Batch geocode you would want to ensure that you have something like this, PostalCode="98052"  in the sample above.
    Thursday, September 12, 2019 4:31 PM
    Owner
  • I am facing some configuration issue. Here is the problem.

    the below address, which clearly has a zip code, city and State on the address line is some how showing a lat long from Florida.

     

    I understand there might not be a valid address in Lansing with that house number however the closest it is coming up with a hierarchy alphabetically in FL.  I don't want that. Is there a way I can ask to return the closest Lat/Long based on the city/State and Zip if the address is not found?  Otherwise I don't want a suggested one which is wrong in this case?

    Thank you for your help.

     


    • Edited by jobbazar Wednesday, September 18, 2019 3:01 PM
    Tuesday, September 17, 2019 5:36 PM
  • I now have a workable solution. I reformatted the entire input and have State, Zipcode and City first and then with a comma the remaining address that is house number and street etc and it worked.

    The only issue that I have is when it does not find the correct zip it goes to other lat/long but that is fine as my input is bad and I am okay with that.

    thanks again!@

    • Marked as answer by jobbazar Wednesday, September 18, 2019 3:03 PM
    Wednesday, September 18, 2019 3:03 PM
  • Hi jobbazar,

    I am glad my guidance to put you highest priority items first worked for you.  It would be best if you actually used the definitive call instead but I outlined above but if moving the order works for you, that is great.

    Sincerely,

    IoTGirl

    Thursday, September 19, 2019 4:25 PM
    Owner