here's another summary of the usecases of a specific module. This article should enable you to understand under what circumstances the usage of a distance matrix is meaningful. It would be great if you get an impression of how to improve your existing requirements but also if you get triggered to create new usecases, too.
Check these videos, too!
English / German
Before I go into details let me distinguish the following major scenarios
- xDima creates information which is persisted on the server. Another component such as xTour or xCluster then refers to the content : possible
- xDima creates information which is returned to the client who then uses it for whatever (e.g. your own optimization algorithm) : possible
- you upload your own information to xDima which then provides the handle to xTour/xCluster, e.g. custom driving times based on some kind of a schedule : currently impossible. If you need this : let me know!
- Sequence optimization: a set of stops (x,y) is supposed to be ordered in a way that a single vehicle requires a minimum of driving time and distance to handle as many of them as possible. Shape: single distance matrix with a square shape.
- TourOptimization - Part I - homogeneous: a set of stops is supposed to be assigned (and ordered) to several vehicles in a way that maximum of orders s scheduled with lowest number of vehicles and compact tours. Homogeneous fleet: All vehicles have same routing options. Shape: believe it or not: just one square dima is required (same as with sequencing).
- TourOptimization - Part II - heterogeneous: a set of stops is supposed to be assigned (and ordered) to several vehicles in a way that maximum of orders s scheduled with lowest number of vehicles and compact tours. Heterogeneous fleet: Vehicles have two or more classes of routing options, e.g. some fast ones versus some slow ones, some large ones versus some smaller ones. Shape: One square distance matrix per routing category.
- Nearest search I - restaurant case - outbound: you know the positions of several destinations and you want to determine the optimal one (=the one you can reach from a given start location in the optimal time/distance). Shape: "one to many" - rectangular shape, not neccesarily squared
- Nearest search II - delivery case - inbound: you know the positions of several starts (pizza servcies
) and you want to determine the optimal one (=the one who can serve you fastest at your given destination location). Shape: "many to one" - rectangular shape, not neccesarily squared - Reference dima (EWS): just want to keep the driving times and distances from all your offices, factories, hubs to all customers and then retrieve it later when needed? Sounds like a reference distance matrix which can be persisted on the server and is then extended whenever needed (new office, new customers). Shape: depends. Sometimes you only need the relation from N offices to M customers? "N to M". If you need both directions? "M to N" + " N to M". Want to consider distances/traveltimes between all involved objects? "M+N to M+N"
- A distance matrix contains driving times and distances. With xServer2 we can also store toll costs. Not part of a dima: routing polygons, itinaries. These objects are usually created once the distance matrix core purpose (e.g. sequencing) is processed and a specific sequence needs to be displayed/reported.
- All relations within a specific dima are based on the same routing options.
- A dima is not necessarily square. Check the stories above.
- A dima shape is subject to change. You can add further locations if you want.
- Lifecycle: depending on your usecase a dima may be destroyed short after it's creation, e.g. after a dispatchin session. Or it can be kept for on-going usage (e.g. reference dima).
- The content of a DIMA is map-dependant. You may have to recreate a distance matrix after a map update.
Best regards and get into 2021 healthy and wealthy,
Bernd
