PTV Group - Logistics Forum

These days a client approached me with some strange result behaviour in xcluster2.planClusters: he compared the output of two requests which only differed in the parameter PlanClustersOption.reduceOverlappingInClusters and in his case the additional check caused the engine to return poorer results than without it (poorer: more overlaps).

We analyzed this behaviour and here's some valuable info:
What happens when you use reduceOverlap?

• Border locations/customers are identified. These are locations that have "more" neighboring locations from other clusters than their own cluster. See this pic for example:

  

  Sample of overlapping / non overlapping clusters

• All other locations/customers are pre assigned to their clusters but the border locations are set free.
• Imbalance tolerance is increased and a re-assignment of border customers is attempted based solely on travel times or distances. Activities are ignored.
• This makes some of the border locations change clusters. But these changes are very sensitive to the parameters.
• For this example CBC obtains a sub-optimal re-assignment, which (weirdly) yields the older or existing clustering.
• GRB claims to find (mathematically speaking) a better re-assignment of border locations. But this increases the overlaps in this and some other cases.
• With GRB, if you set imbalanceTolerance to 14% or more, you will get a "better" re-assignment, that is, the older or existing clustering.

So the reduceOverlap process hasn't been tuned for all instances and scenarios. Why? Because usually the result without reduceOverlap is pretty good, as in it does not contain any overlaps.

Thanks to Nitin for the details!

Bernd