the usecase of last mile delivery occurs quite often and though I recommend to check a concrete scenario 1:1 with your local technical counterpart here's a quick guide towards what objects might be relevant. If this approach of a description is successful we may add further usecases
If the following story doesn't match your own expectation treat it as a beginning. Get back to us to check how we can align it to your requirements.
Here we go - let's start with the rough story from a usecase perspective:
- Input situation: central depot and several delivery locations
There you go - let's model this with the xTour2 API. The objects we need for this are:
- Imagine a central depot where all the parcels are located and ready for processing. You know the shipping addresses.
- Optional: the weight and dimensions of each parcel. Maybe also some service level based "deliver before HH:MM" constraints.
- To fullfill the orders you have a fleet of vehicles (Heterogeneous? Homogeneous?) with specific capacities
- and a team of drivers.
- Furthermore there are some additional constraints such as "drivers should not work more than hh hours..."
- Though we can also deal with equipment / skill.sets let's just ignore this for the beginning.
- The core challenge in one sentence: determine the assignment of parcels to vehicles/drivers and the delivery sequence. Ensure that all constraints are considered. I assume that we plan everything from scratch - so there are neither initial assignments nor sequences.
- The required method from the xTour2 API is a PlanToursRequest.
- For each destination (or pickup address for returns) we need a location of type CustomerSite. Usually a CustomerSite per (x,y) is sufficient. You may need two separated CustomerSites for the same (x,y) if two orders have to be shipped to the same address but within independent opening hours (driven by the SLA).
- Furthermore we need a location of type Depot.
- Next thing to check is the orders. Usually we would need PickupDeliveryOrders which means there's a unique pickup and a unique delivery location and you can refer to the location IDs provided in the objects mentioned above. For a regular shipping the pickupLocationId is the Depot's ID and the deliveryLocationId is the CustomerSite's ID. For returns it is vice versa. At this step you could already mention the quantity of a parcel if this information is available. Furthermore y<ou can specify how much time is required for the picking or delivery.
- Next object category is the Fleet. In xTour 2 we separate the drivers from the vehicles. If your fleet is based on a homogenous type of vehicles you can just create a single vehicle and specify a number of IDs that reflects the size of the fleet. If your fleet is heterogeneous you need to define a Vehicle per category and then define the number of vehicles per category.
- For the vehicles you have to specify the startLocationId and the endLocationId which is probably just the the Depot's ID.
- At this moment you can also specify the loading capacities of a vehicle category which will be used as a constraint that ensures that a vehicle is not overloaded at a time. Some parcel delivery scenarios define a absolute maximum number of parcels. Others define the mass of each parcel (if available) and limit the loading capacities as a maximum mass of parcels at a time.
- Be aware that the distance calculation o f the required distance matrix (homogeneous fleet) or even distance matrices (hmogeneous fleet) has to be created in advance through the xDima API (e.g. through CreateDistanceMatrixRequest). The IDs of those distance matrices have then to be mentioned per Vehicle.
- The result of the planning is based on routed distance matrices though the map connects the orders through airline. Usually this visualization is sufficient for a dispatcher and shows the sequence of the stops in the output.
- If you want to display the precise geometries of the routing polygons after the optimization call you can process each tour/trip through xRoute to get the geometries.
- InputPlan: as we plan from scratch this parameter remains empty (null).
- Next core object: PlanToursOptions defines the planning horizon (e.g. 1.1.2020 06:00 - 18:00). As a CalculationMode you can choose between Quality (production), Standard/Performance (Tests) or AVOID_INTERSECTIONS. In the TourRestrictions you can specify some more constraints such as maximumTravelTimePerTour or the drivers break- and rest rules. Constrains such as "singleStopPerCustomerSite" are available to prevent the algrithm from creating structures you'd likje to avoid (e.g. customer get's two independent visits by two drivers at the same day).
- DistanceMode: if you want to optimize a large number of hundreds or even thousands of deliveries you need to define your understanding of driving time and distance. While you could work with DirectDistance in a proof of concept it is more complicated in a production case. For a real usage you should apply ExistingDistanceMatrix for homogeneous fleets or ExistingDistanceMatrixPerVehicle for a heterogeneous fleet. In the later case you need to prepare a distance matrix for each vehicle category.
- The last paramezter for this method of PlanToursRequest is the storeRequest. If you wish to manipulate the output of the request through the ChangeTours call afterwards you have to set storeRequest to TRUE, otherwise FALSE applies.
So this is a long story - I know. Let's give it a try - get back to me if needed.
Bernd
PS: Both tour results are equal - just the visualization differs!
