Route API gives a SHORTEST route which is faster than the FASTEST route

21 posts / 0 new
Last post
purchase.1
Route API gives a SHORTEST route which is faster than the FASTEST route

Hello,

I am running into the following issue, when requesting the route between two points (45.5859,4.7848) to (45.539,4.27778) with the option route type SHORTEST I get a faster solution than with route type FASTEST (see below for the relevant part of the two answers). What can be causing this issue as this result seems completely inconsistent?

 

<route>
    <sessionId>5ac78431-01c2-4ee4-02b4-254d-0ae38bcd5a94</sessionId>
    <options>
      <shapeFormat>raw</shapeFormat>
      <generalize>-1.0</generalize>
      <maxLinkId>0</maxLinkId>
      <narrativeType>text</narrativeType>
      <stateBoundaryDisplay>true</stateBoundaryDisplay>
      <countryBoundaryDisplay>true</countryBoundaryDisplay>
      <sideOfStreetDisplay>true</sideOfStreetDisplay>
      <destinationManeuverDisplay>true</destinationManeuverDisplay>
      <avoidTimedConditions>false</avoidTimedConditions>
      <enhancedNarrative>false</enhancedNarrative>
      <returnLinkDirections>false</returnLinkDirections>
      <timeType>0</timeType>
      <routeType>SHORTEST</routeType>
      <locale>en_US</locale>
      <unit>M</unit>
      <tryAvoidLinkIds />
      <mustAvoidLinkIds />
      <manmaps>true</manmaps>
      <drivingStyle>2</drivingStyle>
      <highwayEfficiency>22.0</highwayEfficiency>
      <useTraffic>false</useTraffic>
    </options>
    <boundingBox>
      <ul>
        <lat>45.58826</lat>
        <lng>4.246019</lng>
      </ul>
      <lr>
        <lat>45.441879</lat>
        <lng>4.786293</lng>
      </lr>
    </boundingBox>
    <distance>37.091</distance>
    <time>2545</time>

...

 

<route>
    <sessionId>5ac78403-0017-4ee4-02b4-2364-0ec055f42e60</sessionId>
    <options>
      <shapeFormat>raw</shapeFormat>
      <generalize>-1.0</generalize>
      <maxLinkId>0</maxLinkId>
      <narrativeType>text</narrativeType>
      <stateBoundaryDisplay>true</stateBoundaryDisplay>
      <countryBoundaryDisplay>true</countryBoundaryDisplay>
      <sideOfStreetDisplay>true</sideOfStreetDisplay>
      <destinationManeuverDisplay>true</destinationManeuverDisplay>
      <avoidTimedConditions>false</avoidTimedConditions>
      <enhancedNarrative>false</enhancedNarrative>
      <returnLinkDirections>false</returnLinkDirections>
      <timeType>0</timeType>
      <routeType>FASTEST</routeType>
      <locale>en_US</locale>
      <unit>M</unit>
      <tryAvoidLinkIds />
      <mustAvoidLinkIds />
      <manmaps>true</manmaps>
      <drivingStyle>2</drivingStyle>
      <highwayEfficiency>22.0</highwayEfficiency>
      <useTraffic>false</useTraffic>
    </options>
    <boundingBox>
      <ul>
        <lat>45.638519</lat>
        <lng>4.190581</lng>
      </ul>
      <lr>
        <lat>45.441879</lat>
        <lng>4.787023</lng>
      </lr>
    </boundingBox>
    <distance>51.171</distance>
    <time>3051</time>

...

 

 

 

 


MQBrianCoakley
Thanks for the heads up. I
Thanks for the heads up. I sent this to the routing development team and it points to a bug in their system. A ticket has been created and this should be addressed in a future update. Sorry for any inconvenience.

purchase.1
Hello,

Hello,

thanks a lot for the quick reaction. Can you keep us posted about the resolution of the issue?


MQBrianCoakley
Yup.
Yup.

purchase.1
Hello Brian,

Hello Brian,

any update on this subject? When can we expect a resolution for this issue?

Best Regards


MQBrianCoakley
No update yet. It is in the
No update yet. It is in the team's backlog. 

purchase.1
Hello Brian,

Hello Brian,

any update on this one?

Regards


MQBrianCoakley
Nope. It's still in the
Nope. It's still in the backlog.

purchase.1
It's been 3 months now, can

It's been 3 months now, can you provide an estimate about when this is going to be fixed?

Thanks in advance


MQBrianCoakley
The shortest route type is

The shortest route type is much less restrictive and can at times produce faster results. These are very rare edge cases that are related to an issue that is being evaluated now and will be addressed with a future release that we don't have an eta for at this time.

 

Is this particular route a consistent issue or are there other routes that produce similar results? Since this route ends on the side of a major highway, it is an edge case that the route algorithm is not handling well. If the route destination is moved to the driveway of the facility that the lat/lng seems to be within, rather than the highway the lat/lng is actually closer to, the route does not behave unpredictably.


john@zippyzen.com
Hi,

Hi,

