Route Optimization Minimize Crossing

Requires Route Optimization v3 - POST /api/v2/optimizations/scheduled

The optional minimizeCrossing parameter tells the optimizer to order each route's stops so it crosses main roads or rivers as few times as possible. This cuts down on back-and-forth travel and makes routes easier to drive, though total distance or time may be slightly higher in some cases. It's a preference, not a strict rule, so routes still cross when needed. It only changes the order of stops within a route, not which tasks each driver gets. If you leave it out, optimization works the same as today.

Orgs can set a default minimizeCrossing value on their route optimization profile on the Organization level instead of sending it on each request. The default applies to every driver, vehicle, service area, and on-demand optimization that doesn't set its own value. It accepts the same two string values.

NameTypeDescription
minimizCrossingstringOptional, default is null and will have no effect. Only main_road or rivers are acceptable values with exact spelling. If provided null, the request will produce an error.
{ 
	"tasks": [...], 
	"teams": [...], 
	"minimizeCrossing": "rivers" 
}

Route Optimization Behaviour

  • Which value applies: If the request includes minimizeCrossing, that value is used. If not, the org's route optimization profile default is used. If neither is set, routes have no crossing preference, same as today.
  • Applies to all job types: Scheduled driver, vehicle, and service area optimizations, on-demand optimizations, and re-optimizations all use it. (This is different from clusteringLevel, which only applies to scheduled optimizations.)
  • A preference, not a rule: A route can still cross a main road or river if that's the only way to reach its stops, or if avoiding the crossing would cost too much. No error or flag is returned when this happens. To strictly keep routes inside an area, use boundaries instead.
  • Re-optimization: The re-optimization uses the same value the original optimization ran with, whether it came from the request or the profile at that time. Any value sent on the re-optimization request is ignored, and the profile default isn't checked again.
  • Nothing set anywhere: Routes are ordered the same as today (backward compatible).