The samples are based on
- 300 sample customers located in a specifc region of Germany - the component works fine with thousands or even hundred thousand of objects. The more objects you plan, the longer it takes. It might also require an additional solver called GUROBI.
- I applied airline distances for the examples because it is more intuitive. The API works fine with routing DIMAs, too and this is recommended for a production.
- There are two major object categories. The first one is "the location" which knows (x,y) and also a value that is called "activity" (>0).
- The sample customers. In this picture / first scenario each customer has an activity of "1". Therefore all icons are displayed with an equal size.
Where is the best position to serve all the customers from?
- The first output: the API tells you the position of this center of gravity. It is not just located in the geographic center of all the customers but a bit left because the customers are more dense in the west.
Where is the best position to serve all the customers from?
- Same question, but different output because the input is different. The icon sizes in the map show that some customers have a bigger activity compared to others. I created some major customers with a very big activity in the west: Therefore the center of gravity is again shifted to the west.
What if I do not seek a single center of gravity for a single area but 4 different centers for 4 new territories?
- In this next example the total number of requested centers is not 1 but 4. As you can see on the upper chart in the right: all aggregated activities in a specific area have almost same values (about 2% difference). Though the red area has the most assigned customers (77) it's assigned activity is the minimum out of the 4 regions (24.6%).
- The next few scenarios will handle the four predefined territory centers (blue pins). The centers are fixed - I want the API to assign the customers by applying the compactness and the equal total activity per customer.
- Each area is compact, each total activity is almost 25% but as two of the fixed input centers are locetd very close one of the centers is placed at the border of its territory.
- Here I provided 4 input centers but requested 5 output clusters so the API decided where to place the new 5th. center (black)
- Lets go back to "number of input clusters == number of output clustere". With this example I also mentioned that the balance between the total activities is no longer set to "same total activity for all centers": I predefined that the center in the NorthEast has 4 times more ressources than the blue one (Southwest). And RED and GREEN have 2 times the capacity of BLUE. As a consequence in this output the BLACK area is much bigger than GREEN and RED and finally the BLUE area is the smallest one.
- In this next example I defined the input clusters "capacities" as "absolute. This means that for each center I specify a maximum quantity and this leads to some new effect: as the sum of the 4 capacities is less than the total activity of all customers together the output returns some customers unassigned (west and south). Anyhow the balance between the assigned territories is still scaled.
- In this example I started with 4 input centers and asked for "which ones aren't needed if I need 2 in the output?". I also mentioned that NW (=blue) is mandatory while the other three input centers are candidates for the sacrifice. As you can see from the blue pin (south west/south east): these centers are not part of the result (no pyramids).
They have been chosen as "least needed". This is useful if you have existing centers (predefined) and several candidates for new centers to be opened.