Was there ever any resolution to this problem?  I am currently making two API calls for every route API call (https://www.mapquestapi.com/directions/v2/route) because of this bug/problem.  I am making the first API call with routeType=fastest then another API call with routeType=shortest, then comparing both the distance and time of the two results, then picking the result of the routeType=shortest only both the distance and the time are less than the results using routeType=fastest.  I'm am doing this because I was getting a lot of reports from my users that the routeType=fastest was not returning sensible results.  Only once I checked both API calls and manually chose the result that had both shortest distance as well as shortest time did my users tell me the results were sensible.

While my technique worked to solve the problem for my users, it also means I'm making double the API calls.  I am now getting overage charges every month and would like a way to get back to just making a single API call so that I don't have overage charges every month.

So I am wondering if there was ever any resolution on this issue and if I could reliably switch back to just using the single default routeType=fastest API call without the need to use the safety net of the second API call.  To be clear, I am expecting that using routeType=fastest should always return an equal or faster driving time than using routeType=shortest.  Based on my version control history of my application code, this problem existed in January of 2018 and looks like it still existed in April of 2018 based on this thread.  So I am wondering if this problem might have been resolved since April 2018?

Thanks,

John


MQBrianCoakley
This issue is still in the
This issue is still in the backlog. It has not been resolved.   Do you know what percentage of routes that you're requesting are faster as the SHORTEST route than than the FASTEST? We don't have that type of statistics internally and the testing the team has done shows that it is an edge case.

john@zippyzen.com
I don't have any specific

I don't have any specific statistics or percentages currently, but I could build a pretty specific mechanism to log it and get the testing team some very specific cases and percentages.  I only know that it has happened "sometimes" because I used to get bug reports / calls from my customers explaining specific situations in which it used to occur before I put my fix / hack in.  Since I put my hack in, I have not heard any complaints about "weird" directions.

I'd be happy to do that in order to get you all some specific examples and numbers.  This bug is costing me $100 / month at this point due to my current usage of directions requests, so I definitely have some motivation to provide you all what I can in order to help resolve it.

I'll turn on some logging and will see if I can post some results in the next few days, and we can see if my info helps at all.


MQBrianCoakley
That would be fantastic!
That would be fantastic!

john@zippyzen.com
Hi,

Hi,

I implemented a custom logging mechanism to track this on my production server, so I should have some decent data to report within a few days.  In the meantime, here is an example result that illustrates the problem from our dev/test environment:

Using the lat/lng pair start=45.528951,-122.659042 and stop=45.489714,-122.595231 (Portland, Oregon, USA), here are the two API calls that my application made:  https://www.mapquestapi.com/directions/v2/route?key=XXX&from=45.528951,-... and https://www.mapquestapi.com/directions/v2/route?key=XXX&from=45.528951,-...

The result from the fastest call: time 909 seconds, distance 10.7 miles.  Result from the shortest call: time 814 seconds, distance 5.5 miles.  So the call using the shortest parameter returns both a faster time and a shorter distance.

In my initial test tonight, I made 125 directions requests (actually 250 because I have to make two calls), and out of those 125 requests, I got 8 responses that had a faster time and a shorter distance using the shortest parameter, so at least for my test tonight, I'm getting about 6% of my requests are incorrectly returning results for fastest.

I'll let some data build up in the logs for a couple days and will report back when I have more info.

Thanks,

J


MQBrianCoakley
It looks like the realTime of
It looks like the realTime of the fastest route is less than the realTime of the shortest route. While the time is the other way around, traffic will affect the route times.

john@zippyzen.com
Thanks so much for the info. 

Thanks so much for the info.  If I'm understanding what you are saying, I don't think I understood precisely what routeType=fastest is returning.  Technically, it sounds like it is returning the route that has the smallest realTime value (I'm assuming based on precisely when the API request is made?), not the smallest time value.  Possibly my confusion is because I am trying to get the routeType=fastest response based on ideal driving conditions (basically always ignore traffic).  I don't always know precisely when during the day the user is going to drive the route, so my intention was to ask the API "Give me the fastest driving route based on ideal driving conditions, since I don't know what the driving conditions will be when the route is actually driven."

So, is there a way to ask the API routeType=fastest, but have it return the result that has the smallest time value instead of the smallest realTime value?  I see that there are options available in the Date / Time Routing advanced options, but the default values of those options are all set to false (meaning ignore traffic conditions).  So I don't see how providing those options in my request would help.

So, again, if I am understanding what you've explained, and the routeType=fastest returns the route with the smallest realTime value, I'm not exactly sure how to formulate an API request to get what I'm looking for.  I suppose I could use the Date / Time Routing advanced options and just randomly pick a certain time of day such as noon.

Any info/suggestions?


MQBrianCoakley
This is the default function
This is the default function of the Directions API. Changing it would be an enhancement request.

john@zippyzen.com
Thanks so much for the info. 

Thanks so much for the info.  I'm going to spend some time thinking about if there is a way I can adjust my application based on my users' requirements, and if there is a way I can use the default behavior of the API.

I'll submit an enhancement request if I can't figure out how to make it work.  Thanks again!


john@zippyzen.com
By the way, thanks so much

By the way, thanks so much for the response.


MQBrianCoakley
You're welcome. I wish I had
You're welcome. I wish I had a more positive/helpful response.