4 ms·
This optimisation must exist at a basic level in all satnav software because journey time must be longer for the route with more left turns, as fed back into th
by Theodores 10y ago
This optimisation must exist at a basic level in all satnav software because journey time must be longer for the route with more left turns, as fed back into the system from previous journeys by other users.
It would be an interesting experiment to see how different consumer grade satnav systems compare on this pure travelling salesman problem.
- lorenzhs 10y agoIt's not TSP. In TSP, you have a graph and want to visit every node exactly once. Here you have a (road) graph and want to visit some set of nodes (the delivery addresses) at least once (it's okay to drive past a house where you dropped off a parcel earlier if that somehow makes the journey shorter). Also, consumer satnav systems don't support this kind of query. You can't plug in a list of dozens of destinations and ask for the shortest path to get you to all of them, in any order.
- DerekL 10y agoIt reduces to a special case called the metric TSP. If going through node C is shorter than going from A to B directly, then just replace the A-to-B distance with the length of A-to-C-to-B. It's just as hard to solve as regular TSP, but easier to approximate.
- lorenzhs 10y agoWell yeah it's clearly still NP-complete. But the TSP (or variant thereof) isn't related to the routing engine at all, as the routing engine only defines the edge weights. They're fairly orthogonal problems. Logistics software needs to solve both, but consumer satnav doesn't.