none
Bing Custom Map URL - Route Options (rtop) RRS feed

  • Question

  • I am working on a website that takes two addresses and gives users the option to display directions in Bing Maps, optimized by either Time or Distance. I believe this used to work correctly, but since the overhaul to Bing maps, it appears like I can only get directions with the shortest time.

    Here is an example of the URLs:

    Optimize by Time (rtop=0~0~0):

    http://bing.com/maps/default.aspx?v=2&rtop=0~0~0&rtp=adr.4202 E Fowler Ave, Tampa, FL 33620~adr.Stanford Dr, Coral Gables, FL 33146

    Optimize by Distance (rtop=1~0~0):

    http://bing.com/maps/default.aspx?v=2&rtop=1~0~0&rtp=adr.4202 E Fowler Ave, Tampa, FL 33620~adr.Stanford Dr, Coral Gables, FL 33146

    Note that the two routes are the same. Am I doing something wrong, or is optimization by distance no longer possible?

    Thanks!


    • Edited by Sentinel7e Friday, June 10, 2016 7:19 PM Correcting Links
    Friday, June 10, 2016 7:08 PM

Answers

  • The new site does not support these route options. It was found that very few ever calculated routes other than the fastest with traffic. The only time the shortest distance was ever used was when calculating walking directions. As such the map now automatically uses shortest distance when calculating walking directions.

    If you really want to option to override this, you can request it here: https://binglistens.uservoice.com/forums/283355-ideas/category/94066-maps


    [Blog] [twitter] [LinkedIn]


    Monday, June 13, 2016 7:05 PM
  • Funny, this is actually the forums for the Bing Maps API's and not the consumer site. So your second question is in the right place.

    This will have no effect on the Bing Maps REST API's. This change is limited to the Bing Maps consumer site which is basically just another customer who has built their app on top of the Bing Maps API's.


    [Blog] [twitter] [LinkedIn]

    Tuesday, June 14, 2016 12:38 AM
  • Can you provide example start and end points for testing? The routing services should be the same, however the website is using a new backend geocoder that we are testing which the developer API's isn't using yet. It is possible that the start/end locations are being geocoded to slightly different locations and thus the differences in the route calculations.

    That said, if you were to use a standard route optimization calculation in any solution it will almost always return slightly different answers as the optimization calculation is often approximated. The only way to get the perfect optimization is through brute force which would take a very long time to calculate. Take a look at the path the website and the API take and see if they are the same. If they are exact and were calculated at the same time, then it is possible that there is a difference in the routing service between the API's and the developer API's. We often use the website as a testing ground when we implement tweaks to our service and don't expose these through our API until we are happy with the results as we don't want to negatively effect the API's for developers.


    [Blog] [twitter] [LinkedIn]

    Monday, September 19, 2016 11:47 PM
  • I just tried the routes you provided at the same time in both the website and the REST services and got nearly identical results. The only difference is what I already pointed out. The geocoded end points are not the same. If you geocode "Stanford Dr, Coral Gables, FL 33146" you will find that the website and the REST API's have slightly different coordinates for this address. This is to be expected as we are testing a new backend geocoder on the website. Once this geocoder passes all quality control tests the developer API's will be updated on the backend to use this geocoder.


    [Blog] [twitter] [LinkedIn]

    Thursday, September 22, 2016 5:13 PM

All replies

  • The new site does not support these route options. It was found that very few ever calculated routes other than the fastest with traffic. The only time the shortest distance was ever used was when calculating walking directions. As such the map now automatically uses shortest distance when calculating walking directions.

    If you really want to option to override this, you can request it here: https://binglistens.uservoice.com/forums/283355-ideas/category/94066-maps


    [Blog] [twitter] [LinkedIn]


    Monday, June 13, 2016 7:05 PM
  • Thank you!

    This may be the wrong forum for this, but do you know if this will eventually impact the Bing Maps REST Services? Will the optimize (optmz) parameter also be phased out?

    Monday, June 13, 2016 7:49 PM
  • Funny, this is actually the forums for the Bing Maps API's and not the consumer site. So your second question is in the right place.

    This will have no effect on the Bing Maps REST API's. This change is limited to the Bing Maps consumer site which is basically just another customer who has built their app on top of the Bing Maps API's.


    [Blog] [twitter] [LinkedIn]

    Tuesday, June 14, 2016 12:38 AM
  • Sorry for resurrecting this old thread. One of our users has come across a similar API vs. Bing issue that I can't explain. Our app is using the REST API to determine driving directions, optimized by time without traffic. In this example it returned 37 miles. However if you copy the same addresses into Bing Maps, it presents 2 routes that have shorter time without traffic than the 37 mile route. My understanding that Bing Maps is using the same REST API's as we are, so how are they getting routes that are quicker?

    Here's another example where the API returned 115.2 miles but Bing Maps found a route that was 113.6 miles and quicker without traffic.

    Thanks for any clarification you can provide!

    Friday, September 16, 2016 7:18 PM
  • Can you provide example start and end points for testing? The routing services should be the same, however the website is using a new backend geocoder that we are testing which the developer API's isn't using yet. It is possible that the start/end locations are being geocoded to slightly different locations and thus the differences in the route calculations.

    That said, if you were to use a standard route optimization calculation in any solution it will almost always return slightly different answers as the optimization calculation is often approximated. The only way to get the perfect optimization is through brute force which would take a very long time to calculate. Take a look at the path the website and the API take and see if they are the same. If they are exact and were calculated at the same time, then it is possible that there is a difference in the routing service between the API's and the developer API's. We often use the website as a testing ground when we implement tweaks to our service and don't expose these through our API until we are happy with the results as we don't want to negatively effect the API's for developers.


    [Blog] [twitter] [LinkedIn]

    Monday, September 19, 2016 11:47 PM
  • Thanks for the reply Ricky. This was escalated internally, and we now have an enterprise ticket open for this issue.

    When I set maxSolutions=3, the API returned the same three results as Bing Maps. The problem now is, if maxSolutions=1, we are trying to determine why the API would return the 37.0 or the 115.2 mile routes, if faster/shorter routes are available. This is currently being investigated by the Bing Maps API team that handles routing.

    Thanks again for your help!

    Thursday, September 22, 2016 1:56 PM
  • I just tried the routes you provided at the same time in both the website and the REST services and got nearly identical results. The only difference is what I already pointed out. The geocoded end points are not the same. If you geocode "Stanford Dr, Coral Gables, FL 33146" you will find that the website and the REST API's have slightly different coordinates for this address. This is to be expected as we are testing a new backend geocoder on the website. Once this geocoder passes all quality control tests the developer API's will be updated on the backend to use this geocoder.


    [Blog] [twitter] [LinkedIn]

    Thursday, September 22, 2016 5:13 PM