locked
Route API fails for an address which worked until yesterday RRS feed

  • Question

  • We are using Route API  REST service to calculate Driving distance between addresses. The service worked ok for the address  "4 Irving Pl 10003" until 5/2, 7 PM EST and  we noticed a failure for the same address starting 5/3, 7 PM EST.

    we tried "4 Irving Pl, NY 10003" and "4 Irving Pl, New York, NY 10003" to see if there is an address formatting issue, it failed even then.

    URL: http://dev.virtualearth.net/REST/v1/Routes/Driving?o=xml&ed=true&wp.1=4+Irving+Pl+10003&wp.2=30+Flatbush+Ave+11217&routeAttributes=excludeItinerary&distanceUnit=Mile&key=xxxxxxx

    <?xml version="1.0" encoding="utf-8"?>
    <Response xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/search/local/ws/rest/v1">
    <Copyright>Copyright © 2017 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.</Copyright><BrandLogoUri>http://dev.virtualearth.net/Branding/logo_powered_by.png</BrandLogoUri><StatusCode>404</StatusCode><StatusDescription>Not Found</StatusDescription>
    <AuthenticationResultCode>ValidCredentials</AuthenticationResultCode><Errors><ErrorDetails><string>One or more locations specified in the waypoint parameter are invalid or require more information.</string>
    <string>4 Irving Pl 10003</string></ErrorDetails><ErrorCode>NotFound</ErrorCode></Errors><TraceId>8d5e046a890a42e784049c8603eb07f0|BN20240253|7.7.0.0|</TraceId><ResourceSets /></Response>



    • Edited by RaviA4 Thursday, May 4, 2017 5:44 PM
    Thursday, May 4, 2017 5:40 PM

Answers

  • I just tested those addresses with the REST services and they worked fine. I also tried your URL as-is and it also worked, although it does not align with best practices.

    Looks like you are escaping and not encoding your waypoints. All information passed into the REST services should be encoded as noted in the best practices here: https://msdn.microsoft.com/en-us/library/dn894107.aspx This can significantly increase the success rate of your requests.

    Also worth noting that your addresses are fairly poorly formatted and could become an issue at some point. You are providing a street address and a zip code. At a minimum I would recommend a comma between them. Adding commas and a city would be better. There are a lot of street addresses that look just like this and the "zip code" is actually a street or building number. 


    [Blog] [twitter] [LinkedIn]

    Friday, May 5, 2017 3:15 AM

All replies

  • I just tested those addresses with the REST services and they worked fine. I also tried your URL as-is and it also worked, although it does not align with best practices.

    Looks like you are escaping and not encoding your waypoints. All information passed into the REST services should be encoded as noted in the best practices here: https://msdn.microsoft.com/en-us/library/dn894107.aspx This can significantly increase the success rate of your requests.

    Also worth noting that your addresses are fairly poorly formatted and could become an issue at some point. You are providing a street address and a zip code. At a minimum I would recommend a comma between them. Adding commas and a city would be better. There are a lot of street addresses that look just like this and the "zip code" is actually a street or building number. 


    [Blog] [twitter] [LinkedIn]

    Friday, May 5, 2017 3:15 AM
  • we opened up a support request and the issue was resolved  around 5/4, 6:45 pm ET after the Bing Maps Operations team rolled out a fix. As described in the question we tried with fully formatted address and at this particular time majority of the Manhattan addresses failed.

    Encoding waypoints - yes, we are  implementing this in our next application patch.

    Address formatting: Agreed and that's on our radar to go for a better formatting. But is there a documentation available around this on how to format a waypoint to make it work a 99.99%  for the U.S. addresses ? which one would you recommend from the examples given below.

    4 Irving Pl, New York, 10003

    4 Irving Pl, NY 10003

    4 Irving Pl, New York, NY 10003

    The city name would be little tricky over here in NYC because many customers just use borough name

    For example: 134 AUDLEY ST , QUEENS, NY 11418 address is valid and with the real city name it would become 134 AUDLEY ST, RICHMOND HILL, NY 11418.

    Also, sending the full address doesn't always return a good response either : e.g.: 1455 51st St, Brooklyn, NY 11219 address was not found by route API for the whole month of April and  in the same window 1455 51st St 11219 worked perfect. I don't have many examples of this scenario at the moment, but I will certainly open another case with Microsoft if we encounter this issue again.

    I didn't quite get this comment "and the "zip code" is actually a street or building number". Does BING consider 10003 as building number in "4 Irving Pl 10003" if there is no comma ?

    Tuesday, May 9, 2017 9:23 PM
  • Ok, good to know you synced up with the support team. If you have a Bing Maps license, they should be your first point of contact for issues. 

    For the zip code comment, there are addresses in the world that have the exact same format as your input but the "zip code" is actually a road number. For example "758 Lakeshore Rd 103" (a road I used to live on). Without a comma between your road name and zip code, their is a sight chance that some results will return unexpected results because the zip code is seen as a road name. I have seen similar issues many times before. The world is a big place with a lot of different address formats.


    [Blog] [twitter] [LinkedIn]

    Tuesday, May 9, 2017 9:51 PM