Route Optimization Boundaries

The boundaries parameter can be set as a default area profile on an Organization level where by all Route Optimization will use this boundarie when set as default. However, this cannot be used in combination with Service Area type of optimization.

This optional boundaries parameter submitted at per RO-level will overwrite the Organization level setting and lets customers keep route optimization inside one or more geographic areas defined in the request. When boundaries are set, and included in the request, the optimization will only consider tasks that are inside of the boundaries. Any tasks that are outside of the boundaries is not considered.

This can be used on the scheduled-optimization request, for driver and vehicle optimizations and for on-demand optimizations jobType: "ON-DEMAND").

Name	Type	Description
boundaries	array of object	The boundaries object contains a `name` and an `polygon` array that is similar to geojson and must have both fields in order to work. Accepts 1 to 100 objects.

The following fields are in a boundaries object

Name	Type	Description
name	string	Required. Can't be empty or start/end with a space. Any characters are allowed. Must be unique within the request. Uniqueness ignores capitalization, spacing, and separators (space, `-`, `_`, `:`), so `"North Bay"` and `"north-bay"` count as the same name.
polygon	array of latitude and	Required. At least 3 `{ "lat": number, "lon": number }` points, listed in order around the area. `lat` must be between -90 and 90, and `lon` between -180 and 180. \|

"boundaries": [
  {
    "name": "SF North",
    "polygon": [
      { "lat": 37.79, "lon": -122.42 },
      { "lat": 37.79, "lon": -122.38 },
      { "lat": 37.81, "lon": -122.38 },
      { "lat": 37.81, "lon": -122.42 },
      { "lat": 37.79, "lon": -122.42 }
    ]
  }
]

{ 
  "tasks": [...], 
  "teams": {...}, 
  "boundaries": [ 
      { 
          "name": "SF North", 
          "polygon": [...] 
      } 
  ] 
}

Boundaries behaviours

Which boundaries apply: If the request includes boundaries, those are used and fully replace the profile's (they aren't merged). If the request doesn't include them, the org's route optimization profile default is used. If neither is set, there are no restrictions, same as today.

What boundaries limit: Only which tasks a vehicle can be assigned. They don't limit the path a driver takes between stops, which can go outside the area.

Shared by all drivers: Every driver or vehicle type in the run gets all of the boundaries and can be assigned tasks in any of them, so together they act as one combined area. Boundaries can't be assigned to specific drivers or vehicles yet. For example, with "North" and "South" boundaries, any driver in the run can get tasks in either one. To keep a group of drivers in one area, run a separate optimization for them using only that area's boundary.

Tasks outside the boundaries: These are left unassigned in the result. All other tasks are optimized as usual.

On-demand, driver already has a stop outside the boundaries: Existing stops stay locked to their driver by default. If a driver's current route has a stop outside every boundary, that driver is left out of the run and keeps their route unchanged, and the remaining drivers are still optimized. If no other driver is available, the optimization fails with an error that names the driver and the stop. New tasks are never assigned outside the boundaries.

Re-optimization: Boundaries aren't applied when re-optimizing a route plan, even if the original optimization used them.

Nothing set anywhere: No restrictions. Optimization works the same as it does today (backward compatible).