问题
This question already has an answer here:
- Using real distances between points in optaplanner 2 answers
I am new to optaplanner. I am trying to modify the vrp example [whether the CVRP or the VRPTW] to supports more than just the Euclidean distance as the edge weight between nodes. I am using the newest release optaplanner 6.0.0.CR5
回答1:
There are several ways to handle this. All presume you have a GPS system (such as google maps) that can easily return the distance between 2 points A and B.
Note that's it's the GPS's system responsibility to decide the actual roads to take from A to B (that's not an NP-complete problem and GPS systems have already been optimized for it). OptaPlanner is to decide which order to do A, B, C, D, ... (which is NP-complete).
A) Calculate the distance at hoc (not recommended)
Just replace the get Location.get...Distance(Location) method with a call to your GPS system.
Disadvantage: normally that method is called thousands of time per second and your GPS system won't return the answer that fast, slowing down your average score calculation enormously.
B) Precalculate the distance and store it in memory
In the class Location, add a Map<Location, int> dinstanceMap to holds the distance to every other Location. Fill that Map before calling solve() and implement get...Distance() to just do return distanceMap.get(otherLocation).
Disadvantage: memory scaling: if you have too many customers you'll get a OutOfMemory exception.
Workaround: for each Location, only add the 1000 closest Locations in that Map. Filter the Move selectors so it never tries to connect 2 locations which are not in each other's Maps. This might affect the quality of the result though.
C) Precalculate the distance and store it on disk and cache it in memory
Same as B), but because the distance matrix is too big, store it on disk. Use caching to only fetch a value from the disk if it hasn't been asked recently.
Update 2019: Just start from optaweb-vehicle-routing
来源：https://stackoverflow.com/questions/19410972/optaplanner-vrp-edge-weights-need-to-use-actual-gps-data-instead-of-euclidean-di