Azure maps compute best order summary not matching returned polylines

Question

Hello,

When using the azure maps route api with compute best order enabled I've found that the lines and routes output are different to the optimized order summaries that come in the same response. This leads to a mismatch between the two and after manually looking at the lines produced they create the logical order expected while the summary doesn't which means the result then can't be used without examining where the lines start and end.

Example using some generated coordinates in the UK:

URL used to generate rest api call -
https://atlas.microsoft.com/route/directions/json?api-version=1.0&query=53.79913,-1.547699:53.773066,-1.568298:53.820922,-1.601944:53.813626,-1.456375:53.73734,-1.493454:53.734497,-1.586151:53.788889,-1.655502:53.882083,-1.51886:53.871559,-1.675415:53.86832,-1.419296:53.764949,-1.358185:53.694267,-1.472168:53.657661,-1.583405:53.730842,-1.728973:53.849286,-1.770172:53.801665,-1.538043&subscription-key=*subscription-key*&computeBestOrder=True&routeType=fastest

I would have expected the two to align and I've factored in the n-1 due to the start and end being removed, some of the differences are much larger than that for me to think that is the issue, happy to know if I've configured something incorrectly though.

Thanks,
Alex

Answer 1

This is known and documented here: https://learn.microsoft.com/en-us/azure/azure-maps/how-to-use-best-practices-for-routing#calculate-and-optimize-a-multi-stop-route. The start and end points keep their index, the computed best order indices are relative to waypoints 1 through N - 1. So you need to increment the computed best order indices by 1 to have them align with the indices from start - end. This isn't something that can be changed as it would break any apps already using this service.

Answer 2

I've tried your waypoints in this sample: https://azuremapscodesamples.azurewebsites.net/?search=route%20waypoint&sample=Route%20Waypoint%20Optimization

And the generated optimization looks good. When you account for the offset, the optimized order I'm seeing for the original waypoint index values is: 0, 1, 5, 4, 3, 7, 9, 10, 11, 12, 13, 14, 8, 6, 2, 15 which creates a loop around the city.

Here is a screenshot. Note that the numbers are the original waypoint index value (i.e. the 3rd stop is had index of 5 in the original set of waypoints).

Note that the web SDK uses [lon,lat] format for coordinates. Here is the waypoint values I used in the sample:

   var waypoints = [  
       [-1.547699, 53.79913],  
       [-1.568298, 53.773066],  
       [-1.601944, 53.820922],  
       [-1.456375, 53.813626],  
       [-1.493454, 53.73734],  
       [-1.586151, 53.734497],  
       [-1.655502, 53.788889],  
       [-1.51886, 53.882083],  
       [-1.675415, 53.871559],  
       [-1.419296, 53.86832],  
       [-1.358185, 53.764949],  
       [-1.472168, 53.694267],  
       [-1.583405, 53.657661],  
       [-1.728973, 53.730842],  
       [-1.770172, 53.849286],  
       [-1.538043, 53.801665]  
   ];